Arquitetura Lakehouse no Databricks: Planos, Pilares e o Substrato AWS

Todas as outras lições deste curso assumem três coisas que você ainda não provou para si mesmo: que lakehouse é uma categoria arquitetural real e não uma palavra de marketing, que o software Databricks roda em duas contas da AWS ao mesmo tempo e que o dinheiro chega em duas faturas separadas. Erre qualquer uma das três e você vai desenhar um workspace cujo data lake fica no bucket errado, cujo modelo de ameaça aponta para a conta errada e cujo modelo de custo subconta cerca de metade.

Esta lição prova as três com fontes primárias. Cada fato arquitetural abaixo vem de páginas de docs.databricks.com com datas entre 2026-07-28 e 2026-09-25, dos blogs próprios de deployment da Databricks na AWS (2022-09-30, 2023-01-27) e das páginas de preços da AWS acessadas em outubro de 2026. Todo preço é preço de tabela em USD, carimbado com a data em que foi lido, porque as taxas de DBU e as taxas da AWS mudam.

Nesta lição você vai:

• definir o lakehouse em contraste com o data lake e o data warehouse, usando as três propriedades que a Databricks publicou em 2020 e o padrão medalhão (bronze → silver → gold);
• separar os dois pilares, Delta Lake para confiabilidade e formato, Unity Catalog para governança, e mapear cada um ao objeto da AWS que ele toca (seu bucket S3, sua IAM role);
• desenhar a divisão plano de controle / plano de compute, incluindo secure cluster connectivity, a IAM role entre contas e a regra de região do plano serverless;
• descobrir onde os dados realmente ficam, e por que o bucket de armazenamento do workspace definitivamente não é o seu data lake;
• montar o mapa de workloads (ingest → curate → serve → ML) e combinar cada workload ao compute que o executa;
• ler a tabela de preços de DBU em out 2026 e calcular à mão seis exemplos resolvidos com números reais;
• comparar a plataforma com a stack nativa da AWS, Snowflake e Hadoop on-prem sem repetir marketing de fornecedor como fato;
• estudar três estudos de caso nomeados da AWS, ler a caixa de atualizações de 2026 e responder doze questões no estilo de exame.

---

1. O que é um lakehouse: uma arquitetura, três propriedades

A definição atual da Databricks (databricks.com/blog/what-is-data-lakehouse-article, 2026-06-23) é a que vale decorar:

"Um lakehouse de dados é uma nova arquitetura aberta de gerenciamento de dados que combina a flexibilidade, a eficiência de custo e a escala dos data lakes com o gerenciamento de dados e as transações ACID dos data warehouses, permitindo business intelligence (BI) e machine learning (ML) em todos os dados."

O post canônico de 2020 que batizou o padrão lista exatamente três propriedades definidoras (databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html, 2020-01-30):

1. Suporte a transações: transações ACID em armazenamento de objetos, de modo que escritores concorrentes e jobs com falha não corrompem uma tabela.
2. Aplicação de schema e governança: a camada de armazenamento rejeita dados que violam o schema declarado em vez de aceitá-los silenciosamente.
3. Abertura: os formatos de armazenamento são "abertos e padronizados, como Parquet", de modo que motores diferentes daquele que escreveu os dados possam lê-los.

Leia essas três propriedades em contraste com as duas arquiteturas entre as quais o lakehouse se situa:

A frase "permitir BI e ML em todos os dados" é todo o caso de negócio: os warehouses forçam uma escolha entre SQL governado e ML utilizável, os lakes forçam uma escolha entre armazenamento barato e dados confiáveis. O lakehouse remove as duas escolhas ao colocar gerenciamento de tabelas de nível warehouse diretamente sobre o armazenamento de lake.

1.1 O padrão medalhão

A Databricks documenta o layout lógico padrão como a arquitetura medalhão, "um padrão de design de dados usado para organizar logicamente dados em um lakehouse ... (das tabelas das camadas Bronze ⇒ Silver ⇒ Gold)" (databricks.com/blog/what-is-medallion-architecture, 2022-03-09):

• Bronze: cru, apenas append, tudo que chegou, com os metadados de origem intactos.
• Silver: limpo, sem duplicatas, conformado, uma linha por entidade do mundo real.
• Gold: agregações de nível de negócio e tabelas largas prontas para BI, dashboards e feature stores.

As camadas são logicamente. Fisicamente são tabelas Delta comuns em buckets S3 comuns, separadas por nomes de catalog ou schema: é por isso que a lição 03 (Unity Catalog) e a lição 04 (transações Delta) partem desse diagrama.

