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

Job envolvente y despliegue

Contenido abierto

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

Lección 4 de 5

Job envolvente y despliegue

Lakeflow Jobs envuelve el pipeline para parametrizar entorno, ejecutar validaciones, condicionar publicación y manejar alertas o backfills.

Duración
30 min aprox.
Objetivo
Lakeflow Jobs envuelve el pipeline para parametrizar entorno, ejecutar validaciones, condicionar publicación y manejar alertas o backfills.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Proyecto de pipeline declarativo

Construye una cadena declarativa con calidad, CDC, orquestación y operación documentada.

Al terminar podrás
  • Entregar datasets incrementales fiables
  • Probar dependencias y reglas
  • Operar fallos y backfills
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
pipelines
Dominios blueprint
Production pipelines
Estado
Revisión editorial interna
Fuentes principales
Best practices for Spark Declarative Pipelines · Databricks · AUTO CDC APIs · Databricks
Reportar un error
04
Diagnóstico

Job envolvente y despliegue

Lakeflow Jobs envuelve el pipeline para parametrizar entorno, ejecutar validaciones, condicionar publicación y manejar alertas o backfills.

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

Una pipeline task actualiza datasets declarativos. Una tarea posterior consulta event log y reconciliación; una If/else bloquea publicación si se supera el umbral. Cleanup y notificación usan Run if. El mismo bundle define recursos para dev, test y prod con identidades y catálogos diferentes.

La promoción no consiste en copiar notebooks. Se valida el bundle, se despliega el mismo artefacto, se ejecuta un smoke test y se compara lineage/esquema. Producción se activa con trigger pausado inicialmente y rollback conocido.

Modelo mental

Lakeflow pipelines administra el grafo de datos; Lakeflow Jobs administra el proceso operativo que lo rodea. Un task de pipeline ejecuta la actualización, pero un flujo de producción suele necesitar parámetros de entorno, prechecks, validación agregada, decisión de publicación, notificaciones y backfills. Jobs no debe duplicar las dependencias internas del pipeline ni llamar cada dataset por separado: trata la actualización como una unidad y coordina fronteras externas. Un run recibe business window y versión de configuración inmutables. Después del pipeline, tareas leen event log y targets staging, calculan controles y una rama publica o contiene. Los retries se aplican a fallos transitorios; repair reejecuta el subgrafo necesario con el contexto original. Backfills usan el mismo artefacto y contrato con modo y rango explícitos, no copias de notebooks.

Pipeline task

Tipo de tarea de Lakeflow Jobs que inicia y espera una actualización de un pipeline gestionado como una unidad operativa.

Integra procesamiento declarativo con control flow, parámetros, reparaciones y notificaciones sin recrear el DAG de datasets.
Precheck

Tarea previa que valida parámetros, permisos, disponibilidad o manifests antes de consumir compute y modificar datasets del pipeline.

Falla pronto ante condiciones deterministas y evita updates costosos o parciales que nunca podrían publicarse.
Puerta de publicación

Decisión posterior a procesamiento y validación que hace visible el resultado al consumidor únicamente cuando cumple controles acordados.

Separa éxito técnico de corrección del producto y proporciona una frontera idempotente para repair y rollback.
YAMLDAG de actualización y validación
tasks:
  - task_key: update_pipeline
    pipeline_task:
      pipeline_id: orders_pipeline
  - task_key: validate_update
    depends_on:
      - task_key: update_pipeline
    notebook_task:
      notebook_path: /Workspace/commerce/validate_update
  - task_key: quality_gate
    depends_on:
      - task_key: validate_update
    condition_task:
      left: "{{tasks.validate_update.values.failure_rate}}"
      op: LESS_THAN_OR_EQUAL
      right: "0.01"

En un bundle real `pipeline_id` referencia el recurso desplegado; evita IDs fijos entre entornos.

Puntos clave

  • Pipelines transforma; Jobs coordina control flow y efectos operativos.
  • El mismo artefacto se parametriza por target y se ejecuta con service principal.
  • Quality gate usa métricas persistidas y bloquea solo publicación downstream.

Evita

  • Meter notificaciones y llamadas externas dentro de una función declarativa del pipeline.
  • Desplegar prod con identidad personal y rutas hardcoded de dev.

Recuerdo activo

¿Por qué separar `validate_update` del pipeline task?

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