Lakeflow Declarative Pipelines (anteriormente Delta Live Tables): Expectations, Modes e a Decisão DLT vs Jobs

Todo patrimônio de dados acaba fazendo duas perguntas à sua camada de ETL: os dados estão bons? e o job realmente rodou? Na Databricks na AWS, a primeira pergunta é respondida dentro dos Lakeflow pipelines, o produto que os seus tutoriais de 2023 chamavam de Delta Live Tables (DLT): por um recurso chamado expectations: verificações SQL por registro, com três ações graduadas (warn, drop, fail) e métricas legíveis por máquina. A segunda pergunta é respondida pela orquestração, que no mundo Databricks significa Lakeflow Jobs (Workflows). O erro mais caro deste domínio é confundir os dois planos: expectations garantem qualidade de dados, jobs garantem orquestração, e os docs dizem isso com todas as letras: "Expectations enforce data quality, not orchestration" (docs.../ldp/expectation-patterns, datado de 2026-07-14).

Esta lição ensina o produto sob seu nome atual e com todo o histórico de renomeação, porque em outubro de 2026 o seu ambiente vai conter os três nomes ao mesmo tempo: notebooks com import dlt, faturas com SKUs DLT_, campos de event log com dlt neles, e documentação que diz "Lakeflow pipelines". "O produto antes conhecido como Delta Live Tables (DLT) foi atualizado para Lakeflow pipelines. Se você já usou DLT, não há migração necessária para usar Lakeflow pipelines: seu código continua funcionando" (docs.../ldp/concepts/where-is-dlt, rodapé de 11 de setembro de 2026). Três nomes, um produto, zero reescritas forçadas, e uma superfície de cobrança que ainda diz DLT.

Nesta lição você vai:

• reconstruir a linha do tempo de nomes (anúncio do Lakeflow 2024-06 → GA 2025-06 + renomeação do DLT + contribuição ao Spark → nome nos docs out 2026) e triar os vestígios do DLT que sobrevivem a ela;
• escrever pipeline Python na API dp e provar para você mesmo que o estilo antigo @dlt.expect ainda roda;
• aplicar todos os seis decorators de expectation e as três ações, e explicar com precisão por que fail não grava métricas;
• consultar métricas de expectation no event log e na tabela de sistema pipeline_events (Beta);
• construir o padrão de quarentena com regras NULL-safe, para que linhas boas e ruins particionem a entrada exatamente uma vez;
• escolher entre os modos triggered, continuous e real-time e calcular a forma de custo de $105 vs$2,520 por mês dessa escolha;
• configurar pipelines na AWS: cascata de armazenamento do Unity Catalog, serverless vs classic, edições, run-as com service principals, Declarative Automation Bundles;
• decidir Lakeflow pipelines vs Workflows jobs com uma matriz de decisão, estudar NAB e Shell na AWS, ler a caixa de atualizações de 2026 e praticar com doze questões mais quatro verificações interativas.

---

1. Um produto, três nomes: a linha do tempo sobre a qual você será avaliado

1.1 A renomeação, com datas

Formulação da lição para decorar: Delta Live Tables (DLT), renomeado Lakeflow Declarative Pipelines no GA de junho de 2025 e hoje chamado Lakeflow pipelines nos docs: mesmo produto, três nomes, uma linha do tempo. Dois nomes relacionados não podem ser confundidos com o nome do produto: Apache Spark™ Declarative Pipelines (SDP) é o padrão aberto que a Databricks estendeu ("Todas as APIs Python do Lakeflow pipelines são implementadas no módulo pyspark.pipelines"; "Apache Spark™ inclui declarative pipelines a partir do Spark 4.1", docs.../ldp/developer/python-dev, datado de 2026-07-10), e Lakeflow é a família: Lakeflow Connect (ingestão gerenciada), Lakeflow Declarative Pipelines (esta lição), Lakeflow Jobs (Workflows) (blog de GA, 2025-06-12).

1.2 Os vestígios: por que suas queries de cobrança ainda grepam dlt

A página de FAQ é explícita sobre o que não mudou: "Ainda existem algumas referências ao nome DLT no Databricks. Os SKUs clássicos do Lakeflow pipelines ainda começam com DLT, e os schemas de event log com dlt no nome não mudaram. As APIs Python que usavam dlt no nome ainda podem ser usadas, mas a Databricks recomenda migrar para os novos nomes" (docs .../ldp/concepts/where-is-dlt, 2026-09-11).

