Streaming de dados vs processamento em lote

Você montou um Kafka para gerar um relatório diário

Vi esse filme mais de uma vez: o time precisava de um relatório que rodava uma vez por dia, de madrugada, e alguém decidiu que a solução "moderna" era um pipeline de streaming. Kafka, consumidores, gerenciamento de offset, deduplicação, tratamento de evento atrasado — toda a artilharia. Seis meses depois, três engenheiros gastavam metade do tempo cuidando da infraestrutura de streaming para entregar um número que um cron com uma query teria produzido em quinze minutos. A latência exigida era de horas. Eles construíram para milissegundos.

Este texto compara processamento em lote (batch) e streaming de dados, e ajuda a escolher sem se deixar levar pela moda. Antes, um pré-requisito prático dos dois mundos: processar volume sem estourar a RAM — sobre isso vale ler como lidar com arquivos grandes sem estourar a memória.

O que é processamento em lote

Batch opera sobre dados limitados (bounded): um conjunto que tem começo e fim conhecidos. Você junta os dados de um período, roda o processamento de uma vez, e produz o resultado. É o modelo do relatório noturno, do ETL agendado, do fechamento mensal.

As propriedades que importam: alta vazão (throughput), porque você otimiza para processar grandes volumes de uma vez; simplicidade, porque o dado está parado e você sabe exatamente quanto há; e latência alta, medida em minutos ou horas, porque o resultado só sai quando o lote inteiro termina. Você troca tempo de resposta por simplicidade e eficiência. Para um relatório que ninguém olha antes das nove da manhã, essa troca é ótima.

00:00  cron dispara
00:01  lê todos os pedidos de ontem (conjunto fechado)
00:14  agrega, calcula, grava o resultado
00:15  pronto — latência: ~9 horas até alguém ler

O que é streaming de dados

Streaming opera sobre dados ilimitados (unbounded): um fluxo contínuo que nunca "termina". Eventos chegam, são processados um a um (ou em janelas pequenas) e o resultado é atualizado em tempo quase real. É o modelo da detecção de fraude, do dashboard ao vivo, do alerta que precisa disparar agora.

A vantagem é a baixa latência: o resultado acompanha o evento. O custo é que streaming é genuinamente mais difícil, e a dificuldade não é acidental, é da natureza do problema:

• Ordem. Eventos podem chegar fora de ordem. O clique que aconteceu antes pode ser processado depois.
• Eventos atrasados (late events). Um evento de dez minutos atrás chega agora, depois que você já fechou a janela daquele período. O que fazer com ele?
• Exactly-once. Garantir que cada evento seja contado uma única vez, mesmo com falhas e reprocessamento, é um dos problemas mais espinhosos de sistemas distribuídos.

Nenhum desses problemas existe no batch, porque no batch o conjunto está fechado e parado.

Quando cada um se encaixa

A pergunta certa não é "qual é melhor", é "qual latência o negócio realmente exige". A resposta dita a escolha:

• Batch para relatórios noturnos, ETL, fechamento contábil, treino de modelo de ML, faturamento mensal, qualquer coisa em que "amanhã de manhã" ou "em uma hora" é resposta aceitável.
• Streaming para detecção de fraude, dashboards ao vivo, alertas operacionais, recomendação em tempo real, monitoramento — casos em que um resultado com dez minutos de atraso já não vale nada.

O teste mental que eu uso: se o resultado ficar pronto uma hora depois, alguém perde dinheiro ou toma uma decisão errada? Se não, é batch. Detecção de fraude com uma hora de atraso é inútil; relatório de vendas com uma hora de atraso é exatamente o que se espera.

O imposto de complexidade do streaming

Aqui vem a opinião que costuma incomodar: a maioria dos times parte para streaming muito antes de precisar. O streaming é sedutor — soa moderno, escalável, em tempo real — e por isso entra na decisão de arquitetura por status, não por requisito.

O problema é que streaming cobra um imposto de complexidade permanente. Você passa a lidar com gerenciamento de estado, checkpoints, watermarks, janelas, garantias de entrega, reprocessamento — uma classe inteira de bugs que simplesmente não existe no batch. Cada uma dessas peças é um lugar onde o sistema pode falhar de madrugada. Um pipeline batch que falha você re-roda; um pipeline de streaming que falha exige entender em que offset parou, se houve duplicação e como recuperar o estado.

Minha regra: comece com batch. Migre para streaming quando a latência batch comprovadamente custar dinheiro ou quebrar um requisito, não quando alguém achar que seria legal. Streaming é uma ferramenta poderosa para o problema certo e um peso morto para o problema errado.

Micro-batching: o meio-termo

Entre os dois extremos existe o micro-batching: processar lotes pequenos em intervalos curtos, a cada poucos segundos, em vez de evento a evento. Spark Structured Streaming popularizou a abordagem. Você ganha latência de segundos — boa para a maioria dos casos "quase em tempo real" — sem pagar o custo total da complexidade de um streaming evento a evento puro.

Para muitos dashboards e métricas operacionais, latência de cinco segundos é indistinguível de tempo real para o usuário, e o micro-batching entrega isso com um modelo mental bem mais próximo do batch. Antes de adotar streaming puro com todas as suas garantias caras, pergunte se um lote a cada poucos segundos não resolve. Na prática, resolve em mais casos do que se imagina.

Perguntas frequentes

Streaming sempre tem latência menor que batch?

Em geral sim, essa é a razão de existir do streaming. Mas a latência menor vem com um custo de complexidade que nem sempre se justifica. Se o negócio tolera minutos ou horas, a latência menor do streaming não compra nada de valor e você paga o imposto à toa.

Dá para começar com batch e migrar para streaming depois?

Dá, e costuma ser o caminho mais sensato. Comece com batch, prove que a latência é um gargalo real e só então migre. Reescrever um pipeline batch funcional como streaming é mais barato e seguro do que debugar um streaming prematuro que você nunca precisou.

O que torna o exactly-once tão difícil no streaming?

Porque em um sistema distribuído com falhas, garantir que cada evento seja processado uma única vez exige coordenar estado, offsets e idempotência diante de reinícios e reprocessamento. No batch o conjunto está fechado, então contar uma vez é trivial. No fluxo contínuo, falhas parciais e reentregas tornam isso um problema fundamental.

Micro-batching é batch ou streaming?

É um meio-termo. Tecnicamente processa lotes pequenos em intervalos curtos, com um modelo mental próximo do batch, mas entrega latência de segundos como um streaming. Para a maioria dos casos "quase em tempo real", é o ponto de equilíbrio entre simplicidade e baixa latência.

Como decidir na prática

Batch e streaming não competem pelo mesmo problema — eles resolvem problemas com requisitos de latência diferentes. Batch entrega simplicidade e vazão para dados limitados quando minutos ou horas bastam; streaming entrega baixa latência para fluxos contínuos quando o atraso custa dinheiro, ao preço de uma complexidade real. Não escolha pela moda: defina a latência que o negócio exige e deixe ela decidir. Na dúvida, comece com batch, considere micro-batching como meio-termo, e só vá para streaming puro quando o requisito provar que precisa.