Escolher entre batch e streaming: latência exigida, tempo do evento e dados atrasados

O que é

Um job em batch lê uma entrada finita, normalmente um intervalo de agendamento, depois que esse intervalo terminou, e grava um resultado que pode ser recalculado a qualquer momento a partir da mesma entrada. Um job de streaming lê uma entrada sem fim. A documentação do Dataflow (citada) descreve essa entrada como uma coleção com um número potencialmente infinito de elementos por chave, de modo que agrupar apenas por chave é impossível e a agregação exige janelas (windows), watermarks e gatilhos (triggers). Um watermark é o limite a partir do qual o sistema espera que todos os dados de uma janela já tenham chegado; dados que chegam depois disso, com um timestamp dentro da janela, são dados atrasados (late data). A documentação do Flink (citada) distingue duas noções de tempo: o tempo de processamento (processing time), que é o relógio da máquina que executa o operador, é a opção mais simples e de menor latência, mas não é determinística, porque os resultados dependem da velocidade de chegada e de interrupções; e o tempo do evento (event time), que é o momento em que cada evento ocorreu no dispositivo que o produziu, dá resultados consistentes mesmo com eventos fora de ordem ou no reprocessamento do histórico, ao custo de esperar pelos retardatários, e só por um tempo finito, pois alguns elementos podem sofrer atrasos arbitrários.

Por que importa

A diferença não está na velocidade, mas na semântica. O total em batch de segunda-feira é definido pelas linhas presentes quando o job rodou; o total em streaming de segunda-feira é uma sequência de resultados provisórios que ainda podem mudar quando chegarem eventos atrasados, e o projeto precisa dizer se esses eventos são descartados, emitidos como correções ou ignorados. Equipes que adotam streaming para um dashboard atualizado de hora em hora pagam por estado, checkpoints e um job sempre ativo sem que ninguém aproveite a latência que compraram.

Como aplicar

• Parta do consumidor: defina a ação tomada com base no resultado e quanto tempo depois do evento ela precisa acontecer. Só uma reação em segundos até um minuto justifica um caminho de streaming; um relatório pode esperar o intervalo fechar.
• Se o streaming se justificar, use tempo do evento, defina explicitamente o atraso permitido (allowed lateness) e encaminhe os eventos atrasados para uma saída lateral (side output) consumida por uma correção em batch.
• Mantenha um caminho de reprocessamento em batch mesmo para resultados em streaming: ele é a referência para a exatidão dos resultados, a ferramenta de recuperação após um bug e o meio de fazer o backfill do histórico.
• Considere micro-batches (de minutos) antes de um motor contínuo; eles mantêm a semântica de batch com latência menor.

Armadilhas

Joins de streams mantêm estado durante a janela do join nos dois lados; janelas ilimitadas significam memória ilimitada. Uma saída exactly-once (exatamente uma vez) exige destinos (sinks) idempotentes ou transacionais, e não apenas uma configuração do motor. Duas respostas para a mesma métrica, uma em streaming e outra em batch, precisam ser conciliadas, ou os consumidores não confiarão em nenhuma delas.