Detecção ultrarrápida de anomalias usando o modo em tempo real do Apache Spark

Este post estabelece um padrão reutilizável para cargas de trabalho operacionais que realmente fazem a diferença: detecção de fraudes, monitoramento de sensores de IoT, personalização em tempo real, processamento de sinais de segurança — qualquer cenário em que a resposta imediata a eventos seja crítica para os resultados de negócios.

O objetivo principal: Quando um evento parecer suspeito ou inválido, marque-o imediatamente e encaminhe-o para a ação downstream apropriada.

Neste blog, demonstramos a detecção de anomalias em transações da blockchain Ethereum. Analisamos dados da blockchain Ethereum e marcamos transações com padrões inválidos em tempo real. Especificamente, detectamos:

1. Violações de qualidade de dados: Blocos onde gas_used > gas_limit são fisicamente impossíveis sob o protocolo Ethereum, indicando corrupção de dados, bugs do produtor ou falhas de parsing de esquema
2. Violações de higiene de payload: O campo extra_data contendo padrões reconhecíveis de PII ou credenciais (endereços de e-mail, tokens JWT, chaves de acesso AWS) sinaliza vazamento de dados ou produtores mal configurados

Embora usemos dados do Ethereum para demonstração, essa classificação de "suspeito ou inválido" se aplica a vários casos de uso de alto valor:

• Detecção de fraude: Uma transação apresenta padrões anômalos → aciona fluxos de trabalho de investigação downstream
• Monitoramento de IoT: A leitura de um sensor fica fora dos parâmetros fisicamente possíveis → inicia uma resposta automatizada
• Operações de segurança: O payload contém segredos ou padrões de PII → quarentena em tempo real com governança unificada
• Motores de personalização: Responda a eventos comportamentais específicos com ofertas contextuais imediatas

A mesma lógica de detecção se mapeia diretamente para qualquer domínio: transações financeiras que contêm PII inesperadas, payloads de IoT com leituras de sensores fora do intervalo ou logs de eventos de API contendo segredos que deveriam ter sido removidos. O stream do Ethereum fornece um conjunto de dados limpo e reproduzível para demonstrar o padrão em escala.

Sobre o Spark Real-Time Mode

Real-Time Mode (RTM) é um novo tipo de trigger para o Apache Spark™ Structured Streaming que oferece latência de nível de milissegundo para as APIs do Spark — sem a necessidade de um mecanismo especializado separado como o Apache Flink.

Enquanto o modo micro-batch padrão do Structured Streaming funciona como um ônibus de traslado de aeroporto que espera encher antes de partir, o RTM opera como uma esteira rolante de alta velocidade, processando cada evento assim que ele chega. Ele alcança isso por meio de três inovações arquitetônicas: fluxo contínuo de dados (os eventos são processados à medida que chegam, não em blocos discretos), agendamento de pipeline (todas as etapas da consulta são executadas simultaneamente, sem bloqueio) e streaming shuffle (os dados são passados entre as tarefas imediatamente na memória, ignorando o disco).

O RTM é projetado especificamente para cargas de trabalho operacionais onde a latência afeta diretamente os resultados de negócios — detecção de fraudes, personalização em tempo real, computação de features de ML e monitoramento de IoT. Para cargas de trabalho que podem tolerar de 1 a 2 segundos de latência, o micro-batch tradicional continua sendo a opção mais econômica.

Por que o RTM é um divisor de águas

1. Ultrarrápido: latência de subsegundo agora é possível

O Real-Time Mode muda fundamentalmente o que é possível com o Apache Spark. As latências de ponta a ponta que variam de ~5 ms a ~300 ms, dependendo da complexidade da carga de trabalho, trazem o Spark para o território anteriormente dominado por mecanismos especializados de processamento de stream. O micro-batch tradicional oferece latência de 1 a 2 segundos; o Real-Time Mode alcança de ~5 ms a ~300 ms.
A arquitetura consegue isso por meio de pipelines de execução pré-alocados e checkpointing assíncrono, eliminando a sobrecarga de agendamento que tradicionalmente limitava o processamento em micro-batch. Para cargas de trabalho operacionais onde os milissegundos importam — detecção de fraudes, monitoramento de IoT, ofertas em tempo real —, esse nível de desempenho é transformador.

