Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLecció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.
17 min aprox.
01Modelo mentalSchedule 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.
+
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.
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.
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.
¿Por qué UTC no siempre puede sustituir la zona de negocio en un cierre diario?
Profundiza
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.
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.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.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.Resumen
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.