¿Cómo manejas los eventos que llegan tarde en un pipeline de streaming?

Usa tiempo de evento en lugar de tiempo de procesamiento y define un watermark, que es la estimación heurística del motor de que ya no llegarán eventos más antiguos que un timestamp dado. Las ventanas se cierran cuando el watermark pasa su final. Configura una tardanza permitida para que los eventos ligeramente tardíos aún actualicen resultados, y manda todo lo posterior a una salida lateral o a una tabla de reconciliación en lugar de descartarlo en silencio.

Lo primero, todo va indexado por tiempo de evento, porque los resultados por tiempo de procesamiento cambian cada vez que reprocesas y eso los vuelve inútiles para reconciliar. Luego, el watermark es la afirmación del motor de que ya no espera eventos más antiguos que ese timestamp, y las ventanas se cierran cuando lo supera. Elegir ese retraso es la decisión de diseño de verdad: un watermark corto te da resultados rápidos que a veces están incompletos, uno largo te da resultados correctos pero tarde. Yo lo fijo con datos y no con intuición. En un pipeline de una app móvil medimos la diferencia entre tiempo de evento y tiempo de ingesta y vimos que el percentil noventa y nueve estaba en unos cuatro minutos, por teléfonos sin conexión, así que pusimos la tardanza permitida en diez minutos. Todo lo posterior iba a una salida lateral que alimentaba un job diario de reconciliación que corregía las ventanas afectadas en el warehouse. La regla que mantengo es que los datos tardíos nunca se descartan en silencio. Si los tiramos, primero los contamos.