• 📚 Você sabia? "Lakehouse" é uma arquitetura, não um produto da Databricks. O próprio post de nomenclatura da Databricks em 2020 admite: "Outros serviços gerenciados como BigQuery e Redshift Spectrum têm algumas das funcionalidades de lakehouse listadas acima" (2020-01-30). Snowflake, Amazon Redshift, Microsoft Fabric e outros agora também reivindicam funcionalidades de lakehouse. O discriminador neste curso nunca é a palavra: é a combinação de um formato de tabela aberto no seu armazenamento com uma camada de governança que atravessa todos os motores.

---

2. Os dois pilares: Delta Lake e Unity Catalog

Tudo o que a Databricks vende na AWS se apoia em dois projetos open source. O enquadramento próprio da Databricks em 2024 os pareia explicitamente: "Confiabilidade dos dados ... a Databricks fornece Delta Lake" e "Governança facilitada ... com a ajuda do Unity Catalog" (databricks.com/blog/lakehouse-common-language-across-enterprise, 2024-06-21).

2.1 Pilar um, Delta Lake: a camada de confiabilidade e formato

Delta Lake é a camada de armazenamento open source que adiciona transações ACID, aplicação de schema, time travel e gerenciamento escalável de metadados ao armazenamento de objetos, e é o formato de tabela padrão no Databricks: "a fundação do lakehouse" (databricks.com/blog/what-is-data-lakehouse, 2020-02-11). Fisicamente é simples: um log de transações write-ahead armazenado ao lado dos arquivos Parquet no seu bucket S3 (databricks.com/blog/2020/09/10/diving-deep-into-the-inner-workings-of-the-lakehouse-and-delta-lake.html, página atualizada em 2024-06-20).

O que isso te compra, tudo coberto na lição 04: commits serializáveis, upserts com MERGE, change data feed, time travel por versão ou timestamp, check constraints e evolução de schema sob regras explícitas.

2.2 Pilar dois, Unity Catalog: a camada de governança

O Unity Catalog modela "Todo ativo que você governa ... como um objeto securable", cobrindo "tabelas, views, volumes, funções, modelos e serviços", todos seguindo "um namespace de três níveis (catalog.schema.object)" (docs.databricks.com/aws/en/data-governance/unity-catalog, acesso em 2026-10). Três fatos moldam todo projeto de AWS que você for construir:

• O metastore é o securable de nível superior e é escopado a uma região de nuvem: "O metastore é o objeto securable de nível superior ... Um metastore contém todos os objetos securable registrados no Unity Catalog em uma única região de nuvem" (docs .../unity-catalog/securable-objects).
• Você precisa de "um metastore para cada região em que sua organização opera", e "os usuários precisam estar em um workspace anexado a um metastore em sua região" (docs .../unity-catalog/create-metastore).
• Grants viajam entre workspaces: "um privilégio concedido em um workspace é eficaz em todos os outros workspaces que compartilham esse metastore" (mesma fonte).
• Na AWS, uma storage credential é uma IAM role: essa é a costura onde a governança encontra a sua conta de nuvem (docs.../securable-objects).

Tabelas e volumes são gerenciadas (o Unity Catalog é dono tanto da governança quanto do ciclo de vida dos arquivos) ou externas (o Unity Catalog governa; você é dono dos arquivos) (docs .../unity-catalog).

2.3 Por que a combinação importa na AWS

Delta responde "posso confiar nesses bytes?" sem tirá-los do S3. O Unity Catalog responde "quem pode ler quais bytes?" com um único modelo de grants que sobrevive a mudanças de workspace, escopo de região e múltiplas contas da AWS. Nenhum substitui o outro: uma tabela perfeitamente ACID sem grants é um vazamento sem governança, e um catalog perfeitamente governado sobre arquivos descuidados é uma auditoria esperando para falhar.

---

3. Anatomia do workspace: o plano de controle e o plano de compute

"A Databricks opera a partir de um plano de controle e de um plano de compute" (docs.databricks.com/aws/en/getting-started/high-level-architecture, página atualizada pela última vez em 2026-09-11). Esta é a frase mais testável da lição 01, e a mais frequentemente deturpada por engenheiros que só leram os blogs de engenharia mais antigos da Databricks.

3.1 Os três planos

