Arquitetura de Referência do Capstone: Observabilidade, Ativação de ML e o Plano de 90 Dias para Databricks na AWS

Dezesseis lições construíram a máquina. A lição 01 te deu o conceito de lakehouse e a separação plano de controle / plano de compute na AWS; a lição 02, o substrato de VPC, bucket raiz, KMS e PrivateLink; a lição 03, o metastore do Unity Catalog e as external locations; a lição 04, o log de transações do Delta e o liquid clustering; a lição 05, o Auto Loader; a lição 06, DBR, Photon e economia de clusters; a lição 07, os pipelines declarativos do Lakeflow com expectations; a lição 08, os SQL warehouses do Databricks SQL e o Lakeview; a lição 09, os Lakeflow Jobs; a lição 10, os gates de qualidade de dados e a quarentena; a lição 11, grants, views dinâmicas e auditoria; a lição 12, Delta Sharing e Marketplace; a lição 13, Structured Streaming; a lição 14, desempenho; a lição 15, custo em DBU; a lição 16, Declarative Automation Bundles e Terraform. Este capstone faz uma coisa só: monta essas dezesseis camadas em uma única arquitetura de referência, acrescenta as duas camadas que as lições anteriores apenas esboçaram, a pilha de observabilidade e uma fatia de ML governada, e te entrega um plano sequenciado para realmente construir tudo isso.

A camada de observabilidade merece cuidado especial, porque é onde lakehouses de produção falham em silêncio. "As system tables fornecem uma store analítica hospedada pela Databricks com os dados operacionais da sua conta, localizada no catalog system", e "As system tables são gratuitas. Você só é cobrado pelo compute usado para consultá-las" (docs.databricks.com/aws/en/admin/system-tables, rodapé Oct 8, 2026). Gratuito não é o mesmo que automático: a retenção começa a contar a partir da habilitação, o histórico nunca é preenchido retroativamente e os docs são diretos ao dizer que há "No support for real-time monitoring. Data is updated throughout the day." Cada fato desta lição carrega sua fonte Databricks ou AWS e um carimbo de outubro de 2026; tudo o que os documentos não confirmam é deixado de fora ou marcado explicitamente como autoral do curso.

Nesta lição você vai:

• modelar observabilidade como cinco planos distintos, todos sobre o Unity Catalog, mais um sexto plano de consciência de modelos, e aprender exatamente qual latência cada plano carrega;
• inventariar os nomes atuais das system tables (referência de 8 de outubro de 2026), suas retenções gratuitas e suas latências por tabela, e rodar um dashboard de auditoria de seis consultas contra elas;
• usar o monitoramento de qualidade de dados, anomaly detection mais data profiling, a família de produto que absorveu o "Lakehouse Monitoring", com seus indicadores de saúde, incidentes e regras de alerta;
• fechar o ciclo com um runbook de alerta → incidente → replay, ligado por webhooks de jobs, regras de alerta do DQM e SQL Alerts-as-code;
• desenhar o diagrama completo de ponta a ponta do capstone: AWS VPC/S3/KMS, os dois planos do Databricks, Unity Catalog, pipelines do Lakeflow, serving do DBSQL, Delta Sharing e a pilha de observabilidade em uma página só;
• sequenciar um roadmap autoral do curso de 30/60/90 dias contra as 10 fases de planejamento de produção da Databricks, com um placar de marcos que nomeia a system table que prova cada marco;
• posicionar seu time em um modelo de maturidade de quatro estágios (ad hoc → governado → self-service → ML-ready) com critérios de saída;
• ativar uma fatia de ML governada, modelos MLflow no Unity Catalog, signatures, aliases, observabilidade de serving e de inference tables, respeitando a fronteira entre este curso e um curso dedicado de ML;
• estudar Rivian, Block e NAB na AWS, ler a caixa de atualização de outubro de 2026, mapear o curso no blueprint do Data Engineer Associate e responder doze questões no estilo de exame mais quatro verificações interativas.

---

1. Cinco planos de observabilidade, um plano de governança

O erro arquitetural mais comum nesta camada é tratar observabilidade como um produto que você "liga". Não é: são cinco planos com donos diferentes, privilégios diferentes e: criticamente: latências diferentes. Todos os cinco ficam sobre o Unity Catalog, e as próprias system tables são securables governados pela UC: "Users with both the account admin and metastore admin roles have access to system tables by default… USE CATALOG on the system catalog, USE SCHEMA on the system schemas, and SELECT on the system schemas" (referência de system tables, 2026-10-08). Todo o resto precisa desses grants de forma explícita, ou de uma view dinâmica. Observabilidade é algo que se concede: não é algo que já está lá.

Três consequências se seguem, e cada uma já mordiu times de produção:

