Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lecció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.
- Duración
- 17 min aprox.
- Objetivo
- 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.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Estado, ventanas, watermarks y datos tardíos
Controla el crecimiento de estado y la corrección temporal con eventos fuera de orden.
- Definir event time y processing time
- Aplicar watermark con intención
- Deduplicar y agregar ventanas acotando estado
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.
Modelo mental
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.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.
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.
Recuerdo activo