Processamento de dados · tema 6 de 30
Processamento batch e stream
35 min · 2 vídeos · 12 cards · 2 drill
Por que cai
É a pergunta de cenário mais frequente da sabatina: dado um caso do banco, batch ou stream? Quem responde 'stream porque é tempo real' entrega que nunca operou um pipeline; quem coloca latência exigida, custo e complexidade lado a lado mostra que já tomou essa decisão.
Pré-teste · 1 de 2
responda antes de verUm pipeline agrega gasto por cartão em janelas de 5 minutos. Ele usa o horário em que o evento chegou ao Kafka. Qual é o risco?
Vídeo · português · 7 min
Em uma frase
Batch processa um conjunto fechado, com começo e fim conhecidos; stream processa um fluxo sem fim, em que você decide com o que já chegou e nunca viu tudo.
A diferença real não é velocidade
Muita gente resume batch como "lento" e stream como "rápido". A diferença estrutural é outra: em batch você sabe onde o dado termina, em stream não. Isso muda tudo. Em batch dá para ordenar, agrupar e recalcular o conjunto inteiro. Em stream você precisa decidir quanto tempo espera antes de fechar uma conta que talvez ainda receba um registro atrasado.
| Aspecto | Batch | Stream |
|---|---|---|
| Fronteira do dado | Lote fechado: o arquivo do dia, a partição do mês | Fluxo aberto: nunca acaba |
| Latência típica | Minutos a horas | Milissegundos a segundos |
| Custo | Paga o cluster durante a janela de execução | Paga cluster ligado o tempo todo, mais estado |
| Complexidade | Baixa: rodou, terminou, dá para reexecutar | Alta: estado, atraso, ordem, plantão |
| Reprocessar | Simples: aponta para a partição e roda de novo | Difícil: precisa reler o tópico e refazer o estado |
| Exemplo no banco | Reporte regulatório mensal, recálculo de limite | Score de fraude na autorização, alerta de saldo |
Micro-batch: o meio de campo
O Spark Structured Streaming, por padrão, não processa evento a evento. Ele agrupa a chegada em micro-lotes de alguns segundos e roda batch em cima. Você ganha o modelo mental de batch com latência de segundos, e paga com um piso de latência que não desce a milissegundos. Flink, por outro lado, processa registro a registro.
Isso é uma resposta de sabatina, não trivialidade: se o negócio pede resposta em duzentos milissegundos, micro-batch não entrega.
Event time e processing time
event time— O momento em que o fato aconteceu: a hora da compra registrada pela maquininha. processing time— O momento em que o motor viu o evento.Os dois relógios divergem sempre que há fila, retentativa, agência sem rede ou reprocessamento. A consequência prática é dura: agregação por processing time não é reproduzível. Rode o mesmo histórico duas vezes e os números da janela mudam, porque a chegada mudou. Em banco, isso significa um fechamento que não bate com o de ontem e uma conversa desagradável com a área de controles.
Por isso a regra é agregar por event time. E aí aparece o problema seguinte: se o evento pode chegar atrasado, quando você fecha a janela?
Watermark e dado atrasado
O watermark é o limite de atraso que você aceita. Declarar watermark de trinta minutos é dizer: "não espero mais evento com event time anterior a agora menos trinta". Com isso o motor fecha a janela, emite o resultado e libera o estado.
Evento que chega depois do watermark não deve sumir. Mande para uma trilha separada e tenha um job batch de reconciliação que recalcula a janela com tudo.
Garantias de entrega
- 1at-most-once: commita o offset antes de processar. Em falha, perde o evento.
- 2at-least-once: processa e depois commita. Em falha, reprocessa e duplica.
- 3exactly-once: offset, estado e escrita no destino avançam de forma consistente.
Exactly-once é caro porque não é uma propriedade do transporte: é uma propriedade do conjunto transporte mais estado mais destino. Exige checkpoint, armazenamento de estado durável e um destino transacional ou idempotente. Cada uma dessas peças custa latência, dinheiro e um ponto a mais de falha.
Como escolher
Comece pelo prazo em que a decisão perde valor. Se o consumidor age em segundos — bloquear cartão, alertar saldo, atualizar extrato no app — é stream. Se o consumidor age em horas ou dias, e o resultado precisa ser auditável — reporte ao regulador, fechamento, treino de modelo — é batch.
A resposta madura costuma ser as duas: stream para a decisão em linha e batch para reprocessar, recalibrar e corrigir o que o stream errou.
Se quiser outro ângulo
Como cai na sabatina
“Detecção de fraude em cartão: batch ou stream? Quais os trade-offs?”
Erros comuns
- Dizer que stream é sempre melhor porque é tempo real. Stream cobra cluster ligado 24 por 7, estado para manter, plantão e reprocessamento difícil. Se a decisão só é tomada no dia seguinte, você pagou por latência que ninguém consome.
- Confundir micro-batch com stream evento a evento. Spark Structured Streaming agrupa a chegada em micro-lotes de segundos; Flink processa registro a registro. Isso muda o piso de latência que você pode prometer para o negócio.
- Ignorar a diferença entre event time e processing time. Agregar pelo horário de chegada faz a mesma janela dar resultado diferente a cada execução, e em banco isso vira número de fechamento que não bate duas vezes.
- Prometer exactly-once como se fosse uma flag. Ponta a ponta ela exige checkpoint, estado durável e destino idempotente ou transacional. Sem controlar o destino, o que você tem é at-least-once com deduplicação.
- Esquecer o dado atrasado. Sem watermark o estado cresce sem limite; com watermark curto demais você descarta transação legítima que chegou fora de ordem.
- Tratar batch como coisa antiga. Fechamento contábil, reporte regulatório e treino de modelo continuam em batch por bons motivos: lógica simples e resultado reproduzível.
Flashcards
Card 1 de 12
0 certos · 0 a reverDrill
Batch ou stream?
Para cada caso do banco, decida a arquitetura e diga em uma frase qual é o requisito que manda na decisão. Responda antes de abrir.
1.Aprovar ou negar uma autorização de cartão com base em score de fraude, com orçamento de 200 ms.
2.Relatório de operações suspeitas enviado ao regulador todo dia 5.
3.Alertar o cliente no app quando o saldo fica negativo.
4.Recalcular o limite de crédito de toda a base uma vez por mês, com um modelo que precisa dos 24 meses de histórico.
5.Atualizar o extrato do app com o PIX que o cliente acabou de receber.
6.Carregar diariamente o cadastro de clientes vindo do core bancário para a zona bronze do lake.
Drill
Que garantia de entrega esse desenho oferece?
Classifique cada desenho pela garantia efetiva que ele dá ao consumidor final, não pela que o time gostaria de ter.
1.Consumidor commita o offset no Kafka assim que lê a mensagem e só depois grava no destino.
2.Consumidor grava no destino e só depois commita o offset, sem chave de deduplicação.
3.Structured Streaming com checkpoint e escrita em tabela Delta usando MERGE pela chave da transação.
4.Job que lê o tópico do zero toda vez e faz append em arquivo Parquet.
Quiz · 1 de 2
Por que exactly-once ponta a ponta é caro?
Explique para um gerente
Explique para o gerente de prevenção a fraude por que bloquear o cartão durante a compra custa muito mais caro que o relatório de fraude do dia seguinte.
Responda em voz alta antes de seguir. Se travar numa palavra técnica, é sinal de que ainda não entendeu essa parte.
Perguntas de sabatina deste tema
- · Detecção de fraude em cartão: você faria em batch ou em stream? Quais os trade-offs?
- · Seu pipeline de stream agrega PIX recebido por conta em janelas de 10 minutos. Uma agência ficou sem rede por meia hora e os eventos chegaram todos juntos depois. O que acontece e como você trata?
Para ir além