• 📚 Você sabia? Um ticket de suporte que diz "why is there a pipeline ID on our SQL bill?" tem uma resposta documentada: "When you create a materialized view in a Databricks SQL warehouse, a serverless pipeline is created to process refreshes", e a linha de cobrança aparece como billing_origin_product = 'SQL' com usage_metadata.dlt_pipeline_id IS NOT NULL (docs.../admin/system-tables/serverless-billing, 2026-06-01). Pipelines não são apenas a coisa que você constrói; são também maquinário que outros produtos criam nas suas costas.

1.3 Exemplo resolvido E1, a migração: código dlt legado vs código dp atual

Em outubro de 2026. A Equipe A entrega um notebook DLT da era de 2023. A Equipe B pergunta se vale a pena reescrevê-lo. Resposta segundo os docs: sem migração obrigatória, mas a divisão de @dlt.table em dois decorators importa.

A tabela de mapeamento da referência de Python (datada de 2026-08-06): aprenda a coluna do meio e cite a coluna da esquerda só ao ler código antigo:

Duas armadilhas visíveis neste exemplo. Primeiro, a divisão de decorators: @dlt.table cobria os dois tipos de dataset; @dp.table com um DataFrame batch (ou @dp.materialized_view com um streaming) declara errado o tipo de dataset e quebra o planejamento de flows (mapeamento python-ref, 2026-08-06). Segundo, o predicado NULL-safe: amount >= 0 descarta apenas as linhas em que o predicado é falso; uma quantia NULL avalia como NULL e é mantida por expectations em modo drop. Escreva amount IS NOT NULL AND amount >= 0 (a seção 5 volta a esse ponto com a prova de particionamento da quarentena).

⚠️ AVISO, não copie e cole o resto de um blog post do DLT de 2023. Material antigo também diz "set continuous in the pipeline settings for production", "query LIVE.my_table", e "serverless is preview". Em outubro de 2026: o modo de publicação padrão ignora LIVE (consulte catalog.schema.table), serverless é o padrão para pipelines ETL novos, e a Databricks desaconselha o setting built-in de continuous para pipelines novos, embale o pipeline em um continuous job em vez disso (docs.../ldp/concepts/pipeline-mode, acesso 2026-10;.../ldp/serverless, 2026-10-09;.../ldp/target-schema, 2026-09-11).

---

2. O modelo declarativo: o que você escreve vs o que a plataforma faz

2.1 Pipelines, flows, datasets, e um DAG inferido

"A pipeline is the main unit of development and execution of Apache Spark™ Declarative Pipelines (SDP) in Lakeflow. A pipeline is a collection of source code files and a configuration" (docs.../ldp/concepts/pipelines, datado de 2026-10-09). A página de conceitos nomeia os blocos de construção: "pipelines, flows, streaming tables, materialized views, and sinks" (docs.../ldp/concepts/, datado de 2026-08-15). Você declara datasets com decorators; a plataforma "automatically infer[s] dependencies between datasets and arrange[s] them in a directed acyclic graph (DAG)": não existe decorator @graph; o grafo é inferido a partir do que as suas funções de dataset leem (concepts/pipelines, 2026-10-09).

Um flow é a aresta de processamento: "A flow reads data from a source, applies user-defined processing logic, and writes the result into a target … (Currently, only the Append and Update flows are exposed.)" (conceitos, 2026-08-15). Append flows são o padrão, um por alvo; update flows são apenas Python, via @dp.update_flow.

2.2 Leis de código: o motor avalia a sua função repetidamente

"Python pipeline code does not directly call the functions that perform data ingestion and transformation … Instead, Lakeflow pipelines interpret the decorator functions … and build a dataflow graph" (docs.../ldp/developer/python-dev, 2026-07-10). As funções de dataset "must return a Spark DataFrame", e você nunca deve chamar collect(), count(), toPandas(), save(), saveAsTable(), start(), toTable() dentro delas, o planejador avalia as definições várias vezes, então ações e efeitos colaterais quebram a idempotência. Ler outros datasets é feito com readers Spark comuns (spark.read.table, spark.readStream.table, SQL STREAM(...)), não com um helper especial source().

2.3 Fontes na AWS: de onde vêm os bytes

Dentro dos pipelines a plataforma é dona da encanagem: "Se você usa Lakeflow pipelines, o Databricks gerencia a schema location e outras informações de checkpoint automaticamente" (docs de schema do auto-loader, 2026-07-10), e "A localização do event log também serve como a schema location para qualquer consulta do Auto Loader no pipeline" (docs .../ldp/monitor-event-logs, 2026-10-09). A página de best practices do Auto Loader diz o padrão de produção sem rodeios: "Para a maioria dos usuários e pipelines de produção, o Auto Loader com Lakeflow pipelines é uma boa escolha. No entanto, se você precisar de controle e personalização máximos, use o Auto Loader com Structured Streaming" (docs, 2026-06-29).

