Streaming y eventos
Lote frente a flujo
El lote procesa un conjunto acotado y acabado, con comodidad de ver todo antes de agregar. El flujo procesa registros que nunca terminan de llegar, agregando sobre fragmentos en movimiento y respondiendo sin esperar al final.
Microbatch y de evento
- Spark Streaming procesa en microbatches: trozos pequeños que simulan flujo con latencia mayor.
- El procesamiento de un evento a la vez baja la latencia pero complica el orden y el estado.
- Elegir entre ambos es un reparto entre latencia aceptable y simplicidad operativa.
Ventanas
Para agregar hay que cortar el tiempo en ventanas: por cada cinco minutos, deslizantes de uno en uno, o por sesiones de actividad. La ventana define qué cuenta con qué y con qué frecuencia se emite.
Reloj de evento frente a proceso
El tiempo real del servidor traiciona: un evento llega hoy con marca de ayer. El reloj de evento usa el instante que el propio dato declara, y sobre él se abren y cierran ventanas, con marcas de agua que dicen «hasta aquí ya no llegarán más tarde».
Fuera de orden
Tolerar llegada tardía exige mantener la ventana abierta un margen extra y decidir si un evento tarde actualiza un resultado ya emitido o se descarta. Ese margen es coste de estado a cambio de exactitud.
Garantías de entrega
Los brokers ofrecen al menos una vez, que obliga a deduplicar en el receptor, o exactamente una vez, más cara y con checkpoints. Elegir mal significa perder eventos o contarlos dos veces.
Estado y watermarks
Un agregado sobre flujo mantiene estado por clave, y los watermarks indican que el tiempo avanzó lo suficiente para cerrar ventanas. Sin ellos, una ventana jamás se cierra por si acaso llega algo más tarde.
Errores frecuentes
- Asumir que los eventos llegan ordenados y cerrar la ventana al primer silencio.
- Usar el reloj del servidor en vez del tiempo del evento y contar hoy lo que ocurrió ayer.
- Elegir exactamente una vez sin necesidad, o al menos una vez sin deduplicar.
Ejemplo resuelto: panel de ventas con cobros tardíos
Un panel en vivo suma ventas por minuto, pero algunos pagos llegan con segundos de retraso y generan picos falsos. El arreglo:
- Adoptar el reloj de evento, asignando cada suceso a la ventana de su marca de tiempo.
- Tolerar llegadas tardías manteniendo la ventana abierta un margen acotado.
- Definir el watermark que indica cuándo cerrar y emitir sin esperar ya más retrasos.
- Decidir si un evento muy tardío corrige lo emitido o se descarta y se registra.
- Vigilar el tamaño del estado que exige la tolerancia y ajustar el margen.
¿Para qué sirve en la realidad?
Detección de fraude, monitorización industrial o paneles de venta en vivo exigen responder sin esperar al lote nocturno. El modelo de tiempo bien elegido separa un panel fiable de uno que miente en cada arranque.
Una métrica por ventanas de un minuto muestra picos falsos porque algunos eventos llegan con varios segundos de retraso y caen en la ventana ya cerrada. El ajuste más directo es:
En procesamiento de streaming, el reloj de procesamiento siempre refleja mejor el momento real del evento que el reloj de evento.
Streaming
Ordena el tratamiento de un evento en una ventana tolerante a retrasos:
Llegada
Ventana
Tarde
Cierre
Apache Kafka
Plataforma de eventos y colas que suele alimentar pipelines de streaming.
Une cada noción del streaming con su definición.
Tiempo casi real, decisiones reales
# Streaming de eventos ## Modelo ### microbatch simple ### evento a evento veloz ## Ventanas ### fijas o deslizantes ### por sesión de actividad ## Tiempo ### reloj de evento ### watermarks ### tolerar retrasos ## Entrega ### al menos una vez ### exactamente una vez con estado
Structured Streaming en Spark
Guía oficial del procesamiento de flujos con ventanas y watermarks.
Tu panel de ventas en vivo muestra el total del día. Si un pago se registra seis horas tarde, ¿debe corregir el total ya mostrado? Razona por reloj de evento, watermark y coste de estado.