• Plano de controle (conta da Databricks). "O plano de controle inclui os serviços de backend que a Databricks gerencia na sua conta Databricks. O plano de controle fica na conta da Databricks, não na sua conta de nuvem" (mesma página, 2026-09-11). Ele guarda a web UI, comandos e metadados de notebook, cluster manager, orquestração de jobs e metadados do Unity Catalog: criptografados em repouso (databricks.com/blog/best-practices-and-guidance-cloud-engineers-deploy-databricks-aws-part-1, 2022-09-30).
• Plano de compute clássico (a sua conta). Clusters e SQL warehouses pro/clássico rodam como instâncias EC2 "dentro da rede virtual de cada workspace, na conta de AWS do cliente", o que dá ao plano "isolamento natural porque roda na própria conta AWS de cada cliente" (docs .../high-level-architecture, 2026-09-11).
• Plano de compute serverless (conta da Databricks). "A Databricks cria um plano de compute serverless na mesma região AWS do plano de compute clássico do seu workspace" e o isola "dentro de um limite de rede do workspace" (mesma página). Mesma região do seu plano clássico: não uma região arbitrária da Databricks.

Materiais mais antigos, incluindo os próprios blogs de deployment de 2022 to 2023 da Databricks, dizem plano de dados onde a documentação de hoje diz plano de compute. Mesmo conceito, vocabulário atual. Se um tutorial diz "plano de dados", ele quer dizer o plano de compute clássico/serverless descrito aqui.

3.2 Secure cluster connectivity: sem portas abertas, sem IPs públicos

"Todos os workspaces novos são criados com secure cluster connectivity por padrão. Secure cluster connectivity significa que as VPCs do cliente não têm portas abertas e que os recursos do plano de compute clássico não têm endereços IP públicos" (docs.databricks.com/aws/en/security/network/classic, atualizado em 2026-09-25). Os clusters alcançam o plano de controle por um túnel seguro sobre a porta HTTPS 443 até um relay SCC, e o tráfego é sempre iniciado do plano de compute para fora (databricks.com/blog/...part-1, 2022-09-30). Não existe caminho de entrada para a Databricks abrir, porque não existe caminho de entrada algum.

Consequência que os alunos perdem: SCC não é "sem egress". Os clusters ainda precisam de uma rota de saída, NAT gateway, internet gateway ou PrivateLink, para alcançar o plano de controle e as APIs da AWS, e um gateway endpoint de S3 mantém o tráfego do S3 na espinha dorsal da AWS para nunca ser cobrado pelo NAT (databricks.com/blog/optimizing-aws-s3-access-databricks, 2022-08-11). A lição 02 dimensiona isso corretamente.

3.3 A IAM role entre contas: como a Databricks pode lançar a sua EC2

A criação de um workspace precisa de três configurações, credential (uma IAM role entre contas), network (VPC/subnets/security groups) e storage (o bucket de armazenamento do workspace), e pode ser dirigida pelo console de conta, pela Account API ou pelo Terraform (docs.databricks.com/aws/en/admin/workspace, 2026-07-28). A credential é um papel que você cria na sua conta cuja política de confiança nomeia a conta AWS da Databricks: "Crie uma nova IAM role entre contas com uma política de acesso... No campo Account ID, insira o ID da conta Databricks 414351767826" (docs.../create-uc-workspace; docs.../administration-guide/account-api/iam-role.html, 2026-01-24), com o ID da sua conta Databricks como external ID. Pré-requisitos nessa página: "Tenha uma VPC e um NAT gateway disponíveis na sua conta AWS, na região do workspace."

---

4. Onde os dados realmente ficam (e onde não ficam)

Um workspace clássico tem três superfícies de armazenamento na sua conta da AWS, e só uma delas é o lake:

Duas distinções da documentação oficial evitam os erros clássicos:

1. Dados do sistema do workspace versus DBFS root. A documentação os separa explicitamente: "DBFS root é um sistema de arquivos acessível pelo usuário, enquanto os dados do sistema do workspace são usados internamente pelos recursos da Databricks": mesmo que ambos fiquem no mesmo bucket. DBFS root e mounts de DBFS são legados e não recomendados para projetos novos (docs.../high-level-architecture, 2026-09-11).
2. Tabelas gerenciadas versus externas. Os arquivos de uma tabela Delta gerenciada vivem onde o Unity Catalog os colocou (ainda no seu S3, sob um caminho que o UC gerencia); os arquivos de uma tabela externa vivem em um prefixo que você já possui, e o UC governa só os metadados. Ambos são "seus dados": nenhum fica no bucket de armazenamento do workspace.

Workspaces serverless mudam a história de armazenamento do workspace (os dados do workspace vão para o armazenamento padrão gerenciado pela Databricks), mas não mudam a história do lake: as tabelas analíticas continuam nos seus buckets S3, alcançados pelo Unity Catalog. A pergunta do plano de dados e a pergunta do armazenamento são perguntas separadas.

