Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 14 · Lección

Ventanas tumbling y sliding

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.

Lección 2 de 5

Ventanas tumbling y sliding

Una ventana agrupa por event time y el watermark limita cuánto estado se conserva antes de considerar una ventana finalizable.

Duración
17 min aprox.
Objetivo
Una ventana agrupa por event time y el watermark limita cuánto estado se conserva antes de considerar una ventana finalizable.
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.

Al terminar podrás
  • Definir event time y processing time
  • Aplicar watermark con intención
  • Deduplicar y agregar ventanas acotando estado
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
streaming
Dominios blueprint
Streaming state · Reliability
Estado
Revisión editorial interna
Fuentes principales
Apply watermarks to control data processing thresholds · Databricks · dropDuplicatesWithinWatermark · Databricks PySpark reference
Reportar un error
02
Implementación

Ventanas tumbling y sliding

Una ventana agrupa por event time y el watermark limita cuánto estado se conserva antes de considerar una ventana finalizable.

Mostrar prerrequisitos
Dificultad
Professional
Prerrequisitos
m13
Reportar un error en esta lección

Las ventanas tumbling no se solapan; las sliding pueden asignar el mismo evento a varias ventanas. En una agregación, Spark mantiene acumuladores para ventanas todavía abiertas. El watermark avanza a partir del máximo event time observado menos el retraso configurado y permite retirar estado antiguo.

Una tolerancia corta reduce memoria y acelera resultados finales, pero descarta más eventos tardíos. Una tolerancia larga mejora completitud a costa de latencia y estado. La decisión debe expresar un compromiso medible, por ejemplo aceptar el 99,5% de eventos en quince minutos y corregir el resto mediante un proceso separado.

Modelo mental

Una ventana transforma un flujo infinito en grupos temporales finitos; un watermark proporciona la evidencia para dejar de mantener algunos de esos grupos. No es un temporizador que espera exactamente N minutos después de cada evento ni una promesa de que todo lo anterior se descartará en un instante preciso. Spark observa el máximo event time visto y resta el retraso configurado para obtener una frontera. Una ventana cuyo final queda suficientemente atrás puede cerrarse y su estado eliminarse según el modo de salida. El compromiso es explícito: ampliar la tardanza protege más eventos desordenados, pero conserva más claves y ventanas, aumenta checkpoint y retrasa resultados finales. Reducirla mejora coste y latencia a cambio de una ruta de excepciones. La columna marcada debe ser la misma que alimenta `window`; perder su metadato mediante expresiones mal ubicadas puede impedir el comportamiento esperado.

Ventana tumbling

Intervalos contiguos de tamaño fijo sin solapamiento, donde cada evento pertenece a una sola ventana.

Simplifica totales por minuto u hora y limita el número de acumuladores activos por clave.
Ventana sliding

Intervalos de tamaño fijo iniciados con una cadencia menor, de modo que un evento puede pertenecer a varias ventanas.

Permite métricas móviles, pero multiplica actualizaciones y estado respecto a una ventana tumbling.
Watermark

Frontera derivada del máximo event time observado menos una tolerancia de tardanza.

Da al motor una condición para limpiar estado y al negocio una política cuantificable sobre datos tardíos.
PySparkVentas por ventanas de cinco minutos
from pyspark.sql import functions as F

sales_5m = (
    events.withWatermark("event_ts", "15 minutes")
      .groupBy(F.window("event_ts", "5 minutes"), "store_id")
      .agg(
          F.countDistinct("order_id").alias("orders"),
          F.sum("amount").alias("revenue")
      )
)

El retraso de quince minutos debe justificarse con la distribución real de tardanza y el SLA de publicación.

Puntos clave

  • Watermark no significa esperar exactamente ese tiempo desde la llegada de cada fila.
  • La columna marcada debe participar en la ventana o condición temporal del operador stateful.
  • Output mode y watermark determinan cuándo se emiten y retiran resultados.

Evita

  • Aplicar `withWatermark` a una columna y agrupar por otra, impidiendo que el operador use la marca temporal esperada.
  • Elegir un watermark igual al intervalo de trigger; resuelven problemas diferentes.

Recuerdo activo

¿Qué se sacrifica al reducir de una hora a diez minutos el watermark?

Borrador privado · solo en este navegador
5 lecciones pendientes

Fuente revisada · vista externa

Azure Databricks Hands-on

Azure Databricks Hands-on · commit a91650b

HandsOn.dbc

Archivo importable

Este notebook se abre desde su fuente revisada

El repositorio no permite republicar su contenido dentro de Lakehouse Lab. Conservamos la misma experiencia lateral, la ruta exacta y el commit auditado, y dejamos la lectura en GitHub para respetar la autoría.

Autor
Tsuyoshi Matsuzaki
Licencia
No verificada
Formato
dbc
Abrir / descargar .dbc