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

Operación

Contenido abierto

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

Professional

Triggers, alertas, backfills y operación

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

Lectura pública
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.

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.
Duración estimada
17 min aprox.
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
02
Implementación

File arrival y table update

File arrival monitoriza una external location o Volume de Unity Catalog y usa cooldown/debounce para convertir múltiples archivos en runs controlados.

Objetivo
File arrival monitoriza una external location o Volume de Unity Catalog y usa cooldown/debounce para convertir múltiples archivos en runs controlados.
Duración estimada
17 min aprox.
Dificultad
Professional
Prerrequisitos
m20
Reportar un error en esta lección

El trigger observa una raíz o subruta y comprueba recursivamente nuevas llegadas. Con managed file events en la external location, Databricks aprovecha notificaciones del proveedor y reduce listing. El Job necesita permisos de lectura sobre la ubicación y administración del Job.

`wait_after_last_change_seconds` implementa debounce: espera un periodo sin cambios para agrupar un lote. `min_time_between_triggers_seconds` limita frecuencia. Ninguno garantiza completitud absoluta; productores serios publican un manifiesto o marcador y el código valida conteos antes de promover.

Modelo mental

File arrival monitoriza una external location o Volume gobernado por Unity Catalog y convierte notificaciones de objetos en runs. Con file events habilitados en la external location, la plataforma usa eventos del proveedor para mayor eficiencia y escalabilidad; sin ellos puede depender de mecanismos de listing con más límites. `Wait after last change` actúa como debounce: cada llegada reinicia la espera para agrupar una ráfaga. `Minimum time between triggers` limita frecuencia después de un run. Ninguno garantiza que un archivo haya terminado de escribirse correctamente ni que pertenezca al contrato; productores deben publicar atómicamente o acompañarlo de manifest. El Job no debe confiar solo en el nombre recibido: Auto Loader o una tabla de control conserva qué archivos fueron procesados. Eventos duplicados o agrupados son normales y la carga debe converger.

File events

Notificaciones de cambios de almacenamiento configuradas en una external location para evitar listing repetitivo y detectar llegadas eficientemente.

Mejoran escala y latencia de triggers y Auto Loader, pero necesitan configuración y permisos del entorno cloud.
Debounce

Espera que se reinicia con cada cambio adicional para agrupar una ráfaga antes de iniciar un único run.

Evita procesar entregas multipart incompletas y reduce overhead de numerosos runs casi simultáneos.
Manifest

Archivo o registro de control que declara partes, conteos, checksums y completitud de una entrega lógica de datos.

Permite distinguir una llegada visible de un dataset realmente completo y seguro para publicar.
JSONTrigger de llegada con debounce
{
  "trigger": {
    "file_arrival": {
      "url": "/Volumes/main/landing/orders/",
      "min_time_between_triggers_seconds": 900,
      "wait_after_last_change_seconds": 60
    }
  }
}

El ejemplo espera 60 segundos de calma y no crea runs con menos de 15 minutos de separación.

Puntos clave

  • La ruta debe estar gobernada por Unity Catalog como external location o Volume.
  • Debounce agrupa ráfagas; cooldown limita runs consecutivos.
  • File events mejoran descubrimiento, pero la idempotencia sigue residiendo en el pipeline.

Evita

  • Apuntar a una ruta no gobernada o sin permisos y asumir que el trigger hereda credenciales del notebook.
  • Tratar el primer archivo como prueba de lote completo cuando el productor publica decenas durante varios minutos.

Recuerdo activo

¿Qué diferencia hay entre cooldown y debounce?

Borrador privado · solo en este navegador
03
Operación

Continuous y triggered pipelines

Table update inicia un Job cuando cambian tablas Unity Catalog y entrega la lista actualizada como referencia dinámica para procesamiento selectivo.

Objetivo
Table update inicia un Job cuando cambian tablas Unity Catalog y entrega la lista actualizada como referencia dinámica para procesamiento selectivo.
Duración estimada
17 min aprox.
Dificultad
Professional
Prerrequisitos
m20
Reportar un error en esta lección

Es útil cuando una publicación Delta upstream es la señal autoritativa y no interesa observar archivos físicos. El trigger puede monitorizar una o varias tablas y el downstream consulta `{{job.trigger.table_update.updated_tables}}` para saber cuáles cambiaron desde el run anterior.

La señal no debe convertirse en lógica frágil por tabla sin fallback. Un Job puede recibir varias actualizaciones coalescidas y debe leer el estado confirmado de cada tabla. Si se requiere orden transaccional entre varias tablas, un trigger separado no crea esa transacción; se necesita un marcador de publicación o una capa coordinadora.

Modelo mental