---

3. Expectations: seis decorators, três ações, um regulamento

3.1 O inventário verificado: exatamente seis, sem decorator de quarentena

"Expectations are optional clauses in pipeline materialized view, streaming table, or view creation statements that apply data quality checks on each record passing through a query. Expectations use standard SQL Boolean statements" (docs.../ldp/expectations, rodapé de 11 de setembro de 2026). A referência de Python (datada de 2026-09-11) não deixa margem: "The dp module includes six decorators to control expectations behavior", e a ordem canônica é depois do decorator do dataset e antes da função:

Gêmeo SQL (para datasets escritos em SQL): CONSTRAINT name EXPECT (expr) com opcional ON VIOLATION DROP ROW ou ON VIOLATION FAIL UPDATE. Não existe decorator expect_all_or_quarantine: quarentena é um padrão documentado que você constrói sozinho (seção 5). Expectations exigem a edição de produto Advanced: "Core to run streaming ingest workloads … doesn't require advanced features such as change data capture (CDC) or expectations. Pro … plus … CDC. Advanced … and includes data quality constraints with expectations" (docs.../ldp/configure-pipeline, datado de 2026-10-01).

3.2 As três ações, desenhadas

Três cláusulas do doc de expectations (2026-09-11) que decidem o desenho de produção:

1. "Como fail faz a atualização falhar quando um registro inválido é detectado, as métricas não são registradas." Fail é uma parada de mão, não um instrumento de medição: nunca instrumente uma tabela com expectations em modo fail e depois fique se perguntando por que seu dashboard de qualidade está vazio.
2. "O nome de uma expectation deve ser único para um dado dataset. Você pode reutilizar expectations em vários datasets de um pipeline."
3. Constraints "must use valid SQL syntax and cannot contain … Custom Python functions, External service calls, Subqueries referencing other tables." Sem UDFs, sem APIs externas, sem verificações entre tabelas: se você precisa disso, isso pertence a um notebook de validação ou a um pipeline separado.

A semântica do modo de execução também importa: "In a triggered pipeline, the failure of a single flow does not cause other parallel flows to fail. In a continuous pipeline, an expectation failure stops the flow, all dependent flows, and the pipeline emits a message explaining why it stopped" (mesma página). O artefato de depuração dos docs para o modo fail é este: [EXPECTATION_VIOLATION.VERBOSITY_ALL] Flow 'sensor-pipeline' failed to meet the expectation. Violated expectations: 'temperature_in_valid_range'. Input data: '{"id":"TEMP_001",…}': nome do flow, nome da expectation e o registro problemático, em um erro só.

3.3 Exemplo resolvido E2: um pipeline medallion com as três ações

Em outubro de 2026, serverless, edição Advanced, alvos no Unity Catalog. A fonte completa do pipeline (adaptada da forma documentada nos docs; os aliases @dlt.expect* funcionam da mesma forma):

Narre o grafo antes de rodá-lo: bronze avisa (só métricas, bronze é para perícia, não para serving), silver descarta (linhas ruins nunca chegam ao consumidor; só as contas restam, a seção 5 mostra o que fazer quando contas não bastam), gold falha (um total de receita negativo é impossível, então pare o update em vez de publicá-lo). O motor infere o DAG (bronze_orders → silver_orders → gold_daily_revenue), publica os três no target schema do pipeline no Unity Catalog (fisicamente no armazenamento S3 gerenciado daquele schema) e um update triggered processa os dados disponíveis no início e para. Repare na divisão de tipos de dataset em ação: gold_daily_revenue é uma agregação batch, logo é @dp.materialized_view, não @dp.table.

---

4. Métricas: onde os números de expectation realmente ficam

4.1 O payload do event log é a API de métricas

Métricas não são colunas na sua tabela alvo. Os docs atuais as definem puramente como payloads do event log: "as métricas com a contagem de registros que passaram e falharam em uma expectation são armazenadas no objeto details:flow_progress.data_quality.expectations. A métrica com a contagem de registros descartados é armazenada no objeto details:flow_progress.data_quality. Os eventos … têm o tipo de evento flow_progress" (docs .../ldp/monitor-event-logs, 2026-10-09). O schema do array de expectations é publicado: array<struct<name: string, dataset: string, passed_records: int, failed_records: int>>, e dropped_records conta as linhas que "falharam em uma ou mais expectations".

Três superfícies leem os mesmos números:

1. UI de monitoramento do pipeline → dataset → aba Data quality (expectations warn/drop; a visão humana).
2. O event log por pipeline: uma tabela Delta oculta consultável como SELECT * FROM event_log(<pipeline_id>) (formatada event_log_{pipeline_id}), que você pode publicar em uma tabela nomeada do Unity Catalog para acesso mais largo (JSON de Advanced settings {"event_log": {"catalog", "schema", "name"}}).
3. A tabela de sistema pipeline_events (Beta): system.lakeflow_pipeline_events_preview.pipeline_events, que "contém eventos de todos os pipelines em todos os workspaces de uma região" e hoje é a superfície de consulta recomendada, completa com um Lakeview dashboard para download (docs.../ldp/monitor-and-query-events, 2026-10-09).

⚠️ Não vá caçar colunas _expectation_name na sua tabela silver. Material de comunidade mais antigo mostra colunas de metadados de expectation; os docs atuais definem o contrato acima e nada mais. Se o seu SQL de monitoramento faz select de _expectation_* a partir de uma tabela de pipeline, você está rodando código velho (docs .../ldp/monitor-event-logs, 2026-10-09; doc de expectations, 2026-09-11). E lembre-se: expectations em modo fail deixam nenhuma métrica por design, e é exatamente por isso que fail pertence a gates orquestrados (seção 7), não a tabelas de serving monitoradas.

4.2 Exemplo resolvido E3, SQL de monitoramento de DQ: event log, tabela de sistema, fatura

A query (c) é a tabela de vestígios da §1.2 em forma executável: pipelines são cobrados sob usage_metadata.dlt_pipeline_id, e as linhas serverless carregam product_features.performance_target ∈ {PERFORMANCE_OPTIMIZED, STANDARD} (docs .../admin/system-tables/serverless-billing, 2026-06-01). A aba Data quality na UI serve para um humano verificando um dataset; as queries (a) e (b) é o que você coloca em um alerta agendado ou em um dashboard de saúde do Lakeview.

• 📚 Você sabia? Pipelines retêm "60 dias de atualizações anteriores na interface do pipeline e na API do Pipelines" (docs.../ldp/configure-pipeline, 2026-10-01), mas "as mais antigas permanecem apenas no event log". Qualquer auditoria ou revisão de incidente que vá além de 60 dias é uma query de event log (ou da tabela publicada de event log), o que é mais uma razão para nunca apagar aquela tabela.

---

5. Quarentena: um padrão, não um decorator, e a armadilha do NULL dentro dele

Quando expectations em modo drop são destrutivos demais (dados regulamentados, requisitos de replay), você precisa manter as linhas ruins. A Databricks documenta a receita: uma streaming table temporária particionada por uma flag is_quarantined computada, anotada com @dp.expect_all(rules) para que as métricas continuem fluindo, e depois duas views que dividem o stream (docs.../ldp/expectation-patterns, datado de 2026-07-14).

5.1 Exemplo resolvido E4: a forma oficial de quarentena, deixada NULL-safe

Depois, em produção, promova invalid_trips_data a um @dp.table(name="trips_quarantine") de verdade (ela precisa persistir no S3 sob o Unity Catalog: para pipelines UC isso significa o armazenamento gerenciado do schema, a location do catalog ou a raiz do metastore, nessa ordem de fallback) e alerte sobre a contagem de linhas dela; nada na plataforma faz replay automático nem expira tabelas de quarentena.

História de replay (prática do curso, consistente com o padrão documentado): trague as linhas de quarentena → corrija no upstream ou aceite-as → rode de novo a mesma transformação filtrada com um predicado alargado ou com MERGE a partir da tabela de quarentena depois do reparo → o próximo update do pipeline continua (Delta ACID + estado do pipeline mantêm os replays idempotentes desde que você faça replay por chave, não por append às cegas) → arquive ou descarte as linhas de quarentena sob direitos MODIFY do UC com trilha de auditoria.

---

6. Modos e garantias: triggered, continuous, real-time

6.1 A tabela de modos

"Triggered mode refreshes available data and stops, while continuous mode keeps tables fresh as new data arrives" (docs .../ldp/concepts/pipeline-mode, acesso 2026-10). Dois fatos que os alunos costumam errar: "Pipeline mode is independent of the type of table being computed" (tanto MVs quanto streaming tables atualizam em qualquer modo), e "Refresh operations for standalone materialized views and streaming tables always run using triggered pipeline mode".

6.2 Exactly-once: dentro do envelope e nas suas bordas

