Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLecció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.
17 min aprox.
01Modelo mentalIf/else task
El DAG de Lakeflow Jobs expresa dependencias de ejecución y permite paralelismo solo cuando tareas y datos son realmente independientes.
+
If/else task
El DAG de Lakeflow Jobs expresa dependencias de ejecución y permite paralelismo solo cuando tareas y datos son realmente independientes.
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.
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.
¿Qué determina el critical path de un Job?
Profundiza
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.
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.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.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.Resumen
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.