• 📚 Você sabia? A terminologia mudou duas vezes. O blog de deployment de 2023 da Databricks diz S3 root bucket; a documentação atual diz workspace storage bucket; e o "plano de dados" dos mesmos blogs é hoje o plano de compute. Quando você ler um tutorial antigo ou um site de preparação para exame que usa as palavras antigas, traduza: root bucket → workspace storage bucket, plano de dados → plano de compute clássico/serverless. Materiais didáticos que ainda apresentam "plano de dados" como vocabulário atual da Databricks estão citando posts de engenharia de 2022 to 2023.

---

5. O mapa de workloads: ingest → curate → serve → ML

O fluxo de referência deste curso, montado a partir da documentação de Auto Loader, medalhão, Databricks SQL e MLflow:

1. Fontes: Kafka/Amazon MSK, Kinesis, JDBC, APIs SaaS e arquivos deixam payloads crus em um landing bucket no S3.
2. Ingestão: Auto Loader (cloudFiles) descobre novos arquivos incrementalmente e escreve tabelas Delta bronze. Ele "processa incremental e eficientemente novos arquivos de dados à medida que chegam ao armazenamento em nuvem" e seu armazenamento de estado chave-valor "garante que os dados sejam processados exactly once" (docs.../auto-loader, página datada de 2026-04-01).
3. Curate: Lakeflow Spark Declarative Pipelines (o Delta Live Tables renomeado) ou jobs comuns limpam, removem duplicatas e conformam para silver, e depois agregam para gold.
4. Serve: Databricks SQL em um warehouse serverless/pro/clássico alimenta dashboards, o editor SQL, alertas e BI externo via JDBC/ODBC. "O Databricks SQL é um data warehouse de nuvem construído sobre arquitetura lakehouse. Ele roda diretamente no seu data lake, suporta SQL ANSI com extensões do Delta Lake" (docs.../aws/en/sql/, atualizado em 2026-09-11).
5. Aprender: MLflow rastreia experimentos, e o Model Registry no Unity Catalog fornece "controle de acesso centralizado, auditoria, lineage e descoberta de modelos entre workspaces" (docs.../manage-model-lifecycle).
6. Governar: Unity Catalog cobre cada camada, com lineage e auditoria disponíveis a partir das system tables.

5.1 Mapeamento workload → compute

Esta tabela é o núcleo prático da lição; toda decisão de custo posterior começa aqui.

• 📚 Você sabia? O mesmo código PySpark pode custar materialmente menos como job do que como cluster interativo. O guia de gestão de custos da Databricks afirma o mecanismo diretamente: "Melhor desempenho somado às taxas de custo por DBU mais baixas que os job clusters oferecem levam a economias de custo dramáticas" (databricks.com/blog/best-practices-cost-management-databricks, 2022-10-18). Job clusters são efêmeros e de propósito único; clusters all-purpose ficam quentes para humanos. O intervalo exato de taxas entre SKUs varia por região e camada de plano: a Databricks publica apenas valores "a partir de" em suas páginas públicas de preços (acesso em 2026-10), então sempre verifique de novo o seu próprio contrato em vez de decorar uma grade vinda de um site de terceiros.

---

6. Os dois medidores: taxas de DBU e a fatura da AWS

"Uma Databricks Unit (DBU) é uma unidade normalizada de poder de processamento na Databricks Lakehouse Platform usada para fins de medição e precificação" (databricks.com/product/pricing, acesso em 2026-10), e o glossário a define como "unidades de capacidade de processamento por hora com base no tipo de instância de VM" (docs .../resources/glossary, atualizado em 2026-08-15). Você paga DBUs pelo processamento; a AWS cobra separadamente pelo metal e pelo encanamento.

6.1 A tabela de preços, em outubro de 2026

Preços de tabela, em USD, com acesso em 2026-10; variam por nuvem, região e camada de plano (AWS: Standard/Premium/Enterprise) e por contrato. A Databricks publica valores "a partir de" para jobs e SKUs interativos: trate qualquer grade completa que você encontre em um site de custos de terceiros como não verificada.

6.2 Exemplo resolvido E1: um job cluster de quatro nós, os dois medidores

Em out 2026. Um trabalho noturno roda em um cluster de 4 nós cujo tipo de instância é cobrado a 3 DBU/hora no SKU de jobs.

Leitura: o lado em DBU de um trabalho noturno de 8 horas é de $432/mês na taxa publicada de jobs "a partir de"; o lado da AWS é uma segunda fatura que você precisa somar você mesmo. Mesmo código, SKU diferente: se aquele workload fosse dirigido interativamente na taxa interativa "a partir de" de $0.40/DBU, os mesmos 2,880 DBU seriam cobrados como $1,152: uma diferença de 2.67× para um compute que faz a mesma aritmética. É por isso que workloads de produção pertencem a job clusters e que BI pertence a warehouses.