"Lakeflow pipelines give you exactly-once processing by default within the tables they manage, and at the edges you add idempotent writes to keep re-runs safe" (docs.../ldp/best-practices/processing-guarantees, datado de 2026-08-15). Mecanismo: "Streaming tables use Structured Streaming checkpoints combined with Delta Lake's transactional writes: each micro-batch commits its source offsets and its output together, so a retried batch after a failure either fully succeeds or is fully rolled back … never partially applied twice", para Auto Loader, Kafka, Kinesis e upserts de AUTO CDC, "without any code from you". A regra de bolso: "if your entire pipeline is Delta-to-Delta … you already have exactly-once." Onde termina: foreach_batch_sink, sinks Kafka/não-Delta e fontes Python customizadas são at-least-once, torne a escrita idempotente ou deduplique downstream.

6.3 A regra do continuous job (higiene de produção)

A orientação atual da Databricks é um padrão, não uma preferência: "A Databricks recomenda rodar pipelines continuous com um continuous job em vez de definir … Pipeline mode como continuous … o job gerencia o ciclo de vida de execução do pipeline e desbloqueia performance modes serverless, como o Standard mode, que o modo continuous nativo do pipeline não suporta." E quando um job orquestra um pipeline, "o job determina o modo de execução e prevalece … defina o Pipeline mode do pipeline como triggered (o padrão) quando o envolver em um continuous job." O setting nativo "não está sendo removido, mas a Databricks desaconselha seu uso em pipelines novos" (docs .../ldp/concepts/pipeline-mode, acesso 2026-10). O modo real-time anda na mesma pilha: "O modo continuous ainda é obrigatório" (docs .../ldp/real-time, acesso 2026-10).

6.4 Exemplo resolvido E5: a decisão de modo, em dólares

Em outubro de 2026. Aritmética sobre as taxas documentadas: pipelines Lakeflow serverless são relatados a $0.35/DBU (orçamento de cliente da página de preços, confirmado em substância por uma resposta de staff da Databricks, "Embora o preço em DBU seja o mesmo nos dois modes, o mode Performance Optimized … pode aumentar bastante o custo total por consumir mais DBUs", Databricks Community, 2025-07-10); SKUs clássicos do DLT corroborados por um CSV de taxas de terceiros (coletado em 2026-04-10): DLT_CORE_COMPUTE $0.20, DLT_PRO_COMPUTE $0.25, DLT_ADVANCED_COMPUTE $0.36, trate aquele CSV como corroboração de nomes de SKU e confirme o card no ar antes de assinar um orçamento.

O enquadramento de break-even é a disciplina que este curso quer: comece em triggered, e compre continuous (ou real-time) apenas com um SLA de latência cujo valor de negócio supere o prêmio de sempre-ligado. A mesma matemática se estende aos performance modes: o performance mode serverless padrão "costuma iniciar em quatro a seis minutos após ser acionado" e "Os dois modes usam o mesmo SKU, mas o standard performance mode consome menos DBUs": a economia está no consumo, não na taxa, e o standard mode para pipelines continuous só é alcançável via um continuous job com "Performance optimized" desmarcado (docs.../ldp/serverless, 2026-10-09).

---

7. Topologia: um pipeline ou vários? (e por que expectations não podem fazer gate)

7.1 Um pipeline: o grafo medallion em um único update

Um único pipeline pode abrigar bronze→silver→gold: o motor infere as dependências, publica todo dataset não-private no target schema e deixa esconder intermediários com private=True (ref. de tabela, 2026-08-06). Você tem um update, uma atribuição de compute, ordenação automática e estado incremental compartilhado: é por isso que o grafo do exemplo resolvido E2 é um pipeline só. Mas lógica de orquestração não pode morar dentro dele: um dataset de validação com expect_or_fail falha apenas o seu próprio flow (modo triggered) ou os dependentes dele (modo continuous), e "A validation table doesn't gate its downstream tables … To stop downstream processing when a validation fails, split the validation logic and the downstream work into separate pipelines and orchestrate them with a job" (expectation-patterns, 2026-07-14).

Regra prática deste curso: um pipeline por domínio/SLA delimitado (ex.: ingest+limpeza de pedidos; um segundo pipeline para os marts gold gated), jobs orquestrando-os em ordem, executando como um service principal. O run_if = ALL_SUCCESS padrão do job é o que transforma um expectation em modo fail em um gate de verdade: "Because a pipeline task fails when its update fails, the downstream task doesn't run unless the validation pipeline succeeds" (expectation-patterns, 2026-07-14).

7.2 Updates de desenvolvimento vs updates de produção

