Arquitetura Moderna de Dados: Do Batch ao Real-Time Analytics

Arquitetura Moderna de Dados: Do Batch ao Real-Time Analytics

A maioria das empresas ainda move dados da mesma forma que fazia há quinze anos: um job agendado roda à meia-noite, extrai tudo que mudou desde a última execução, transforma, carrega no warehouse, e as equipes de negócio consultam os dados de manhã. Isso funciona — até deixar de funcionar.

Pipelines em batch são previsíveis, operacionalmente simples e fáceis de compreender. Eles também introduzem 8 a 24 horas de latência como uma premissa estrutural, não como um bug. Quando as empresas passaram a competir em decisões tomadas em segundos — detecção de fraude, recomendações personalizadas, precificação dinâmica — essa premissa se tornou insustentável.

A transição para real-time analytics não é sobre seguir tendências tecnológicas. É sobre tornar possíveis categorias inteiramente novas de decisão. Este guia vai ajudá-lo a entender a arquitetura por trás dessa transição, os trade-offs envolvidos e como escolher a abordagem certa para o seu contexto.

As limitações do processamento em batch

Pipelines ETL em batch (Extract, Transform, Load) serviram bem às equipes de dados. Ferramentas como Apache Spark, dbt e Airflow formam stacks maduras e bem compreendidas. Os problemas começam quando os requisitos do negócio superam o que o batch consegue entregar.

A restrição central é a freshness. Em um mundo batch, seus dados são sempre obsoletos por design. A janela de obsolescência é determinada pelo agendamento do pipeline e não pode ser menor do que o tempo de execução do job.

Considere o que isso significa na prática:

• Um modelo de detecção de fraude rodando nos dados de transação de ontem vai perder os padrões de fraude de hoje.
• Um motor de recomendação que atualiza diariamente não consegue reagir ao que o usuário fez cinco minutos atrás.
• Um dashboard de operações mostrando o inventário da noite anterior não auxilia um gerente de armazém a tomar decisões de alocação em tempo real.
• Um teste A/B que reconcilia resultados diariamente perde sinal nas horas em que os padrões de tráfego são mais reveladores.

Esses não são casos de borda — são os casos de uso centrais da próxima geração de produtos de dados.

Arquitetura orientada a eventos: a mudança conceitual

A reorientação fundamental em dados em tempo real é tratar eventos como a unidade de dado, não registros ou tabelas. Em vez de perguntar "o que mudou desde a meia-noite?", a pergunta se torna "o que acabou de acontecer?".

Um evento é um registro imutável e com timestamp de algo que ocorreu no seu sistema: um usuário fez um pedido, um pagamento falhou, um sensor publicou uma leitura de temperatura. Eventos acontecem continuamente. Uma arquitetura orientada a eventos captura cada um no momento em que ocorre e o disponibiliza imediatamente para qualquer sistema downstream que precise.

Isso muda a forma da sua infraestrutura de dados:

• Fontes (aplicações, bancos de dados, APIs) emitem eventos quando mudanças de estado ocorrem.
• Um message broker (Kafka, Pulsar, Kinesis) captura e armazena de forma durável esses eventos em logs ordenados e reprocessáveis.
• Consumidores (processadores de stream, motores de analytics, pipelines de ML) leem desses logs em near real-time e computam resultados.

O insight central é que o event log se torna o sistema de registro. Não é um mecanismo de transporte — é história imutável. Todo sistema downstream deriva seu estado lendo e processando esse log.

Apache Kafka: a espinha dorsal de plataformas de dados em tempo real

Kafka é o sistema de mensageria distribuída mais amplamente adotado no ambiente corporativo, e por boas razões. Entender seu modelo é essencial para compreender a arquitetura moderna de streaming.

Conceitos centrais do Kafka

Topics são logs append-only e ordenados. Produtores escrevem eventos em um topic; consumidores leem dele. Topics são particionados para escalabilidade horizontal — cada partição é um log ordenado independente, e múltiplos consumidores podem ler de partições diferentes em paralelo.

Consumer groups habilitam tanto paralelismo quanto tolerância a falhas. Cada consumidor em um grupo lê de um subconjunto distinto de partições. Se um consumidor falhar, o Kafka redistribui suas partições para os outros membros do grupo.

Retention é configurável e independente do consumo. Você pode reter eventos por 7 dias, 30 dias ou indefinidamente. Isso habilita o replay — a capacidade de reprocessar um stream inteiro de eventos desde o início, o que é transformador para pipelines de dados.

Offsets são ponteiros para a posição de um consumidor em uma partição. Como offsets são explícitos, um consumidor pode processar eventos e commitar seu offset de forma independente. Isso permite semânticas de entrega exactly-once, at-least-once ou at-most-once dependendo dos seus requisitos.