Table update trigger inicia un Job cuando cambian tablas o vistas soportadas de Unity Catalog. Puede vigilar una sola fuente o varias y disparar cuando se actualice cualquiera (`Any`) o cuando todas hayan cambiado (`All`). La señal se refiere a commits observados, no necesariamente a filas relevantes para la consulta downstream: una vista filtrada puede considerarse actualizada aunque el cambio quede fuera del filtro. Las referencias dinámicas exponen lista de tablas actualizadas y, según el caso, versión y timestamp de commit; permiten procesamiento selectivo y auditoría. `Wait after last change` y mínimo entre triggers agrupan oleadas de commits. File events en las ubicaciones subyacentes mejoran rendimiento y habilitan capacidades relacionadas. El Job conserva de todos modos una tabla de control o checkpoints, porque dos commits pueden agruparse y una notificación no define exactamente el rango consumido.

Updated tables reference

Lista dinámica de objetos que el table update trigger observó como modificados para el contexto del run creado.

Permite saltar ramas innecesarias y conservar evidencia de por qué se inició la ejecución.
Any versus All

Política que dispara cuando cambia al menos una tabla vigilada o espera a que todas registren actualización respectivamente.

Debe corresponder al contrato de coordinación upstream para evitar runs prematuros o bloqueados.
Commit signal

Indicación de que un objeto gobernado registró una actualización, independientemente de si todas sus filas afectan al producto downstream.

Evita interpretar el trigger como una prueba de cambio semántico y justifica filtrado y checkpoint propios.
JSONPaso de tablas actualizadas a una tarea
{
  "task_key": "refresh_consumers",
  "notebook_task": {
    "notebook_path": "/Workspace/commerce/refresh_consumers",
    "base_parameters": {
      "updated_tables": "{{job.trigger.table_update.updated_tables}}",
      "trigger_type": "{{job.trigger.type}}"
    }
  }
}

El notebook debe validar el JSON y ser capaz de actualizar todas las tablas relevantes aunque varias aparezcan en el mismo run.

Puntos clave

  • Table update reacciona al objeto gobernado, no a su implementación de archivos.
  • La lista de tablas actualizadas está disponible mediante dynamic value reference.
  • Una notificación puede representar varios cambios y no sustituye un contrato de consistencia multitabla.

Evita

  • Monitorizar archivos de una tabla Delta y disparar antes de que el commit sea visible.
  • Suponer que una señal por cada tabla ofrece una snapshot consistente entre varias tablas relacionadas.

Recuerdo activo

¿Qué ventaja tiene table update sobre observar archivos internos Delta?

Borrador privado · solo en este navegador
04
Diagnóstico

Backfills y ventanas de proceso

Concurrencia, queueing, timeouts y notificaciones determinan cómo responde el Job cuando llegan triggers más rápido de lo que termina el trabajo.

Objetivo
Concurrencia, queueing, timeouts y notificaciones determinan cómo responde el Job cuando llegan triggers más rápido de lo que termina el trabajo.
Duración estimada
17 min aprox.
Dificultad
Professional
Prerrequisitos
m20
Reportar un error en esta lección

Por defecto, un Job suele admitir un run activo. Aumentar `max_concurrent_runs` puede reducir espera, pero solo si runs simultáneos escriben rangos aislados. Si no, aparecen carreras y sobrecarga. Queueing conserva runs cuando no hay capacidad; omitirlo o superar límites puede producir skips.

Continuous inicia otro run al completar o fallar el anterior y aplica reintentos/backoff propios. Es adecuado para servicios siempre activos, no para un batch que espera datos. Las notificaciones se configuran para fallo, duración o atraso y deben incluir owner y contexto sin secretos.

Modelo mental

Concurrencia describe cuántos runs del mismo Job pueden estar activos; queueing decide si un run espera cuando no hay capacidad; timeouts acotan cuánto puede permanecer una tarea o run; notificaciones comunican estados relevantes. Estos controles forman una política de presión, no simples opciones. La configuración segura por defecto suele ser una ejecución concurrente para evitar que dos runs escriban el mismo periodo. Aumentarla solo es correcto si ventanas, staging, checkpoints y efectos están aislados. Cuando los triggers llegan más rápido que el procesamiento, poner todo en cola conserva trabajo pero aumenta frescura y puede crear una deuda imposible; omitir runs es aceptable únicamente si el siguiente procesa acumulativamente desde un checkpoint. Timeouts deben exceder p99 normal y activar cancelación idempotente, no matar cargas sanas durante picos. Las alertas incluyen inicio tardío, duración, fallo y pérdida de SLA, no solo estado final.

Max concurrent runs

Límite configurado de ejecuciones simultáneas del mismo Job que el scheduler admite antes de aplicar espera u omisión.

Protege targets y dependencias, y solo debe crecer cuando existe aislamiento demostrable entre runs.
Queueing

Política que mantiene un run pendiente hasta disponer de capacidad en lugar de descartarlo inmediatamente por límites de concurrencia.