1. Os planos não se substituem uns aos outros. Expectations e constraints do Delta impedem escritas ruins no momento da escrita (lição 10); anomaly detection detecta desvio em um schema; profiling mede e armazena métricas de desvio; alerts de SQL e de job notificam. Privilégios diferentes também: MANAGE em um schema para habilitar anomaly detection, SELECT nas tabelas de métricas para construir alerts, CAN MONITOR em um warehouse para abrir o query profile de outra pessoa. Misturar tudo em "nós temos DQ" esconde qual camada está faltando.
2. Reação em nível de minutos precisa ser in-band. As system tables são atualizadas "throughout the day": tudo que precisa disparar em minutos é uma policy fail de expectation, um webhook de job, uma regra de alerta do DQM ou um SQL Alert dentro de um job, e não um scan de system.access.audit.
3. Latência é um insumo de projeto, não curiosidade. Os registros de query history ficam "typically available within one hour" (referência de query history, 2026-10-06); o uso faturável, "typically available within 12 hours" para record_type = 'ORIGINAL' (referência de billing, 2026-09-15). Um dashboard de "anomalia de custo por hora" sobre system.billing.usage é um erro de categoria: a tabela não suporta isso.

📚 Você sabia? Os schemas antigos system.operational_data e system.lineage estão "descontinuados e conterão tabelas vazias" (referência de system tables, 2026-10-08). Qualquer runbook, notebook ou dashboard de fornecedor ainda apontando para eles está lendo nada em silêncio. As casas atuais são system.lakeflow.* para timelines de job/pipeline e system.access.table_lineage / system.access.column_lineage para lineage.

---

2. Plano 1: system tables como plano da conta

2.1 O inventário que importa (verificado em 8 de outubro de 2026)

Você não precisa de toda tabela do catalog system no dia um: você precisa destas, com suas retenções, para que seus dashboards e políticas de retenção batam com a realidade:

Fontes: referência de system tables (2026-10-08); referência de audit-logs (2026-07-01); referência de query history (2026-10-06); referência de billing (2026-09-15); referência de lineage (acessada em 2026-10). A retenção configurável existe em Beta, opt-in, padrão de 395 dias, configurável de 30 a 3.650 dias, mas "does not apply to system.data_classification, system.data_quality_monitoring, system.lakebase" (2026-10-08). E observe as ressalvas de streaming se você quiser fazer stream das system tables para suas próprias tabelas Delta: DBR 16.4+ para stream, 17.3+ para CDF, Trigger.AvailableNow em 18.0+, e os próprios schemas system usam "the default 7 days retention for VACUUM".

2.2 Exemplo resolvido E1, o dashboard de auditoria de seis consultas

Este é o centro da lição: um único dashboard Lakeview, seis consultas, todas válidas contra os schemas acima, implantadas como código por meio de um bundle (lição 16). Rode-o semanalmente; publique-o para um grupo platform-ops com USE CATALOG / USE SCHEMA / SELECT concedidos: ou, melhor, uma view dinâmica por grupo (a própria recomendação da página de query history).

Notas de ensino, cada uma extraída de uma armadilha documentada. Q1 é sua consulta de evidência de conformidade: sempre com predicado em event_date, porque a página de audit diz "To improve query performance, filter on event_date rather than event_time". Q3 é a ponte da visão de fleet para a visão de uma consulta só: clique em qualquer statement_id na Query History UI e você cai no query profile daquele statement. Q5 precisa ser pareada com um tile do Cost Explorer da AWS, porque system.billing.usage contém zero de gasto da AWS, nem EC2, nem S3, nem NAT (lição 15). Scans sem filtro de qualquer uma dessas tabelas podem bater no guard documentado: "System Table query returned too much data. Please repeat query with more selective predicates." E a Databricks "highly discourages" exportar system tables para fora da plataforma, o dado "can expose sensitive data and put your deployment at risk".

⚠️ WARNING, observabilidade adicionada por último é observabilidade que começa vazia. A retenção começa a contar a partir da habilitação, e o histórico nunca é preenchido retroativamente: um dashboard construído no dia 200 tem 200 dias de dados; construído no dia 400, ainda tem 200 dias. A própria melhor prática da página de system tables (levada para a Fase 9 do deployment guide, 2026-09-11) é "Enable system tables for all metastores to capture comprehensive usage data" durante a fundação, que é exatamente por que o roadmap de 30/60/90 da seção 8 coloca a habilitação em dias 1 to 30, e não no dia 89.

---

3. Plano 2: monitoramento de qualidade de dados (o produto que comeu o "Lakehouse Monitoring")

3.1 Os nomes, de uma vez por todas

Se um tutorial de 2024, um slide de fornecedor ou até um post do blog da Databricks de setembro de 2026 diz Lakehouse Monitoring, a resposta de outubro de 2026 é: essa capacidade agora é data profiling, uma das duas capacidades sob monitoramento de qualidade de dados no Unity Catalog, sendo a outra o anomaly detection (página de data quality monitoring, 2026-09-11: "Data profiling was formerly known as Lakehouse Monitoring"; página de produto, acessada em 2026-10). Ensine o nome novo, reconheça o antigo e saiba que até material atual da Databricks escorrega, o deployment guide ainda intitula uma seção "Lakehouse Monitoring capabilities" (2026-09-11).

