Lakeflow Jobs (antes Databricks Workflows): multi-task jobs como código, triggers, reintentos y la matriz de decisión del scheduler

Toda lakehouse acaba fallando de la misma manera: los datos estaban bien, el cluster estaba bien, y nadie pulsó el botón, o tres botones, en el orden equivocado, dos veces. La orquestación es lo que separa la demo de un lakehouse, y en Databricks sobre AWS el orquestador nativo es Lakeflow Jobs. Si ese nombre te resulta nuevo, esa es la primera lección: «Databricks Workflows» pasó a llamarse Lakeflow Jobs dentro de la familia Lakeflow: «Lakeflow Jobs (formerly known as Databricks Workflows)» (blog de Databricks, 2025-07-24): mientras que las rutas REST, los objetos de la API y las system tables siguen diciendo jobs. Tres nombres, un producto, y una página de docs actualizada el 9 de octubre de 2026 que ahora abre con «Lakeflow Jobs is workflow automation for Databricks, providing orchestration for data processing workloads» (docs.databricks.com/aws/en/jobs/).

Esta lección es el manual de operaciones: cómo se construye un job (tasks, DAG, cómputo), cuándo dispara (seis tipos de trigger), qué pasa cuando se acaba la capacidad (cola frente a skip), cómo se recupera (reintentos, reparaciones, notificaciones), en quién se ejecuta (service principals), cómo se empaqueta (YAML de Declarative Automation Bundles, antes Databricks Asset Bundles) y cuándo no usarlo en absoluto (Amazon MWAA/Airflow, AWS Step Functions). Cada límite y cada precio lleva abajo su fuente y su fecha de octubre de 2026; todo lo que Databricks no publica se deja fuera en lugar de adivinarse.

En esta lección vas a:

• reconstruir el renombramiento Workflows → Lakeflow Jobs y la anatomía del modelo job/tasks/triggers contra el margen de escala publicado (tasks, jobs, triggers, concurrencia, creaciones por hora);
• elegir tipos de task y cómputo desde la matriz serverless-first, y poner precio al mismo job con los suelos de $0.15 vs$0.40 por DBU;
• cablear el DAG: depends_on + las seis condiciones run_if, el control flow de condition/for-each/Run Job y la semántica Excluded cuenta como éxito que decide si tu alert task se ejecuta alguna vez;
• configurar las seis familias de triggers: schedules Quartz con el suelo de 10 segundos y el arreglo DST → UTC, triggers de llegada de archivos con cooldown de 900 s / debounce de 60 s, triggers de actualización de tabla con su suelo de 60 segundos de debounce;
• separar la cola (tope de 48 horas, activada por defecto en jobs de UI desde 2024-04-15) del skipping y diagnosticar ambos forensemente en las system tables de jobs;
• fijar reintentos, timeouts, repairs, partial runs y notificaciones por webhook, sabiendo que las tasks classic vienen sin reintentos por defecto y que las alertas a nivel de job se quedan mudas mientras haya reintentos;
• ejecutar jobs de producción como service principals con OAuth M2M, no como la persona que pulsó Crear;
• escribir el estate como Declarative Automation Bundles YAML con targets dev/prod y fuentes de task remotas en Git, y tender el puente hacia los calendarios empresariales con Amazon MWAA y DatabricksRunNowOperator;
• elegir Workflows vs Airflow/MWAA vs Step Functions desde una matriz de decisión con precios, estudiar NAB y Asurion en AWS, leer el recuadro de actualizaciones de 2026 y practicar con catorce preguntas más cuatro comprobaciones interactivas.

---

1. Anatomía: un job, un DAG, tres conceptos

Las docs son breves a propósito: un job contiene tasks, las tasks se representan visualmente mediante un DAG, y los triggers deciden cuándo dispara el job. Los ajustes a nivel de job cargan con lo demás: Trigger, Parameters, Notifications (emails o webhooks), Git (docs.../jobs/, 9 oct 2026). Todo lo demás de esta lección es un detalle de una de esas cuatro superficies.

1.1 El margen de escala (todo consultado en oct 2026)

