Detección de anomalías ultrarrápida con el modo en tiempo real de Apache Spark

Este artículo establece un patrón reutilizable para cargas de trabajo operativas que realmente marcan la diferencia: detección de fraudes, monitoreo de sensores de IoT, personalización en tiempo real, procesamiento de señales de seguridad... cualquier escenario donde la respuesta inmediata a los eventos sea fundamental para los resultados del negocio.

El objetivo principal: Cuando un evento parezca sospechoso o no válido, márquelo de inmediato y enrútelo para la acción posterior correspondiente.

En este blog, mostramos la detección de anomalías en transacciones de la blockchain de Ethereum. Analizamos datos de la blockchain de Ethereum y marcamos transacciones con patrones no válidos en tiempo real. Específicamente, detectamos:

1. Violaciones de calidad de datos: bloques donde gas_used > gas_limit son físicamente imposibles según el protocolo de Ethereum, lo que indica corrupción de datos, errores del productor o fallas en el análisis del esquema
2. Violaciones de higiene del payload: el campo extra_data que contiene patrones reconocibles de PII o credenciales (direcciones de correo electrónico, tokens JWT, claves de acceso de AWS) indica una filtración de datos o productores mal configurados

Aunque utilizamos datos de Ethereum para la demostración, esta clasificación de "sospechoso o no válido" se aplica a numerosos casos de uso de alto valor:

• Detección de fraudes: una transacción presenta patrones anómalos → activa flujos de trabajo de investigación posteriores
• Monitoreo de IoT: la lectura de un sensor queda fuera de los parámetros físicamente posibles → inicia una respuesta automatizada
• Operaciones de seguridad: el payload contiene secretos o patrones de PII → se pone en cuarentena en tiempo real con gobernanza unificada
• Motores de personalización: responden a eventos de comportamiento específicos con ofertas contextuales inmediatas

La misma lógica de detección se aplica directamente a cualquier dominio: transacciones financieras que contienen PII inesperada, payloads de IoT con lecturas de sensores fuera de rango o registros de eventos de API que contienen secretos que deberían haberse redactado. El flujo de Ethereum proporciona un conjunto de datos limpio y reproducible para demostrar el patrón a escala.

Acerca de Spark Real-Time Mode

Real-Time Mode (RTM) es un nuevo tipo de trigger para Apache Spark™ Structured Streaming que ofrece latencia de nivel de milisegundos a las API de Spark, sin necesidad de un motor especializado independiente como Apache Flink.

Mientras que el modo microbatch predeterminado de Structured Streaming funciona como un autobús de enlace de aeropuerto que espera a llenarse antes de salir, RTM funciona como una cinta transportadora de alta velocidad, procesando cada evento a medida que llega. Esto se logra a través de tres innovaciones arquitectónicas: flujo de datos continuo (los eventos se procesan a medida que llegan, no en fragmentos discretos), programación de pipelines (todas las etapas de la consulta se ejecutan simultáneamente, sin bloqueos) y streaming shuffle (los datos se pasan entre tareas inmediatamente en la memoria, evitando el disco).

RTM está diseñado específicamente para cargas de trabajo operativas donde la latencia afecta directamente los resultados del negocio: detección de fraudes, personalización en tiempo real, computación de características de ML y monitoreo de IoT. Para las cargas de trabajo que pueden tolerar de 1 a 2 segundos de latencia, el microbatch tradicional sigue siendo la opción más rentable.

Por qué RTM cambia las reglas del juego

1. Ultrarrápido: latencia de menos de un segundo ahora posible

Real-Time Mode cambia fundamentalmente lo que es posible con Apache Spark. Las latencias de extremo a extremo que van desde ~5 ms hasta ~300 ms, según la complejidad de la carga de trabajo, llevan a Spark al territorio anteriormente dominado por motores de procesamiento de streaming especializados. El microbatch tradicional ofrece una latencia de 1 a 2 segundos; Real-Time Mode logra de ~5 ms a ~300 ms.
La arquitectura lo logra a través de pipelines de ejecución preasignados y checkpointing asíncrono, lo que elimina la sobrecarga de programación que tradicionalmente limitaba el procesamiento de microbatch. Para las cargas de trabajo operativas donde los milisegundos importan (detección de fraudes, monitoreo de IoT, ofertas en tiempo real), este nivel de rendimiento es transformador.