2. Stack simplificada: nenhuma tecnologia separada é necessária

As organizações frequentemente se deparam com um equívoco caro: "O Spark não tem desempenho suficiente para casos de uso em tempo real, por isso precisamos de uma stack totalmente separada para esse único requisito."

Para cargas de trabalho que toleram de 1 a 2 segundos de latência, o micro-batch do Spark entrega dados de forma confiável no Delta Lake com excelentes características de custo-benefício. Para cargas de trabalho operacionais que exigem tempos de resposta de subsegundo, o Real-Time Mode elimina totalmente a necessidade de tecnologias separadas — conforme validado por equipes da Coinbase, DraftKings e MakeMyTrip, que se consolidaram em uma única stack baseada em Spark para cargas de trabalho analíticas e operacionais.

Com o Real-Time Mode, o Spark lida com cargas de trabalho analíticas (na faixa de segundos) e operacionais (na faixa de milissegundos) dentro de uma única plataforma unificada. Isso reduz:

• Complexidade operacional: Uma única stack de tecnologia para gerenciar, monitorar e solucionar problemas
• Sobrecarga de treinamento: A experiência existente em Spark se transfere diretamente para casos de uso em tempo real
• Fricção de integração: Sem transferências complexas (handoffs) entre mecanismos de streaming separados
• Custo total de propriedade: A consolidação reduz os custos de infraestrutura, licenciamento e operacionais

3. Amigável para desenvolvedores: alteração simples de trigger, sem reescrita de código

Talvez o aspecto mais atraente do Real-Time Mode seja sua notável simplicidade para desenvolvedores que já estão familiarizados com o Structured Streaming. Ativar esse recurso poderoso não exige nenhuma migração complexa ou reestruturação fundamental de código.

As organizações podem desbloquear latência de nível de milissegundo simplesmente modificando a configuração do trigger:

E pronto. A mesma API familiar do Structured Streaming. O mesmo gerenciamento de checkpoint. A mesma semântica de entrega at-least-once. Apenas uma alteração de configuração para habilitar inteligência operacional de subsegundo.

Nota sobre garantias de entrega: O RTM com sink do Kafka fornece garantias de entrega at-least-once. Os consumidores downstream devem lidar com possíveis duplicatas por meio de gravações idempotentes ou lógica de deduplicação.

Essa integração perfeita representa uma vantagem crucial. As equipes podem criar protótipos e colocar em produção cargas de trabalho operacionais sem a sobrecarga substancial de aprender, implantar e gerenciar stacks de tecnologia totalmente separadas. Essa abordagem acelera drasticamente a inovação, ao mesmo tempo que reduz o risco tradicionalmente associado à adoção de novos recursos em tempo real.

Depois de estabelecer por que o Real-Time Mode é importante, vamos examinar como implementar esse padrão na prática. As seções a seguir demonstram um pipeline de guardrail pronto para produção — o padrão operacional que transforma esses recursos em valor de negócios.

Visão geral da arquitetura: construindo um stream de guardrail operacional

Cada evento de entrada passa por uma avaliação imediata, produzindo um evento downstream enriquecido que contém:

• Decisão: ALLOW versus QUARANTINE
• Motivos: Explicação detalhada de quaisquer sinalizações (flags) acionadas (violações de qualidade de dados, preocupações com a higiene do payload)

Este padrão operacional serve como uma única fonte de verdade para a tomada de decisões em tempo real:

• Este evento deve ser colocado em quarentena para investigação?
• Como enriquecemos os eventos para que os sistemas downstream possam reagir instantaneamente?

Embora nossa demonstração use dados de blocos do Ethereum, esse padrão se aplica universalmente: transações financeiras, leituras de sensores, logs de autenticação, chamadas de API — a arquitetura permanece consistente.

