Lakeflow Jobs (anteriormente Databricks Workflows): Multi-Task Jobs como Código, Triggers, Retries e a Matriz de Decisão do Scheduler

Todo lakehouse eventualmente falha do mesmo jeito: os dados estavam bons, o cluster estava bom, e ninguém apertou o botão: ou três botões, na ordem errada, duas vezes. Orquestração é a diferença entre uma demo de lakehouse e um lakehouse, e no Databricks na AWS o orquestrador nativo é o Lakeflow Jobs. Se esse nome é novo para você, essa é a primeira lição: "Databricks Workflows" foi renomeado Lakeflow Jobs dentro da família Lakeflow: "Lakeflow Jobs (formerly known as Databricks Workflows)" (blog da Databricks, 2025-07-24): enquanto os caminhos REST, os objetos de API e as system tables continuam dizendo jobs. Três nomes, um produto, e uma página de docs atualizada em 9 de outubro de 2026 que agora abre com "Lakeflow Jobs é automação de workflow para o Databricks, fornecendo orquestração para workloads de processamento de dados" (docs.databricks.com/aws/en/jobs/).

Esta lição é o manual de operações: como um job é construído (tasks, DAG, compute), quando ele dispara (seis tipos de trigger), o que acontece quando a capacidade acaba (fila vs. skip), como ele se recupera (retries, repairs, notificações), com qual identidade ele roda (service principals), como ele é distribuído (YAML de Declarative Automation Bundles, anteriormente Databricks Asset Bundles) e quando você não deve usá-lo de modo algum (Amazon MWAA/Airflow, AWS Step Functions). Todo limite e preço abaixo traz a fonte e o carimbo de data de outubro de 2026; tudo que a Databricks não publica fica de fora, em vez de ser chutado.

Nesta lição você vai:

• reconstruir o rename de Workflows → Lakeflow Jobs e a anatomia job/tasks/triggers contra o envelope de escala publicado (tasks, jobs, triggers, concorrência, criações por hora);
• escolher tipos de task e compute na matriz serverless-first e precificar o mesmo job nos pisos de $0.15 vs.$0.40 por DBU;
• montar o DAG: depends_on + as seis condições run_if, fluxo de controle por condition/for-each/Run Job, e a semântica Excluded-conta-como-sucesso que decide se a sua task de alerta chega a rodar;
• configurar as seis famílias de trigger: agendamentos Quartz com o piso de 10 segundos e o ajuste DST → UTC, triggers de chegada de arquivo com cooldown de 900 s / debounce de 60 s, triggers de atualização de tabela com o piso de debounce de 60 segundos;
• separar o enfileiramento (teto de 48 horas, ligado por padrão em jobs de UI desde 2024-04-15) do skipping e diagnosticar os dois com forense nas system tables de jobs;
• definir retries, timeouts, repairs, partial runs e notificações por webhook, sabendo que tasks classicas não fazem nenhum retry por padrão e que alertas de nível de job ficam em silêncio enquanto houver retries;
• rodar jobs de produção como service principals com OAuth M2M, e não como a pessoa que clicou em Create;
• descrever o estate em Declarative Automation Bundles YAML com alvos dev/prod e fontes de task em Git remoto, e fazer a ponte com calendários corporativos via Amazon MWAA com DatabricksRunNowOperator;
• escolher Workflows vs. Airflow/MWAA vs. Step Functions a partir de uma matriz de decisão com preços, estudar NAB e Asurion na AWS, ler a caixa de atualizações de 2026 e praticar com catorze questões mais quatro verificações interativas.

---

1. Anatomia: um job, um DAG, três conceitos

Os docs são lacônicos de propósito: um job guarda tasks, tasks são visualmente representadas por um DAG, e triggers decidem quando o job dispara. As configurações de nível de job carregam o resto: Trigger, Parameters, Notifications (e-mails ou webhooks), Git (docs.../jobs/, 9 de outubro de 2026). Todo o resto desta lição é um detalhe uma dessas quatro superfícies.