Dos números causan la mayor parte del daño operativo. Primero, max_concurrent_runs vale 1 por defecto: «Por defecto, el número máximo de runs concurrentes de todos los jobs nuevos es 1» y un run que superaría el tope se salta salvo que la cola lo atrape (configure-job). Segundo, el techo del workspace de 2,000 task runs concurrentes es global: una flota de jobs fan-out se puede privar mutuamente de capacidad, y el error aparece como un 429 o como WORKSPACE_RUN_LIMIT_EXCEEDED en las system tables (jobs overview; system-tables/jobs, 21 may 2026).

• 📚 ¿Sabías que…? La referencia heredada de Jobs API 2.0 (última actualización 3 ago 2026) todavía dice «A job can contain up to 100 tasks», mientras que el overview actual y el blog de 2024-08-22 «What's new in Workflows?» dicen 1,000. La cifra de 1,000 tasks es el límite de producto vigente (los endpoints de escritura lo imponen); el 100 es una página heredada obsoleta, y los endpoints de lectura simplemente devuelven 100 por página con paginación. Pon siempre fecha al límite que cites.

---

2. Tipos de task y cómputo: serverless primero, nunca all-purpose

2.1 La paleta de tipos de task

La paleta actual de la UI (página configure-task) dice:

• Notebook
• Visual data prep
• Clean Room notebook
• Python script
• Python wheel
• SQL (query/alert/file)
• Pipeline (Lakeflow)
• Database Table Sync pipeline
• Ingestion pipeline
• SQL Alert (Public Preview)
• Dashboards
• Power BI
• dbt
• dbt platform (Public Preview)
• JAR
• Spark Submit
• Run Job
• Genie Code (Beta)
• If/else
• For each

El mapeo REST (Jobs API 2.2) es lo que tu YAML escribe de verdad: notebook_task, spark_jar_task, spark_python_task, python_wheel_task, sql_task, dbt_task, run_job_task, condition_task, foreach_task, pipeline_task: con spark_submit_task marcado como «Deprecated (Legacy) … Databricks recommends using the spark_jar_task instead».

Tres entradas merecen comentario antes de la matriz de cómputo:

• dbt es de primera clase: una task de dbt es «one or more dbt commands» más un project_directory, y «La task de dbt requiere tanto Databricks SQL como la capacidad de usar un SQL warehouse serverless o pro»: los SQL warehouses classic se limitan a jobs SQL programados de una sola task (Jobs API 2.2). Databricks inyecta DBT_ACCESS_TOKEN para la identidad Run as, y por eso el service principal de run as necesita acceso al warehouse y grants de UC.
• Las tasks Condition (if/else) «no requieren un cluster para ejecutarse ni admiten reintentos ni notificaciones» (Jobs API 2.2; docs de bundles, 21 ago 2026). No puedes «reintentar una rama»: reintenta la task de datos que la rama protege.
• Las tasks Run Job disparan «otros jobs configurados en tu workspace de Databricks», solo del mismo workspace, con los parámetros del job empujados hacia abajo, y tienen un tope duro: «Databricks no admite jobs con dependencias circulares ni que aniden más de tres Run Job tasks» (docs.../jobs/tasks/run-job, 11 sep 2026).

2.2 El árbol de decisión del cómputo

La página de la matriz de cómputo (última actualización 15 sep 2026) es explícita: «El cómputo serverless para workflows… es el valor por defecto para todas las tasks que lo admitan», y «All-purpose compute | Puedes configurar opcionalmente tasks usando cómputo classic all-purpose. Databricks no recomienda esta configuración para jobs de producción.»

La facturación sigue a la elección de cluster, y esta sola regla ancla cada lección de coste del curso: «When you run a job on a new jobs cluster, the job is treated as a Jobs Compute (automated) workload subject to Jobs Compute pricing. When you run a job on an existing all-purpose cluster, it is treated as an All-Purpose Compute (interactive) workload subject to All-Purpose Compute pricing» (referencia de Jobs API 2.0, 3 ago 2026). Los job clusters también se comportan distinto a la salida: el cómputo «termina y no está disponible para reiniciarse cuando el job termina», mientras que un job programado apuntado a un all-purpose cluster terminado lo autostarta (docs.../compute/clusters-manage): así es como un cluster reutilizado «barato» se convierte en silencio en una línea de 24×7.

2.3 Ejemplo resuelto E1: el mismo job, dos SKUs