Preserva trabajo, pero transforma saturación en latencia acumulada que debe medirse contra frescura.
Timeout

Límite de tiempo tras el cual una tarea o ejecución se cancela y adopta un estado terminal de fallo.

Contiene bloqueos y coste, pero necesita idempotencia porque cancelar no deshace efectos externos ya confirmados.
YAMLGuardrails de ejecución
max_concurrent_runs: 1
queue:
  enabled: true
timeout_seconds: 7200
email_notifications:
  on_failure:
    - data-platform-oncall@example.invalid
  on_duration_warning_threshold_exceeded:
    - data-platform-oncall@example.invalid

La dirección `.invalid` es deliberadamente ficticia; reemplázala por un destino gestionado del entorno.

Puntos clave

  • Más concurrencia solo es segura con entradas y efectos aislables.
  • Queueing gestiona presión del planificador; no corrige un Job más lento que la llegada indefinidamente.
  • Timeout y alertas delimitan fallos colgados y protegen el SLO.

Evita

  • Aumentar concurrencia para reducir cola mientras todos los runs sobrescriben la misma partición.
  • Usar continuous para una fuente ociosa y pagar reinicios/compute sin mejorar frescura.

Recuerdo activo

¿Cuándo es seguro permitir varios runs concurrentes del mismo Job?

Borrador privado · solo en este navegador
05
Decisión de diseño

Alertas, webhooks y ownership

Un backfill reutiliza el mismo Job parametrizado que producción para ejecutar intervalos históricos, con concurrencia y publicación controladas.

Objetivo
Un backfill reutiliza el mismo Job parametrizado que producción para ejecutar intervalos históricos, con concurrencia y publicación controladas.
Duración estimada
17 min aprox.
Dificultad
Professional
Prerrequisitos
m20
Reportar un error en esta lección

Lakeflow Jobs puede generar múltiples runs para un rango e intervalo y pasar parámetros de backfill. El código usa `process_date` o límites temporales explícitos y escribe idempotentemente la partición correspondiente. Mantener una ruta de código distinta para históricos provoca divergencia justo cuando más se necesita fiabilidad.

Antes de lanzar noventa días se calcula número de runs, volumen, coste, capacidad de origen y colisión con producción. Puede reducirse concurrency, escribir en una tabla sombra y promover por lotes. La validación compara conteos y totales por día, y el rollback conoce exactamente qué particiones tocó.

Modelo mental

Un backfill es una ejecución histórica del mismo contrato de transformación, delimitada por parámetros reproducibles y aislada de la publicación corriente. No debería requerir copiar un notebook y cambiar fechas manualmente. El Job acepta `start`, `end`, versión de código y modo, lee una fuente durable y escribe staging o particiones deterministas. La granularidad equilibra paralelismo y overhead; For each por día puede servir para meses, mientras millones de claves pertenecen a Spark. El backfill coexiste con producción mediante rangos no solapados o un paso serial de reconciliación. Debe cubrir inserts, updates y deletes, no solo añadir filas faltantes. Una vez validado, un `MERGE`, replaceWhere controlado o cutover publica el resultado. El checkpoint streaming de producción no se rebobina, y los efectos externos permanecen deshabilitados o idempotentes durante historia.

Intervalo cerrado-abierto

Rango temporal que incluye su inicio y excluye su final, permitiendo concatenar particiones sin huecos ni doble conteo fronterizo.

Hace deterministas backfills por día u hora y evita duplicar eventos exactamente en medianoche.
Backfill id

Identificador único de la campaña histórica que acompaña staging, métricas, logs, approvals y acciones de publicación asociadas.

Permite auditar, reparar y revertir una corrección sin mezclarla con runs normales o campañas anteriores.
Punto de corte

Versión u instante hasta el cual se reconstruye historia antes de reconciliar cambios nuevos que producción continúa generando.

Evita carreras y pérdida de updates durante una reconstrucción larga que convive con el flujo activo.
SQLTransformación idempotente por fecha
MERGE INTO main.silver.orders_daily AS target
USING (
  SELECT *
  FROM main.bronze.orders
  WHERE event_date = :process_date
) AS source
ON target.order_id = source.order_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

El parámetro del run delimita el rango, mientras `MERGE` permite reintentar el mismo día sin duplicar claves.

Puntos clave

  • Backfill y ejecución ordinaria comparten artefacto y contrato.
  • Parámetros temporales deben ser explícitos y usar límites no solapados.
  • Coste, concurrencia y reconciliación se estiman antes de crear cientos de runs.

Evita

  • Crear un notebook especial para backfill que ya no comparte validaciones ni lógica de producción.
  • Lanzar todos los días con máxima concurrencia y degradar el workload diario o la fuente.

Recuerdo activo

¿Qué evita que reintentar un día de backfill duplique filas?

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