3.2 Anomaly detection: com escopo de schema, aprendido e paciente

O anomaly detection é habilitado em um schema ou catalog: "up to 50 schemas at a time" pela UI do catalog, exigindo MANAGE, e "Databricks creates a background job that monitors tables for freshness and completeness" (página de anomaly detection, 2026-10-09, Public Preview). Freshness: "If a commit is unusually late, the table is marked as stale." Completeness: "Se o número de linhas enviadas nas últimas 24 horas for menor que o limite inferior deste intervalo, a tabela é marcada como incompleta." Os resultados caem em system.data_quality_monitoring.table_results; os indicadores de saúde (Healthy / Unhealthy / Training / Error / Excluded / Not enabled) aparecem nas páginas de tabela e nos nós de lineage; e "Intelligent scanning prioritizes high-impact tables as determined by popularity and downstream usage": apoiando-se no lineage e na certificação da UC, então uma organização que nunca certifica nada tem monitoramento mais fraco. Espere "Smart scanning might delay the population of health indicators for some tables by up to two weeks", incidentes que podem ser atribuídos ("Assign to me" persiste 7 dias) ou dispensados ("Not an issue"), e o gatilho irreversível: "When you disable anomaly detection, the anomaly detection job and all anomaly detection tables and information are deleted. This action cannot be undone."

3.3 Data profiling: duas tabelas de métricas, três tipos de profile

O profiling é por tabela e produz exatamente o que um dashboard de desvio precisa: "Profiling creates two metric tables and a dashboard… The profile metric table contains summary statistics… The drift metrics table contains statistics related to the data's drift over time" (página de data profiling, 2026-09-11). As tabelas de métricas são tabelas Delta em um schema da UC que você escolhe. Três tipos de profile: time series (métricas ao longo de janelas de tempo), inference (logs de requisições de modelo) e snapshot ("A tabela completa é processada a cada refresh. O tamanho máximo da tabela para um profile snapshot é 4 TB"). Profiles de time series e de inference "calculam apenas métricas dos últimos 30 dias". O profiling roda em compute serverless "mas não exige que sua conta esteja habilitada para compute serverless", é cobrado como DBUs serverless sob billing_origin_product = 'DATA_QUALITY_MONITORING' (resultados a partir de fevereiro de 2026) e, um alívio para estates regulados, "Data quality monitoring does not modify any tables it monitors, nor does it add overhead to any jobs that populate these tables."

3.4 Exemplo resolvido E2: ligando a camada de alerting de ponta a ponta

Três planos de entrada, um único vocabulário de destinos. (i) Webhook de job: um admin configura um sistema de destino uma vez (email, Slack, Microsoft Teams, PagerDuty ou qualquer webhook); cada job então define notifications.on_failure, limitado a "a maximum of three system destinations for each notification event type" por job ou task (página de notifications de jobs, 2026-10-09). O payload é JSON estável:

(ii) Regra de alerta do DQM (Beta), com escopo em catalog.acme ou catalog.acme.sales, exigindo MANAGE, entregando no mesmo vocabulário de destinos quando uma tabela fica Unhealthy. (iii) SQL Alert como código, "Databricks SQL Alerts is Generally Available (GA), with more than 4,000 customers already using Alerts in production" (blog da Databricks, 2026-05-19); um alert agrupa "a SQL query, an evaluation condition, a schedule, and a set of notification destinations", é versionável em Git e implantável por bundles/Terraform, e pode rodar como uma task SQL Alert de Lakeflow Job (Public Preview) cuja saída OK / TRIGGERED / ERROR decide a próxima task via run_if. Uma verificação de custo de monitoramento que você vai realmente rodar:

• 📚 Você sabia? A própria pilha interna de confiabilidade da Databricks, RADAR, são os quatro planos desta lição rodando em produção: métricas de confiabilidade → anomaly detection SPOT (um modelo não supervisionado de streaming que aprende o "normal" do passado 14 dias) → alerting → dashboards de causa raiz. Resultado publicado: "95% reduction in incident-discovery time, at over 90% precision" (blog da Databricks, 2026-09-19). O mapa de construção naquele post, métricas em Delta, um detector treinado no MLflow servido em um endpoint do Model Serving, recorrência do Workflows, SQL Alerts, Genie para causa raiz, tudo implantado como um único DAB, é este capstone, por dentro.

---

4. Planos 3 to 5: pipelines, workloads e desempenho de consulta

4.1 O event log do pipeline, e a exclusão que quebra o Auto Loader