2. Stack simplificado: no se requiere tecnología independiente

Las organizaciones suelen encontrarse con una idea errónea y costosa: "Spark no es lo suficientemente eficiente para casos de uso en tiempo real, por lo que necesitamos un stack completamente independiente para este único requisito".

Para las cargas de trabajo que toleran de 1 a 2 segundos de latencia, el microbatch de Spark entrega datos de manera confiable en Delta Lake con excelentes características de relación precio/rendimiento. Para las cargas de trabajo operativas que exigen tiempos de respuesta de menos de un segundo, Real-Time Mode elimina por completo la necesidad de tecnologías independientes, como lo validaron los equipos de Coinbase, DraftKings y MakeMyTrip, quienes se consolidaron en un único stack basado en Spark tanto para cargas de trabajo analíticas como operativas.

Con Real-Time Mode, Spark maneja cargas de trabajo tanto analíticas (en el rango de segundos) como operativas (en el rango de milisegundos) dentro de una única plataforma unificada. Esto reduce:

• Complejidad operativa: un solo stack tecnológico para administrar, monitorear y solucionar problemas
• Sobrecarga de capacitación: la experiencia existente en Spark se transfiere directamente a los casos de uso en tiempo real
• Fricción de integración: sin traspasos complejos entre motores de streaming independientes
• Costo total de propiedad: la consolidación reduce los costos de infraestructura, licencias y operativos

3. Fácil para los desarrolladores: cambio de trigger simple, sin reescritura de código

Quizás el aspecto más atractivo de Real-Time Mode es su notable simplicidad para los desarrolladores que ya están familiarizados con Structured Streaming. Habilitar esta potente capacidad no requiere una migración compleja ni una reestructuración fundamental del código.

Las organizaciones pueden desbloquear la latencia de nivel de milisegundos simplemente modificando la configuración del trigger:

Eso es todo. La misma API familiar de Structured Streaming. La misma gestión de checkpoints. La misma semántica de entrega al menos una vez. Solo un cambio de configuración para habilitar la inteligencia operativa de menos de un segundo.

Nota sobre las garantías de entrega: RTM con sink de Kafka proporciona garantías de entrega al menos una vez. Los consumidores posteriores deben manejar los posibles duplicados mediante escrituras idempotentes o lógica de deduplicación.

Esta integración perfecta representa una ventaja fundamental. Los equipos pueden crear prototipos y poner en producción cargas de trabajo operativas sin la sobrecarga sustancial de aprender, implementar y administrar stacks tecnológicos completamente independientes. Este enfoque acelera drásticamente la innovación al tiempo que reduce el riesgo asociado tradicionalmente con la adopción de nuevas capacidades en tiempo real.

Una vez establecido por qué es importante Real-Time Mode, examinemos cómo implementar este patrón en la práctica. Las siguientes secciones muestran un pipeline de protección (guardrail) listo para producción: el patrón operativo que convierte estas capacidades en valor comercial.

Descripción general de la arquitectura: creación de un flujo de protección (guardrail) operativo

Cada evento entrante se somete a una evaluación inmediata, lo que produce un evento posterior enriquecido que contiene:

• Decisión: ALLOW frente a QUARANTINE
• Motivos: explicación detallada de cualquier alerta activada (violaciones de calidad de datos, problemas de higiene del payload)

Este patrón operativo sirve como una única fuente de verdad para la toma de decisiones en tiempo real:

• ¿Debería ponerse este evento en cuarentena para su investigación?
• ¿Cómo enriquecemos los eventos para que los sistemas posteriores puedan reaccionar al instante?

Aunque nuestra demostración utiliza datos de bloques de Ethereum, este patrón se aplica de forma universal: transacciones financieras, lecturas de sensores, registros de autenticación, llamadas de API; la arquitectura sigue siendo la misma.

Validación a escala