A oct 2026. Un job medallion corre 2 horas al día y consume 12 DBU/h (un fan-out multi-task modesto sobre cómputo classic de jobs). Coste mensual en DBU a los suelos oficiales de la página de precios de Databricks (instantánea 2026-10):

Los jobs serverless son la tercera ruta: «bill only when a command or query runs (plus a small session fee for the REPL VM); charges stop automatically after a few minutes of idle time» (Databricks Answers, 2026-08-27), y la página de mejores prácticas de serverless añade que «Standard mode can reduce costs by up to 70% compared to performance-optimized mode»: al precio de «4 to 6 minutes» de latencia de arranque (run-serverless-jobs, 9 oct 2026). Los jobs serverless requieren un workspace con Unity Catalog habilitado y standard access mode; la auto-optimización (incluidos los reintentos, sección 6) viene activada por defecto.

• 📚 ¿Sabías que…? Los jobs serverless llevan rate-limit objects automatizados que limitan la ejecución a unos 60 / 120 / 240 / 480 / 960 DBU por hora de Small a 2X-Large, y «Within a single job, the cap is shared across all the job's tasks» (docs.../compute/serverless/manage-serverless-compute, consultadas oct 2026). Los límites de tasa se aplican solo a cargas automatizadas, los notebooks interactivos y Databricks Connect están exentos, y hacerlos cumplir requiere Databricks Runtime 17.3.1 o superior. Un ticket de «¿por qué se me ha atascado mi fan-out?» suele tener esta respuesta.

---

3. Dependencias y control flow: el DAG que de verdad obtienes

Las tasks posteriores a la primera declaran depends_on: [{task_key: …}], que dibuja los bordes. Lo que esos bordes significan lo decide Run if, y ahí es donde se torcieron los DAGs de producción. Las seis condiciones (docs de configuración de run-if, 25 jun 2026): All succeeded (defecto) · At least one succeeded · None failed · All done · At least one failed · All failed.

Tres semánticas documentadas son de examen y de incidente a la vez:

1. «Upstream tasks with the Excluded result state are treated as successful when evaluating Run if conditions.»
2. «Upstream tasks marked Upstream failed or Upstream canceled are treated as failed, not as skipped.»
3. «If all of a task's dependencies are excluded, the task itself is also excluded… exclusion cascades along a linear dependency chain»; sin importar el propio Run if de esa task. La cancelación igualmente «se propaga a las tasks aguas abajo, y las tasks con una condición Run if que maneja fallos se ejecutan».

Lee el diagrama como una política, no como una forma. dq_gate usa NONE_FAILED porque la publicación en gold no debe ejecutarse sobre un silver corrupto, pero un upstream cancelado cuenta como fallido, así que una cancelación humana sigue saltándose el gold, que es justo lo que quieres. La task de alerta usa AT_LEAST_ONE_FAILED para sobrevivir al fallo de silver; porque «Upstream failed» cuenta como fallo, la alerta dispara exactamente en los incidentes que te importan. Los compañeros de control flow completan la caja de herramientas: las tasks de condición If/else comparan operandos (EQUAL_TO, GREATER_THAN, …) contra valores dinámicos como {{job.repair_count}} o {{tasks.task_key.values.output}} (docs de job-task-types de bundles, 21 ago 2026); For each recorre un array JSON, manual o producido aguas arriba mediante dbutils.jobs.taskValues.set; Run Job compone jobs enteros, del mismo workspace, sin ciclos, con ≤3 niveles de anidamiento.

• 📚 ¿Sabías que…? La propagación de parámetros tiene dirección y ganador: los parámetros del job «are pushed down automatically, and if a job parameter and a task parameter share a key, the job parameter takes precedence», pero «Tasks that take JSON-array parameters don't receive job parameters automatically; reference them explicitly with {{job.parameters.<name>}}» (docs.../jobs/parameters, 26 jun 2026). Las tasks con array JSON son Python script, wheel posicional, JAR, Spark Submit y For each. Si te lo saltas, tu task de Python script se ejecuta en silencio con argv vacío.

---

4. Triggers: el cron es una conjetura, la llegada de datos es un hecho