Os pipelines do Lakeflow expõem três superfícies de observabilidade aninhadas: a UI (página de monitoring, grafo, métricas de dataset, aba Data quality); o event log por pipeline, uma tabela Delta oculta legível via SELECT * FROM event_log(<pipelineId>) e publicável em uma tabela UC nomeada; e a system.lakeflow_pipeline_events_preview.pipeline_events em escopo regional (Beta), que os docs agora chamam de "the recommended way to query events", com um JSON de dashboard Lakeview pronto para importar na página de monitoring (datada de 2026-10-09). Os resultados das expectations viajam nos eventos flow_progress: details:flow_progress.data_quality.expectations é um array<struct<name: string, dataset: string, passed_records: int, failed_records: int>>. Atribuição de custo de um pipeline: SELECT sku_name, sum(usage_quantity) FROM system.billing.usage WHERE usage_metadata.dlt_pipeline_id = :pipeline_id GROUP BY 1.

⚠️ IMPORTANT, nunca apague o event log de um pipeline. "O local do event log também serve como o local do schema para quaisquer queries de Auto Loader no pipeline… Não apague o event log nem o catálogo ou schema pai" (página de pipeline event log, 2026-10-09). Apagá-lo não custa só o histórico, ele quebra updates futuros, porque o estado exactly-once do Auto Loader vive lá (lição 05).

Um detalhe operacional que vale levar para os seus runbooks: updates acionados pela UI/API usam "fast-start, debugging-focused behavior", enquanto "Updates iniciados pelo Jobs ou pela Pipelines API, e todos os updates de pipelines contínuos, usam retry e reinício automáticos": que é exatamente por que pipelines de produção precisam ser disparados a partir de um job (lição 09), e não da UI.

4.2 Notifications de job: a camada de paging, com duas armadilhas documentadas

As notifications de job cobrem eventos de início, conclusão bem-sucedida, falha, limiar de duração, limiar de backlog de streaming e manutenção contínua, entregues por email ou pelos sistemas de destino configurados pelo admin (Slack, Teams, PagerDuty, webhook), no máximo três destinos por tipo de evento por job ou task. 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. Alerts de backlog de streaming avaliam "average backlog over a 10-minute period" e notificam de novo após 30 minutos. As armadilhas: "Job-level notifications aren't sent when failed tasks are retried" (silencie até a última retentativa, ou use notifications por task), e "Succeeded with failures" conta como sucesso. Para contexto de escala: um workspace é limitado a 2.000 execuções de task simultâneas, pode guardar até 12.000 jobs salvos, criar 10.000 jobs por hora e um único job pode conter até 1.000 tasks (visão geral do Lakeflow Jobs, 2026-10-09).

4.3 Query profiles: o plano por statement

Para SQL warehouses e compute serverless, o query profile é o diagnóstico por statement: DAG de operadores com Time spent / Memory peak / Rows, um painel de Top operators, Performance insights ranqueados "by their projected effect on total task duration" e reescritas assistidas por código do Genie apresentadas para sua aprovação (página de query profile, 2026-09-11). O acesso é um fato de permissão com consequências reais de organização: "você precisa ser o owner da query ou ter pelo menos a permissão CAN MONITOR no SQL warehouse que executou a query". Não existem profiles para queries com cache hit, e a exportação/importação de JSON de profile não é persistida. Cargas de trabalho em clusters classic usam a Spark UI em vez disso: a Fase 9 do deployment guide diz a divisão sem rodeios: "Para compute serverless e SQL warehouses, use o query profile… Para clusters classic, use a Spark UI". A Q3 do E1 é a visão de fleet em system.query.history; o profile é a visão de uma consulta só; statement_id as une.

O corpo do runbook, cada passo nomeando sua ferramenta: 1. Detectar por qualquer um dos três planos. 2. Classificar: freshness (stale) vs completeness vs pico de failed_records em expectation vs falha de compute. 3. Delimitar com system.access.table_lineage / column_lineage. 4. Causa raiz em pipeline_events (error.exceptions[0].error_class) e no array de expectations. 5. Reparar em dev via um PR de DAB (lição 16). 6. Reexecutar de forma idempotente, o repair do job reroda apenas os subconjuntos falhados/pulados; o Auto Loader faz replay do prefixo de chegada exatamente uma vez. 7. Validar e fechar, considerando até duas semanas de atraso do scan de indicadores de saúde, e escrever o novo limiar de volta no runbook (Fase 9: "Document runbooks for common operational scenarios", 2026-09-11).

---

5. Plano 6: a fatia de ML: governança primeiro, algoritmos em outro lugar

5.1 A linha de fronteira, dita uma vez

Este curso é dono do substrato de lakehouse onde o ML roda: UC como plano de governança para modelos e features (nomes de três níveis, grants, aliases, lineage), observabilidade de inference tables e de endpoints de serving como o mesmo padrão de observabilidade aplicado a modelos, e onde os artefatos de ML ficam na arquitetura de referência. Um curso dedicado de ML é dono de algoritmos, metodologia de treino e de hiperparâmetros, AutoML, disciplina de experiment tracking, design de feature engineering, desenvolvimento de LLM/agente, autoria de política de AI Gateway e ajuste de desempenho de deploy. O corte limpo: nós ensinamos governança e observabilidade de modelos, não como construí-los.