Fieles a nuestro compromiso con las soluciones de calidad de producción, validamos este patrón a escala. La cadena completa de Ethereum (aproximadamente 95 GB distribuidos en 4 particiones, lo que representa unos 23 millones de mensajes) se cargó en Kafka para realizar pruebas.

Definición de reglas de validación para la clasificación de eventos

Implementamos reglas de validación intencionadamente sencillas y de alta señal:

Regla 1: Validación de higiene de la carga útil (payload)

Escanee el campo extra_data en busca de patrones que indiquen claramente datos que no deberían estar presentes en los flujos de producción. Los ejemplos de código muestran una detección de patrones básica (direcciones de correo electrónico, tokens JWT, formatos de clave de AWS).

Las organizaciones deberían reemplazar estas reglas por otras específicas para sus requisitos de cumplimiento: patrones de PII, identificadores internos, credenciales de API y datos confidenciales similares.

La clave fundamental: Las protecciones en tiempo real deben formar parte del pipeline como parte de una gobernanza unificada, no descubrirse durante el análisis posterior a un incidente.

Regla 2: Validación de la calidad de los datos

gas_used > gas_limit

Esta condición nunca debería ocurrir en datos válidos. Cuando se detecta, indica uno de varios problemas:

• Corrupción de datos durante la transmisión
• Errores de generación de datos en el lado del productor
• Inconsistencias en el análisis del esquema
• Fallos en los sistemas de origen (upstream)

Desde una perspectiva operativa, este es precisamente el tipo de anomalía que queremos marcar de inmediato, lo que permite una respuesta rápida antes de que los sistemas descendentes (downstream) se vean afectados.

Con nuestra lógica de validación establecida, ahora pasamos a la configuración de streaming que permite la ejecución en menos de un segundo.

Modo Real-Time: configuración esencial

El modo Real-Time se habilita a través del activador (trigger) en tiempo real y funciona en modo de actualización (update). En PySpark, se especifica un parámetro de intervalo (por ejemplo, "5 minutes").

Dos requisitos de configuración críticos:

1. Configuración del clúster: La documentación de Databricks especifica los ajustes necesarios del clúster de tareas (job cluster) y la etiqueta de habilitación de RTM
2. Modo de salida (Output mode): Debe utilizar el modo update con activadores (triggers) de RTM

Configuración utilizada en esta demostración:

• Runtime: Databricks Runtime 16.4 LTS o posterior
• Computación: Clúster dedicado (de un solo usuario) con un número fijo de workers (escalado automático desactivado)
• Photon: Desactivado (no es compatible con RTM)
• Workers: 4 workers para esta carga de trabajo
• Modo de salida: update (obligatorio para RTM)

Consulte el repositorio complementario para ver el archivo cluster_config.template.json completo.

Implementación: Pipeline de protección en tiempo real

Este pipeline de una sola pasada demuestra la integración perfecta entre Kafka y el modo Real-Time de Spark:

1. Conectarse al origen de Kafka
2. Analizar las cargas útiles (payloads) JSON entrantes
3. Calcular la decisión y los motivos
4. Escribir el JSON enriquecido de vuelta en Kafka

Puede leer el código aquí.

Resultados: Rendimiento a escala

Validamos el rendimiento del modo Real-Time procesando datos de la blockchain de Ethereum: ~23 millones de mensajes distribuidos en 4 particiones de Kafka en modo de streaming continuo.

Rendimiento de procesamiento (Throughput)

El pipeline demostró unas características de procesamiento impresionantes:

• Tasa de entrada: 65.592 filas/segundo
• Tasa de procesamiento: 69.713 filas/segundo (sostenida)
• Total de registros procesados: ~23.213.628 mensajes
• Configuración del clúster: DBR 16.4 LTS, 4 workers (i3.xlarge), modo dedicado de usuario único, Photon desactivado

Métricas de latencia

Los registros del driver capturan métricas de latencia detalladas a través del evento spark.streaming.madeProgress. El modo Real-Time informa processingLatencyMs, que mide el tiempo transcurrido desde que la consulta lee un registro hasta que lo escribe en el receptor (sink) descendente.

Para este pipeline de validación sin estado (stateless) que procesa ~23 millones de registros, observamos:

• P0, P50, P90, P95: 1 milisegundo (se redondea a 0 en las métricas) P99: 1 milisegundo Tasa de procesamiento: 69.713 filas/segundo sostenida
• Entendiendo processingLatencyMs: Esta métrica mide el tiempo entre que RTM lee un registro y lo escribe en el receptor (sink) descendente. Se mide por tarea y se informa en la sección rtmMetrics.processingLatencyMs de StreamingQueryProgress con percentiles (P0, P50, P90, P95, P99). Para un pipeline Kafka-to-Kafka de una sola etapa como este, representa eficazmente la latencia de extremo a extremo por registro.
• Qué significa esto: La gran mayoría de los registros (percentil 95) se procesaron en menos de medio milisegundo, e incluso el 1 % más lento se completó en 1 milisegundo. Los valores que muestran "0" para P0-P95 indican latencias inferiores a 0,5 ms (redondeadas hacia abajo por el sistema de métricas).

Nota: Estos resultados representan el rendimiento en un pipeline de validación sin estado (stateless). Las operaciones con estado (stateful) más complejas (agregaciones, ventanas) pueden experimentar latencias más altas dentro del rango de RTM de ~5 ms a ~300 ms, según la complejidad de la carga de trabajo.

Información clave sobre el rendimiento

• Interpretación: El 99 % de todos los registros se procesaron en menos de 1 milisegundo, y solo el 1 % más lento alcanzó 1 milisegundo. Esto demuestra un rendimiento de baja latencia excepcionalmente constante.
• Rendimiento (Throughput): El pipeline mantuvo 69.713 filas/segundo mientras procesaba ~23 millones de registros, lo que demuestra un rendimiento estable bajo una carga continua.

Estas métricas validan que el modo Real-Time ofrece una latencia inferior al milisegundo de nivel de producción (P95 0,5 ms, P99 = 1 ms) al tiempo que procesa flujos de gran volumen a casi 70.000 filas/segundo, lo que elimina el dilema tradicional entre las plataformas unificadas y los requisitos de baja latencia.

Conclusión

El modo Real-Time amplía Apache Spark™ Structured Streaming a una nueva clase de cargas de trabajo: aplicaciones operativas y sensibles a la latencia que exigen una respuesta inmediata a los datos en streaming. Al llevar la latencia de menos de un segundo a las API de Spark que su equipo ya utiliza, elimina la necesidad de operar un motor especializado independiente para sus pipelines más críticos en cuanto a tiempo.

La propuesta de valor es convincente:

• Una plataforma unificada maneja cargas de trabajo tanto analíticas (en el rango de segundos) como operativas (en el rango de milisegundos)
• La experiencia existente en Spark se transfiere directamente, sin necesidad de una especialización independiente
• Riesgo de migración mínimo: un único cambio en la configuración del activador (trigger) desbloquea las capacidades en tiempo real
• Rendimiento validado en producción: latencias P99 de 1 ms con P95 por debajo de 0,5 ms procesando millones de eventos

Tanto si está creando pipelines de detección de fraudes, motores de personalización o sistemas de computación de características de ML, el modo Real-Time ofrece la latencia que su aplicación exige, al tiempo que mantiene la sencillez de Spark y la amplitud de su ecosistema.

Primeros pasos

Clone el repositorio complementario para ejecutar este pipeline de protección de extremo a extremo (end-to-end): incluye la implementación completa, la configuración del clúster y la guía de implementación.

Para profundizar más, revise la documentación del modo Real-Time para conocer las opciones de configuración y los orígenes/receptores (sources/sinks) compatibles, o vea el Análisis técnico profundo del modo Real-Time para obtener un recorrido completo por la arquitectura.

Recursos

• Inmersión técnica profunda en el Modo de tiempo real: cómo logramos streaming de menos de 300 milisegundos en Apache Spark™
• Cómo ofrecer latencia de menos de un segundo para cargas de trabajo operativas en Databricks
• Documentación del Modo de tiempo real de Databricks
• Repositorio de código complementario: demostración de guardrails del Modo de tiempo real - Implementación lista para producción con una suite de pruebas completa, configuración de clúster y guía de despliegue

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original