Hoy se entregan seis comportamientos de trigger (docs de triggers, 6 oct 2026): Scheduled, Table update, File arrival, Model update (Beta), Continuous («trigger another job run whenever a job run completes or fails») y None (manual). Los triggers múltiples por job están en Beta: hasta cinco, cada uno pausable de forma independiente, y «Un trigger continuo no puede combinarse con ningún otro trigger». La API los trae en un array triggers; no mezcles ese array con los campos heredados schedule / trigger / continuous en una misma request.

4.1 Programado: cron de Quartz, el suelo de 10 segundos y el DST

Los schedules usan sintaxis cron de Quartz con una timezone id de Java, con pause_status UNPAUSED/PAUSED (esquema del objeto Run, Jobs API 2.2: ejemplo "quartz_cron_expression": "20 30 * * * ?", "timezone_id": "Europe/London"). Tres reglas de la página de schedules (última actualización 26 jun 2026):

• «Databricks enforces a minimum interval of 10 seconds between subsequent runs triggered by the schedule of a job regardless of the configuration in the cron expression.»
• Zonas horarias con horario de verano: «an hourly job is skipped or might appear to be delayed by an hour or two when daylight saving time begins or ends. To run at every hour (absolute time), choose UTC.»
• «The job scheduler is not intended for low-latency jobs. Due to network or cloud issues, job runs might occasionally be delayed up to several minutes.»

4.2 Ejemplo resuelto E2: el bug del cron y el arreglo event-driven

Los triggers de llegada de archivos «hacen un esfuerzo por comprobar si hay archivos nuevos cada minuto», monitorizan «the root of a Unity Catalog external location or volume, or a subpath» de forma recursiva, y «do not incur additional costs other than cloud provider costs associated with listing files» (docs de file-arrival, 7 oct 2026). Los filos: solo disparan los archivos nuevos: «Sobrescribir un archivo existente con otro del mismo nombre no dispara un run»; sin wildcards; y «Cuando el directorio configurado no existe o se borra de Amazon S3…, los triggers de llegada de archivos siguen evaluándose sin error». Sin file events habilitados en la external location, el workspace te limita a «A maximum of 50 jobs» con triggers de llegada de archivos en tales ubicaciones y «10,000 files» en la ruta vigilada. El acoplamiento recomendado es Auto Loader con cloudFiles.useManagedFileEvents=true y trigger(availableNow=True): una variante foreachBatch «provides only at-least-once processing guarantees»: con el checkpoint guardado fuera de la ruta vigilada.

4.3 Triggers de actualización de tabla

Un trigger de actualización de tabla «comprueba si hay actualizaciones de tablas y, cuando se actualiza una tabla, se ejecuta el job», monitorizando hasta 10 tablas gestionadas Delta/Iceberg de Unity Catalog, tablas externas sobre Delta, materialized views, streaming tables y vistas dependientes: detectando «updates, merges, and deletes» (docs de table-update, 26 jun 2026). wait_after_last_change_seconds tiene un suelo de 60 segundos: es un debounce, no un SLA sub-minuto. Igual que la llegada de archivos, «no genera costes adicionales más allá de los costes del proveedor cloud», y «For best performance and scalability, enable file events on the external location.»

• 📚 ¿Sabías que…? Un workspace puede alojar hasta 12,000 triggers activos en todos los jobs y tipos de trigger, y los triggers pausados no cuentan para ese límite (docs de triggers, 6 oct 2026). Eso convierte la higiene del estado de pausa en una herramienta de capacidad: una flota de jobs de backfill dormidos debería desplegarse con pause_status: PAUSED: que es exactamente lo que el modo de desarrollo de Declarative Automation Bundles hace por ti (sección 8).

---

5. Cola, concurrencia y la trampa del skip

Cuando un run no puede arrancar, lo atrapan dos máquinas distintas, y solo una viene activada por defecto. La cola (activada por defecto en jobs creados desde la UI después del 15 de abril de 2024) retiene el run «for up to 48 hours if resources are unavailable», y se activa cuando se alcanca cualquiera de tres límites: el máximo de runs activos concurrentes del workspace, el máximo de runs concurrentes de tasks Run Job del workspace, o el propio max_concurrent_runs del job (configure-job, 7 jul 2026). Sin cola, alcanzar un límite significa que el run se salta, y un run programado saltado es un hueco de datos silencioso.