1.1 O envelope de escala (todos acessados em out 2026)

Dois números causam a maior parte do estrago operacional. Primeiro, max_concurrent_runs tem padrão 1: "Por padrão, o máximo de execuções concorrentes de todos os jobs novos é 1", e uma execução que excederia o teto é pulada, a menos que o enfileiramento a intercepte (configure-job). Segundo, o teto de 2.000 execuções de tasks concorrentes do workspace é global: uma frota de jobs de fan-out pode esfomear umas às outras, e o erro aparece como 429 ou como WORKSPACE_RUN_LIMIT_EXCEEDED nas system tables (visão geral de jobs; system-tables/jobs, 21 de maio de 2026).

• 📚 Você sabia? A referência legada da Jobs API 2.0 (atualizada pela última vez em 3 de agosto de 2026) ainda diz "A job can contain up to 100 tasks", enquanto a visão geral atual e o blog "What's new in Workflows?" de 2024-08-22 dizem 1.000. O número de 1.000 tasks é o limite atual de produto (os endpoints de escrita o impõem); as 100 são uma página legada desatualizada, e os endpoints de leitura simplesmente devolvem 100 por página com paginação. Carimbe sempre a data do limite que você cita.

---

2. Tipos de task e compute: serverless primeiro, nunca all-purpose

2.1 A paleta de tipos de task

A paleta atual da UI (página configure-task) é:

• 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

O mapeamento REST (Jobs API 2.2) é o que o seu YAML realmente escreve: notebook_task, spark_jar_task, spark_python_task, python_wheel_task, sql_task, dbt_task, run_job_task, condition_task, foreach_task, pipeline_task: com spark_submit_task marcado "Deprecated (Legacy) … Databricks recommends using the spark_jar_task instead".

Três entradas merecem comentário antes da matriz de compute:

• dbt é first-class: uma task dbt é "one or more dbt commands" mais um project_directory, e "A task dbt requer tanto o Databricks SQL quanto a capacidade de usar um SQL warehouse serverless ou pro": SQL warehouses classicos ficam restritos a jobs SQL agendados de task única (Jobs API 2.2). A Databricks injeta DBT_ACCESS_TOKEN para a identidade Run-as, e é por isso que o service principal de run-as precisa de acesso ao warehouse e de grants no UC.
• Tasks de Condition (if/else) "não exigem um cluster para executar e não suportam retries nem notificações" (Jobs API 2.2; docs de bundles, 21 de agosto de 2026). Você não consegue "repetir um branch": repita a task de dados que o branch protege.
• Tasks de Run Job disparam "outros jobs configurados no seu Databricks workspace", apenas no mesmo workspace, com os parâmetros do job empurrados para baixo, e têm teto rígido: "A Databricks não suporta jobs com dependências circulares nem jobs que aninham mais de três Run Job tasks" (docs.../jobs/tasks/run-job, 11 de setembro de 2026).

2.2 A árvore de decisão de compute

A página compute-matrix (atualizada pela última vez em 15 de setembro de 2026) é explícita: "Compute serverless para workflows… é o padrão para todas as tasks que o suportam", e "Compute all-purpose | Você pode configurar opcionalmente tasks usando all-purpose clássico. A Databricks não recomenda essa configuração para jobs de produção."

A cobrança segue a escolha do cluster, e essa única regra ancora toda lição de custo do 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" (referência da Jobs API 2.0, 3 de agosto de 2026). Job clusters também se comportam diferente na saída: o compute "termina e fica indisponível para reinício quando o job é concluído", enquanto um job agendado apontado para um cluster all-purpose encerrado o autostarta (docs.../compute/clusters-manage): é assim que um cluster reutilizado "barato" vira discretamente uma linha de conta 24×7.

2.3 Exemplo resolvido E1, o mesmo job, dois SKUs

