Streaming vs batch processing: quando cada abordagem faz sentido

1. Fundamentos do Processamento de Dados: Batch e Streaming

O processamento de dados é o coração de qualquer sistema moderno de análise e tomada de decisão. Duas abordagens fundamentais dominam esse cenário: batch processing e streaming processing.

Batch processing (processamento em lote) opera sobre conjuntos de dados finitos e estáticos, processando grandes volumes de uma só vez. Caracteriza-se por alta latência (minutos a horas), alto throughput e processamento em janelas temporais definidas. Exemplo clássico: processar todas as transações do dia às 2h da manhã.

# Exemplo conceitual de batch processing com Apache Spark
# Processamento de logs de servidor em lote
spark.read.csv("hdfs://logs/2024-01-01/*.csv")
  .groupBy("status_code")
  .count()
  .write.mode("overwrite")
  .parquet("hdfs://relatorios/diarios/2024-01-01")

Streaming processing (processamento em fluxo) opera sobre dados em movimento contínuo, processando eventos individualmente ou em micro-lotes. Caracteriza-se por baixa latência (milissegundos a segundos), processamento contínuo e estado mantido em memória. Exemplo clássico: detectar fraudes em transações de cartão de crédito em tempo real.

# Exemplo conceitual de streaming processing com Apache Flink
# Detecção de anomalias em tempo real
DataStream<Transaction> transactions = env
  .addSource(new KafkaSource<>("transactions"))
  .keyBy(t -> t.getUserId())
  .window(TumblingEventTimeWindows.of(Time.minutes(5)))
  .process(new FraudDetector())

As principais características contrastantes incluem:
- Estado: batch é stateless (processa lotes independentes), streaming mantém estado entre eventos
- Janelas temporais: batch opera em janelas fixas (dia, hora), streaming em janelas deslizantes ou saltitantes
- Consistência: batch oferece consistência forte (ACID), streaming frequentemente usa consistência eventual
- Reprocessamento: batch reprocessa lotes inteiros, streaming reprocessa via replay de eventos

2. Casos de Uso Clássicos para Batch Processing

O batch processing brilha em cenários onde a latência não é crítica e o volume de dados é massivo.

ETL noturno e data warehouses: Relatórios financeiros, dashboards históricos e consolidação de dados de múltiplas fontes são exemplos perfeitos. Um banco processa milhões de transações diárias durante a madrugada para gerar extratos matinais.

# Pipeline ETL batch com Apache Airflow
with DAG('etl_financeiro', schedule_interval='0 2 * * *') as dag:
    extract = PythonOperator(task_id='extrair_dados', python_callable=extract_from_sources)
    transform = PythonOperator(task_id='transformar_dados', python_callable=transform_data)
    load = PythonOperator(task_id='carregar_warehouse', python_callable=load_to_warehouse)
    extract >> transform >> load

Processamento de grandes volumes estáticos: Logs de servidores web, arquivos CSV de milhões de linhas, imagens de satélite. Cenários onde o dado já existe e precisa ser processado uma única vez.

Modelos de machine learning treinados periodicamente: Modelos de recomendação, previsão de vendas ou classificação são treinados em lote semanalmente ou mensalmente, usando todo o histórico disponível.

3. Casos de Uso Ideais para Streaming Processing

Streaming processing é a escolha natural quando cada milissegundo importa.

Monitoramento em tempo real: Detecção de fraudes em transações financeiras, alertas de infraestrutura (CPU, memória, disco), sistemas de segurança cibernética. Cada evento pode ser crítico.

# Pipeline streaming com Apache Kafka e Flink
# Detecção de múltiplas tentativas de login em 1 minuto
DataStream<LoginEvent> logins = env.addSource(new KafkaSource<>("login_events"))
  .keyBy(e -> e.getUserId())
  .window(SlidingEventTimeWindows.of(Time.minutes(1), Time.seconds(10)))
  .apply(new CountWindowFunction())
  .filter(count -> count >= 5)
  .addSink(new AlertSink())

Aplicações interativas: Dashboards em tempo real, recomendações ao vivo em e-commerce, preços dinâmicos em marketplaces.

Pipelines contínuos: Dados de sensores IoT, logs de servidores em produção, feeds de redes sociais. O dado nunca para de chegar.

4. Trade-offs e Desafios de Cada Abordagem