5.2 Models in Unity Catalog: a mecânica verificada

"Models in Unity Catalog, which Databricks recommends" (página de ciclo de vida do modelo, 2026-10-09) é "a hosted version of MLflow Model Registry in Unity Catalog… including centralized access control, auditing, lineage, and model discovery across workspaces". Mecânica para saber de cor:

• o URI de registro padrão no MLflow 3 é databricks-uc; modelos ganham nomes de três níveis <catalog>.<schema>.<model>;
• modelos são um subtipo do securable FUNCTION: conceda com GRANT ON FUNCTION, crie com GRANT CREATE MODEL ON SCHEMA, use com EXECUTE;
• "Novas versões de modelo em UC precisam ter uma signature de modelo": sem ela você perde imposição de entrada, uso de funções de IA e exemplos de entrada de serving gerados automaticamente;
• aliases substituem stages: "Stages não são suportados para modelos no Unity Catalog": uma referência nomeada mutável como Champion é o mecanismo de promoção;
• a promoção entre ambientes é feita "by deploying ML pipelines as code" (preferido) ou copy_model_version() (MLflow 2.8.0+);
• lineage tabela→modelo via mlflow.log_input (MLflow 2.11.0+) aparece na aba Lineage da versão do modelo no Catalog Explorer;
• não suportado em modelos da UC: webhooks, notifications por email, threads de comentário, activity log: use audit logs e gates de CI em vez disso.

Pareamento de versão do MLflow por runtime (release notes, 2026-09-11): DBR 19 → MLflow 3.12.0; 18 LTS → 3.8.1; 17.3 LTS → 3.0.1; 16.4 LTS → 2.21.3.

5.3 Exemplo resolvido E3: a fatia de ativação de ML com governança primeiro

Vinte linhas que satisfazem todas as regras de UC acima, e então observe o modelo como observe dados:

Grants: GRANT CREATE MODEL ON SCHEMA acme.ml TO o principal de treino; GRANT EXECUTE ON FUNCTION acme.ml.churn_model TO os consumidores. Observabilidade: uma inference table registra predições para análise de desvio; system.serving.endpoint_usage (retenção de 90 dias, o rastreamento de uso precisa estar habilitado) e system.serving.served_entities dão a visão de frota; system.mlflow.runs_latest / run_metrics_history (180 dias) carregam a telemetria de treino. O próprio Model Serving é uma superfície REST serverless que "suporta mais de 25K queries por segundo com latência de overhead de menos de 50 ms" (página de model serving, 2026-10-06): com duas ressalvas em torno das quais você precisa projetar: os dados de métricas ficam retidos por apenas 14 dias (logs de build de container, 30 dias), e "Model Serving does not provide security patches to existing model images because of the risk of destabilization to production deployments". Feature Store está atual e é UC-first: Feature Views (declarativo, Public Preview, recomendado) e feature tables publicam ambos no Online Feature Store com joins point-in-time que eliminam o skew entre treino e serving; o Workspace Feature Store está obsoleto.

📚 Você sabia? A Databricks anunciou o Genie ZeroOps em 2026-06-16: "an autonomous background agent that monitors your data and AI assets… and takes action before or when things go wrong", com validação de correções propostas por shallow clone contra dados reais sem tocar em produção. Sua disponibilidade declarada no anúncio era "entering private preview in the coming weeks"; esta lição o cita apenas como uma direção anunciada para a camada de runbook, nunca como uma capacidade da qual você possa depender hoje.

---

6. O capstone completo: AWS + Databricks de ponta a ponta

Aqui está o curso inteiro em uma página. Leia de cima para baixo: fontes à esquerda da sua mente, armazenamento na conta AWS do cliente, governança no Unity Catalog, pipelines medallion no meio, serving e sharing à direita, observabilidade envolvendo tudo, e os dois medidores de cobrança (fatura da AWS vs DBU) que a lição 15 te ensinou a nunca confundir.

6.1 Exemplo resolvido E4, o checklist de 17 componentes

Cada componente abaixo foi construído em uma lição anterior; a coluna "prova" nomeia a system table ou o artefato que demonstra que ele existe. Esta é a tabela que você revisa no dia 90.

---

7. 30/60/90 dias: um roadmap autoral do curso sobre as 10 fases da Databricks

📌 Nota de procedência. Não existe nenhum cronograma de adoção "30/60/90-day" publicado pela Databricks; o cronograma abaixo é uma síntese do curso ancorada na sequência oficial de 10 fases de planejamento de produção (página do deployment guide, 2026-09-11: cuja própria página de introdução em outro lugar diz 9 fases; nós ensinamos a tabela de 10 fases, a página que de fato lista as fases). Os nomes das fases são da Databricks; os dias são nossos.