6.3 Exemplo resolvido E2: um mês de warehouse serverless e o imposto de ociosidade

Uma equipe roda um SQL warehouse serverless 8 horas/dia, 20 dias/mês, com média de 4 DBU/hora (o serverless faz auto-scale dentro da hora; 4 DBU/h é uma média plausível de equipe pequena: ajuste aos seus próprios números de system.billing.usage quando chegar lá).

Leitura: a própria documentação da Databricks avisa que "SQL warehouses ociosos continuam a acumular DBU e cobranças de instância de nuvem até serem parados" (docs .../compute/sql-warehouse/create). Padrões de parada automática em out 2026: pro/clássico 45 minutos (mínimo 10), serverless 10 minutos (mínimo na UI 5; a API pode definir 1 minuto). Mudar a parada automática de 45 minutos para 10 em um warehouse pro usado em sessões de 30 minutos é uma economia grátis; deixar qualquer coisa ligada 24/7 é a maior linha evitável de uma operação de BI.

6.4 Exemplo resolvido E3: a fatura de armazenamento sob as mesmas tabelas

O armazenamento do próprio lake, para escala: 1 TB (1,024 GB) mantidos por um mês em S3 Standard a $0.023/GB-mês (aws.amazon.com/s3/pricing, acesso em 2026-10) = $23.55/mês, mais requisições PUT/GET (o GET do S3 Standard custa $0.0004 por 1,000 requisições). Um ambiente gold curado de 10 TiB custa, portanto, cerca de $235/mês para ser mantido: aproximadamente metade do que um único warehouse serverless ocioso cobra no mesmo intervalo (E2). Armazenamento é a metade barata de um lakehouse; a disciplina de compute é onde está o dinheiro.

---

7. A mesma query, três medidores: Databricks versus a stack nativa da AWS

A alternativa nativa da AWS é uma composição, não um produto: S3 para armazenamento, Glue Data Catalog para metadados/crawlers/ETL, Athena para SQL serverless, Redshift para um warehouse provisionado ou serverless, Lake Formation para grants, QuickSight para BI. Preços, todos com acesso em 2026-10:

7.1 Exemplo resolvido E4: Athena versus Databricks SQL para um workload de dashboard

Um dashboard escaneia 20 GB/dia durante 22 dias/mês.

Leitura: para um dashboard de BI leve e pesado em scans, o medidor por TB do Athena é dramaticamente mais barato: ~$2.15 vs ~$168. Esse é um resultado honesto, não uma falha do Databricks: o preço por byte pune scans pesados repetidos, ETL, joins, MERGE, streaming e ML, e recompensa leituras raras, largas e ad hoc. A pergunta de projeto nunca é "qual motor é mais barato", mas "qual medidor corresponde à forma do workload". É exatamente por isso que a lição 15 ensina atribuição de custo através do system.billing.usage em vez de benchmarks de fornecedor.

7.2 Exemplo resolvido E5: dimensionar a landing zone

Uma pipeline deposita 500 GB/dia de arquivos crus no S3 Standard.

Leitura: $345/mês para manter um mês de dados de aterragem. Dois alavancas dominam: retenção (limpe os arquivos de origem depois que o Auto Loader fizer o commit; as opções cleanSource da documentação existem para exatamente isso) e tamanho de arquivo (milhares de arquivos minúsculos inflacionam tanto as cobranças de requisição quanto o planejamento do Delta). Armazenamento é previsível; os lados de requisição e de compute são onde os projetos falham em silêncio.

7.3 As duas stacks, lado a lado

• 📚 Você sabia? A própria AWS documenta a interoperabilidade do Delta em vez de tratá-lo como concorrente: o Athena "pode ler tabelas Delta Lake armazenadas no Amazon S3 diretamente, sem precisar gerar arquivos de manifesto nem executar a instrução MSCK REPAIR" (docs.aws.amazon.com/athena/latest/ug/delta-lake-tables.html, acesso em 2026-10): com os limites honestos de somente leitura, motor v3 e ausência de time travel. Glue, EMR e Redshift Spectrum também podem processar tabelas Delta no S3 (databricks.com/blog/databricks-aws-guide-data-ai-summit-2023-featuring-labcorp-conde-nast-grammarly-vizio-ntt-data, 2023-06-23). Formatos abertos cortam nos dois sentidos: o seu lake é portátil, e os motores dos seus concorrentes podem lê-lo.

---

8. O substrato da AWS que você herda (dimensionamento resolvido)

