Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 3 de 5
Run job y modularidad
If/else decide por un valor; Run if decide por el estado de tareas upstream y ambos resuelven problemas distintos.
- Duración
- 17 min aprox.
- Objetivo
- If/else decide por un valor; Run if decide por el estado de tareas upstream y ambos resuelven problemas distintos.
- 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.
- Usar branching y for-each con límites
- Aplicar retries y repairs correctamente
- Transferir parámetros y task values
03OperaciónRun job y modularidad
If/else decide por un valor; Run if decide por el estado de tareas upstream y ambos resuelven problemas distintos.
+
Run job y modularidad
If/else decide por un valor; Run if decide por el estado de tareas upstream y ambos resuelven problemas distintos.
Una If/else task compara parámetros, valores dinámicos o task values con operadores como `>`, `==` o `!=`. Por ejemplo, publica si `invalid_ratio <= 0.01` y envía a cuarentena en caso contrario. Las tareas de cada rama declaran el outcome requerido.
`Run if` se configura sobre una dependencia para ejecutar limpieza, notificación o recuperación según estados como `ALL_SUCCESS`, `AT_LEAST_ONE_FAILED` o `ALL_DONE`. No se debe codificar un valor de negocio como estado de tarea ni usar If/else para saber si upstream lanzó una excepción.
Modelo mental
`If/else` y `Run if` controlan dimensiones diferentes. La tarea If/else compara un valor —parámetro, referencia dinámica o task value— con un operador y abre una rama verdadera o falsa. `Run if` evalúa estados terminales de dependencias, como todos correctos, al menos uno fallido o todos terminados, y decide si una tarea downstream es aplicable. Confundirlos produce DAGs frágiles: comprobar `row_count > 0` es decisión por valor; ejecutar limpieza aunque upstream falle es decisión por estado. Las tareas omitidas adquieren estados que influyen en dependientes, por lo que se diseña y prueba cada ruta, incluida la ausencia de datos. Una rama condicional no reemplaza validación transaccional: publicar porque una bandera dice true requiere confiar en quién calculó esa bandera y conservar evidencia. Las tareas de cleanup usan `All done`, pero deben ser idempotentes y no ocultar el fallo original.
Tarea de control que compara un valor disponible con un operador soportado y habilita una de dos ramas del DAG.
Expresa decisiones de negocio o de datos, como publicar únicamente cuando un conteo supera un umbral.Condición asociada a dependencias que decide ejecución según estados de tareas upstream, incluidos éxito, fallo o finalización.
Permite cleanup, notificación y tolerancia parcial sin convertir estados técnicos en valores inventados.Conjunto de tareas que el scheduler no ejecuta porque una condición eligió otra rama o sus dependencias no aplican.
Debe probarse porque su estado influye en downstream y puede ocultar que nunca se validó una alternativa rara.{
"task_key": "quality_gate",
"depends_on": [{"task_key": "validate"}],
"condition_task": {
"op": "LESS_THAN_OR_EQUAL",
"left": "{{tasks.validate.values.invalid_ratio}}",
"right": "0.01"
}
}Las tareas downstream de publicación o cuarentena dependen de `quality_gate` con el outcome true o false correspondiente.
Puntos clave
- If/else evalúa datos o parámetros; Run if evalúa resultado de ejecución.
- Una tarea de cleanup suele usar `ALL_DONE` para ejecutarse incluso tras fallos.
- Las ramas deben converger con condiciones que acepten outcomes esperados.
Evita
- Usar If/else para capturar fallos técnicos cuando `Run if` ya modela estados de upstream.
- Olvidar una rama o convergencia y dejar el Job aparentemente correcto pero incompleto.
Recuerdo activo