Updates interativos a partir do Lakeflow Pipelines Editor (a "IDE for data engineering" anunciada no release de GA, com pareamento código-DAG, previews contextuais e execução seletiva de um arquivo/tabela) usam "fast-start, debugging-focused behavior"; updates vindos de Jobs ou da Pipelines API, e todos os updates continuous, usam retry e restart automáticos (restart do cluster em erros recuperáveis como credenciais obsoletas, retry em falha de subida do cluster, cluster derrubado depois da execução) (monitor-event-logs, 2026-10-09; doc de updates). Checklist de higiene de produção: agende uma pipeline task no Workflows (os gatilhos de update são "Manual … Scheduled (jobs) … Programmatic"), defina run-as como um service principal ("Running pipelines as service principals is considered a best practice because they are not tied to individual users"), promova código com Declarative Automation Bundles, mantenha o pipeline em triggered a menos que um SLA sub-segundo comprovado exija continuous/real-time, e lembre-se da janela de histórico de 60 dias na UI/API.

---

8. Configurando o pipeline na AWS: armazenamento, compute, edições, identidade

8.1 Onde os dados aterrisam: a cascata de armazenamento do Unity Catalog

"Unity Catalog é o padrão para pipelines recém-criados" e é um requisito para serverless (docs .../ldp/unity-catalog, 2026-10-09). O armazenamento segue uma regra: "Os dados de materialized views e streaming tables são armazenados na storage location do schema que os contém. Se nenhuma schema storage location for especificada, as tabelas são armazenadas na storage location do catalog. Se as schema e as catalog storage locations não forem especificadas, as tabelas são armazenadas na storage location raiz do metastore." Duas exceções que você precisa decorar:

• O parâmetro Python path= em @dp.table(...)/create_table, "Uma storage location para os dados da tabela. Se não for definida, use a storage location gerenciada do schema que contém a tabela" (ref. de tabela, 2026-08-06), a forma suportada de fixar uma tabela de pipeline em uma location explícita (ex.: um volume UC ou um prefixo S3 atrás de external location).
• A propriedade SQL LOCATION não é suportada ao definir tabelas em pipelines UC (limitações unity-catalog, 2026-10-09). Settings legados de pipeline storage (pipelines anteriores a 5 de fevereiro de 2025, era do Hive metastore) caem por padrão em dbfs:/pipelines/ e "cannot be changed after a pipeline is created" (ref. de propriedades, 2026-07-14).

A semântica de exclusão também mudou com o UC: excluir um pipeline retém as suas tabelas por padrão (ficam inativas, mas continuam consultáveis); DELETE /api/2.0/pipelines/{id}?cascade=true as remove; UNDROP recupera tabelas derrubadas em até 7 dias; e os dados de suporte vivem sob um catálogo __databricks_internal: "This is expected" (doc unity-catalog, 2026-10-09).

8.2 Serverless vs classic (AWS)

Pipelines ETL novos já nascem como "Unity Catalog · Current channel · Serverless compute" (configure-pipeline, 2026-10-01). Requisitos de serverless: workspace com UC habilitado, aceite dos termos de serverless, uma região com serverless habilitado (confira a matriz de suporte de regiões, não dê por garantido) e "Se você precisar usar uma conexão AWS PrivateLink com os seus pipelines Lakeflow serverless, entre em contato com o seu representante da Databricks" (doc serverless, 2026-10-09). Nenhuma permissão de criação de cluster é necessária. Capacidades exclusivas de serverless: "Incremental refresh for Materialized views", "Stream pipelining" (habilitado por padrão) e "Vertical autoscaling". O classic continua para pipelines legados de Hive metastore, setups de rede não suportados e regiões sem serverless; as suas alavancas são enhanced autoscaling, tipos de instância worker/driver, instance profile, cluster policy, cluster tags e o toggle do Photon. Você não pode misturar: um pipeline grava ou no UC ou no Hive metastore, nunca nos dois, e "Os pipelines existentes que usam o Hive metastore não podem ser atualizados para usar o Unity Catalog … você precisa criar um novo pipeline e reingestionar os dados" (doc unity-catalog, 2026-10-09).

8.3 Exemplo resolvido E6, ligação de produção: bundle DAB, config de pipeline, continuous job, run-as