A lição 02 entra fundo; aqui está o quadro. Os requisitos centrais de um deployment padrão são "uma VPC gerenciada pelo cliente, conectividade do plano de dados ao plano de controle, IAM role entre contas e S3 root bucket" (databricks.com/blog/...part-2, 2023-01-27), e "Para cada workspace deve haver um mínimo de duas subnets privadas dedicadas, cada uma com máscara de rede entre /17 e /26, em zonas de disponibilidade separadas" (mesma fonte). O guia bem-arquitetado acrescenta: "Crie uma VPC com bloco CIDR mínimo /18 para deployments de workspace" (docs.databricks.com/aws/en/lakehouse-architecture/security-compliance-and-privacy/best-practices, 2026-07-16).

8.1 Exemplo resolvido E6: dimensionamento de subnet para um workspace

Leitura: dois /24 em AZs separadas satisfazem a regra publicada com folga. A restrição que realmente morde é "dedicadas por workspace": subnets não são colocadas em pool entre workspaces, então cada workspace que você cria consome as próprias duas subnets do CIDR da sua VPC. Planeje a VPC como /18 (segundo o guia bem-arquitetado) e você pode hospedar vários workspaces antes de tocar no roteamento.

Existem três arquiteturas de referência de rede da Databricks em out 2026, Managed security, Hardened connectivity e Isolated environment, que diferem em profundidade de PrivateLink, listas de acesso por IP, controles de egress serverless e PrivateLink de entrada, enquanto secure cluster connectivity mais uma VPC gerenciada pelo cliente estão presentes nas três (docs.databricks.com/aws/en/security/network/deployment-architecture, acesso em 2026-10). Observe também os bloqueios por plano: VPC gerenciada pelo cliente, criação de metastore do UC e SQL serverless todos exigem o plano Premium ou superior (docs.../permissions, atualizado em 2026-09-11; docs.../create-metastore; docs.../admin/sql/serverless).

---

9. Escolhendo a plataforma: Snowflake e o Hadoop do qual você está saindo

9.1 versus Snowflake

Enquadramento neutro, porque ambos os fornecedores publicam páginas de comparação que se contradizem:

Ambas as páginas fazem afirmações opostas de desempenho e de preço/desempenho. Este curso trata cada uma delas como uma afirmação de fornecedor com data, nunca como fato, e nunca cita um multiplicador head-to-head como algo que um aluno deva decorar. Escolha Snowflake quando o workload for puro SQL/BI com concorrência previsível e você quiser a simplicidade de um warehouse; escolha Databricks quando ML/AI, streaming, Python/Spark e portabilidade de formato aberto forem requisitos de primeira classe; cada vez mais, coexistam: federação e Delta Sharing significam que os dois não se excluem mutuamente (ver lições 12 e 17).

9.2 versus Hadoop on-prem (HDFS + YARN + Hive)

O guia de migração da Databricks é direto: "Mesmo que você migre workloads legados de Hadoop on-premises para serviços gerenciados em nuvem como o EMR ... ainda vai esbarrar nos mesmos problemas de confiabilidade e escalabilidade" (databricks.com/solutions/migration/hadoop, 2023-09-03). O mapeamento é mecânico:

Habilidades e investimentos em BI atravessam precisamente porque os formatos continuam abertos: o SQL não precisa ser reescrito para sair de tabelas estilo Hive e chegar a tabelas gold sustentadas por Delta, e a lição 03 cobre esse caminho de migração (hive_metastore aparece como um catalog legado de nível superior).

9.3 A decisão, desenhada

O diagrama codifica três regras práticas desta lição: portabilidade de formato aberto e workloads mistos apontam para o lakehouse; só-SQL mais preferência por um único fornecedor aponta para a stack nativa da AWS; e um ambiente Hadoop não sofre "lift and shift": ele é redesenhado (é por isso que a lição 03 trata a migração do hive_metastore como um caminho de primeira classe).

---

10. Por que abertura é requisito de projeto, não slogan

Três fatos concretos de interoperabilidade, todos oficiais e todos datados:

1. Seus dados são Parquet mais um log de transações Delta no seu bucket S3: qualquer motor que entenda o formato pode lê-lo sem exportar de um armazenamento proprietário (databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html).
2. Leitores do lado da AWS: o Athena lê tabelas Delta registradas no catalog do AWS Glue (somente leitura, motor v3, sem time travel: docs.aws.amazon.com/athena/latest/ug/delta-lake-tables.html, acesso em 2026-10).
3. Leitores de terceiros via Unity Catalog: "Por meio de APIs abertas e credential vending, o Unity Catalog permite que motores externos como Trino, DuckDB, Apache Spark, Daft e motores integrados ao Iceberg REST catalog, como o Dremio, acessem tabelas gerenciadas" (docs .../tables/managed, 2026-08-18), pela Unity REST API e pelo Iceberg REST Catalog (IRC) (docs .../external-access/unity-rest, 2026-08-26).