Mandos y techos que no debes confundir: max_concurrent_runs defecto 1, máximo duro 1,000, 0 salta todo; bajarlo nunca mata runs activos; el 2,000 task runs concurrentes de todo el workspace devuelve 429 o WORKSPACE_RUN_LIMIT_EXCEEDED incluso con la cola activada (jobs overview; system tables). La profundidad de la cola más allá del tope documentado de 48 horas no se publica: trata «¿qué tan profunda es la cola interna, y en qué orden hace dequeue?» como desconocido, y diseña para el tope, no para la equidad.

5.1 Ejemplo resuelto E3: forensia de colas en las system tables

La misma referencia lista los estados de fallo sobre los que conviene alertar: WORKSPACE_RUN_LIMIT_EXCEEDED («El workspace ha alcanzado la cuota máxima de runs activos concurrentes»), MAX_CONCURRENT_RUNS_EXCEEDED, MAX_JOB_QUEUE_SIZE_EXCEEDED, CLUSTER_REQUEST_LIMIT_EXCEEDED y REPOSITORY_CHECKOUT_FAILED: más la nota honesta de que creator_user_name y paused están «sin rellenar para las filas emitidas antes de principios de diciembre de 2025», así que las consultas de higiene histórica necesitan un suelo de fecha.

---

6. Fiabilidad: reintentos, timeouts, reparaciones, notificaciones

6.1 Los reintentos varían según el cómputo: el valor por defecto es el silencio

«El ajuste por defecto de los reintentos de task depende de la configuración del job. Para la mayoría de las configuraciones, el ajuste por defecto no reintenta ninguna task cuando una task falla» (configure-task). Frente a eso: «Serverless jobs auto-optimize retries by default» (desactívalo con la casilla «Enable serverless auto-optimization», y desactívalo sí para destinos no idempotentes), y «Continuous jobs use an exponential backoff retry policy» (misma página). Los mandos por task: max_retries, min_retry_interval_millis, retry_on_timeout; timeout_seconds es por task con «A value of 0 means no timeout» (Jobs API 2.2), y un timeout no se reintenta salvo que retry_on_timeout esté activo.

6.2 Ejemplo resuelto E4: la política de reintentos como documento de diseño

Superficies de recuperación más allá de los reintentos: el repair reejecuta «the subset of unsuccessful tasks» en un run multi-task; los partial runs (blog de Lakeflow Jobs, 2025-07-24) «allow users to select which tasks to execute without affecting others»: la respuesta operativa a «reejecuta solo la task de gold rota»; y las salidas de consultas SQL pueden alimentar tareas posteriores como parámetros (mismo blog). Las tasks de notebook también traen techos duros de salida: 30 MB de salida combinada de celdas, 8 MB por celda: más allá de los cuales el run falla (docs.../jobs/tasks/notebook, 11 sep 2026); las tasks parlanchinas deben escribir en Delta, no en stdout.

6.3 Notificaciones: tres destinos, reintentos silenciosos

Eventos de notificación (docs de notifications, 9 oct 2026):

• Start
• Successful completion
• Failure
• umbral de duración superado
• umbral de backlog de streaming superado
• inicio/fin de mantenimiento (jobs continuos)

Los destinos son «email addresses or third-party destinations such as Slack, Microsoft Teams, PagerDuty, or any webhook-based service», donde «An administrator must configure system destinations», y «Para cada job o task, puedes configurar un máximo de tres destinos de sistema para cada tipo de evento de notificación». Los códigos event_type del webhook son estables: jobs.on_start, jobs.on_success, jobs.on_failure, jobs.on_duration_warning_threshold_exceeded.

6.4 Ejemplo resuelto E5: el payload del webhook y la llamada run-now

Usa tokens OAuth M2M (client id + secreto OAuth; access tokens válidos 1 hora, secretos acotables a jobs) en lugar de personal access tokens; si una integración heredada te fuerza a un PAT, usa un PAT de service principal, nunca el de una persona (sección 7 y la costura de Airflow de la sección 9).

---

7. Identidad: owner, Run as y la marcha que rompe las 3 a.m.

