Durante décadas, processar dados significou rodar um job toda madrugada sobre o que aconteceu no dia anterior. Hoje, muitos negócios não podem esperar até amanhã: detecção de fraude, recomendação, painéis ao vivo. Entender a diferença entre processamento em lote e em tempo real — e as ferramentas como o Kafka — é conhecimento central de um profissional sênior de dados.
Batch: processar em lotes
No batch, os dados são acumulados e processados em blocos, em intervalos definidos — de hora em hora, uma vez por dia. É o modelo dos pipelines tradicionais. Tem latência alta (você só vê o resultado no próximo ciclo), mas é simples, barato e fácil de reprocessar: se algo der errado, roda o lote de novo.
Streaming: evento a evento
No streaming, cada evento é processado assim que chega — uma compra, um clique, uma leitura de sensor. A latência é de segundos ou menos, permitindo reações imediatas. Em troca, o sistema é mais complexo: precisa rodar continuamente, lidar com eventos fora de ordem e atrasados, e nunca "termina".
| Aspecto | Batch | Streaming |
|---|---|---|
| Unidade | Lote de dados | Evento individual |
| Latência | Alta (minutos a horas) | Baixa (segundos) |
| Complexidade | Menor | Maior |
| Reprocessamento | Simples (roda de novo) | Mais difícil |
| Bom para | Relatórios, cargas diárias | Alertas, dashboards ao vivo |
O log de eventos append-only
O coração do streaming moderno é um log append-only: uma sequência de eventos à qual você só adiciona no fim, nunca altera o passado. Pense num extrato bancário — cada transação é uma nova linha; você nunca apaga uma anterior. Esse log durável é o que permite reler eventos e que vários consumidores leiam o mesmo fluxo de forma independente.
Kafka: tópico, partição, consumer
O Kafka é a implementação mais difundida desse log. Três conceitos bastam para começar:
- Tópico — um canal nomeado de eventos ("pedidos", "cliques").
- Partição — cada tópico é dividido em partições para escalar (a mesma ideia de particionamento); a ordem é garantida dentro de uma partição.
- Consumer — quem lê o tópico, acompanhando sua posição (offset) para saber até onde já processou.
Produtores ──▶ Tópico "pedidos"
├─ Partição 0: [e1][e4][e7]──▶ Consumer A
├─ Partição 1: [e2][e5][e8]──▶ Consumer B
└─ Partição 2: [e3][e6][e9]──▶ Consumer C
(cada evento append-only, ordem por partição)Janelas de tempo
Em um fluxo infinito, perguntas como "quantas vendas no último minuto?" exigem recortar o tempo em janelas. As mais comuns: tumbling (janelas fixas e sem sobreposição, como "cada 1 minuto") e sliding (janelas que deslizam e se sobrepõem). É assim que você calcula métricas contínuas sem esperar o fluxo "acabar" — porque ele nunca acaba.
Semânticas de entrega
Em sistemas distribuídos, mensagens podem se perder ou se duplicar. Há três garantias possíveis:
- At-most-once (no máximo uma vez) — pode perder eventos, nunca duplica. Rápido, mas arriscado.
- At-least-once (ao menos uma vez) — nunca perde, mas pode duplicar. O mais comum; exige que o consumidor seja idempotente para tolerar repetições.
- Exactly-once (exatamente uma vez) — cada evento processado uma única vez. É a garantia ideal e a mais cara de implementar.
A pergunta não é "batch ou streaming é melhor", e sim "quão fresco o dado precisa ser para gerar valor?". Se a decisão pode esperar a madrugada, batch é mais simples e barato. Se cada segundo conta, paga-se o preço do streaming.
É comum em entrevista pedirem para explicar at-least-once versus exactly-once e por que idempotência importa em streaming. No dia a dia isso aparece quando você decide se uma feature nova precisa de tempo real de verdade ou se um batch de hora em hora já resolve — e essa escolha define muito do custo e da complexidade do sistema.
Conclusão
Batch processa lotes com latência alta e simplicidade; streaming processa evento a evento com baixa latência e mais complexidade. O log append-only — concretizado no Kafka com tópicos, partições e consumers — é a fundação; janelas recortam o tempo; e as semânticas de entrega definem que garantias você tem. Saber escolher entre os dois mundos, pelo frescor que o negócio exige, é o cerne da decisão.
For decades, processing data meant running a job every night over what had happened the day before. Today, many businesses can't wait until tomorrow: fraud detection, recommendations, live dashboards. Understanding the difference between batch and real-time processing — and tools like Kafka — is core knowledge for a senior data professional.
Batch: processing in chunks
In batch, data is accumulated and processed in blocks, at set intervals — hourly, once a day. It's the model of traditional pipelines. It has high latency (you only see the result in the next cycle), but it's simple, cheap and easy to reprocess: if something goes wrong, you just run the batch again.
Streaming: event by event
In streaming, each event is processed as soon as it arrives — a purchase, a click, a sensor reading. Latency is seconds or less, allowing immediate reactions. In exchange, the system is more complex: it must run continuously, deal with out-of-order and late events, and it never "finishes".
| Aspect | Batch | Streaming |
|---|---|---|
| Unit | Batch of data | Individual event |
| Latency | High (minutes to hours) | Low (seconds) |
| Complexity | Lower | Higher |
| Reprocessing | Simple (run again) | Harder |
| Good for | Reports, daily loads | Alerts, live dashboards |
The append-only event log
The heart of modern streaming is an append-only log: a sequence of events to which you only add at the end, never changing the past. Think of a bank statement — each transaction is a new line; you never erase a previous one. This durable log is what lets you re-read events and lets several consumers read the same stream independently.
Kafka: topic, partition, consumer
Kafka is the most widespread implementation of this log. Three concepts are enough to get started:
- Topic — a named channel of events ("orders", "clicks").
- Partition — each topic is split into partitions to scale (the same idea as partitioning); order is guaranteed within a partition.
- Consumer — whoever reads the topic, tracking its position (offset) to know how far it has processed.
Producers ──▶ Topic "orders"
├─ Partition 0: [e1][e4][e7]──▶ Consumer A
├─ Partition 1: [e2][e5][e8]──▶ Consumer B
└─ Partition 2: [e3][e6][e9]──▶ Consumer C
(each event append-only, order per partition)Time windows
In an infinite stream, questions like "how many sales in the last minute?" require slicing time into windows. The most common: tumbling (fixed, non-overlapping windows, like "every 1 minute") and sliding (windows that slide and overlap). That's how you compute continuous metrics without waiting for the stream to "end" — because it never ends.
Delivery semantics
In distributed systems, messages can get lost or duplicated. There are three possible guarantees:
- At-most-once — may lose events, never duplicates. Fast, but risky.
- At-least-once — never loses, but may duplicate. The most common; it requires the consumer to be idempotent to tolerate repeats.
- Exactly-once — each event processed a single time. It's the ideal guarantee and the most expensive to implement.
The question isn't "which is better, batch or streaming", but "how fresh does the data need to be to create value?". If the decision can wait until the small hours, batch is simpler and cheaper. If every second counts, you pay the price of streaming.
In interviews they often ask you to explain at-least-once versus exactly-once and why idempotency matters in streaming. Day to day, this shows up when you decide whether a new feature truly needs real time or whether an hourly batch already does the job — and that choice defines much of the system's cost and complexity.
Conclusion
Batch processes chunks with high latency and simplicity; streaming processes event by event with low latency and more complexity. The append-only log — made concrete in Kafka with topics, partitions and consumers — is the foundation; windows slice time; and delivery semantics define which guarantees you get. Knowing how to choose between the two worlds, based on the freshness the business requires, is the crux of the decision.