O ponto estratégico é o da própria Databricks: um lakehouse proprietário armazena dados "em formatos que apenas um fornecedor consegue ler", enquanto os dados de um lakehouse aberto vivem em "Delta Lake e Apache Iceberg ... em formatos de arquivo abertos como Apache Parquet" (databricks.com/blog/what-open-lakehouse-open-data-standards-explained, 2026-06-16). Na AWS isso importa de uma segunda forma: você mantém os dados na sua conta, então uma troca de motor, uma disputa com fornecedor ou uma aquisição não vira um projeto de extração de dados.

• 📚 Você sabia? Compartilhar também é aberto: Delta Sharing é um protocolo aberto (coberto na lição 12), enquanto Databricks Marketplace é o catálogo comercial construído sobre ele. Como os arquivos subjacentes são formatos abertos, um share pode ser consumido por motores que não são Databricks: essa é a resposta prática para "o que acontece com o meu lake se um dia sairmos?".

---

11. As armadilhas: onze confusões que este curso não vai deixar você manter

1. "Plano de dados" versus "plano de compute". A mesma coisa; a documentação desde 2026 diz plano de compute, dividido em clássico e serverless. Blogs antigos dizem plano de dados.
2. O plano de controle não é a sua conta. Ele fica na conta AWS da Databricks, mas o bucket de armazenamento do workspace em um workspace clássico fica na sua conta. Confundir os dois produz um modelo de ameaça errado.
3. O bucket de armazenamento do workspace não é o data lake. Só dados do sistema; não apagável; nunca compartilhado entre workspaces; nunca usado para dados de cliente.
4. O DBFS root é legado. Ele pode ficar no mesmo bucket que os dados do sistema do workspace, mas "DBFS root é um sistema de arquivos acessível pelo usuário, enquanto os dados do sistema do workspace são usados internamente pelos recursos da Databricks" (docs.../high-level-architecture, 2026-09-11), e DBFS root/mounts não são recomendados para projetos novos.
5. Renomeações são reais; verifique antes de ensinar ou responder. Delta Live Tables → Lakeflow Spark Declarative Pipelines (docs .../ldp/concepts/where-is-dlt, 2026-01-23; nota de release de 2025-11-12) sem exigir migração de código, com os SKUs clássicos ainda começando com DLT; SQL endpoints → SQL warehouses (2023); Model Registry do workspace → Models in Unity Catalog.
6. Duas faturas. DBUs mais a sua fatura da AWS; taxas serverless embutem instâncias, taxas clássicas não.
7. Jobs versus SKU all-purpose. O mesmo código pode custar materialmente menos como job, a orientação oficial diz isso (2022-10-18), mas o intervalo exato depende de região/contrato, então verifique de novo em vez de decorar.
8. Athena lendo Delta ≠ suporte total a Delta. Só Glue catalog, motor v3, somente leitura, sem time travel.
9. O escopo do metastore é regional, não por workspace. Um metastore por região; hive_metastore é um catalog legado de nível de workspace.
10. Serverless é condicional. Exige plano Premium, e o compute serverless roda na conta da Databricks na mesma região AWS do seu plano clássico.
11. Benchmarks de fornecedor são marketing nos dois sentidos. As páginas Databricks-versus-Snowflake e Snowflake-versus-Databricks fazem afirmações mutuamente contraditórias; cite-as apenas como "afirmação de fornecedor, com data".

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

---

Casos Reais