Un job tiene dos identidades: el owner (ACL del job; «Solo los admins del workspace pueden editar el owner del job») y la identidad Run as cuyos permisos ejecutan cada task. Run as por defecto = la persona creadora del job, y la recomendación de las docs no deja lugar a dudas: «Databricks recomienda cambiar el Run as user a un service principal, de modo que los privilegios se puedan controlar por separado de los del owner, y de modo que los jobs no se rompan cuando el owner se vaya o cambie de privilegios» (docs.../jobs/privileges, consultadas oct 2026). Cambiar Run as requiere CAN MANAGE o IS OWNER en el job, el service principal necesita el entitlement Service Principal User, y «Run as a group» está en Public Preview.

El matiz de auditoría importa durante la revisión de incidentes: identity_metadata.run_as registra tu identidad configurada (el grupo, en la preview de Run as por grupo), mientras que identity_metadata.run_by «always records» el service principal de aplicación del servicio Jobs (misma página). El modo de fallo que previene es el rompedor de producción más común del curso: el job programado sigue pareciendo sano a la hora programada y muerte en la primera lectura de UC después de que se revoque el acceso de su creador. La autenticación máquina-a-máquina para la orquestación es OAuth M2M (tokens de 1 hora) o, para Airflow en AWS, la federación AWS IAM OIDC token del proveedor: «exchange for a Databricks OAuth token. Stores no secrets» (docs de apache-airflow-providers-databricks 7.19.0, consultadas oct 2026).

---

8. Jobs como código: Declarative Automation Bundles

