Elegir entre batch y streaming: latencia requerida, tiempo de evento y datos tardíos

Qué es

Un trabajo batch lee una entrada acotada, normalmente un intervalo de planificación, después de que el intervalo ha terminado, y escribe un resultado que puede recalcularse en cualquier momento a partir de la misma entrada. Un trabajo de streaming lee una entrada no acotada, que la documentación de Dataflow (citada) describe como una colección con un número potencialmente infinito de elementos por clave, de modo que agrupar solo por clave es imposible y la agregación requiere ventanas, watermarks y triggers. Un watermark es el umbral en el que el sistema espera que hayan llegado todos los datos de una ventana, y los datos que llegan después con una marca de tiempo dentro de esa ventana son datos tardíos. La documentación de Flink (citada) distingue dos nociones de tiempo: el tiempo de procesamiento (processing time), que es el reloj de la máquina que ejecuta el operador, es la opción más simple y de menor latencia, pero no es determinista, porque los resultados dependen de la velocidad de llegada y de las interrupciones; y el tiempo de evento (event time), que es el momento en que ocurrió cada evento en el dispositivo que lo produjo, da resultados consistentes incluso con eventos desordenados o al reprocesar el historial, a costa de esperar a los rezagados, y solo durante un tiempo finito, ya que algunos elementos pueden retrasarse de forma arbitraria.

Por qué importa

La diferencia no es la velocidad, sino la semántica. El total batch del lunes queda definido por las filas presentes cuando se ejecutó el trabajo; el total en streaming del lunes es una secuencia de resultados provisionales que aún pueden cambiar cuando lleguen eventos tardíos, y el diseño debe indicar si esos eventos se descartan, se emiten como correcciones o se ignoran. Los equipos que adoptan streaming para un panel que se actualiza cada hora pagan por el estado, los checkpoints y un trabajo siempre activo sin que nadie aproveche la latencia que han comprado.

Cómo aplicarlo

• Partir del consumidor: nombrar la acción que se toma con el resultado y cuánto tiempo después del evento debe ocurrir. Solo una reacción en un plazo de segundos a un minuto justifica una vía de streaming; un informe puede esperar a que se cierre el intervalo.
• Si el streaming está justificado, usar tiempo de evento, definir de forma explícita el retraso permitido (allowed lateness) y enviar los eventos tardíos a una salida lateral (side output) que consuma una corrección batch.
• Mantener una vía de reprocesamiento batch incluso para resultados calculados en streaming: es la referencia de corrección, la herramienta de recuperación tras un error y el modo de rellenar el historial (backfill).
• Considerar micro-batches (de minutos) antes que un motor continuo; conservan la semántica batch con menor latencia.

Trampas

Los joins en streaming mantienen estado durante la ventana del join en ambos lados; las ventanas sin límite implican memoria sin límite. La salida exactly-once exige destinos (sinks) idempotentes o transaccionales, y no basta con un ajuste del motor. Dos respuestas para la misma métrica, una en streaming y otra en batch, deben conciliarse; de lo contrario los consumidores no se fiarán de ninguna.