Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 1 de 5
Event time frente a processing time
El event time pertenece al hecho de negocio; el processing time describe cuándo lo observa la plataforma y no corrige el desorden de llegada.
17 min aprox.
01Modelo mentalEvent time frente a processing time
El event time pertenece al hecho de negocio; el processing time describe cuándo lo observa la plataforma y no corrige el desorden de llegada.
+
Event time frente a processing time
El event time pertenece al hecho de negocio; el processing time describe cuándo lo observa la plataforma y no corrige el desorden de llegada.
Un pago generado a las 10:03 puede llegar a las 10:17 por una desconexión móvil. Agrupar por la hora de ingesta lo asignaría a una ventana distinta y haría que un reproceso produzca otro resultado. La columna de event time debe proceder del evento, convertirse a `timestamp` y validarse antes de cualquier operación temporal.
El retraso `processing_time - event_time` es una distribución, no una constante. Para elegir tolerancia se estudian percentiles y casos extremos por fuente. Un reloj del productor defectuoso debe enviarse a cuarentena; ampliar indefinidamente el watermark para ocultarlo traslada el problema al state store.
from pyspark.sql import functions as F
events = (
raw.withColumn("event_ts", F.to_timestamp("event_time_iso"))
.withColumn("ingested_at", F.current_timestamp())
.withColumn(
"lateness_seconds",
F.col("ingested_at").cast("long") - F.col("event_ts").cast("long")
)
)
valid = events.where("event_ts IS NOT NULL AND lateness_seconds >= 0")Conserva ambos tiempos: uno gobierna la semántica y el otro permite medir el comportamiento de la fuente.
¿Por qué un reproceso debe conservar el event time original?
Profundiza
Event time y processing time responden preguntas diferentes. Event time pertenece al hecho: cuándo ocurrió la compra, lectura o clic según el productor. Processing time pertenece a la plataforma: cuándo el evento fue observado y transformado. En un sistema distribuido, reintentos, desconexiones móviles, buffers y particiones hacen que el orden de llegada difiera del orden de negocio. Structured Streaming no puede corregir ese desorden mirando el reloj del cluster; necesita una columna de event time válida y una política explícita de tardanza. El modelo mental útil es una línea temporal que avanza con evidencia imperfecta: cada fuente revela máximos observados, el watermark deriva una frontera conservadora y los operadores deciden cuándo dejar de esperar. Antes de agregar, hay que normalizar zona horaria, precisión, valores imposibles y semántica del productor, porque un timestamp incorrecto puede adelantar la frontera y expulsar datos legítimos.
Instante en que ocurrió el hecho según el dominio productor, transportado como parte del evento.
Es la base correcta para ventanas, orden de negocio y análisis reproducible pese a retrasos de red.Instante en que el motor recibe o procesa el evento en una ejecución concreta.
Sirve para operación y triggers, pero produce resultados dependientes de retrasos y reejecuciones si se usa como tiempo de negocio.Marca añadida al entrar en una frontera controlada de la plataforma.
Permite medir retraso y detectar relojes anómalos sin sustituir la semántica del event time.Resumen
Puntos clave
- Event time determina ventanas reproducibles; processing time mide la observación del sistema.
- La calidad y zona horaria del timestamp son parte del contrato del evento.
- La distribución de tardanza informa el watermark y el SLA de correcciones.
Evita
- Usar `current_timestamp()` como event time porque siempre está presente, haciendo que un replay cambie los resultados.
- Aceptar timestamps sin zona o muy futuros y permitir que adelanten prematuramente el watermark.