Em out 2026. Um job medallion roda 2 horas por dia e consome 12 DBU/h (um fan-out modesto de múltiplas tasks em compute de jobs classicos). Custo mensal de DBU nos pisos oficiais da página de preços da Databricks (instantâneo 2026-10):

Jobs serverless são o terceiro caminho: eles "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), e a página de best practices de serverless acrescenta que "Standard mode can reduce costs by up to 70% compared to performance-optimized mode": ao preço de "4 to 6 minutes" de latência de inicialização (run-serverless-jobs, 9 de outubro de 2026). Jobs serverless exigem um workspace com Unity Catalog habilitado e access mode padrão; a auto-otimização (incluindo retries, seção 6) vem ligada por padrão.

• 📚 Você sabia? Jobs serverless carregam rate-limit objects automatizados que limitam a execução a cerca de 60 / 120 / 240 / 480 / 960 DBU por hora de Small até 2X-Large, e "Within a single job, the cap is shared across all the job's tasks" (docs.../compute/serverless/manage-serverless-compute, acesso em out 2026). Rate limits valem apenas para cargas automatizadas, notebooks interativos e Databricks Connect são isentos, e aplicá-los exige Databricks Runtime 17.3.1 ou superior. Um ticket do tipo "por que meu fan-out travou?" muitas vezes tem essa como resposta.

---

3. Dependências e fluxo de controle: o DAG que você realmente tem

Tasks depois da primeira declaram depends_on: [{task_key: …}], o que desenha as arestas. O que essas arestas significam é decidido pelo Run if, e é aqui que DAGs de produção saem do trilho. As seis condições (docs de configuração do run-if, 25 de junho de 2026): All succeeded (default) · At least one succeeded · None failed · All done · At least one failed · All failed.

Três semânticas documentadas são de prova de exame e de incidente ao mesmo tempo:

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": independentemente do próprio Run if daquela task. Cancelamento da mesma forma "propaga para as tasks a jusante, e tasks com uma condição Run if que trata falhas são executadas".

Leia o diagrama como uma política, não como um formato. dq_gate usa NONE_FAILED porque a publicação em gold não pode rodar sobre um silver corrompido, mas um upstream cancelado conta como falha, então um cancelamento manual ainda pula o gold, que é o que você quer. A task de alerta usa AT_LEAST_ONE_FAILED para sobreviver à falha do silver; como "Upstream failed" conta como falha, o alerta dispara exatamente nos incidentes que interessam. Os companheiros de fluxo de controle completam a caixa de ferramentas: tasks de condition If/else comparam operandos (EQUAL_TO, GREATER_THAN, …) contra valores dinâmicos como {{job.repair_count}} ou {{tasks.task_key.values.output}} (docs de job-task-types do bundles, 21 de agosto de 2026); For each percorre um array JSON, manual ou produzido a montante via dbutils.jobs.taskValues.set; Run Job compõe jobs inteiros, no mesmo workspace, sem ciclos, com aninhamento ≤3 níveis.

• 📚 Você sabia? A propagação de parâmetros tem direção e vencedor: os parâmetros do job "are pushed down automatically, and if a job parameter and a task parameter share a key, the job parameter takes precedence", mas "Tasks that take JSON-array parameters don't receive job parameters automatically; reference them explicitly with {{job.parameters.<name>}}" (docs.../jobs/parameters, 26 de junho de 2026). Tasks com array JSON são Python script, wheel posicional, JAR, Spark Submit e For each. Erre isso e a sua task de Python script roda silenciosamente com argv vazio.

---

4. Triggers: cron é um palpite, chegada de dados é um fato

Seis comportamentos de trigger existem hoje (docs de triggers, 6 de outubro de 2026): Scheduled, Table update, File arrival, Model update (Beta), Continuous ("trigger another job run whenever a job run completes or fails") e None (manual). Múltiplos triggers por job estão em Beta: até cinco, cada um pausável independentemente, e "Um trigger contínuo não pode ser combinado com nenhum outro trigger". A API os carrega em um array triggers; não misture esse array com os campos legados schedule / trigger / continuous em uma mesma request.