📋 Caso A: Biogen (farmacêutica, Cloud: AWS) Desafio. A informática on-premises não conseguia escalar para petabytes de genômica: "um pipeline que antes levava 2 semanas para processar 700,000 variantes". Stack na AWS. Runtime Databricks for Genomics com Delta Lake, ao lado da plataforma DNAnexus na AWS: a página do caso carrega a própria tag Cloud: AWS da Databricks. Resultado relatado. "2 milhões de variantes genômicas analisadas em 15 minutos · 2 alvos de fármaco descobertos" (https://www.databricks.com/customers/biogen, página sem data, acesso em 2026-10; origem do caso 2020-11). Relação com esta lição. L01: migração para um lakehouse de nuvem medida em semanas de compute removidas, não apenas em dólares: o conceito de lakehouse e o pilar de formatos abertos tornaram portável um ambiente on-prem. ⏳ Nota temporal: um número de origem de 2020; trate-o como o que a Biogen relatou na época, não como uma garantia de plataforma de 2026.

📋 Caso B: Punchh / fidelidade no varejo (Cloud: AWS) Desafio. MySQL da AWS superado, um warehouse caro demais, ferramentas sem ACID, e relatórios do Tableau pagando um join de 12 tabelas a cada refresh. Stack na AWS. Databricks SQL sobre Delta Lake bronze/silver/gold, notebooks, Tableau por cima: Cloud: AWS na página do caso. Resultado relatado. "10x mais rápido no time-to-insight · 30% menores custos operacionais · 12% de aumento na satisfação do cliente" (https://www.databricks.com/customers/punchh, página sem data, acesso em 2026-10; origem do caso 2021-09). Citação. "Somos capazes de armazenar dados crus assim como dados refinados no mesmo lakehouse.": Jagan Mangalampalli, Punchh (mesma URL). Relação com esta lição. L01 secundário, o layout medalhão da seção 5 como controle de custo: tabelas gold pré-join vencem joins de 12 vias na hora do relatório. ⏳ Nota temporal: relatado em 2021; as proporções são da Punchh, não um SLA de plataforma.

📋 Caso C: Rivian (veículos elétricos, Cloud: AWS) Desafio. Terabytes de dados de veículos por dia de mais de 70,000 veículos, com ferramentas legadas que "luitavam para escalar pipelines com custo eficiente" e times em silos bloqueando o ML de manutenção preditiva. Stack na AWS. Databricks SQL, Delta Lake, Unity Catalog e liquid clustering: Cloud: AWS na página do caso; o compêndio de 100 casos nomeia "Unity Catalog para governança de dados, Delta Tables para armazenamento e Liquid Clustering para layout de dados" para ML de previsão de carga em tempo real. Resultado relatado. "1,000+ usuários da plataforma, um aumento de 75% em relação a um ano antes" (https://www.databricks.com/customers/rivian, página sem data, acesso em 2026-10); "50% melhor desempenho de tempo de execução" (https://www.databricks.com/your-ai/customers/rivian, 2024-05-30); detalhes da stack em https://www.databricks.com/blog/data-intelligence-action-100-data-and-ai-use-cases-databricks-customers (2025-07-09). Relação com esta lição. L01: um lakehouse AWS governado alimentando dashboards e ML de produção a partir das mesmas tabelas, o que concretiza a afirmação de "cópia única de dados" da seção 1. ⏳ Nota temporal: as métricas vêm de páginas de 2024 to 2025; carimbe-as com a data quando as citar.

Veredito Comparativo: lakehouse versus nativo da AWS versus Snowflake versus Hadoop on-prem

• Versus um data lake puro (S3 + Parquet, sem camada de tabela): você mantém o custo e a elasticidade, mas perde ACID, aplicação de schema e time travel. Se nada jamais falhar, sobrescrever ou rodar de forma concorrente, um lake cru é mais barato; em produção, o log de transações do Delta é o seguro mais barato da stack.
• Versus a stack nativa da AWS (S3 + Glue + Athena + Redshift + Lake Formation): o nativo da AWS vence para ambientes só-SQL, majoritariamente batch, padronizados na AWS, que querem um único fornecedor e medidores por uso ($5.00/TB no Athena, $0.44/DPU-hour no Glue). O Databricks vence quando você precisa de uma cópia única governada para SQL e Python/Spark e streaming e ML: ao preço de um segundo fornecedor, de um medidor de DBU e de um plano Premium para o conjunto completo de recursos. Ambos se apoiam no mesmo S3, e a AWS documenta a interoperabilidade do Delta em vez de isolá-la.
• Versus Snowflake: o Snowflake vence na simplicidade de SQL/BI puro e no zero de trabalho com VPC; o Databricks vence em ML/AI, streaming e portabilidade de formato aberto. Não publique nenhum multiplicador head-to-head em um documento de projeto: as páginas de comparação de ambos os fornecedores são marketing carimbado com data que contradiz o outro lado.
• Versus Hadoop on-prem (HDFS + YARN + Hive): não é uma disputa acirrada em 2026, o S3 substitui o HDFS, o compute elástico/serverless substitui o YARN, e o Unity Catalog substitui o Hive metastore, enquanto os formatos abertos preservam os seus ativos de SQL e BI. A ressalva honesta: "Mesmo que você migre workloads legados de Hadoop on-premises para serviços gerenciados em nuvem como o EMR... ainda vai esbarrar nos mesmos problemas de confiabilidade e escalabilidade" (2023-09-03), o que você está mudando é a arquitetura, não o hosting.

---

Perguntas de Prática (Practice Questions)