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

If/else task

Contenido abierto

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

Lección 1 de 5

If/else task

El DAG de Lakeflow Jobs expresa dependencias de ejecución y permite paralelismo solo cuando tareas y datos son realmente independientes.

Duración
17 min aprox.
Objetivo
El DAG de Lakeflow Jobs expresa dependencias de ejecución y permite paralelismo solo cuando tareas y datos son realmente independientes.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Lakeflow Jobs avanzado: control flow y repairs

Orquesta decisiones, bucles y recuperaciones sin convertir el DAG en lógica opaca.

Al terminar podrás
  • Usar branching y for-each con límites
  • Aplicar retries y repairs correctamente
  • Transferir parámetros y task values
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
pipelines
Dominios blueprint
Debugging and Deploying · Lakeflow Jobs
Estado
Revisión editorial interna
Fuentes principales
Control the flow of tasks within Lakeflow Jobs · Databricks · Dynamic value references · Databricks
Reportar un error
01
Modelo mental

If/else task

El DAG de Lakeflow Jobs expresa dependencias de ejecución y permite paralelismo solo cuando tareas y datos son realmente independientes.

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

Cada task tiene una responsabilidad, parámetros y resultado observable. Dos ingestas regionales pueden ejecutarse en paralelo si escriben particiones o targets independientes; la publicación gold depende de ambas. Introducir dependencias innecesarias alarga el critical path, pero eliminar una dependencia de datos crea carreras.

El DAG no debe ocultar lógica de transformación dentro de docenas de notebooks. Jobs coordina unidades desplegables —pipeline, wheel, SQL o notebook— y las tareas comparten información mediante parámetros, task values o outputs, no variables de memoria del driver.

Modelo mental

Un Lakeflow Job es un grafo de tareas, no una lista visual de notebooks. Cada arista declara una condición de dependencia y el scheduler ejecuta en paralelo únicamente las ramas cuyos prerrequisitos están satisfechos. El DAG debe reflejar dependencias de datos y efectos reales: dos tareas que escriben la misma tabla no son independientes aunque no se lean entre sí, y una arista innecesaria desperdicia paralelismo. La unidad de retry, timeout, compute, parámetros y observabilidad es la tarea; por eso conviene que sea cohesionada e idempotente. Un Job puede orquestar notebooks, scripts Python, pipelines, SQL y otros tipos, pero no convierte su contenido en transaccional de extremo a extremo. La arquitectura separa producir, validar y publicar para que un fallo no exponga datos parciales. Los nombres y task keys son contratos operativos porque aparecen en referencias dinámicas, repair runs, alertas y system tables.

Task key

Identificador estable y único de una tarea dentro del Job, utilizado por dependencias, referencias dinámicas, métricas y operaciones de reparación.

Cambiarlo sin planificación puede romper parámetros downstream y comparabilidad histórica aunque el nombre visible parezca equivalente.
Camino crítico

Secuencia dependiente de tareas cuya duración acumulada determina el tiempo mínimo posible para completar el run completo.

Ayuda a optimizar donde realmente reduce SLA, en lugar de acelerar ramas que ya terminan antes.
Dependencia de efecto

Relación no visible solo por lecturas, creada cuando tareas compiten por el mismo target, recurso externo o publicación.

Debe representarse o eliminarse mediante aislamiento para impedir carreras y resultados no deterministas.
YAMLParalelismo y convergencia explícitos
tasks:
  - task_key: ingest_eu
    python_wheel_task:
      package_name: commerce
      entry_point: ingest
  - task_key: ingest_us
    python_wheel_task:
      package_name: commerce
      entry_point: ingest
  - task_key: publish_gold
    depends_on:
      - task_key: ingest_eu
      - task_key: ingest_us
    pipeline_task:
      pipeline_id: ${resources.pipelines.orders.id}

En el bundle real usa la sintaxis de sustitución `${resources.pipelines.orders.id}`; aquí se escapa el signo para mantener el ejemplo como texto.

Puntos clave

  • Dependencias representan requisitos de datos/estado, no preferencia visual.
  • Tareas independientes pueden usar compute y retries separados.
  • El critical path determina la latencia mínima del workflow.

Evita

  • Serializar tareas independientes y aumentar tiempo/coste sin mejorar corrección.
  • Ejecutar en paralelo tareas que sobrescriben el mismo rango de la tabla.

Recuerdo activo

¿Qué determina el critical path de un Job?

Borrador privado · solo en este navegador
5 lecciones pendientes

Vista de lectura · sin ejecución

Learn Databricks

Learn Databricks · commit 08c378c

README.md