Validação em escala

Fieis ao nosso compromisso com soluções de qualidade de produção, validamos esse padrão em escala. A cadeia completa do Ethereum — aproximadamente 95 GB distribuídos em 4 partições, representando cerca de 23 milhões de mensagens — foi carregada no Kafka para testes.

Definindo regras de validação para classificação de eventos

Implementamos regras de validação intencionalmente simples e de alto sinal:

Regra 1: Validação de higiene do payload

Verifique o campo extra_data em busca de padrões que indiquem claramente dados que não deveriam estar presentes em fluxos de produção. Os exemplos de código demonstram a detecção básica de padrões (endereços de e-mail, tokens JWT, formatos de chave AWS).

As organizações devem substituir essas regras por outras específicas para seus requisitos de conformidade — padrões de PII, identificadores internos, credenciais de API e dados confidenciais semelhantes.

O insight crítico: As proteções em tempo real (guardrails) pertencem ao pipeline como parte de uma governança unificada, e não descobertas durante a análise pós-incidente.

Regra 2: Validação de qualidade de dados

gas_used > gas_limit

Essa condição nunca deve ocorrer em dados válidos. Quando detectada, indica um dos seguintes problemas:

• Corrupção de dados durante a transmissão
• Erros de geração de dados no lado do produtor
• Inconsistências na análise do esquema
• Falhas no sistema upstream

De uma perspectiva operacional, esse é precisamente o tipo de anomalia que queremos sinalizar imediatamente — permitindo uma resposta rápida antes que os sistemas downstream sejam afetados.

Com nossa lógica de validação estabelecida, passamos agora para a configuração de streaming que permite a execução em menos de um segundo.

Modo em Tempo Real: Configuração essencial

O Modo em Tempo Real é ativado por meio do trigger em tempo real e opera no modo de atualização. No PySpark, você especifica um parâmetro de intervalo (por exemplo, "5 minutes").

Dois requisitos de configuração críticos:

1. Configuração do cluster: A documentação do Databricks especifica as configurações de cluster de job necessárias e a flag de ativação do RTM
2. Modo de saída: Deve usar o modo update com triggers RTM

Configuração usada nesta demonstração:

• Runtime: Databricks Runtime 16.4 LTS ou posterior
• Computação: Cluster dedicado (usuário único) com contagem fixa de workers (autoscaling desativado)
• Photon: Desativado (não suportado com RTM)
• Workers: 4 workers para esta carga de trabalho
• Modo de saída: update (obrigatório para RTM)

Consulte o repositório complementar para obter o cluster_config.template.json completo.

Implementação: Pipeline de guardrail em tempo real

Este pipeline de passagem única demonstra a integração contínua entre o Kafka e o Modo em Tempo Real do Spark:

1. Conectar à origem do Kafka
2. Analisar os payloads JSON recebidos
3. Calcular a decisão e os motivos
4. Gravar o JSON enriquecido de volta no Kafka

Você pode ler o código aqui.

Resultados: Desempenho em escala

Validamos o desempenho do Modo em Tempo Real processando dados do blockchain Ethereum — ~23 milhões de mensagens distribuídas em 4 partições do Kafka no modo de streaming contínuo.

Desempenho de throughput

O pipeline demonstrou características impressionantes de throughput:

• Taxa de entrada: 65.592 linhas/segundo
• Taxa de processamento: 69.713 linhas/segundo (sustentada)
• Total de registros processados: ~23.213.628 mensagens
• Configuração do cluster: DBR 16.4 LTS, 4 workers (i3.xlarge), modo de usuário único dedicado, Photon desativado

Métricas de latência

Os logs do driver capturam métricas detalhadas de latência por meio do evento spark.streaming.madeProgress. O Modo em Tempo Real relata processingLatencyMs, que mede o tempo entre o momento em que a consulta lê um registro e o momento em que o grava no sink downstream.

Para este pipeline de validação sem estado (stateless) que processa ~23 milhões de registros, observamos:

• P0, P50, P90, P95: 1 milissegundo (arredonda para 0 nas métricas) P99: 1 milissegundo Taxa de processamento: 69.713 linhas/segundo sustentada
• Entendendo o processingLatencyMs: Essa métrica mede o tempo entre a leitura de um registro pelo RTM e sua gravação no sink downstream. Ela é medida por tarefa e relatada na seção rtmMetrics.processingLatencyMs do StreamingQueryProgress com percentis (P0, P50, P90, P95, P99). Para um pipeline Kafka-para-Kafka de estágio único como este, ela representa efetivamente a latência de ponta a ponta por registro.
• O que isso significa: A grande maioria dos registros (percentil 95) foi processada em menos de meio milissegundo, com até mesmo o 1% mais lento sendo concluído em 1 milissegundo. Os valores que mostram "0" para P0-P95 indicam latências abaixo de 0,5 ms (arredondadas para baixo pelo sistema de métricas).

Observação: esses resultados representam o desempenho em um pipeline de validação sem estado (stateless). Operações com estado (stateful) mais complexas (agregações, janelamento) podem apresentar latências mais altas dentro da faixa de ~5 ms a ~300 ms do RTM, dependendo da complexidade da carga de trabalho.

Principais insights de desempenho

• Interpretação: 99% de todos os registros foram processados em menos de 1 milissegundo, com apenas o 1% mais lento atingindo 1 milissegundo. Isso demonstra um desempenho de baixa latência excepcionalmente consistente.
• Throughput: O pipeline sustentou 69.713 linhas/segundo enquanto processava ~23 milhões de registros, demonstrando um desempenho estável sob carga contínua.

Essas métricas validam que o Modo em Tempo Real oferece latência abaixo de milissegundo de nível de produção (P95 0,5 ms, P99 = 1 ms) ao processar fluxos de alto volume a quase 70.000 linhas/segundo — eliminando o trade-off tradicional entre plataformas unificadas e requisitos de baixa latência.

Conclusão

O Modo em Tempo Real estende o Apache Spark™ Structured Streaming para uma nova classe de cargas de trabalho — aplicações operacionais e sensíveis à latência que exigem resposta imediata aos dados de streaming. Ao trazer latência abaixo de um segundo para as APIs do Spark que sua equipe já usa, ele elimina a necessidade de operar um mecanismo especializado separado para seus pipelines mais críticos em termos de tempo.

A proposta de valor é atraente:

• Uma única plataforma unificada lida com cargas de trabalho analíticas (na faixa de segundos) e operacionais (na faixa de milissegundos)
• A experiência existente em Spark se transfere diretamente — sem a necessidade de especialização separada
• Risco mínimo de migração — uma única alteração de configuração de trigger libera recursos em tempo real
• Desempenho validado em produção — latências P99 de 1 ms com P95 abaixo de 0,5 ms processando milhões de eventos

Quer você esteja criando pipelines de detecção de fraude, mecanismos de personalização ou sistemas de computação de features de ML, o Modo em Tempo Real oferece a latência que sua aplicação exige, mantendo a simplicidade e a amplitude do ecossistema do Spark.

Primeiros passos

Clone o repositório complementar para executar este pipeline de guardrail de ponta a ponta — ele inclui a implementação completa, a configuração do cluster e o guia de implantação.

Para se aprofundar, revise a documentação do Modo em Tempo Real para obter opções de configuração e origens/sinks suportados, ou assista ao Aprofundamento Técnico do Modo em Tempo Real para ver o passo a passo completo da arquitetura.

Recursos

• Imersão Técnica no Modo de Tempo Real: Como Criamos Streaming de Sub-300 Milissegundos no Apache Spark™
• Entregando Latência de Subsegundo para Cargas de Trabalho Operacionais no Databricks
• Documentação do Modo de Tempo Real do Databricks
• Repositório de Código Complementar - Demonstração de Guardrail do Modo de Tempo Real - Implementação pronta para produção com suíte de testes abrangente, configuração de cluster e guia de implantação

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original