Dias 1 to 30: Fundação (fases 1 to 5: conta, estratégia de workspace, Unity Catalog, rede, storage). Conta + metastore no ar; SSO/SCIM; um metastore por região; buckets S3 raiz + externos com KMS; storage credential + external location para o prefixo de chegada; workspaces dev/prod; um módulo Terraform para recursos de nível de conta; system tables habilitadas; USE CATALOG / USE SCHEMA / SELECT concedidos a um grupo platform-ops. Marco: uma primeira tabela bronze do Auto Loader aterrissa no S3 por uma external location, fica consultável na UC e system.access.audit retorna linhas dela.

Dias 31 to 60: Pipeline + qualidade (fases 6 to 8: Delta Lake, IaC, compute). Pipeline do Lakeflow bronze→silver→gold com expectations e uma tabela de quarentena; constraints do Delta no silver; job multi-task com gates run_if, retries, run_as de service principal; DABs implantando targets dev/prod; cluster policies + instance pools + auto-stop; um warehouse DBSQL serverless com auto-stop; anomaly detection habilitado no schema silver e um profile de time series na tabela gold de KPI; um webhook jobs.on_failure para o canal do time. Marco: um arquivo corrompido de propósito dispara métricas de expectation → quarentena → saúde do DQM vira Unhealthy → webhook dispara, de ponta a ponta, em um drill de game day.

Dias 61 to 90: Operar + estender (fases 9 to 10: observabilidade, HA/DR). Um dashboard "Ops" no Lakeview sobre system.lakeflow.job_run_timeline, system.query.history, system.billing.usage e pipeline_events; SQL Alerts para KPIs de frescor/contagem de linhas com versionamento em Git/DAB; o dashboard de auditoria do E1 revisado semanalmente; runbooks publicados (seção 4.3); política de retenção de backup/time travel + VACUUM documentada; atribuição de custo por tag com <5% de gasto sem tag. Marco: o plantão resolve uma página usando apenas o dashboard de ops e um runbook.

7.1 Exemplo resolvido E5, o placar de marcos

7.2 Exemplo resolvido E6: um rascunho mensal de custo de observabilidade

As system tables são gratuitas; as consultas e os dashboards não. Considere um warehouse de ops (serverless, $0.70/DBU na lista, página de preços de SQL acessada em 2026-10) rodando o dashboard do E1 mais triagem ad hoc 2 horas/dia × 20 dias/mês a ~4 DBU/hora: 160 DBU × $0.70 = $112/mês do lado Databricks, além de zero de armazenamento para as próprias tabelas. Some um profile snapshot em uma tabela gold de 500 GB (sob o teto de 4 TB) e anomaly detection em dois schemas, ambos cobrados como DBUs serverless sob billing_origin_product = 'DATA_QUALITY_MONITORING'; a taxa não é publicada, então meça quantidades em system.billing.usage e precifique contra o seu contrato corporativo em vez de assumir a taxa de lista. Do lado da AWS, não acrescente nada além do armazenamento em S3 já contado na lição 15 ($0.023/GB-mês) e do tráfego de NAT da sua VPC. A lição de projeto: o plano de observabilidade é uma margem de arredondamento ao lado do plano de pipeline, desde que o auto-stop esteja ligado e o warehouse do dashboard não fique nos padrões de 45 minutos sem ninguém olhando.

---

8. O modelo de maturidade: ad hoc → governado → self-service → ML-ready

📌 Nota de procedência. Não existe nenhuma página oficial de "maturity model" da Databricks; os quatro estágios são um construto do curso mapeado sobre funcionalidades verificadas, com as recomendações da Fase 9 e o post de data products de setembro de 2026 como a linguagem oficial de suporte mais próxima.

Cada critério de saída é observável em uma system table ou em um objeto da UC, que é o ponto. O estágio 2→3 é bloqueado pelo design de organização (propriedade de catalog, MANAGE delegado, contratos de dados), não por funcionalidades faltando; times que instalam o DQM sem donos ganham alerts que ninguém responde, o que é pior do que não ter alerts. O estágio 3→4 exige lineage que atravessa tabela → feature → modelo, o que só existe se o treino usou mlflow.log_input e as features estão registradas na UC. O post de data products da Databricks de 2026-09-03 prescreve "data contracts upfront that include quality metrics, schema definitions, usage policies and security parameters" mais uma fase de "Operate and Govern", o vocabulário do estágio 3, nas palavras da própria Databricks.

---

9. Síntese do curso: lições 01 to 16 mapeadas no blueprint do Data Engineer Associate

