Em streaming, a hora passou. Os dados ficaram prontos?

O Pinterest apresentou um mecanismo para sinalizar quando partições alimentadas continuamente por CDC estão suficientemente completas para consumo analítico.[14] Em vez de usar apenas o término do intervalo do relógio, a solução acompanha o progresso do tempo dos eventos.[14] O problema descrito é que dados atrasados podem chegar depois de o período aparentemente ter terminado.[14]

Minha leitura é que essa é uma discussão de contrato, não apenas de streaming. Um consumidor precisa saber o que “pronto” significa antes de gerar um relatório, concluir uma conciliação ou disparar outra automação.

O que muda para quem desenvolve

A plataforma descrita combina Kafka, Flink, Spark e Iceberg, coletando estatísticas de tempo do evento nos checkpoints do Flink.[14] Um t-digest representa a distribuição de forma compacta nos metadados do snapshot Iceberg.[14]

Após o commit, o sistema calcula um watermark de finalização com checkpoints recentes e o publica como propriedade da tabela.[14] A política padrão considera o menor tempo observado em uma quantidade configurável de commits, enquanto políticas baseadas em percentis podem reduzir atraso aceitando menor completude.[14]

A consequência arquitetural, na minha leitura, é separar chegada dos dados e permissão de consumo. Recomendo que o consumidor consulte uma evidência explícita de prontidão, em vez de assumir que um horário agendado equivale a uma partição completa.

Como aplicar

Não comece copiando a infraestrutura. Monte um experimento pequeno com eventos que tenham dois horários: o do acontecimento e o da chegada. Use registros sintéticos, incluindo alguns entregues fora de ordem.

Defina uma regra de prontidão e produza o mesmo relatório de duas maneiras: encerrando pelo relógio e esperando o marcador escolhido. Compare quais eventos entram em cada resultado e quanto tempo cada versão demora a ficar disponível.

Depois envie um evento ainda mais atrasado. Escreva o comportamento esperado: recalcular o relatório, emitir uma correção ou manter uma versão com incompletude conhecida. O teste só está completo quando essa decisão também é verificável.

Em uma aplicação menor, recomendo avaliar um checkpoint explícito ou marcador transacional antes de adotar uma plataforma de streaming. O mecanismo escolhido deve comunicar o estado que o próximo componente precisa conhecer, sem exigir que ele deduza prontidão a partir de um job ou de um horário.

Cuidados e limites

O watermark descrito é monotônico: não retrocede quando aparece um registro atrasado.[14] Portanto, ele é um critério operacional de consumo, não uma promessa de que nenhum evento tardio existirá.[14]

Esse limite precisa aparecer na documentação da saída. Recomendo registrar a política de atraso tolerado e como corrigir resultados já consumidos. Sem isso, dois relatórios podem divergir e ninguém saber se houve erro ou apenas uma escolha diferente de completude.

A decisão não é eliminar toda espera nem esperar para sempre. É declarar qual atraso o produto aceita, qual dado pode faltar e o que acontece quando a realidade ultrapassa esse contrato.

Fonte

[14] Fonte: InfoQ. Publicação: 19/10/2026 às 11:37.