Batch processing:
- Desafios: Complexidade de agendamento (janelas de processamento), alto custo de armazenamento intermediário (staging areas), dificuldade em reprocessamento incremental (precisa reprocessar tudo)
- Vantagens: Simplicidade de implementação, consistência forte, fácil depuração

Streaming processing:
- Desafios: Consistência eventual, gerenciamento complexo de estado, tratamento de dados fora de ordem (out-of-order), janelas temporárias que podem perder eventos tardios
- Vantagens: Baixa latência, processamento contínuo, capacidade de reagir instantaneamente

Comparação de custos: Batch tende a ser mais barato em infraestrutura (pode usar clusters spot, processamento em horários de menor custo), enquanto streaming requer clusters dedicados 24/7.

5. Arquiteturas Híbridas: Lambda e Kappa

Arquitetura Lambda: Combina camadas batch e streaming. A camada streaming fornece dados em tempo real (com possível imprecisão), enquanto a camada batch corrige e completa os dados históricos. Ambas as camadas são reconciliadas em uma camada de serving.

# Arquitetura Lambda simplificada
# Camada streaming (rápida)
stream_pipeline = KafkaSource() >> FlinkProcessor() >> SpeedLayer()

# Camada batch (precisa)
batch_pipeline = HDFSSource() >> SparkProcessor() >> BatchLayer()

# Camada de serving (reconciliação)
serving_layer = SpeedLayer().union(BatchLayer()) >> Database()

Arquitetura Kappa: Simplifica usando apenas streaming. Todo o processamento é feito em fluxo contínuo. O reprocessamento é feito via replay de eventos armazenados em um log imutável (como Kafka). Ideal quando a complexidade do Lambda não se justifica.

Quando optar por cada uma: Lambda para cenários com requisitos de precisão histórica e velocidade simultâneos; Kappa para equipes maduras em streaming e sistemas onde o replay de eventos é viável.

6. Critérios de Decisão: Como Escolher a Abordagem Correta

Critério Batch Streaming
Latência aceitável Minutos a horas Milissegundos a segundos
Volume de dados Muito alto (TB/dia) Alto (GB/s)
Padrão de consulta Relatórios programados Dashboards ao vivo
Maturidade da equipe Baixa a média Média a alta
Orçamento de infraestrutura Menor (uso intermitente) Maior (uso contínuo)

Análise prática:
- Latência: Se o dado precisa estar disponível em segundos → streaming. Se horas são aceitáveis → batch.
- Volume e velocidade: Picos de dados podem exigir streaming (buffer) ou batch (escalonamento).
- Padrões de consumo: Dashboards em tempo real exigem streaming; relatórios mensais são batch.
- Ecossistema tecnológico: Spark para batch, Flink/Kafka Streams para streaming, Airflow para orquestração híbrida.

7. Exemplos Práticos e Cenários do Mundo Real

Caso 1: Transações financeiras
- Streaming: Detecção de fraudes em tempo real (transações suspeitas bloqueadas em milissegundos)
- Batch: Relatórios de conciliação diária, auditoria mensal, modelos de risco treinados semanalmente

# Streaming: detecção de fraudes
transactions_stream
  .filter(t -> t.amount > 10000)
  .keyBy(t -> t.merchant)
  .window(SlidingEventTimeWindows.of(1.hour, 1.minute))
  .sum("amount")
  .filter(total -> total > 50000)
  .addSink(new FraudAlertSink())

# Batch: relatório diário
daily_transactions = spark.read.parquet("transactions/2024-01-01")
daily_summary = daily_transactions.groupBy("merchant").agg(sum("amount"), count("transaction_id"))
daily_summary.write.mode("overwrite").parquet("reports/daily/2024-01-01")

Caso 2: Logs de servidores web
- Streaming: Alertas de erro 5xx em tempo real, monitoramento de latência
- Batch: Análise de tendências mensais, relatórios de capacidade, modelos de previsão de tráfego

Caso 3: Dados de sensores IoT
- Streaming: Monitoramento de temperatura crítica, alertas de falha iminente
- Batch: Treinamento de modelos preditivos de manutenção, análise de eficiência energética semanal

Conclusão

A escolha entre streaming e batch processing não é binária — é uma decisão estratégica baseada em requisitos de latência, volume, consistência e custo. Muitas organizações bem-sucedidas adotam abordagens híbridas, combinando o melhor dos dois mundos. O importante é entender que não existe bala de prata: a abordagem correta depende do problema específico que você está resolvendo.

Referências