O último ato acadêmico do capstone é conectar este curso à credencial para a qual ele mais diretamente te prepara. O guia de exame vigente da Databricks Certified Data Engineer Associate está datado de 4 de maio de 2026: 45 questões objetivas pontuadas, 90 minutos, $200, validade de 2 anos, com o blueprint de sete domínios abaixo (página de certificação e PDF do exam guide, acessados em 2026-10-12). Note o rebranding que o guia de 2026 absorveu: o texto de público antigo "Databricks Workflows" agora é "Lakeflow Jobs".

9.1 Exemplo resolvido E7: mapeamento curso → domínio DEA

Onde o curso para e o Data Engineer Professional (59 itens, 120 min, os mesmos $200, dez domínios) começa: o domínio mais pesado do DEP, "Developing Code for Data Processing" com 22%, mais triagem sistemática de falhas e teoria de modelagem, ficam em nível de consciência aqui, este curso demonstra padrões de produção; o DEP assume propriedade de produção (plantão, backfills, incidentes de quebra de schema, estouros de custo). A certificação gratuita AWS Platform Architect (20 questões, tempo ilimitado, aprovação com 80%, validade de 1 ano) é a contraparte do lado do substrato e cobre exatamente o território da lição 02: "Customer-managed VPCs · Customer-managed keys · Cloud service integrations". Linha de orçamento em outubro de 2026: uma tentativa de certificação = $200, sem retakes gratuitos, espera de 14 dias entre tentativas; badges (Fundamentals, accreditations) são gratuitas, 10 to 25 questões, aprovação com 80%, via Accredible, não Credly.

---

Veredito Comparativo: Databricks-on-AWS vs AWS nativo vs Snowflake (final, em outubro de 2026)

• Databricks na AWS, convergência. Uma camada de armazenamento (S3 + Delta, lição 04), uma camada de governança (UC, lições 03/11), uma camada de observabilidade (system tables + DQM + event logs, esta lição), uma camada de orquestração (Lakeflow Jobs, lição 09), um mecanismo de entrega (DABs/Terraform, lição 16), um registro de modelos (models na UC). O inventário de painel único mais largo desta comparação, e as tabelas são gratuitas, você paga só o compute das consultas. O custo honesto: um segundo fornecedor, medição de DBU por cima da sua fatura da AWS, e um inventário de observabilidade que vale exatamente o tanto quanto valem os seus grants, as suas tags e a sua disposição de rodar o dashboard toda semana.
• AWS nativo (S3 + Glue + Athena + Lake Formation + QuickSight + CloudWatch/CloudTrail), montagem. Cada capacidade acima é um serviço separado que você costura junto: Glue Catalog e crawlers ($0.44/DPU-hora), Athena SQL serverless ($5.00/TB escaneado, mínimo de 10 MB por consulta), Lake Formation para grants, CloudTrail como plano de auditoria. Serve a times só de SQL, majoritariamente em lote, que não querem um fornecedor de plataforma e querem controle de cobrança por serviço. Fraquezas que este curso encontrou repetidamente: sem uma história de MERGE/CDF ACID tão rica quanto a do Delta, lote e streaming são toolchains diferentes, ML vive em outro produto (SageMaker), e o plano de auditoria é o CloudTrail, não tabelas de governança consultáveis em SQL dentro do mesmo catalog dos seus dados. A própria AWS documenta a interoperabilidade com o Delta (o Athena lê Delta registrado no Glue, somente leitura, engine v3, sem time travel), então a porta de saída é real.
• Snowflake, a abstração de warehouse. Formato de armazenamento proprietário, boa concorrência SQL/BI, operação mínima, observabilidade em grande medida por ACCOUNT_USAGE mais suíte nativa de qualidade de dados dentro de uma única abstração de warehouse. Escolha quando a carga de trabalho é pura SQL/BI com concorrência previsível e você quer a simplicidade do warehouse. É mais fraco quando ML/AI, Python/Spark, ingestão de streaming e portabilidade em formato aberto são requisitos de primeira classe, e ambos os fornecedores publicam números de páginas de comparação mutuamente contraditórios (trate todos como alegações de marketing carimbadas em data, nunca como fatos).
• Veredito em uma frase: Databricks-on-AWS é a escolha certa quando uma cópia governada dos dados precisa servir BI, streaming e ML com observabilidade consultável em SQL; AWS nativo é a escolha certa quando você quer cobrança por serviço e vai aceitar montar os planos você mesmo; Snowflake é a escolha certa quando a carga é só SQL e você quer a superfície operacional mais simples possível, e os estudos de caso abaixo mostram clientes reais da AWS chegando na primeira opção exatamente pelo motivo da convergência.

---

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

---

Casos Reais

