4.2 · Procesamiento en tiempo real: ventanas y tiempos

Batch vs. streaming

El procesamiento batch trabaja sobre conjuntos de datos acotados (bounded): un archivo, una tabla, el log de ayer. Se ejecuta periódicamente (cada hora, cada noche) y produce resultados completos sobre un conjunto cerrado.

El procesamiento streaming trabaja sobre datos no acotados (unbounded): un flujo continuo de eventos que nunca “termina”. El sistema procesa cada evento a medida que llega y emite resultados de forma incremental, con latencias de segundos o milisegundos.

Streaming no reemplaza a batch: son complementarios. De hecho, la arquitectura Lambda (que veremos en la siguiente lección) los combina.

El problema del tiempo: event time vs. processing time

En un stream hay dos relojes distintos:

• Event time: el momento en que el evento ocurrió en el mundo real (timestamp que lleva el propio evento).
• Processing time: el momento en que el sistema procesa el evento (reloj del servidor).

¿Por qué importa la diferencia? Porque los eventos pueden llegar tarde y desordenados: un móvil sin cobertura guarda sus eventos y los envía una hora después; la red introduce retrasos variables. Si agrupamos por processing time, los resultados dependen del azar de la red; si agrupamos por event time, el resultado refleja la realidad — pero tenemos que decidir cuánto esperar a los rezagados.

Ventanas: trocear lo infinito

Para calcular agregados (contar, sumar, promediar) sobre un flujo infinito necesitamos acotarlo en ventanas:

graph LR
subgraph S["Stream de eventos (event time)"]
  direction LR
  E1["e1"] --- E2["e2"] --- E3["e3"] --- E4["e4"] --- E5["e5"] --- E6["e6"] --- E7["e7"]
end
subgraph W1["Ventana 1: 10:00-10:01"]
  E1
  E2
  E3
end
subgraph W2["Ventana 2: 10:01-10:02"]
  E4
  E5
end
subgraph W3["Ventana 3: 10:02-10:03"]
  E6
  E7
end
E1 --> W1
E2 --> W1
E3 --> W1
E4 --> W2
E5 --> W2
E6 --> W3
E7 --> W3
W1 --> R1["count = 3"]
W2 --> R2["count = 2"]
W3 --> R3["count = 2"]

Watermarks: ¿cuándo damos por cerrada una ventana?

Si esperamos a los eventos tardíos, ¿cuánto hay que esperar? Los watermarks responden a esa pregunta: son una marca de progreso del event time que afirma “no espero más eventos con timestamp anterior a T”.

• Cuando el watermark supera el final de una ventana, esta se cierra y emite su resultado.
• Los eventos que lleguen después del watermark se consideran late events y se descartan, se envían a un canal aparte (side output) o se permiten dentro de un allowed lateness adicional.

Es un equilibrio: watermark muy conservador → más completitud pero más latencia; watermark agresivo → baja latencia pero más eventos descartados.

Garantías de entrega

¿Qué pasa si un nodo falla a mitad del procesamiento? Los sistemas de streaming ofrecen distintas semánticas de entrega:

Exactly-once no significa que el evento “se lea una sola vez”, sino que su efecto sobre el estado y la salida se aplica una sola vez, incluso con reintentos y fallos intermedios.

Motores de stream processing

• Spark Structured Streaming: trata el stream como una tabla infinita a la que se le aplican consultas SQL/DataFrame. Usa un modelo de micro-batch (pequeños lotes cada N segundos) con checkpoints que permiten exactly-once. Ideal si ya usas el ecosistema Spark.
• Apache Flink: motor de streaming puro, evento a evento, con soporte de primer nivel para event time, watermarks, estado con checkpoints y exactly-once. Referencia para casos de baja latencia y lógica de ventanas compleja.

Ambos se integran con Kafka como fuente y destino: Kafka actúa como el “hub” de eventos y el motor como el cerebro que los procesa.

Ejercicio: ventana tumbling por minuto

from datetime import datetime, timezone

def ventana_tumbling(eventos, tam=60):
  ventanas = {}
  for ts, _valor in eventos:
      inicio = (ts // tam) * tam
      ventanas[inicio] = ventanas.get(inicio, 0) + 1
  return ventanas

# Eventos: (timestamp unix, valor)
eventos = [
  (1_700_000_005, "clic"),
  (1_700_000_012, "clic"),
  (1_700_000_041, "clic"),
  (1_700_000_067, "clic"),
  (1_700_000_099, "clic"),
  (1_700_000_130, "clic"),
]

conteo = ventana_tumbling(eventos)
for inicio, n in sorted(conteo.items()):
  hora = datetime.fromtimestamp(inicio, tz=timezone.utc).strftime("%H:%M:%S")
  print(f"Ventana [{hora}, +60s): {n} eventos")

Comprueba lo aprendido

Resumen

• Batch procesa datos acotados con alta latencia; streaming procesa flujos continuos con baja latencia.
• Las ventanas acotan el flujo: tumbling (fijas sin solape), sliding (con solape) y session (por inactividad).
• Event time refleja cuándo ocurrió el evento; processing time, cuándo se procesó. Los eventos llegan tarde y desordenados.
• Los watermarks marcan hasta qué punto del event time esperamos eventos, y deciden cuándo cerrar ventanas.
• Las garantías van de at-most-once (pérdidas posibles) a exactly-once (efecto único), pasando por at-least-once (duplicados posibles).
• Spark Structured Streaming (micro-batch) y Flink (streaming puro) son los motores de referencia, usualmente sobre Kafka.

📚 Lecturas y fuentes