4.1 Agendado: Quartz cron, o piso de 10 segundos e o DST

Agendamentos usam sintaxe cron do Quartz em um timezone id do Java, com pause_status UNPAUSED/PAUSED (esquema do objeto Run, Jobs API 2.2: exemplo "quartz_cron_expression": "20 30 * * * ?", "timezone_id": "Europe/London"). Três regras da página de schedules (atualizada pela última vez em 26 de junho de 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."
• Fusos que observam DST: "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 Exemplo resolvido E2, o bug de cron e a correção event-driven

Triggers de chegada de arquivo "fazem o melhor esforço para verificar novos arquivos a cada minuto", monitoram "the root of a Unity Catalog external location or volume, or a subpath" recursivamente, e "do not incur additional costs other than cloud provider costs associated with listing files" (docs de chegada de arquivo, 7 de outubro de 2026). Os cantos afiados: somente arquivos novos disparam: "Sobrescrever um arquivo existente com um arquivo de mesmo nome não dispara uma execução"; sem curingas; e "Quando o diretório configurado não existe ou foi excluído do Amazon S3…, os triggers de chegada de arquivo continuam avaliados sem erro". Sem file events habilitados na external location, o workspace te limita a "A maximum of 50 jobs" com triggers de chegada de arquivo nesses locais e "10,000 files" no caminho monitorado. O pareamento recomendado é Auto Loader com cloudFiles.useManagedFileEvents=true e trigger(availableNow=True): uma variante foreachBatch que "provides only at-least-once processing guarantees": com o checkpoint mantido fora do caminho monitorado.

4.3 Triggers de atualização de tabela

Um trigger de atualização de tabela "verifica atualizações de tabelas e, quando uma tabela é atualizada, o job é executado", monitorando até 10 tabelas gerenciadas Delta/Iceberg do Unity Catalog, tabelas externas com Delta, materialized views, streaming tables e views dependentes: detectando "updates, merges, and deletes" (docs de atualização de tabela, 26 de junho de 2026). wait_after_last_change_seconds tem um piso de 60 segundos: é um debounce, não um SLA de menos de um minuto. Como a chegada de arquivo, ele "não gera custos adicionais além dos custos do provedor de nuvem", e "For best performance and scalability, enable file events on the external location."

• 📚 Você sabia? Um workspace pode guardar até 12.000 triggers ativos em todos os jobs e tipos de trigger, e triggers pausados não contam nesse limite (docs de triggers, 6 de outubro de 2026). Isso transforma a higiene de pause_status em uma ferramenta de capacidade: uma frota de jobs de backfill dormentes deve nascer com pause_status: PAUSED: que é exatamente o que o development mode do Declarative Automation Bundles faz por você (seção 8).

---

5. Enfileiramento, concorrência e a armadilha do skip

Quando uma execução não pode começar, duas máquinas diferentes a capturam, e só uma vem ligada por padrão. O enfileiramento (ligado por padrão em jobs criados pela UI depois de 15 de abril de 2024) segura a execução "for up to 48 hours if resources are unavailable", acionado quando qualquer um dos três limites é atingido: o máximo de execuções ativas concorrentes do workspace, o máximo de execuções de task Run Job concorrentes do workspace, ou o próprio max_concurrent_runs do job (configure-job, 7 de julho de 2026). Sem enfileiramento, atingir um limite significa que a execução é pulada, e uma execução agendada pulada é uma lacuna silenciosa de dados.

Botões e tetos para manter direitos: max_concurrent_runs padrão 1, máximo rígido 1.000, 0 pula tudo; baixá-lo nunca mata execuções ativas; as 2.000 execuções de tasks concorrentes em todo o workspace devolvem 429 ou WORKSPACE_RUN_LIMIT_EXCEEDED mesmo com o enfileiramento ligado (visão geral de jobs; system tables). A profundidade da fila além do teto documentado de 48 horas não é publicada: trate "quão profunda é a fila interna, e em que ordem ela desenfileira?" como desconhecido, e projete para o teto, não para justiça.

5.1 Exemplo resolvido E3: forense de fila nas system tables

A mesma referência lista os estados de falha que valem um alerta: WORKSPACE_RUN_LIMIT_EXCEEDED ("O workspace atingiu a cota para o número máximo de execuções ativas concorrentes"), MAX_CONCURRENT_RUNS_EXCEEDED, MAX_JOB_QUEUE_SIZE_EXCEEDED, CLUSTER_REQUEST_LIMIT_EXCEEDED e REPOSITORY_CHECKOUT_FAILED: mais a nota honesta de que creator_user_name e paused são "Não preenchido para linhas emitidas antes de início de dezembro de 2025", então consultas históricas de higiene precisam de um piso de data.

---

6. Confiabilidade: retries, timeouts, repairs, notificações

6.1 Retries diferem por compute, o padrão é silêncio

"A configuração padrão de retries de task depende da configuração do job. Na maioria das configurações, a configuração padrão não repete nenhuma task quando a task falha" (configure-task). Contra isso: "Serverless jobs auto-optimize retries by default" (dê opt out pela caixa "Enable serverless auto-optimization", e dê mesmo opt out para sinks não idempotentes), e "Continuous jobs use an exponential backoff retry policy" (mesma página). Os botões por task: max_retries, min_retry_interval_millis, retry_on_timeout; timeout_seconds é por task, com "A value of 0 means no timeout" (Jobs API 2.2), e um timeout não é repetido, a menos que retry_on_timeout esteja definido.

6.2 Exemplo resolvido E4: a política de retry como documento de design

Superfícies de recuperação além dos retries: repair reexecuta "the subset of unsuccessful tasks" em uma execução multi-task; partial runs (blog do Lakeflow Jobs, 2025-07-24) "allow users to select which tasks to execute without affecting others": a resposta operacional para "reexecutar só a task de gold que quebrou"; e as saídas de query SQL podem alimentar tasks seguintes como parâmetros (mesmo blog). Tasks de notebook também têm tetos rígidos de saída: 30 MB de saída combinada de células e 8 MB por célula: além dos quais a execução falha (docs.../jobs/tasks/notebook, 11 de setembro de 2026); tasks tagarelas precisam gravar em Delta, não em stdout.

6.3 Notificações: três destinos, retries em silêncio

Eventos de notificação (docs de notificações, 9 de outubro de 2026):

• Start
• Successful completion
• Failure
• duration threshold exceeded
• streaming backlog threshold exceeded
• maintenance start/complete (continuous jobs)

Os destinos são "email addresses or third-party destinations such as Slack, Microsoft Teams, PagerDuty, or any webhook-based service", onde "An administrator must configure system destinations" e "Para cada job ou task, você pode configurar no máximo três system destinations para cada tipo de evento de notificação". Os códigos event_type de webhook são estáveis: jobs.on_start, jobs.on_success, jobs.on_failure, jobs.on_duration_warning_threshold_exceeded.

6.4 Exemplo resolvido E5, o payload do webhook e a chamada run-now

Use tokens OAuth M2M (client id + OAuth secret; access tokens válidos por 1 hora, secrets com escopo em jobs) em vez de personal access tokens; se uma integração legada forçar um PAT, use um PAT de service principal, nunca o de um humano (seção 7 e a costura do Airflow na seção 9).

---

7. Identidade: owner, Run as, e a saída que quebra às 3 da manhã

Um job tem duas identidades: o owner (ACL do job; "Somente administradores do workspace podem editar o owner do job") e a identidade Run as, cujas permissões executam cada task. Run as padrão = criador do job, e a recomendação dos docs é inequívoca: "A Databricks recomenda mudar o Run as user para um service principal, para que os privilégios possam ser controlados separadamente dos privilégios do owner, e para que os jobs não quebrem quando o owner sair ou tiver mudado de privilégios" (docs.../jobs/privileges, acesso em out 2026). Mudar o Run as exige CAN MANAGE ou IS OWNER no job, o service principal precisa do entitlement Service Principal User, e "Run as a group" está em Public Preview.

O detalhe de auditoria importa na revisão de incidentes: identity_metadata.run_as registra a sua identidade configurada (o grupo, no preview de Run-as por grupo), enquanto identity_metadata.run_by "always records" o service principal de aplicação do serviço Jobs (mesma página). O modo de falha que isso evita é o quebra-cabeça de produção mais comum do curso: o job agendado continua parecendo saudável na hora do agendamento e morre na primeira leitura no UC depois que o acesso do criador é revogado. A autenticação machine-to-machine para orquestração é OAuth M2M (tokens de 1 hora) ou, para Airflow na AWS, a federalização de token AWS IAM OIDC do provedor: "exchange for a Databricks OAuth token. Stores no secrets" (docs do apache-airflow-providers-databricks 7.19.0, acesso em out 2026).

---

8. Jobs como código: Declarative Automation Bundles

Montar jobs clicando na UI não sobrevive a um segundo engenheiro. A superfície as-code é o Declarative Automation Bundles, "formerly known as Databricks Asset Bundles" (docs.../dev-tools/bundles, acesso em out 2026), que empacota "Source files… Definitions and settings for Databricks resources, such as Lakeflow Jobs, Lakeflow Spark Declarative Pipelines, Dashboards, Model Serving endpoints, MLflow Experiments". O loop: escreva databricks.yml + resources/*.job.yml, depois databricks bundle validate → databricks bundle deploy --target dev → databricks bundle run --target dev <job>.

8.1 Exemplo resolvido E6: um job multi-task de produção, YAML completo

Tudo nesse arquivo mapeia para um campo documentado: run_as.service_principal_name aceita "the email of an active workspace user or the application ID of a service principal" (Jobs API 2.2); queue.enabled espelha o comportamento de enfileiramento de 48 horas (seção 5); o bloco de retry é o E4; run_if é a seção 3; schedule é o formato verificado do exemplo job-settings da Jobs API (acesso em out 2026). Jobs existentes construídos na UI podem ser engenharia reversa para esse formato com databricks bundle generate job (docs de job-task-types do bundles, 21 de agosto de 2026), o caminho de migração mais rápido a partir do click-ops.

8.2 Alvos dev/prod são a barreira de segurança

Predefinições do development mode (docs de deployment-modes do bundles): "Pausa todos os schedules e triggers nos recursos implantados, como jobs" (anule com schedule.pause_status: UNPAUSED), antepõe o prefixo de nome [dev ${workspace.current_user.short_name}] e "Enables concurrent runs on all deployed jobs". O production mode não aplica nada disso: é por isso que o mesmo YAML é seguro de publicar de um laptop e assustador de publicar de um laptop sem alvos. A promoção é databricks bundle deploy --target prod a partir do CI, com o service principal de run-as e os secrets resolvidos por alvo.

8.3 Fontes Git: um repo, um commit, um snapshot

Tasks de notebook, Python script, SQL file e dbt podem usar uma fonte em repositório Git remoto (docs.../jobs/git, 11 de setembro de 2026): "Todas as tasks de um job devem referenciar o mesmo commit… a Databricks faz um snapshot da branch ou commit especificados" quando a execução começa; "Apenas um repositório Git remoto pode ser usado para todas as tasks de um job"; e "Tasks configured to use a remote Git repository cannot write to workspace files". Git folders (sync workspace-repo) funcionam, mas precisam ser sincronizados manualmente e são recomendados "apenas para iteração rápida e testes durante o desenvolvimento": tasks de staging e produção referenciam o repo remoto com branch/tag/commit fixados, e o histórico de execuções mostra o SHA do commit.

---

9. A costura externa: Airflow e Amazon MWAA

Alguns calendários são propriedade da empresa: janelas de SAP, manutenção do Redshift, SLAs de API de terceiros. A própria página da Databricks documenta a costura, "você também pode agendar seus jobs usando ferramentas como o Apache Airflow", com a ressalva de que os pacotes open source "are not directly supported by Databricks" (docs.../jobs/how-to/use-airflow-with-jobs, 11 de setembro de 2026). O mapa de operators:

Endurecimento de produção vindo dos docs do provedor (7.19.0 / módulo 7.20.0, acesso em out 2026): o 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"; existem variantes deferrables; a conexão deve carregar SP OAuth ou federalização AWS IAM OIDC, e nunca um PAT humano; e o operator "write[s] the job run page URL to the Airflow logs every polling_period_seconds (the default is 30 seconds)" (tutorial do Databricks). Higiene de versão: o tutorial da Databricks ainda diz "Airflow version 2.5.0 and later… tested with Airflow version 2.6.1", enquanto o provider 7.19.0 exige "Apache Airflow version supported by this provider distribution is 2.11.0": fixe e teste no MWAA em vez de confiar em qualquer um dos números sozinho.

9.1 Exemplo resolvido E7, o DAG do MWAA para o Databricks, precificado

A regra de design que sai do E7: uma caminha é dona das arestas do DAG, a outra é dona do compute. Os retries do Airflow espelham, mas não podem multiplicar, os retries de task do Databricks (ponha retries do Airflow em 0 to 1 quando o job já repete 2 to 3); a URL do DatabricksRunNowOperator no log do Airflow é o seu breadcrumb entre sistemas; e estates com múltiplos workspaces mantêm uma conexão MWAA (ou um conjunto de credenciais OIDC) por workspace, porque a task Run Job e o run-now são primitivas do mesmo workspace.

---

10. A matriz de decisão do scheduler: Workflows vs. Airflow vs. Step Functions

Três orquestradores tocam um estate Databricks-na-AWS, e cada um tem uma forma de preço documentada.

O híbrido em que a maioria dos times de AWS para: um único job de "ingest" do Databricks com trigger de chegada de arquivo é dono da prontidão dos dados; o MWAA é dono do calendário corporativo e chama esse job com DatabricksRunNowOperator; e o Step Functions coordena os passos do lado da AWS ao redor da chamada do Databricks. Alternativas da família do Airflow gerenciado (Prefect, Astronomer) integram pela mesma costura REST/SDK: mesma arquitetura, conta diferente, então mantenha a comparação qualitativa até ter as cotações ao vivo delas.

Veredito Comparativo: Lakeflow Jobs vs. Amazon MWAA/Airflow vs. AWS Step Functions (AWS, em out 2026)

• Lakeflow Jobs, o padrão para DAGs nativos do Databricks. Sem cobrança de scheduler ocioso (fornecedor: "sem sobretaxa de orquestração: você paga apenas pelo compute usado pelas suas tasks", blog 2025-01-12), triggers cientes de dados em external locations no S3 e tabelas UC, repairs/partial runs, run-as com service principals e observabilidade de jobs nas system tables. Piso de DBU $0.15/DBU (Data Engineering, instantâneo da página de preços 2026-10) em compute de jobs classicos: ou serverless que "cobra apenas quando um comando ou consulta é executado". Fraqueza: a orquestração para fora do Databricks ainda é jovem (o blog do Lakeflow de junho de 2026 anuncia External Orchestration para Snowflake/REST/Slack/PagerDuty sem declarar a maturidade), e o encadeamento por Run Job é só no mesmo workspace, ≤3 níveis, sem ciclos.
• Amazon MWAA/Airflow, o dono do calendário corporativo. DAGs neutros de fornecedor, operators/sensors customizados, semântica madura de backfill e o único lar confortável para fan-out que gasta a maior parte dos seus passos fora do Databricks. O custo honesto: um piso de $0.99/h em ambiente large ≈ $736.56/mês (exemplo da página de preços da AWS) mais workers a $0.22/h e metadados RDS a $0.10/GB-mês, orquestração com conta própria e com plantão próprio. Chame o Databricks pelo DatabricksRunNowOperator (SP OAuth ou IAM OIDC, deferrable, durable) para que as execuções continuem visíveis na UI de jobs.
• AWS Step Functions, o orquestrador cola da AWS. Melhor quando o centro de gravidade do workflow é Lambda/ECS/Batch/Glue e o Databricks é uma chamada de API entre muitas; a precificação Standard é por state transition ($0.025 por 1.000, AWS Compute Blog 2022-08-30: confira de novo a tabela ao vivo), o Express mede GB-segundos ($0.00001667/GB-s, página de preços acessada em out 2026). Você abre mão de task values, repairs e da UI de jobs: os recursos cientes de Databricks vivem fora do console.
• Veredito em uma linha: Lakeflow Jobs para o DAG interno do Databricks → MWAA onde o calendário ou o fan-out é não-Databricks → Step Functions onde os serviços da AWS são o workflow e o Databricks é um callee, e em todo híbrido, exatamente uma camada é dona das arestas do DAG, o run-now é dono da costura, e a identidade de run-as é um service principal.

---

Atualizações de 2026 (em outubro de 2026)

---

Casos Reais

📋 Caso A: NAB (National Australia Bank, banco, Cloud: AWS) Desafio. Um data warehouse Teradata de 26 anos carregando ~1.000 casos de uso e ~140 suítes de relatórios, mais ETL em Spark escrito à mão com DML de 5.000 to 8.000 linhas e até 64 union-all por pipeline, mantido por 300 to 400 engenheiros com prática inconsistente. Stack na AWS. Databricks SQL, Auto Loader, Spark Declarative Pipelines no Lakeflow (o irmão de pipeline do Jobs desta lição), Unity Catalog e asset bundles para CI/CD: Cloud: AWS na página da história. Resultado relatado. "1,800 Spark Declarative Pipelines running on Databricks Lakeflow · 99.6% Job success rate · 80% Less transformation complexity"; latência ponta a ponta "under 15 minutes"; qualidade de dados "+38%" (https://www.databricks.com/customers/national-australian-bank-nab, página sem data, acesso em 2026-10). Citação. "A migração não teria sido possível sem o Databricks SQL": Gurry (https://www.databricks.com/customers/nab/dbsql, página sem data, acesso em 2026-10). Mapeia para esta lição. Seções 6 e 8: uma taxa de sucesso de jobs de 99,6% em 1.000 pipelines é uma métrica de confiabilidade: retries, repairs, service principals de run-as e definições publicadas por bundle são o que transformam orquestração de heroísmo em um número que um auditor consegue acompanhar. ⏳ Nota temporal: página sem data, acesso em out 2026: um resultado de cliente relatado, não uma garantia de 2026.

📋 Caso B: Asurion (seguros / proteção de dispositivos, Cloud: AWS) Desafio. 8.000 tabelas, 10.000 views e ~600 data marts com mapeamentos de ETL por tabela, mais duplicação entre camada batch e camada de velocidade em milhares de jobs que não caberiam em um modelo de agendamento de um cluster por job. Stack na AWS. Spark Structured Streaming, Auto Loader, foreachBatch no Delta; fontes Kinesis, Kafka, SNS, SQS, CDC, APIs e arquivos flat; Databricks SQL para a camada de mart, o data lake de produção explicitamente na AWS. Resultado relatado. "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). Mapeia para esta lição. Seções 1 e 2: com 4.000+ jobs streaming, o design do job é a arquitetura: um framework parametrizado com convenções compartilhadas (task keys, timeouts, identidade de run-as, escolhas de compute) vence 4.000 ETLs sob medida, e os limites de escala de workspace da seção 1.1 são exatamente o envelope contra o qual um estate desses precisa ser projetado. ⏳ Nota temporal: números de 2021; trate como um marco de escala relatado e confira de novo qualquer limite de concorrência citado no blog na documentação atual antes de reutilizá-lo.

---

---

Perguntas de Prática (Practice Questions)