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

Schedule y time zones

Contenido abierto

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

Lección 1 de 5

Schedule y time zones

Un trigger se elige por la señal real de disponibilidad: calendario para obligaciones temporales, evento para llegadas irregulares y ejecución continua para servicios siempre activos.

Duración
17 min aprox.
Objetivo
Un trigger se elige por la señal real de disponibilidad: calendario para obligaciones temporales, evento para llegadas irregulares y ejecución continua para servicios siempre activos.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Triggers, alertas, backfills y operación

Opera pipelines según disponibilidad real del dato y recupera ventanas históricas sin romper producción.

Al terminar podrás
  • Elegir trigger por evento o calendario
  • Diseñar backfills seguros
  • Crear alertas accionables y SLOs
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
pipelines
Dominios blueprint
Monitoring and Alerting · Orchestration
Estado
Revisión editorial interna
Fuentes principales
Automate jobs with schedules and triggers · Databricks · Trigger jobs when new files arrive · Databricks
Reportar un error
01
Modelo mental

Schedule y time zones

Un trigger se elige por la señal real de disponibilidad: calendario para obligaciones temporales, evento para llegadas irregulares y ejecución continua para servicios siempre activos.

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

Un schedule es apropiado cuando el negocio define un corte, por ejemplo cerrar ventas a las 06:00 Europe/Madrid aunque no haya archivos. La zona horaria debe ser explícita y los cambios DST pueden producir intervalos irregulares; UTC simplifica cadencia técnica, pero quizá no coincide con el día de negocio.

Un trigger por archivo o tabla evita polling y runs vacíos cuando la llegada es irregular. Sin embargo, un evento indica que hubo un cambio, no que un lote multiarchivo esté completo. El pipeline conserva idempotencia y consulta su propia frontera de datos en vez de asumir que cada trigger corresponde a un único lote.

Modelo mental

Un trigger debe representar la señal que afirma que existe trabajo, no la costumbre de ejecutar cada hora. Un schedule expresa una obligación temporal aunque no haya datos; file arrival reacciona a nuevos objetos en una ubicación gobernada; table update reacciona a commits de datasets compatibles; continuous inicia un run tras otro para servicios siempre activos. La señal no sustituye idempotencia: eventos pueden agruparse, repetirse o llegar mientras otro run está activo. Tampoco determina por sí sola la ventana de datos; el Job calcula límites reproducibles a partir del trigger y su checkpoint o tabla de control. Schedules incorporan timezone y horario de verano; triggers por evento incorporan espera tras el último cambio y mínimo entre ejecuciones. Elegir correctamente reduce polling y compute ocioso, pero exige entender disponibilidad de file events, permisos y comportamiento cuando se alcanza la concurrencia máxima.

Schedule trigger

Regla temporal con frecuencia y zona horaria que inicia runs incluso cuando ninguna fuente comunica una llegada de datos.

Es apropiada para obligaciones de calendario, pero exige manejo explícito de ventanas, festivos y horario de verano.
Event trigger

Mecanismo que inicia un run al observar llegada de archivo, actualización de tabla u otro cambio soportado y gobernado.

Reduce polling y latencia ociosa, aunque la señal debe agruparse y no garantiza contenido válido.
Continuous trigger

Modo de Jobs que mantiene servicio iniciando un nuevo run después de terminar o fallar el anterior con manejo específico.

Encaja con cargas siempre activas, pero requiere costes, retries y ausencia de trabajo cuidadosamente controlados.
YAMLSchedule con zona y pausa inicial
schedule:
  quartz_cron_expression: "0 0 6 * * ?"
  timezone_id: "Europe/Madrid"
  pause_status: "PAUSED"

Despliega el trigger pausado en producción, valida parámetros y permisos, y actívalo mediante el proceso de cambio aprobado.

Puntos clave

  • Schedule expresa tiempo; file/table update expresa disponibilidad observada.
  • Zona horaria y DST forman parte del contrato de un calendario.
  • Todo trigger puede coalescer o repetir señales; la tarea sigue siendo idempotente.

Evita

  • Usar la zona local por defecto y descubrir que el Job cambia de hora alrededor de DST.
  • Programar cada minuto una fuente que entrega un lote diario y generar 1.439 ejecuciones vacías.

Recuerdo activo

¿Por qué UTC no siempre puede sustituir la zona de negocio en un cierre diario?

Borrador privado · solo en este navegador
5 lecciones pendientes

Fuente revisada · vista externa

Databricks Free Declarative Pipelines

Databricks Free Declarative Pipelines · commit a515370

docs/3-2-building-bronze-sql.md

Lectura en GitHub

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
andkret
Licencia
No verificada
Formato
project
Ver notebook en GitHub