A identidade de run-as precisa deter, no Unity Catalog: "USE CATALOG no catalog de destino; USE SCHEMA e CREATE TABLE no schema de destino; permissão MODIFY nas tabelas existentes que o pipeline atualiza" (configure-pipeline, 2026-10-01): mais acesso ao armazenamento de nuvem via storage credentials e external locations (os objetos suportados por IAM role da lição 03) para todo caminho S3 que o pipeline tocar. Repare em cada linha não óbvia: pipeline_mode: TRIGGERED + continuous: true na job é o padrão da §6.3 (o job prevalece de qualquer forma, mas deixar o pipeline em triggered evita surpresas); edition: ADVANCED é o gate da §3.1 para expectations; e os targets dev/prod promovem o mesmo código sem bifurcá-lo.

• 📚 Você sabia? O modo file-notification do Auto Loader tem um limite de escala duro que você vai eventualmente bater: "100 pipelines per S3 bucket" no modo clássico de file-notification (docs, 2026-10, via digest 07). File events gerenciados (DBR 14.3 LTS+) usam uma fila por external location em vez disso, o que é mais uma razão para que external locations, e não caminhos s3:// crus, sejam a unidade de governança de ingestão na AWS.

---

9. Lakeflow pipelines vs Workflows jobs: a matriz de decisão

O enquadramento dos docs: pipelines são "declarative datasets + flows" com estado gerenciado e processamento incremental; jobs clássicos são para o trabalho que a abstração esconde. As best practices do Auto Loader deixam o padrão explícito: "Para a maioria dos usuários e pipelines de produção, o Auto Loader com Lakeflow pipelines é uma boa escolha. No entanto, se você precisar de controle e personalização máximos, use o Auto Loader com Structured Streaming" (2026-06-29).

Na prática, ambientes de produção combinam os dois: uma pipeline task dentro de um multi-task job para agenda, dependências, retries e notificações; pipelines separados coordenados por dependências de job para gates de qualidade (§7.1); e jobs clássicos para o trabalho fora de DataFrame que nenhuma função de dataset pode conter.

Veredito Comparativo: Lakeflow pipelines (DLT) vs Workflows jobs (em out 2026)

• Lakeflow pipeline, a resposta padrão para ETL incremental batch-ou-stream sobre Delta. Você declara datasets e expectations; a plataforma infere o DAG, gerencia checkpoints, aplica schema evolution, emite exactly-once em tabelas gerenciadas, grava métricas de qualidade e publica no Unity Catalog, em serverless por padrão, com extras exclusivos de serverless (refresh incremental de MV, stream pipelining, vertical autoscaling). Compre a edição Advanced quando precisar de expectations; embale workloads continuous em um continuous job; trate o setting built-in de continuous como legado para pipelines novos.
• Workflows job: a resposta padrão para orquestração e tudo que não é DataFrame: agendamento (pipeline tasks, notebook tasks, gates run_if), retries, notificações, run-as com service principals, branching, trabalho JAR/Spark-Submit, treino de ML, movimentação de arquivos. Jobs são também onde vivem os gates de qualidade entre pipelines, porque expectations não podem fazer gate dos próprios datasets downstream de um pipeline.
• Veredito em uma frase: pipelines para o plano de dados, jobs para o plano de controle: um pipeline por domínio/SLA delimitado, gated por um pipeline de validação dentro de um multi-task job, rodando como um service principal, triggered por padrão, continuous apenas contra um SLA de latência escrito. Bônus de portabilidade: a metade do pipeline é SDP de padrão aberto; a metade do job é nativa da Databricks.

---

10. As armadilhas: doze confusões que esta lição não vai deixar você manter

1. "O DLT acabou." Meio certo e operacionalmente perigoso: o produto agora é Lakeflow pipelines, mas SKUs DLT_, campos dlt no event log, billing_origin_product='DLT' e import dlt sobrevivem: código novo usa dp, monitoramento ainda grepando dlt.
2. "@dlt.table cobre os dois tipos de dataset." Não na API atual: DF streaming → @dp.table, DF batch → @dp.materialized_view. O desalinhamento quebra o planejamento de flows.
3. "Existe um decorator expect_all_or_quarantine." Não existe. Existem seis decorators; quarentena é o padrão documentado na seção 5.
4. "Expectations em modo fail populam o meu dashboard de qualidade." "Como fail faz a atualização falhar … as métricas não são registradas." Fail = gate, warn/drop = medição.
5. "Expectations fazem gate do pipeline inteiro." expect_or_fail falha apenas o flow ofensor (triggered) ou os dependentes dele (continuous); datasets downstream não esperam o veredito de uma tabela de validação. Gate entre pipelines = pipelines separados + um job.
6. "NOT(rule) divide NULLs corretamente." NULL não é nem verdadeiro nem falso; as duas ramificações podem perder a linha. Torne as regras totais ou ramifique a partir de uma flag explícita.
7. "Continuous é o padrão de produção." É o maior fator de custo no medidor ($2,520 vs$105/mês a 10 DBU/h no E5). Comece em triggered; prefira um continuous job ao setting built-in.
8. "Editar um pipeline continuous vivo é seguro." "Continuous pipelines automatically restart with the updated configuration. This can interrupt an active update"; trocar continuous→triggered cancela o update em execução.
9. "Caminhos s3:// crus funcionam em pipelines UC." O Auto Loader precisa passar por uma external location do UC + storage credential + READ FILES; e a localização do event log também é a schema location, então mover ou apagá-la quebra updates futuros.
10. "Excluir o pipeline apaga os dados." Pipelines UC retêm tabelas por padrão (inativas, ainda consultáveis); cascade=true apaga; UNDROP tem 7 dias.
11. "Expectations funcionam em qualquer edição." Core = ingest, Pro = +CDC, Advanced = +expectations; CDC exige Pro ou superior. Escolha por pipeline, precifique por SKU.
12. "Standard serverless é uma taxa mais barata." Mesmo SKU, menos DBUs e início de 4 to 6 minutos; e o standard mode para pipelines continuous só existe via um continuous job.

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