📋 Caso A: Rivian (veículos elétricos, manufatura, nuvem: AWS) Desafio. Terabytes de dados de veículos e de campo por dia em mais de 70.000 veículos; tooling de nuvem legado que "struggled to scale pipelines cost-effectively and spent significant resources on maintenance"; times em silos bloqueando ML de manutenção preditiva e de eficiência de bateria. Stack na AWS. Databricks SQL, Delta Lake, Unity Catalog, Agent Bricks / Mosaic AI, Liquid Clustering: Cloud: AWS na página de customer story. Resultado relatado. "Mais de 1.000 usuários da plataforma, um aumento de 75% em relação a um ano atrás" e "o Unity Catalog nos dá um catálogo de dados verdadeiramente centralizado em todos os nossos times" (https://www.databricks.com/customers/rivian, não datada, acessada em 2026-10); "50% melhor desempenho de runtime"; "Mais de 70.000 Rivians nas ruas, gerando terabytes de dados todos os dias" (https://www.databricks.com/your-ai/customers/rivian, 2024-05-30); "Unity Catalog para governança de dados, tabelas Delta para armazenamento e Liquid Clustering para layout de dados" para ML de predição de carga em tempo real (https://www.databricks.com/blog/data-intelligence-action-100-data-and-ai-use-cases-databricks-customers, 2025-07-09). Mapeia para esta lição. Seções 5 to 6: Rivian é o exemplo nomeado de AWS do capstone: um lakehouse governado alimentando dashboards e ML de produção, com liquid clustering (lições 04/14) sob as feature tables e UC (lição 11) como catalog único entre times. ⏳ Nota temporal: números da página de story acessados em out. 2026; as métricas dos blogs de 2024 e 2025 são resultados relatados à época, não garantias de 2026.

📋 Caso B, Block (Square, Cash App, TIDAL, serviços financeiros, nuvem: AWS) Desafio. 12PB de dados de grafo + análise fragmentados entre unidades de negócio; fluxo de IAM doloroso em dois passos (policies para roles, depois para buckets S3); governança de PII sob GDPR/CCPA. Stack na AWS. Databricks, Delta Lake, Unity Catalog, Spark Declarative Pipelines, Delta Sharing (clean rooms planejadas); S3 como armazenamento co-localizado: Cloud: AWS. Resultado relatado. "Redução de 12x no custo de compute · Redução de 20% no custo de egress de dados · 12PB de dados gerenciados e governados"; tempo de permissão de compartilhamento de dados cortado "de dias para segundos"; "a adoção do Unity Catalog promoveu a coleta de dados em buckets S3, resultando em latência melhorada e na co-localização de compute e armazenamento" (https://www.databricks.com/customers/block/unity-catalog, não datada, acessada em 2026-10). Mapeia para esta lição. Seções 2 e 6: Block é a prova de governança-e-custo: a UC substituiu uma ferramenta de governança e um pedaço da canalização de IAM/S3, e o dashboard de auditoria E1 é a superfície operacional que mantém um estate de 12PB cobrável por respostas. ⏳ Nota temporal: página não datada, acessada em out. 2026: resultados relatados por clientes, não benchmarks de plataforma.

📋 Caso C: National Australia Bank (bancário, nuvem: AWS) Desafio. Um warehouse Teradata de 26 anos com ~1.000 casos de uso e 140 suítes de relatórios; ETL escrito à mão com até 64 union-all por pipeline em uma equipe de 300 to 400 engenheiros. Stack na AWS. Databricks SQL, Auto Loader, Spark Declarative Pipelines no Lakeflow, Unity Catalog (lineage, masking, controle de acesso), asset bundles para CI/CD: Cloud: AWS. Resultado relatado. "Warehouse Teradata de 26 anos descontinuado · 456 casos de uso migrados para o Databricks SQL · mais de 1.200 usuários habilitados" (https://www.databricks.com/customers/nab/dbsql, não datada, acessada em 2026-10); "1.800 Spark Declarative Pipelines rodando no Databricks Lakeflow · 99,6% de taxa de sucesso de jobs · 80% menos complexidade de transformação", latência "abaixo de 15 minutos", qualidade de dados "+38%" (https://www.databricks.com/customers/national-australian-bank-nab, não datada, acessada em 2026-10). Mapeia para esta lição. Seções 6 to 7: uma taxa de sucesso de jobs de 99,6% em 1.800 pipelines é como a camada de workload (lição 09) mais o runbook de alerta→replay (seção 4.3) se parecem em escala de banco nacional; é o marco do dia 90 deste roadmap, alcançado por um time real. ⏳ Nota temporal: páginas de customer story não datadas, acessadas em out. 2026: resultados relatados à época do story.

---

---

Perguntas de Prática (Practice Questions)

Leia as barras como uma alocação de estudo, não como trivia: Transformation (22%) mais Ingestion (21%) mais Lakeflow Jobs (16%) são 59% do exame, as lições 04, 05, 07, 09, 13 e 14 são seu caminho majoritário, enquanto Governance (15%) é onde a profundidade específica de AWS deste curso (storage credentials vs instance profiles, KMS, PrivateLink, tabelas de audit da UC) te diferencia de um candidato genérico de Spark.