Superando a Barreira do Microbatch: A Arquitetura do Modo em Tempo Real do Apache Spark

O Modo em Tempo Real (RTM) do Apache Spark não é uma nova API, mas uma reinvenção da execução por trás do Structured Streaming, e isso muda tudo para quem lida com pipelines de dados operacionais. Ele elimina o gargalo estrutural do microbatch sem sacrificar as garantias de exatidão: mantém o processamento 'exactly-once' mesmo com fluxo contínuo, algo que o modo experimental de Processamento Contínuo do Spark 2.3 não conseguia oferecer. A chave está na combinação de épocas estendidas (até 5 minutos), agendamento em pipeline de estágios e streaming shuffle em memória, ou seja, os dados se movem entre tarefas assim que são gerados, sem esperar barreiras de batch nem escrita em disco. Isso explica por que benchmarks mostram latência p99 abaixo de 100ms em cenários críticos como detecção de fraude, e até 5ms em configurações otimizadas.

Do ponto de vista do desenvolvedor, o RTM é quase invisível: basta alterar spark.sql.streaming.mode para realtime e ajustar a configuração de recursos do cluster, principalmente núcleos disponíveis para suportar a concorrência de estágios. Não há mudança na DSL do Structured Streaming, nem no modelo de estado ou nas fontes/sinks suportadas. Isso preserva a experiência do desenvolvedor (DX) e reduz drasticamente o custo de adoção, ao contrário de migrar para frameworks como Flink, que exigem reescrita completa e curva de aprendizado distinta.

Para engenheiros de dados e equipes de ML ops, o RTM significa que um único runtime pode agora cobrir desde ETL diário até decisões em milissegundos, sem duplicação de ferramentas, sem silos de código e sem trade-offs entre consistência e velocidade. Isso impacta diretamente a arquitetura de sistemas: não é mais necessário manter dois clusters (um para Spark, outro para Flink) ou usar Kafka + Flink só para baixa latência. O RTM também redefine o papel do Spark em aplicações de tempo real com estado, como feature serving e detecção de anomalias em IoT, onde a latência de ponta a ponta passa a ser limitada pelo hardware e pela rede, não pela engine de processamento.