---

Casos Reais

📋 Caso A: National Australia Bank (NAB) (banking, Cloud: AWS) Desafio. Um data warehouse Teradata de 26 anos com ~1.000 casos de uso, mais ETL escrito à mão em Spark/SQL legado com DML de 5.000 to 8.000 linhas e até 64 union-all por pipeline, mantido de forma inconsistente por 300 to 400 engenheiros. Stack na AWS. Databricks SQL, Auto Loader, Spark Declarative Pipelines on Lakeflow, Unity Catalog (lineage, masking, access control) e asset bundles para CI/CD: tag Cloud: AWS na página da história (https://www.databricks.com/customers/national-australian-bank-nab, página sem data, acesso em 2026-10). 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%"; alguns pipelines passaram de 64 union-all para 3 (mesma URL, sem data, acesso em 2026-10). Página complementar: Teradata de 26 anos descomissionado, 456 casos de uso migrados para o Databricks SQL (https://www.databricks.com/customers/nab/dbsql, sem data, acesso em 2026-10). Como mapeia para esta lição. Seções 2, 7 e 9: 1.800 pipelines declarativos é o que "o DAG é inferido, a plataforma é dona do estado" parece em escala de banco; o número de 80% menos complexidade é o modelo medallion + declarativo substituindo dezenas de milhares de linhas de ETL imperativo. ⏳ Nota temporal: página sem data, acesso em out 2026: trate cada número como o que a NAB relatou, não como garantia da plataforma.

📋 Caso B, Shell (energia, Cloud: AWS, Azure, tag dual-cloud) Desafio. Milhões de tags de séries temporais industriais, infraestrutura legada e crescimento exponencial de dados: ETL em escala IoT com escassez de skills de engenharia de dados. Stack. A plataforma da Shell.ai no Databricks: Delta Live Tables (nome histórico; hoje Lakeflow Declarative Pipelines), Delta Lake, Databricks SQL e o framework de streaming open-source RTDIP. ⚠️ Nota de escopo de nuvem: a página da história está marcada Cloud: AWS, Azure, o padrão (tabelas Delta no S3 + ingestão streaming + pipelines declarativos) é portável entre nuvens; a parte específica da AWS é o substrato: S3, IAM storage credentials, VPC. Resultado relatado. "1,3 trilhão de linhas de dados de sensor processadas com Delta Live Tables · milhões de dólares economizados com operações orientadas a dados · mais de 70 casos de uso de transformação baseados em IA" (PDF de estudo de caso DLT da Shell, agosto de 2021: nome histórico do produto dentro da fonte correta para o período); "O consumo de dados em tempo real aumentou 15 vezes nos últimos 5 anos na Shell" (https://www.databricks.com/blog/developing-time-series-lakehouse-shell, 2023-10-09); 600 membros de times de data science apoiando mais de 100 aplicações de IA (https://www.databricks.com/customers/shell, sem data, acesso em 2026-10). Como mapeia para esta lição. Seções 2 e 6: pipelines declarativos são o que permite a um operador industrial centenário rodar trilhões de linhas de sensor sem um time de ETL de 100 pessoas; o nome DLT no PDF de 2021 é a linha do tempo de renomeação desta lição concretizada. ⏳ Nota temporal: o número de 1,3 trilhões é um relato de 2021; o número de 15× é de 2023: ambos são resultados relatados, não capacidades de plataforma de 2026.

---

---

Perguntas de Prática (Practice Questions)