Streaming de Dados

Processamento em lote (batch) é o modo tradicional de trabalhar com dados: acumular eventos ou transações ao longo de um período, processar o conjunto completo periodicamente (de hora em hora, diariamente, semanalmente), e produzir o resultado. É eficiente, simples de implementar e adequado para análises que não precisam de resultado em tempo real.

Mas há problemas que o batch não resolve: detectar fraude antes de autorizar uma transação que ocorre em milissegundos; recomendar conteúdo relevante para um usuário com base no que ele acabou de assistir; monitorar falha de equipamento industrial antes que ela cause dano; alertar sobre anomalia de segurança no instante em que ocorre. Nesses casos, o tempo entre o evento e a análise não pode ser de horas ou dias — precisa ser de segundos ou menos.

Streaming de Dados é o paradigma de processamento contínuo de dados à medida que são gerados — sem acumular para processar em lote. Cada evento é processado assim que chega, o que viabiliza análises e ações em tempo real ou próximo a tempo real.

A escolha entre batch e streaming não é ideológica — é de requisito de negócio.

Batch é adequado quando:

• Latência aceitável é de minutos a horas (relatórios diários, análises de BI, retreinamento de modelos)
• O processamento é custoso e faz sentido agrupar para eficiência
• A análise precisa de dados completos de um período (consolidação mensal, fechamento financeiro)
• A infraestrutura é mais simples de operar do que streaming

Streaming é necessário quando:

• Decisões ou ações precisam acontecer em segundos após o evento (fraude, alertas, personalização)
• Há necessidade de monitoramento contínuo de métricas em tempo real
• Eventos precisam ser reagidos individualmente, não após acumulação
• A janela de tempo relevante é curta (engajamento de usuário ativo, estado atual de equipamento)

Fontes de dados (producers): aplicações, sensores IoT, logs de sistema, plataformas de transação que geram eventos continuamente. Cada evento tem timestamp e payload com os dados do evento.

Message broker (plataforma de streaming): o componente central. Recebe eventos dos produtores, armazena de forma durável, e os disponibiliza para consumidores. Garante que eventos não se percam, que sejam entregues em ordem (dentro de partições), e que múltiplos consumidores possam ler o mesmo stream independentemente.

Processadores de stream: consumidores que leem eventos em tempo real, aplicam transformações, agregações, enriquecimentos, e produzem resultados — que podem ser novos eventos em outro topic, atualizações em banco de dados, ou chamadas a sistemas externos.

Destinos (sinks): onde os resultados do processamento vão — data warehouse para análise histórica, banco de dados operacional para alimentar aplicações, sistema de alertas, outro stream.

Kafka é a plataforma de streaming distribuído que domina o mercado. Projetado pelo LinkedIn, open source desde 2011, hoje mantido pela Apache Software Foundation com oferta cloud da Confluent.

Conceitos fundamentais do Kafka:

Topic: canal lógico de eventos. "transacoes-financeiras", "eventos-de-usuario", "leituras-de-sensor". Produtores publicam em topics; consumidores leem de topics.

Partição: cada topic é dividido em N partições para paralelismo. Dentro de uma partição, eventos são ordenados. Kafka garante ordem apenas dentro de partição, não entre partições do mesmo topic.

Consumer Group: conjunto de consumidores que cooperam para processar um topic. Kafka distribui partições entre consumidores do mesmo grupo — cada partição é lida por exatamente um consumidor do grupo. Adicionar consumidores ao grupo escala o throughput linearmente (até o número de partições).

Retenção: Kafka armazena eventos por período configurável (dias a semanas), não apenas até o consumo. Consumidores podem reprocessar eventos históricos lendo de um offset anterior — fundamental para reprocessamento em caso de bug e para novos consumidores que precisam do histórico.

Offsets: cada evento em cada partição tem um offset sequencial. Consumidores controlam qual offset já processaram — se falham e reiniciam, continuam de onde pararam.

A diferença mais importante entre processamento batch e streaming está em como agregações são feitas.

Em batch, você agrega sobre o conjunto completo de dados do período. Em streaming, você precisa definir janelas de tempo sobre as quais agregar.

Tumbling windows (janelas disjuntas): janelas de tamanho fixo sem sobreposição. "Total de transações por minuto" — cada evento pertence a exatamente uma janela. Simples de implementar.

Sliding windows (janelas deslizantes): janelas que se sobrepõem, deslizando no tempo. "Total de transações nos últimos 5 minutos, calculado a cada segundo." Cada evento pode pertencer a múltiplas janelas. Útil para métricas que precisam de suavização.

Session windows: janelas definidas por inatividade — agrupam eventos de uma sessão de usuário. "Todos os eventos de um usuário até que fique inativo por mais de 30 minutos" — janela de tamanho variável, determinada pelo comportamento do usuário.

Eventos atrasados (late events): em sistemas distribuídos, eventos chegam fora de ordem — o evento que aconteceu às 10:00:05 chega ao processador às 10:00:12, depois que a janela de 10:00:00-10:00:10 já foi fechada. Frameworks de streaming têm mecanismos de watermark para lidar com isso — quanto tempo esperar por eventos atrasados antes de fechar uma janela.

Apache Flink: o framework de processamento de stream mais robusto. Processamento de stream como caso primeiro-classe (não batch emulado como stream), excelente suporte a stateful processing, exactly-once semantics, processamento de eventos fora de ordem. Preferido em cenários que exigem garantias fortes.

Apache Spark Structured Streaming: Spark tratando stream como tabela que cresce continuamente. Permite usar a mesma API de batch em streaming. Familiar para quem já usa Spark; suporte a micro-batching (latência de segundos) e continuous processing (latência de milissegundos).

Kafka Streams: biblioteca Java/Scala para processamento de stream que roda dentro da aplicação (sem cluster separado) e usa Kafka como infraestrutura. Leve e sem dependência adicional para operações simples.

ksqlDB: SQL sobre Kafka streams. Escrever queries SQL para processar streams em tempo real, sem código Java ou Python. Acessível para analistas que sabem SQL.

Streaming de dados é necessário para um subconjunto específico de casos de uso — onde a latência do batch é inaceitável e onde há decisões ou ações que precisam acontecer em segundos após o evento. Para a maioria das análises de negócio — relatórios, dashboards, modelos preditivos — batch com atualização de minutos a horas é suficiente.

Para PMEs, o ponto de entrada em streaming geralmente não é Kafka auto-hospedado — é AWS Kinesis, Google Pub/Sub ou Confluent Cloud, que eliminam a complexidade operacional de gerenciar clusters Kafka. O caso de uso inicial mais comum é ingestão de eventos de comportamento de usuário (cliques, visualizações) ou eventos operacionais (transações, pedidos) em streaming para análise em tempo real ou para alimentar sistemas de personalização.

A pergunta a fazer antes de investir em infraestrutura de streaming: qual decisão específica precisa ser tomada em menos de X segundos após um evento, que hoje é tomada tarde demais? Se a resposta não existe ou não é clara, batch bem implementado resolve o problema com muito menos complexidade operacional.