Montar jobs a base de clics no sobrevive a un segundo ingeniero. La superficie como código es Declarative Automation Bundles, «formerly known as Databricks Asset Bundles» (docs.../dev-tools/bundles, consultadas oct 2026), que empaqueta «Source files… Definitions and settings for Databricks resources, such as Lakeflow Jobs, Lakeflow Spark Declarative Pipelines, Dashboards, Model Serving endpoints, MLflow Experiments». El ciclo: escribe databricks.yml + resources/*.job.yml, y luego databricks bundle validate → databricks bundle deploy --target dev → databricks bundle run --target dev <job>.

8.1 Ejemplo resuelto E6: un job multi-task de producción, YAML completo

Todo en ese archivo mapea a un campo documentado: run_as.service_principal_name acepta «the email of an active workspace user or the application ID of a service principal» (Jobs API 2.2); queue.enabled refleja el comportamiento de cola de 48 horas (sección 5); el bloque de reintentos es E4; run_if es la sección 3; schedule es la forma verificada de la API del ejemplo job-settings de Jobs API 2.0 (consultada oct 2026). Los jobs existentes creados desde la UI se pueden invertir a esta forma con databricks bundle generate job (docs de job-task-types de bundles, 21 ago 2026): el camino de migración más rápido desde el click-ops.

8.2 Los targets dev/prod son la barra de seguridad

Los presets del modo de desarrollo (docs de deployment-modes de bundles): «Pausa todos los schedules y triggers de los recursos desplegados, como jobs» (anúlalo con schedule.pause_status: UNPAUSED), anteponga un prefijo de nombre [dev ${workspace.current_user.short_name}], y «Enables concurrent runs on all deployed jobs». El modo de producción no aplica nada de eso, y por eso el mismo YAML es seguro de desplegar desde un portátil y aterrador de desplegar desde un portátil sin targets. La promoción es databricks bundle deploy --target prod desde CI, con el service principal de run as y los secretos resueltos por target.

8.3 Fuentes Git: un repo, un commit, una instantánea

Las tasks de notebook, Python-script, archivo SQL y dbt pueden tomar una fuente de un repositorio Git remoto (docs.../jobs/git, 11 sep 2026): «Todas las tasks de un job deben referenciar el mismo commit… Databricks toma una instantánea de la rama o commit indicado» cuando empieza el run; «Solo se puede usar un único repositorio Git remoto para todas las tasks de un job»; y «Tasks configured to use a remote Git repository cannot write to workspace files». Los Git folders (sync de workspace-repo) funcionan pero hay que sincronizarlos a mano y se recomiendan «solo para iteración rápida y pruebas durante el desarrollo»: las tasks de staging y producción referencian el repo remoto con branch/tag/commit fijado, y el historial de runs muestra el SHA del commit.

---

9. La costura externa: Airflow y Amazon MWAA

Hay calendarios que son propiedad de la empresa: ventanas de SAP, mantenimiento de Redshift, SLAs de APIs de terceros. La propia página de Databricks documenta la costura, «también puedes programar tus jobs usando herramientas como Apache Airflow», con la advertencia de que los paquetes open source «are not directly supported by Databricks» (docs.../jobs/how-to/use-airflow-with-jobs, 11 sep 2026). El mapa de operadores:

Endurecimiento de producción desde las docs del proveedor (7.19.0 / módulo 7.20.0, consultadas oct 2026): el durable mode persiste «the Databricks run id… to task state store before polling begins, so if the worker crashes… the operator reconnects to the run… instead of triggering a duplicate run»; existen variantes deferrables; la conexión debe llevar SP OAuth o federación AWS IAM OIDC, no un PAT humano; y el operador «write[s] the job run page URL to the Airflow logs every polling_period_seconds (the default is 30 seconds)» (tutorial de Databricks). Higiene de versiones: el tutorial de Databricks todavía dice «Airflow version 2.5.0 and later… tested with Airflow version 2.6.1», mientras que el proveedor 7.19.0 exige «Apache Airflow version supported by this provider distribution is 2.11.0»: fija y prueba la pareja en MWAA en lugar de fiarte de una sola de las dos cifras.

9.1 Ejemplo resuelto E7: el DAG de MWAA a Databricks, con precios

La regla de diseño que sale de E7: una capa es dueña de los bordes del DAG, la otra del cómputo. Los reintentos de Airflow reflejan, pero no deben multiplicar, los reintentos de task de Databricks (pon los reintentos de Airflow en 0 to 1 cuando el job ya reintenta 2 to 3); la URL del DatabricksRunNowOperator en el log de Airflow es tu migas de pan entre sistemas; y los estates con varios workspaces mantienen una conexión MWAA (o un juego de credenciales OIDC) por workspace, porque la task Run Job y run-now son primitivas del mismo workspace.

---

10. La matriz de decisión del scheduler: Workflows vs Airflow vs Step Functions

Tres orquestadores tocan un estate de Databricks sobre AWS, y cada uno tiene una forma de precio documentada.

El híbrido en el que acaban la mayoría de las tiendas de AWS: un único job de «ingest» de Databricks con trigger de llegada de archivos es dueño de la disponibilidad de los datos; MWAA es dueño del calendario empresarial y llama a ese job con DatabricksRunNowOperator; Step Functions coordina los pasos del lado de AWS alrededor de la llamada a Databricks. Las alternativas de la familia Airflow gestionado (Prefect, Astronomer) se integran por la misma costura REST/SDK: misma arquitectura, factura distinta, así que mantén la comparación cualitativa hasta tener sus ofertas en vivo.

Veredicto comparativo: Lakeflow Jobs vs Amazon MWAA/Airflow vs AWS Step Functions (AWS, a oct 2026)

• Lakeflow Jobs: el valor por defecto para DAGs nativos de Databricks. Sin cargo de scheduler en inactividad (proveedor: «sin recargo de orquestación: solo pagas por el cómputo usado por tus tasks», blog 2025-01-12), triggers conscientes de los datos sobre external locations con soporte S3 y tablas de UC, repairs/partial runs, service principals de run as y observabilidad del job en las system tables. Suelo de DBU $0.15/DBU (Data Engineering, instantánea de la página de precios 2026-10) en cómputo classic de jobs, o serverless que «solo factura cuando se ejecuta un comando o una consulta». Debilidad: la orquestación fuera de Databricks todavía es joven (el blog de Lakeflow de junio de 2026 anuncia External Orchestration para Snowflake/REST/Slack/PagerDuty sin declarar su madurez), y el encadenamiento con Run Job es solo del mismo workspace, ≤3 niveles, sin ciclos.
• Amazon MWAA/Airflow, el dueño del calendario empresarial. DAGs neutral respecto al proveedor, operadores/sensors personalizados, semántica de backfill madura, y el único hogar cómodo para el fan-out que pasa la mayor parte de sus pasos fuera de Databricks. El coste honesto: un entorno large de $0.99/h ≈ $736.56/mes de suelo (ejemplo de la página de precios de AWS) más workers a $0.22/h y metadatos de RDS a $0.10/GB-mes, orquestación con su propia factura y su propia guardia. Llama a Databricks con DatabricksRunNowOperator (SP OAuth o IAM OIDC, deferrable, durable) para que los runs sigan visibles en la UI de jobs.
• AWS Step Functions: el pegamento de AWS. Mejor cuando el centro de gravedad del workflow es Lambda/ECS/Batch/Glue y Databricks es una llamada a la API entre muchas; el precio de Standard es por transición de estado ($0.025 por 1,000, AWS Compute Blog 2022-08-30: vuelve a comprobar la tabla en vivo), Express mide GB-segundos ($0.00001667/GB-s, página de precios consultada oct 2026). Renuncias a task values, repairs y la UI de jobs: las funciones conscientes de Databricks viven fuera de la consola.
• Veredicto en una línea: Lakeflow Jobs para el DAG interno de Databricks → MWAA donde el calendario o el fan-out no son de Databricks → Step Functions donde los servicios de AWS son el workflow y Databricks es un callee, y en cada híbrido, exactamente una capa es dueña de los bordes del DAG, run-now es dueño de la costura, y la identidad de run as es un service principal.

---

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

📋 Caso A: NAB (National Australia Bank, banca, Cloud: AWS) Desafío. Un almacén Teradata de 26 años con ~1,000 casos de uso y ~140 suites de reporting, más ETL en Spark escrito a mano con DML de 5,000 to 8,000 líneas y hasta 64 union-all por pipeline, mantenido por 300 to 400 ingenieros con prácticas inconsistentes. Stack en AWS. Databricks SQL, Auto Loader, Spark Declarative Pipelines sobre Lakeflow (el hermano de pipeline de los Jobs de esta lección), Unity Catalog y asset bundles para CI/CD: Cloud: AWS en la página de la historia. Resultado reportado. «1,800 Spark Declarative Pipelines running on Databricks Lakeflow · 99.6% Job success rate · 80% Less transformation complexity»; latencia extremo a extremo «under 15 minutes»; calidad de datos «+38%» (https://www.databricks.com/customers/national-australian-bank-nab, página sin fecha, consultada 2026-10). Cita. «La migración no habría sido posible sin Databricks SQL»: Gurry (https://www.databricks.com/customers/nab/dbsql, página sin fecha, consultada 2026-10). Encaja con esta lección. Secciones 6 y 8: una tasa de éxito de jobs del 99.6% a través de 1,800 pipelines es una métrica de fiabilidad: reintentos, repairs, service principals de run as y definiciones desplegadas con bundles son lo que convierte la orquestación de hazañas heroicas en un número que un auditor puede seguir. ⏳ Nota temporal: página sin fecha, consultada en oct 2026: un resultado de cliente reportado, no una garantía de 2026.

📋 Caso B: Asurion (seguros / protección de dispositivos, Cloud: AWS) Desafío. 8,000 tablas, 10,000 vistas y ~600 data marts con mapeos de ETL por tabla, más duplicación entre la capa batch y la de velocidad a miles de jobs que no cabían en un modelo de scheduling de un cluster por job. Stack en AWS. Spark Structured Streaming, Auto Loader, foreachBatch hacia Delta; fuentes Kinesis, Kafka, SNS, SQS, CDC, APIs y ficheros planos; Databricks SQL para la capa de mart: el data lake de producción explícitamente en AWS. Resultado reportado. «The Asurion data lake executes 4,000+ streaming jobs and hosts over 4,000 tables in a production data lake on AWS» (https://www.databricks.com/blog/2021/05/10/aws-guide-to-data-ai-summit-featuring-disney-comcast-capital-one-and-mcdonalds.html, 2021-05-10); «unified approach to data movement from traditional ETL to streaming data pipelines between Delta tables» (https://www.databricks.com/blog/2021/09/16/large-scale-etl-and-lakehouse-implementation-at-asurion.html, 2021-09-16). Encaja con esta lección. Secciones 1 y 2: con más de 4,000 streaming jobs, el diseño del job es la arquitectura: un solo framework parametrizado con convenciones compartidas (task keys, timeouts, identidad de run as, elecciones de cómputo) gana a 4,000 ETL a medida, y los límites de escala de workspace de la sección 1.1 son exactamente el margen contra el que hay que diseñar semejante estate. ⏳ Nota temporal: cifras de 2021; trátalas como un hito de escala reportado y vuelve a comprobar cualquier límite de concurrencia citado en el blog contra la documentación actual antes de reutilizarlo.

---

---

Preguntas de Práctica (Practice Questions)