O que o Kafka torna possível

• Sistemas desacoplados — Produtores não esperam pelos consumidores. Múltiplos consumer groups podem ler os mesmos eventos independentemente, cada um no seu próprio ritmo.
• Replay de eventos — Repopule um novo data warehouse, re-treine um modelo de ML em eventos históricos ou depure um pipeline reprocessando a entrada.
• Reprocessamento sem re-extração — A fonte de verdade é o event log. Você não precisa consultar os bancos de dados de origem novamente.
• Fan-out — Um único stream de eventos pode alimentar detecção de fraude, analytics, personalização e audit logging simultaneamente.

Change Data Capture: conectando bancos de dados e streams

Nem todo sistema de origem é projetado para emitir eventos. A maioria dos bancos de dados de produção (Postgres, MySQL, SQL Server) armazena estado atual — linhas, registros, tabelas — não histórico de eventos. Change Data Capture (CDC) é a técnica que preenche essa lacuna.

CDC lê o transaction log do banco de dados (o write-ahead log no Postgres, o binlog no MySQL) e emite um stream de eventos de mudança — inserts, updates e deletes — à medida que ocorrem. O resultado: seu banco de dados relacional se torna uma fonte de eventos sem nenhuma mudança no nível da aplicação.

Debezium: o padrão para CDC

Debezium é a plataforma CDC open source dominante. Ele conecta ao log do seu banco de dados, captura cada mudança e publica essas mudanças como eventos estruturados em topics Kafka.

Um evento Debezium para uma atualização de pedido se parece com isso:

{
  "before": { "order_id": 1001, "status": "pendente", "valor": 249.99 },
  "after": { "order_id": 1001, "status": "confirmado", "valor": 249.99 },
  "op": "u",
  "ts_ms": 1711737600000,
  "source": { "table": "pedidos", "db": "ecommerce" }
}

Esse evento contém o estado completo antes e depois, o tipo de operação e um timestamp preciso. Todo sistema downstream que se importa com mudanças no status do pedido — analytics, estoque, notificações — pode se inscrever nesse topic e reagir em menos de um segundo.

Casos de uso de CDC em produção

• Invalidação de cache — Limpe uma entrada de cache Redis no momento em que a linha subjacente muda, eliminando dados obsoletos baseados em TTL.
• Sincronização de data warehouse — Envie mudanças ao Snowflake ou BigQuery em segundos, em vez de esperar pelo ETL noturno.
• Desacoplamento de microsserviços — Remova chamadas diretas serviço-a-serviço fazendo os serviços se inscreverem em eventos de mudança uns dos outros.
• Trilhas de auditoria — Capture registros imutáveis de cada mudança de dado sem instrumentação no código da aplicação.

Processamento de streams: computando sobre eventos em movimento

Capturar eventos é o primeiro passo. O valor vem da computação sobre eles. Frameworks de processamento de streams executam queries contínuas sobre streams infinitos de dados, produzindo resultados que se atualizam à medida que novos eventos chegam.

Apache Flink e Kafka Streams

Apache Flink é o padrão da indústria para processamento de stream stateful e exactly-once em escala. Ele suporta:

• Windowing — Compute agregações sobre janelas de tempo (sliding, tumbling, session). Uma janela deslizante de 5 minutos sobre eventos de pagamento computa a taxa de fraude atualizada a cada segundo.
• Operações com estado — Mantenha estado entre eventos do mesmo usuário, sessão ou entidade. Faça join de um evento de pedido com o histórico do usuário sem uma consulta ao banco de dados.
• Semânticas exactly-once — Mesmo na presença de falhas, cada evento é processado precisamente uma vez. Crítico para cargas financeiras e de compliance.
• Processamento em event-time — Raciocine sobre quando os eventos realmente ocorreram, não sobre quando chegaram, lidando corretamente com dados fora de ordem.

Kafka Streams é uma opção mais leve para times já investidos em Kafka. Roda dentro da sua aplicação, não requer cluster separado e lida com a maioria dos casos de uso de stream processing com muito menos overhead operacional do que o Flink.

O padrão de materialized view

Um dos padrões mais poderosos em streaming é a materialized view: uma projeção continuamente atualizada do seu event stream que os consumidores podem consultar de forma síncrona.

Em vez de consultar um banco de dados e executar agregações sob demanda, você pré-computa o resultado enquanto os eventos fluem pelo sistema. Um dashboard pré-agregado pode então ler do estado armazenado no Redis ou atualizado no Postgres com latência negligível.

O stack de dados em tempo real na prática

Uma plataforma de real-time analytics em produção tipicamente combina estas camadas:

| Camada | Tecnologia | Papel | |---|---|---| | Ingestão | Debezium, produtores customizados | Captura mudanças dos sistemas de origem | | Transporte | Apache Kafka | Log de mensagens durável e escalável | | Processamento | Flink, Kafka Streams | Computação stateful, enriquecimento | | Serving | Redis, DynamoDB, Postgres | Camada de consulta de baixa latência | | Analytics | Clickhouse, Druid, BigQuery | Queries OLAP sobre histórico de eventos | | Orquestração | Airflow, Temporal | Coordenação de workflows |

Quando usar batch, quando usar streaming

Esta é a questão que realmente importa, e a resposta honesta é: a maioria dos sistemas precisa de ambos.

Use processamento em batch quando:

• Seus consumidores downstream toleram latência de múltiplas horas. Relatórios noturnos, análises históricas, pipelines de treinamento de modelos e relatórios regulatórios raramente precisam de freshness em tempo real.
• Os volumes de dados são massivos mas a chegada é infrequente. Processar 10TB de arquivos de log uma vez por dia é muito mais barato em um job batch do que streamá-los continuamente.
• A computação é complexa e stateful de formas que frameworks de streaming lidam mal (joins massivos entre bilhões de registros, agregações complexas sobre longos históricos).
• A simplicidade operacional é uma prioridade. Pipelines batch são mais fáceis de depurar, testar e monitorar do que pipelines de streaming.

Use streaming quando:

• Funcionalidades voltadas ao usuário requerem freshness de dados sub-segundo ou sub-minuto. Detecção de fraude, recomendações personalizadas, estoque ao vivo.
• Eventos precisam disparar ações, não apenas atualizar estado. Uma falha de pagamento deve imediatamente disparar um workflow de retry, não esperar por um job batch.
• Múltiplos sistemas downstream precisam de acesso ao mesmo evento de mudança simultaneamente. Fan-out é onde o valor do streaming é mais alto.
• Você precisa reagir a padrões entre eventos, não apenas a registros individuais. Transações de alta frequência do mesmo cartão, picos repentinos de tráfego, comportamento sequencial do usuário.

Arquiteturas Lambda e Kappa

Dois padrões arquiteturais surgiram para sistemas que precisam tanto de precisão batch quanto de velocidade de streaming.

A Arquitetura Lambda executa uma camada batch e uma camada de streaming em paralelo. A camada batch computa resultados precisos e completos em um ciclo lento; a camada de streaming computa resultados aproximados e near-real-time rapidamente. Uma mesclagem em tempo de query combina ambos. O trade-off é complexidade operacional significativa — você mantém duas bases de código computando essencialmente a mesma lógica.

A Arquitetura Kappa elimina a camada batch inteiramente. Todo processamento roda como um job de stream. O reprocessamento histórico é tratado pelo replay do event log do Kafka. O trade-off é que você precisa de grande retenção no Kafka e deve lidar com reprocessamento cuidadosamente. Essa arquitetura tem se tornado cada vez mais viável à medida que os frameworks de streaming amadureceram.

Iniciando a migração: um caminho prático

Migrar de batch para streaming é uma jornada, não um big bang. As migrações mais bem-sucedidas seguem um caminho incremental:

1. Identifique seu caso de uso de maior valor — Escolha o único lugar onde freshness em tempo real criaria valor de negócio imediato. Detecção de fraude. Estoque ao vivo. Personalização. Comece por aí.
2. Configure o Kafka primeiro — Antes de processar, foque em fazer os eventos fluírem de forma confiável. Debezium para bancos existentes, produtores customizados para eventos de aplicação.
3. Rode batch e streaming em paralelo — Durante a transição, compute resultados em ambos os sistemas e compare. Construa confiança antes de migrar o tráfego de produção.
4. Expanda incrementalmente — Uma vez que o primeiro caso de uso está no ar e estável, aplique o mesmo padrão ao próximo. Construa conhecimento organizacional progressivamente.
5. Invista em observabilidade — Pipelines de streaming falham de forma diferente dos jobs batch. Consumer lag, desequilíbrio de partições e atrasos de processamento são seus sinais primários.

Reflexão final

A questão não é se deve migrar para arquitetura de dados em tempo real — as pressões de negócio são claras. A questão é onde no espectro entre batch e streaming seus casos de uso específicos precisam estar, e qual é o custo operacional dessa posição.

Batch não é errado; muitas vezes é exatamente certo. Streaming não é sempre necessário; às vezes é essencial. Os melhores engenheiros de dados têm ambos no seu toolkit e fazem a escolha deliberadamente, baseados em requisitos de freshness, capacidade operacional e no valor que os dados em tempo real vão realmente desbloquear.

O erro mais caro é adotar a complexidade do streaming para problemas que o batch resolveria perfeitamente bem.