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

Continuous y triggered pipelines

Contenido abierto

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

Lección 3 de 5

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.

Duración
17 min aprox.
Objetivo
Table update inicia un Job cuando cambian tablas Unity Catalog y entrega la lista actualizada como referencia dinámica para procesamiento selectivo.
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
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.

Mostrar prerrequisitos
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
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