Databricks SQL Warehouses e a Camada de Serviço: Serverless, Escalabilidade, Dashboards, BI e Federação

Tudo que vem antes neste curso termina do mesmo jeito: uma tabela Delta, governada pelo Unity Catalog, que alguém precisa ler. Analistas leem em um editor SQL, executivos leem em um dashboard, o Tableau lê via ODBC e um pipeline de relatórios lê por um catálogo federado. Na Databricks toda essa leitura acontece em uma única peça de compute, o SQL warehouse, e a escolha que você faz sobre qual tipo de warehouse, qual tamanho, qual janela de auto-stop e qual driver de BI é, ao mesmo tempo, uma decisão de latência, uma decisão de governança e uma fatura.

Esta lição é essa escolha, trabalhada de ponta a ponta. A espinha é uma única distinção que os docs de outubro de 2026 enunciam sem rodeios: com um SQL warehouse pro ou classic a camada de compute existe na sua conta AWS; com um SQL warehouse serverless ela existe na conta Databricks (docs.../compute/sql-warehouse/warehouse-types, atualizado em 11 de setembro de 2026). Todo o resto, inícios frios de 2 a 6 segundos contra cerca de quatro minutos, cluster policies que deixam de valer, uma VPC gerenciada pelo cliente que deixa de importar, a nota de rodapé de $0.70 que diz "inclui o custo da instância na nuvem", decorre dessa única linha.

Nesta lição você vai:

• ler a linha de warehouses de out 2026, três tipos GA mais o Lakehouse//RT em Beta, e a matriz de capacidades que os separa (Photon, Predictive IO, Intelligent Workload Management);
• desenhar onde o compute fica na AWS (conta Databricks vs sua VPC), incluindo a história de egress do serverless e do PrivateLink de saída;
• percorrer sete exemplos resolvidos: uma tabela de decisão de tipo de warehouse com a encantação da API, matemática de dimensionamento por concorrência, um cálculo de desperdício de auto-stop, um pacote de consultas de monitoramento, uma ficha de conexão de BI para Tableau e Power BI, uma sequência de DDL de consulta federada e um rascunho de custo mensal DBU + EC2 em duas colunas com tarifas de out 2026;
• dimensionar um warehouse do sintoma ao botão usando os códigos do query profile e dos performance insights;
• construir dashboards AI/BI, consultas salvas e alertas e saber exatamente o que aconteceu com os dashboards legados;
• ligar Tableau, Power BI, Excel e ferramentas do Partner Connect com os nomes atuais dos drivers e os requisitos mínimos;
• esboçar o Lakehouse Federation com foreign catalogs e nomear o requisito que exclui silenciosamente os warehouses classic;
• estudar NAB, Punchh e nCino na AWS, ler a caixa de atualizações de 2026 e praticar com doze questões mais quatro verificações interativas.

---

1. O que é o Databricks SQL e as duas portas por que toda consulta passa

1.1 Uma interface, muitas superfícies

Databricks SQL é "um data warehouse de nuvem construído sobre a arquitetura lakehouse. Ele roda diretamente no seu data lake" com ANSI SQL e extensões do Delta Lake (docs.../sql/, atualizado em 11 de setembro de 2026). As superfícies documentadas: SQL editor (autoria com assistência de IA, comentários de código, histórico de versões), notebooks anexados a um warehouse, jobs, dashboards, metric views, alerts, ETL (tabelas streaming e materialized views definidas direto no SQL) e uma REST API: mais os monitores: query history, query profile e query performance insights.

A regra de compute que vale a pena memorizar: "Databricks uses SQL warehouses for compute in the following interfaces: SQL editor · Databricks SQL queries · Dashboards · SQL alerts" e, opcionalmente, notebooks, o file editor e Lakeflow Jobs (docs .../query, atualizado em 11 de setembro de 2026). A mesma página acrescenta duas restrições que moldam todo o resto:

• "Quando você consulta dados com SQL warehouses, pode usar apenas sintaxe SQL."
• "Para workspaces habilitados para o Unity Catalog, os SQL warehouses sempre usam o Unity Catalog para gerenciar o acesso às fontes de dados."

E, na página de warehouse-types: "SQL warehouses não suportam credential passthrough. A Databricks recomenda usar o Unity Catalog para governança de dados." Não existe caminho de credencial por usuário em um warehouse: a governança é grant do Unity Catalog, ponto final.

1.2 As duas portas

Toda consulta por um warehouse passa por duas verificações independentes, e os alunos costumam confundi-las:

1. A ACL do warehouse, este principal pode usar este compute? (CAN USE para rodar, CAN MONITOR para ver profiles, CAN MANAGE para reconfigurar, seção 9.)
2. O grant do Unity Catalog; este principal pode ler esta tabela? (SELECT em catalog/schema/table.)

Passar por uma não diz nada sobre a outra. Um usuário com CAN USE no warehouse e sem SELECT na tabela recebe um erro de autorização; um usuário com SELECT e sem CAN USE nem chega ao motor. Ensine as duas, sempre.

Esse diagrama é também o modelo mental para o resto da lição: as seções 2 to 4 decidem onde o compute está e quanto dele existe, as seções 5 to 6 decidem o que o usuário vê, as seções 7 to 8 decidem quais ferramentas podem falar com ele, a seção 9 decide quem pode e a seção 10 decide quanto custa.

---

2. A linha de warehouses em out 2026: serverless, pro, classic, e uma Beta

2.1 Três tipos GA, uma Beta

"O Databricks SQL suporta os tipos serverless, pro e classic" e "Além disso, o Lakehouse Real-Time (Beta) é um tipo especializado de warehouse serverless para consultas de leitura sub-segundo e de alta concorrência" que "suporta apenas consultas (SELECT)" (docs .../warehouse-types, atualizado em 11 de setembro de 2026). A matriz de capacidades da mesma página:

Três consequências decorrem da linha do meio apenas:

1. Pro e classic herdam a sua rede AWS. Rodam como EC2 na VPC do workspace, escolhem uma availability zone via Auto-AZ e são governados por cluster policies, configurações de spot e o seu desenho de VPC/PrivateLink (a rede do workspace da Lição 02).
2. Serverless não. "VPCs gerenciadas pelo cliente não se aplicam aos recursos de compute dos SQL warehouses serverless", "Cluster policies, incluindo políticas de instâncias spot, não são suportadas" e "os SQL warehouses serverless não têm endereços IP públicos" (docs .../sql/admin/serverless, atualizado em 10 de junho de 2026).
3. Classic é o padrão da API ao mesmo tempo em que é o tipo menos capaz. Usando a UI "o tipo padrão de SQL warehouse é serverless"; usando a API de SQL warehouses com os padrões "o tipo padrão de SQL warehouse é classic. Para usar serverless, defina o parâmetro enable_serverless_compute como true e warehouse_type como pro." Terraform e scripts que omitem essa flag criam silenciosamente o único tipo de warehouse que não pode federar, não pode criar materialized views nem tabelas streaming e não pode chamar AI Functions.

2.2 Pré-requisitos de serverless na AWS (leia antes de prometer)

De docs .../sql/admin/serverless (atualizado em 10 de junho de 2026): a conta "não pode estar em um período de teste gratuito"; o workspace "deve estar no plano Premium ou superior"; "SQL warehouses serverless são suportados em todas as regiões da AWS"; o workspace "não pode usar S3 access policies" e não pode usar "um Hive metastore legado externo" (warehouse-types repete a cláusula do metastore: "Se o seu workspace usa um Hive metastore externo legado, SQL warehouses serverless não são suportados"). A identidade é o Unity Catalog e a conectividade é privada: serverless "usa conectividade privada entre o plano de controle do Databricks e o plano de compute serverless em quase todos os casos."

• 📚 Você sabia? O egress do serverless até os seus recursos é um problema separado da ausência de IPs públicos do próprio serverless. Para qualquer coisa fora do Amazon S3 ou do DynamoDB na mesma região, "o compute serverless usa endereços IP públicos para alcançar seus recursos", e desde meados de fevereiro de 2026 a Databricks "publica IPs de saída em formato JSON em um endpoint público", depois de 25 de maio de 2026 as listas IP legadas foram descontinuadas (docs.../serverless-firewall, acesso em 2026-10). Para conectividade dedicada você usa PrivateLink de saída por meio de uma network connectivity configuration: cada conta recebe até 10 NCCs por região, cada região 30 private endpoints e cada NCC anexa até 50 workspaces, e esse caminho exige o plano Enterprise (docs.../pl-to-internal-network, acesso em 2026-10).

2.3 Onde o compute fica, desenhado

A aresta da direita é a que os alunos ignoram: a federação a partir de um warehouse serverless até um banco de dados privado ainda precisa atravessar um caminho de rede, e o serverless traz as próprias regras de egress junto. Pro é a escolha documentada quando "você tem rede definida personalizada e quer se conectar a bancos de dados na sua rede" (warehouse-types, 11 de setembro de 2026).

2.4 Exemplo resolvido E1: tabela de decisão de tipo de warehouse e a encantação da API

Entradas (três bifurcações, todas específicas da AWS):

1. O workspace é elegível para serverless (Premium+, sem teste gratuito, sem Hive metastore legado externo, sem S3 access policies)?
2. Você precisa alcançar um banco de dados privado/on-prem para a federação, ou impor uma rede personalizada?
3. Você precisa de AI Functions, ou de materialized views / tabelas streaming criadas a partir do SQL?

O corpo de API que te dá serverless (docs .../api/warehouses/v1/warehouse, acesso em 2026-10):

warehouse_type aceita apenas PRO ou CLASSIC; serverless é PRO mais enable_serverless_compute: true. Esqueça a flag e você construiu um warehouse pro: que é um warehouse perfeitamente bom, só que com início frio de quatro minutos e uma linha de EC2 na sua fatura da AWS. Tags são limitadas a menos de 45 por warehouse e existem, nas palavras da própria API, "to monitor the cost of cloud resources used by users and groups."

---

3. Dimensionamento: tamanhos em camiseta, a regra de concorrência e os limites rígidos

3.1 A escada de tamanhos

Os tamanhos vão de 2X-Small → 5X-Large e, para classic/pro, a escada é concreta: "Todos os workers usam instâncias i3.2xlarge" (docs .../compute/sql-warehouse/warehouse-behavior, atualizado em 8 de outubro de 2026).

Só o driver escala, i3.2xlarge → i3.4xlarge → i3.8xlarge → i3.16xlarge, enquanto todo worker continua i3.2xlarge (mesma página). Os docs observam que a tabela "pode variar conforme a disponibilidade do produto ou da região e a carga de trabalho"; leia system.compute.warehouses para ver a forma que você realmente recebeu.

O padrão ao criar um warehouse na UI é X-Large. O cache de disco vive nos SSDs locais desses workers (seção 6), é por isso que a família storage-optimised i3 importa para o desempenho de consulta e é por isso que o preço do lado da AWS de um nó i3 importa para o rascunho de custo da seção 10.

3.2 Concorrência é um botão de número de clusters, não de tamanho

Regras documentadas (warehouse-behavior 8 de outubro de 2026; create 11 de setembro de 2026):

• "um cluster para cada 10 consultas concorrentes": a regra prática de dimensionamento, enunciada nas duas páginas.
• "O número máximo de consultas em uma fila para todos os tipos de warehouse é 1.000."
• Limites da API: max_num_clusters ≤ 40; min_num_clusters ≤ min(max, 30); padrão do min 1. Aumentar min_num_clusters "vai garantir que um número maior de clusters esteja sempre rodando e, portanto, pode reduzir o tempo de início frio": a um custo contínuo de cobrança.
• Teto do workspace: 1.000 SQL warehouses no total, fixo (docs .../resources/limits, 9 de outubro de 2026).
• "A Databricks recicla clusters que estão rodando há mais de 24 horas" e pode terminá-los à força, então nenhuma consulta individual nem sessão de notebook anexado deve assumir clusters imortais.

A regra dos dois botões que conserta a maioria dos dashboards: tamanho (cluster size) compra poder por consulta; max_num_clusters compra concorrência. Vazamento para disco é o primeiro botão; enfileiramento é o segundo.

A série plana é a lição: com max_num_clusters fixado em 4 você tem 4 × 10 = 40 slots de consulta concorrentes em qualquer tamanho, de um 2X-Small com 1 worker até um 5X-Large com 512 workers. Ir mais largo no eixo do tamanho multiplica o poder por consulta (e o custo) sem admitir nenhuma consulta concorrente extra; ir mais largo em max_num_clusters faz o oposto. Os nomes dos tamanhos de warehouse são idênticos entre os tipos, mas os tamanhos serverless são cobrados a uma taxa fixa de DBU-por-hora que depende do tamanho escolhido (docs answers, página datada de 2026-08-27).

3.3 Exemplo resolvido E2: dimensionar 30 usuários de dashboard concorrentes

Cenário. Uma equipe de BI com 30 usuários de dashboard concorrentes, consulta média de 4 s, dashboards rodando das 09:00 às 18:00, 21 dias úteis por mês.

Resposta: três clusters no mínimo sob a taxa documentada, dimensionados em Medium ou Large a partir da evidência de vazamento, com max_num_clusters definido antes da rajada de pico, e, em serverless, um único warehouse maior com IWM no lugar de ajustar à mão três clusters.

3.4 Sintoma → botão

Dois limites rígidos ficam atrás dessa árvore: a fila segura no máximo 1.000 consultas, e o profile de um resultado em cache não existe (seção 6), então o benchmark precisa derrotar o cache primeiro ou a árvore vai parecer mais limpa do que a realidade.

---

4. Escalabilidade, auto-stop e a economia do cold start

4.1 Dois modelos de scaling, não um

Dois modelos de scaling documentados: um por família de warehouse:

• Classic e pro: min/max de clusters mais autoscaling baseado em carga, com as faixas de carga citadas no E2 (adicionar clusters depois de 2 to 6, 6 to 12, 12 to 22 minutos de carga; escalar para cima quando uma consulta espera 5 minutos; escalar para baixo depois de 15 minutos consecutivos de carga baixa). As availability zones são resolvidas por Auto-AZ.
• Serverless: Intelligent Workload Management. "O IWM usa modelos de machine learning para gerenciar recursos de compute dinamicamente"; quando a capacidade falta "a consulta é colocada em uma fila" e "se os tempos de espera aumentam, o autoscaler provisiona rapidamente mais clusters" (warehouse-behavior, 8 de outubro de 2026). O IWM é exclusivo de serverless: pro e classic ganham Photon e Predictive IO, mas não IWM.

4.2 Auto-stop: a otimização mais barata deste curso

E a frase do dinheiro, literal: "SQL warehouses ociosos continuam acumulando DBU e cobranças de instância na nuvem até serem parados." (mesma página). Um warehouse cobra enquanto está ligado: não enquanto está ocupado.

⚠️ AVISO, o padrão de auto-stop é uma decisão de cobrança que você herda. O padrão de 45 minutos de pro/classic foi escolhido por conforto, não por economia: todo intervalo menor que 45 minutos mantém um warehouse (e suas instâncias EC2, na sua conta AWS) faturável. Em contrapartida, um warehouse serverless no seu mínimo de 1 minuto pela API para entre duas atualizações de dashboard de um usuário: barato, e a apenas um reinício de 2 to 6 segundos de distância. Em um warehouse pro/classic esse mesmo reinício é de ~4 minutos, que os usuários leem como uma indisponibilidade. Combine o auto-stop com o comportamento do cliente: extrações e refreshs agendados → auto-stop mais longo ou min_num_clusters = 1; humanos interativos em serverless → auto-stop curto. E nunca configure o auto-stop como "never": a frase de cobrança por ociosidade dos docs é incondicional.

4.3 Exemplo resolvido E3: quanto custa por mês um padrão de auto-stop

Cenário (premissas declaradas: reexecute com o seu próprio tráfego): um warehouse pro servindo dashboards com tráfego real apenas em dois picos: 09:00 to 10:00 e 14:00 to 15:00: ao longo de 21 dias úteis.

Tarifas: SQL Classic $0.22/DBU (instantâneo de página 2026-10) e AWS us-east-1 sob demanda i3.2xlarge $0.624/h (lista de preços do AWS EC2, lida em 2026-10-12). A emissão de 4 DBU/h é uma cifra ilustrativa por tamanho: a página de preços publica $/DBU apenas, então leia o seu próprio DBU/hora por tamanho em system.billing.list_prices (seção 10). O ponto sobrevive à substituição: vinte minutos desnecessários de auto-stop em vinte warehouses eclipsam qualquer mudança de tier de tamanho.

• 📚 Você sabia? Auto-stop é só metade da história da ociosidade. Aumentar min_num_clusters "reduz o tempo de início frio de novas consultas" (Warehouses API, acesso em 2026-10), mas mantém clusters faturáveis quentes 24 horas por dia: enquanto em serverless o início frio já é de 2 to 6 segundos, então min_num_clusters > 1 raramente vale a pena pagar. E como "a Databricks recicla clusters que estão rodando há mais de 24 horas", um warehouse que nunca fica ocioso ainda tem seus clusters reciclados, com possível terminação forçada de trabalho de longa duração (docs.../sql-warehouse/create, 11 de setembro de 2026).

---

5. Consultas, dashboards e alertas: a bancada do DBSQL

5.1 Consultas salvas têm suas próprias permissões

O SQL editor vem com assistência de IA, comentários de código e histórico de versões (docs .../sql/, 11 de setembro de 2026). Consultas salvas são securables em si mesmas (docs .../sql/user/queries, atualizado em 29 de abril de 2026):

• compartilhar uma consulta exige CAN MANAGE naquela consulta;
• dois modos de credencial: "Run as viewer", "A credencial do visualizador é usada para executar a consulta. O visualizador também precisa ter permissões de pelo menos CAN USE no warehouse", versus "Run as owner";
• "Um usuário administrador do workspace Databricks tem acesso de visualização a todas as consultas do workspace."

A UI de query history mantém 30 dias de histórico; você vê as suas próprias consultas como dono, ou as de outros se tiver pelo menos CAN VIEW no warehouse que as executou. Qualquer coisa mais longa vai para system.query.history (seção 6).

5.2 Dashboards AI/BI: a geração Lakeview, agora a única geração

"Os dashboards AI/BI apresentam autoria com assistência de IA, uma biblioteca de visualização aprimorada e uma experiência de configuração simplificada" (docs .../dashboards, atualizado em 11 de setembro de 2026). O conjunto de capacidades documentado: datasets e visualizações; filtros em nível de página/widget/global com cross-filtering e drill-through; cálculos personalizados; rascunho/publicação; "Quando publicados, seus dashboards podem ser compartilhados com qualquer pessoa registrada na sua conta Databricks, mesmo que ela não tenha acesso ao workspace"; incorporação por iframe; agendamento e assinatura por e-mail ou Slack; integração com Git / controle de versão; Declarative Automation Bundles; APIs REST; agendamento como Lakeflow Job; agentes Genie; monitoramento de uso por logs de auditoria e system tables; e lineage do Unity Catalog integrado.

Os dashboards legados acabaram. "Fim do suporte aos dashboards legados: 10 de abril de 2025. Você não pode mais criar ou clonar dashboards legados usando a UI ou a API" (docs.../ai-bi/release-notes/2025); a documentação legada foi aposentada, e o endpoint de migração POST /api/2.0/lakeview/dashboards/migrate está marcado como Deprecated com a nota "Use Lakeview (AI/BI) dashboards instead" (referência da API Lakeview, acesso em 2026-10).

• 📚 Você sabia? O nome que você vê na API é um fóssil. Os dashboards AI/BI "eram anteriormente conhecidos como Lakeview dashboards. A API Lakeview ainda mantém esse nome", então toda chamada create/list/publish continua sendo /api/2.0/lakeview/dashboards/* mesmo quando a UI diz AI/BI (docs.../dashboards, 11 de setembro de 2026; referência da REST API, acesso em 2026-10). Qualquer script, recurso de Terraform ou tutorial que fala em "migrar para o Lakeview" está escrevendo história de 2023 to 2024: o endpoint de migração está deprecado e dashboards legados não podem ser criados de forma alguma desde 2025-04-10.

5.3 Alertas

"Use os alerts do Databricks SQL para executar consultas periodicamente, avaliar condições definidas e enviar notificações se uma condição for atendida" (docs.../sql/user/alerts, página datada de 28 de julho de 2026). Desde maio de 2025 o editor é consolidado, configuração da consulta, condições, agendamentos e destinos de notificação em uma única interface, e os alertas legados continuam funcionando ao lado dele (release notes, maio de 2025). Alertas são a metade de fechamento do loop de monitoramento: anexe um à consulta de higiene da frota no E4 e um warehouse cujo auto-stop passe dos 30 minutos aciona alguém em vez de faturar quieto.

---

6. Cache, o query profile e as system tables

6.1 Quatro caches, quatro vidas úteis

(docs.../queries/query-caching e.../optimizations/disk-cache, acesso em 2026-10). Para medir com honestidade: SET use_cached_result = false;: documentado como apropriado "only in testing or benchmarking". Consultas determinísticas acertam os caches; um predicado no estilo NOW() os derrota e aí você paga preço cheio em cada execução.

6.2 O profile, os insights e seus significados

• Query profile: você precisa ser o dono da consulta ou ter pelo menos CAN MONITOR no warehouse; "Um query profile não está disponível para consultas que executam a partir do cache de consultas. Para contornar o cache de consultas, faça uma alteração trivial na consulta, como mudar ou remover o LIMIT" (docs.../query-profile, 10 de junho de 2026).
• Query performance insights: recomendações com código (docs.../performance-insights, 11 de setembro de 2026): DATA_SPILL → "Aumente o tamanho do warehouse para adicionar memória"; EXCESSIVE_QUEUE_TIME → "Aumente o número máximo de clusters"; IO_THROTTLING → solicite limites de requisição de armazenamento mais altos; mais DATA_SKEW, MANUAL_DATA_LAYOUT e as acelerações aplicadas AUTO_LIQUID_CLUSTERING, HISTORY_BASED_JOIN_STRATEGY, SHORT_QUERY_PRIORITIZATION.
• System tables: a mesma história dos dados: system.query.history (Public Preview, 365 dias, regional, registros "tipicamente disponíveis dentro de uma hora"), system.compute.warehouses (instantâneos de configuração), system.compute.warehouse_events (eventos de início/parada/scale), system.billing.usage e system.billing.list_prices (o log de preços, retenção indefinida, global).

Nota de acesso sobre system.query.history: "Por padrão, apenas administradores têm acesso à system table… A Databricks recomenda criar uma view dinâmica para cada usuário ou grupo" (docs .../system-tables/query-history, página datada de 21 de setembro de 2026). A coluna client_application dela é o que diz se uma consulta veio do "Databricks SQL Editor, Tableau, and Power BI", e cache_origin_statement_id é como você prova que um resultado veio do cache.

6.3 Exemplo resolvido E4: um pacote de monitoramento para a frota de warehouses

Fontes: página de monitoring-queries (docs.../sql-warehouse/monitor/queries, 11 de setembro de 2026), referência de query-history (21 de setembro de 2026), system tables de billing (atualizado em 2026-10-08). A consulta (a) é a que se acopla a um alerta; a consulta (d) é a que se publica em um dashboard AI/BI: a Databricks entrega consultas de custo prontas e um Usage Dashboard pré-montado exatamente para isso (docs.../admin/usage/system-tables, 11 de setembro de 2026).

---

7. Conectividade de BI: primeiro os drivers, depois as ferramentas

7.1 A situação dos drivers em out 2026

(docs .../integrations/odbc/download, espelho de página datado de 11 de setembro de 2026; páginas de download e de arquivo do driver, acesso em 2026-10). A renomeação de fevereiro de 2026 importa operacionalmente: "A partir de fevereiro de 2026, novas versões do driver ODBC estão sendo publicadas pela Databricks e o driver foi renomeado para Databricks ODBC Driver." Caminhos de instalação: Windows C:\Program Files\Databricks ODBC Driver, macOS /Library/databricks/databricksodbc, Linux /opt/databricks/databricksodbc. Algumas ferramentas embutem o driver (versões recentes do Power BI Desktop); o Tableau Desktop não.

O denominador comum em todas as ferramentas: conexão = Server Hostname + HTTP Path de um SQL warehouse, autenticação = OAuth / login Databricks / personal access token / service principal. Usuário/senha está morto: a própria ajuda do Tableau registra que "Basic authentication using a Databricks user name and password reached end of life as of July 2024."

7.2 A matriz de ferramentas

• 📚 Você sabia? Versões de driver são um compromisso de suporte, não apenas uma lista de download: "a Databricks suporta cada versão de driver por pelo menos 2 anos" (página de download do driver, acesso em 2026-10). O arquivo também carrega um aviso que vale ler uma vez: versões do Simba JDBC anteriores a 2.6.21 dependem de uma biblioteca com CVE-2021-44228 (Log4Shell): uma razão concreta pela qual os docs "strongly recommend migrating" para fora das linhas Simba.

7.3 Exemplo resolvido E5: ficha de conexão de BI (especificação copiar/colar)

Tableau Desktop → um SQL warehouse serverless

Power BI → o mesmo warehouse

As duas fichas assumem as duas portas da seção 1: CAN USE no warehouse para a identidade da ferramenta, SELECT nas tabelas subjacentes para essa mesma identidade (um service principal precisa das duas). Some o auto_stop_minutes do warehouse à ficha: uma extração agendada a cada 15 minutos contra um warehouse serverless com auto-stop de 10 minutos paga um reinício de 2 to 6 segundos cada vez, enquanto o mesmo agendamento contra um warehouse pro paga ~4 minutos.

---

8. Lakehouse Federation: consultando outros sistemas a partir do Databricks SQL

8.1 O que é

"O Lakehouse Federation é a plataforma de query federation do Databricks. Ele fornece acesso governado e somente leitura a dados externos por meio de foreign catalogs do Unity Catalog, com pushdown automático de consultas e controles de acesso refinados no nível da tabela" (docs .../query-federation, atualizado em 29 de setembro de 2026). Dois sabores:

• query federation: empurrado para o banco de dados externo via JDBC; "A consulta roda no Databricks e no compute remoto… Não suportado (somente leitura)" para escritas;
• catalog federation: "Roda diretamente contra o object storage, apenas no compute do Databricks. Mais econômico e otimizado para desempenho."

Listas de fontes verificadas (out 2026). Query federation: MySQL, PostgreSQL, Teradata, Oracle, Amazon Redshift, Salesforce Data 360, Snowflake, Microsoft SQL Server, Azure Synapse, Google BigQuery, Databricks. Catalog federation: Hive metastore legado do Databricks, Hive metastore externo, AWS Glue metastore, Salesforce Data 360, Snowflake, Palantir Foundry, Workday Data Connect, Google Cloud Lakehouse.

8.2 O requisito que exclui os warehouses classic

Das páginas de federação MySQL e SQL Server (19 de agosto / 11 de setembro de 2026): "O compute do Databricks deve usar o Databricks Runtime 13.3 LTS ou superior e o modo de acesso Standard ou Dedicated"; "SQL warehouses devem ser pro ou serverless e devem usar 2023.40 ou superior"; o workspace deve ter o Unity Catalog habilitado (workspaces criados depois de 8 de novembro de 2023 têm). MySQL exige adicionalmente SSL. O pushdown é desigual por design: agregados, aritmética, booleano/bitwise e ordenação com limite descem em 13.3 LTS+; joins exigem DBR 17.2+ (no MySQL: um toggle em Public Preview); funções de janela não são suportadas no MySQL. E quando os dois caminhos existem: "Quando a sua fonte suporta tanto Lakehouse Federation quanto Lakeflow Connect, a Databricks recomenda Lakeflow Connect se desempenho em volumes maiores de dados e menor latência forem prioridades."

8.3 Exemplo resolvido E6: consulta federada, MySQL no RDS → Databricks SQL

A referência de linguagem (docs.../sql-ref-federated-queries, datada de 29 de junho de 2026) enquadra isso como exatamente três pré-requisitos: criar uma foreign connection, registrar foreign catalogs, conceder acesso, e observa que se aplica a "Databricks SQL · Databricks Runtime 13.3 LTS and above · Unity Catalog only". O join do passo 4 é a metade interessante: Delta local juntado ao MySQL remoto, com o lado remoto empurrado via JDBC e governado pelos mesmos grants das suas tabelas nativas. É somente leitura, não substitui ETL em volume, e o caminho de rede do seu warehouse até o RDS é seu para construir (VPC peering, PrivateLink ou VPN: seção 2.3).

---

9. Quem pode tocar no warehouse: ACLs, entitlements e o padrão de grupos

Permissões de warehouse, da matriz de ACLs (docs .../access-control, atualizado em 10 de julho de 2026) e da página de criação de warehouse (11 de setembro de 2026):

Duas entitlements ficam acima de tudo isso: a entitlement databricks-sql-access controla quem pode usar o Databricks SQL de forma alguida, e criar warehouses exige admin do workspace ou a entitlement Allow unrestricted cluster creation: "A maioria dos usuários não consegue criar SQL warehouses, mas pode reiniciar qualquer SQL warehouse ao qual possa se conectar." Warehouses apagados podem ser restaurados pelo suporte dentro de 14 dias.

O padrão de delegação a ensinar: data-analysts → CAN USE no warehouse de BI mais SELECT nos schemas gold; bi-viewers → CAN VIEW; data-engineers → CAN MANAGE no warehouse da plataforma e no seu auto-stop; service principals para Power BI/Tableau → CAN USE mais SELECT. Grupos, não indivíduos: caso contrário o CAN MANAGE em branco dos admins do workspace vira o único modelo que funciona, e a dispersão de admins vem junto.

---

10. Quanto custa: tarifas, medidores e a fatura em duas colunas

10.1 As tarifas (lista dos EUA, AWS, instantâneo de página 2026-10)

Ressalvas que você precisa imprimir ao lado de qualquer número: "Os preços do Databricks e da Infraestrutura de Nuvem podem variar conforme a região geográfica e o provedor de serviços de nuvem" (FAQ de preços, 2026-10); as tarifas serverless acompanham a infraestrutura regional, enquanto as tarifas classic são planas entre as regiões da AWS porque você paga o preço local do EC2 (uma leitura secundária do arquivo de dados da página de preços relatou $0.91/DBU para SQL Serverless em eu-central-1 contra $0.70 em us-east-1, 2026-08-07: confirme na conta); as atualizações de materialized views e de tabelas streaming são cobradas às tarifas DLT serverless, não à tarifa do seu warehouse (nota de rodapé 3 da página de preços, 2026-10); a inferência de AI Function é cobrada separadamente sob MODEL_SERVING / AI_FUNCTIONS (docs.../ai-functions, 9 de outubro de 2026). O número autoritativo é sempre o seu: system.billing.list_prices (retenção indefinida, global) cruzado com system.billing.usage.

10.2 Exemplo resolvido E7: um rascunho de custo mensal em duas colunas

Premissas declaradas: um warehouse 2X-Small (driver + 1 worker = 2 × i3.2xlarge), ligado por 193 h/mês (≈9.2 h/dia × 21 dias úteis de BI em horário comercial), emissão ilustrativa de 4 DBU/h, AWS us-east-1 sob demanda i3.2xlarge $0.624/h (lista de preços da AWS, lida em 2026-10-12), tarifas em 2026-10.

Leia como três lições, não como um ranking. (A) só é o mais barato se você aceitar início frio de ~4 minutos, sem Predictive IO, sem federação, sem AI Functions e sem criação de materialized views. (C) vence (B) aqui porque, nesta forma leve e estável, a coluna de EC2 do warehouse pro ($240.86) supera todo o prêmio de serverless ($540.40 − $424.60 = $115.80). E a linha de sensibilidade de (A) é a manchete real: são as horas ociosas, não as tarifas de lista, que dominam: ou seja, a aritmética de auto-stop da seção 4 aparecendo de novo na fatura. A cifra de 4 DBU/h é uma emissão ilustrativa por tamanho; a página de preços publica $/DBU apenas, então extraia a sua própria emissão por tamanho de system.billing.list_prices para o seu contrato antes de citar um número para alguém.

---

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

1. "Serverless roda na minha VPC." Roda na conta Databricks: "VPCs gerenciadas pelo cliente não se aplicam", sem cluster policies, sem IPs públicos.
2. "A API cria o mesmo warehouse da UI." Padrão da UI = serverless; padrão da API = classic, a menos que enable_serverless_compute seja true e warehouse_type seja PRO.
3. "Classic é a opção econômica." É também a opção que não pode federar, não pode criar MVs/STs e não pode rodar AI Functions.
4. "Um tamanho maior significa mais consultas concorrentes." Concorrência é max_num_clusters × 10; tamanho é poder por consulta. Spill → tamanho; fila → clusters.
5. "O autoscaler vai dar conta da rajada das 9h." Classic/pro escala para cima só depois de uma consulta esperar 5 minutos; o teto da fila é 1.000.
6. "Auto-stop de 45 minutos é inofensivo." "SQL warehouses ociosos continuam acumulando DBU e cobranças de instância na nuvem até serem parados."
7. "O auto-stop do serverless pode ser zero." Mínimo de 5 min na UI, 1 min via API; o mínimo de pro/classic é 10 min.
8. "Eu consegui um query profile, então entendi a execução." Não existe profile para um resultado em cache: mude o LIMIT.
9. "Cache é cache." Cache da UI (≤7 dias, não vale para AI/BI) ≠ cache local de resultados (morre com o cluster) ≠ cache remoto de resultados (exclusivo de serverless, sobrevive à parada) ≠ cache de disco (arquivos, ≤50% do SSD).
10. "Dashboards legados ainda funcionam." Fim do suporte em 2025-04-10: sem criação, sem clonagem, endpoint de migração deprecado.
11. "Lakeview é um produto diferente do AI/BI." Mesmo produto, nome do preview de 2023 mantido no caminho REST /api/2.0/lakeview/dashboards.
12. "Autenticação por senha funciona para o Tableau." A autenticação básica "reached end of life as of July 2024"; e a linha Simba ODBC está deprecada desde a renomeação de fevereiro de 2026.
13. "A federação me deixa gravar de volta." Somente leitura, pushdown JDBC com suporte desigual; use Lakeflow Connect quando volume e latência importam.
14. "A tarifa de $0.70 é a fatura inteira do serverless." Atualizações de MV são cobradas às tarifas DLT serverless, a inferência de IA sob MODEL_SERVING/AI_FUNCTIONS, e a rede até a sua VPC pode carregar cobranças próprias.

---

Veredito Comparativo: warehouses SQL classic vs pro vs serverless (AWS, em out de 2026)

• Classic, $0.22/DBU mais cobranças de instância na nuvem, início de ~4 minutos. O padrão da API e o piso da linha: só Photon, sem Predictive IO, sem IWM. Não pode federar, não pode criar materialized views nem tabelas streaming a partir do SQL, não pode rodar AI Functions. Roda na sua VPC com cluster policies, configurações de spot e o cache de disco no SSD local i3. Escolha quando a carga é SQL simples em forma estável, o custo por DBU é a restrição que decide e nenhum dos três recursos faltantes se aplica, e configure o auto-stop para 10 minutos, não 45.
• Pro, $0.55/DBU mais cobranças de instância na nuvem, início de ~4 minutos. Tudo que o classic tem mais Predictive IO, e a escolha documentada quando "você tem rede definida personalizada e quer se conectar a bancos de dados na sua rede", isto é, federação de dentro da sua VPC. Ainda são suas instâncias, seu Auto-AZ, suas políticas, sua coluna de EC2. Escolha quando o alcance da rede privada pesa mais que a latência do início frio.
• Serverless: $0.70/DBU, máquina incluída, início de 2 to 6 segundos. O padrão documentado para a maioria das cargas: Photon + Predictive IO + IWM, sem cluster policies (logo, sem guardrails baseados em política também), sem VPC gerenciada pelo cliente, sem IPs públicos, padrão de auto-stop de 10 minutos, cobrança por segundo sem cobrança por ociosidade além da janela de auto-stop. Escolha, a menos que alguma bifurcação do E1 diga o contrário.
• Veredito em uma linha: serverless por padrão → pro quando você precisa do compute dentro da sua conta AWS para federação ou rede personalizada → classic apenas para SQL estreito, estável e pobre em recursos onde $0.22 ganha a aritmética. Toda tarifa é lista dos EUA, AWS, instantâneo de página 2026-10; a emissão de DBU-por-hora por tamanho deve vir de system.billing.list_prices, não de um tutorial.

---

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

---

Casos Reais

📋 Caso A: NAB (National Australia Bank, bancos, Cloud: AWS) Desafio. Um data warehouse Teradata de 26 anos carregando ~1.000 casos de uso e ~140 suítes de relatórios, com ETL escrito à mão e prática inconsistente entre 300 to 400 engenheiros. Stack na AWS. Databricks SQL como substituto do warehouse, mais Auto Loader, Spark Declarative Pipelines (Lakeflow), Unity Catalog e asset bundles: Cloud: AWS na página da história. Resultado relatado. "26-year-old Teradata warehouse decommissioned · 456 Use cases migrated to Databricks SQL · 1,200+ Users enabled"; "95% of critical workloads migrated"; ~140 suítes de relatórios aposentadas (https://www.databricks.com/customers/nab/dbsql, página sem data, acesso em 2026-10). Citação. "A migração não teria sido possível sem o Databricks SQL": Gurry, mesma URL. Como mapeia para esta lição. Seções 3, 7 e 9: substituir um warehouse é uma racionalização de relatórios mais um exercício de dimensionamento/ACL: 1.200 usuários precisam de CAN USE por grupo, e 456 casos de uso precisam de um orçamento de concorrência na frota inteira, não de um warehouse gigante. ⏳ Nota temporal: página sem data, acesso em out de 2026: um resultado de cliente relatado, não uma garantia de 2026.

📋 Caso B: Punchh (fidelidade no varejo / tecnologia para restaurantes, Cloud: AWS) Desafio. AWS MySQL que cresceu demais, um warehouse caríssimo de manter, e relatórios Tableau lentos por joins de 12 tabelas executados do zero a cada relatório. Stack na AWS. Databricks SQL sobre tabelas Delta bronze/silver/gold, notebooks e Tableau por cima: Cloud: AWS na página da história. Resultado relatado. "10x Faster time-to-insight · 30% Lower operational costs · 12% Increase in customer satisfaction" (https://www.databricks.com/customers/punchh, página sem data, acesso em 2026-10; história com origem em 2021). Citação. "Quando você está juntando 12 tabelas em tempo real toda vez que um cliente roda um relatório, o custo de gerar o relatório pode ser alto. A Databricks não só aumentou o desempenho do ETL como reduziu os custos gerais": Phylis Savari, mesma URL. Como mapeia para esta lição. Seções 7 e 10, o padrão de BI externo na sua forma mais pura: Tableau via ODBC para um SQL warehouse, tabelas gold pré-joinadas fazendo o que um warehouse maior teria que resolver na força bruta. ⏳ Nota temporal: uma história com origem em 2021 ainda exibida em 2026: ensine o mecanismo, date as métricas.

📋 Caso C: nCino (software bancário, Cloud: AWS) Desafio. Consolidar 13 anos de dados bancários e "trillions in loan history" mantendo informações financeiras sensíveis sob controle total. Stack na AWS. Databricks na AWS com Unity Catalog e AI/BI Genie: Cloud: AWS; a lista de casos de uso traz Analytics and BI, AI, Data Warehousing, Governance and Security. Resultado relatado. "Manter os dados dentro de um único ecossistema AWS reduz a complexidade, reforça a conformidade e dá às equipes controle total sobre informações financeiras sensíveis"; "Com o Unity Catalog governando o acesso e o AI/BI Genie democratizando insights, executivos, analistas e gerentes de relacionamento todos se beneficiam de soluções de IA orientadas por domínio" (https://www.databricks.com/customers/ncino, página sem data, acesso em 2026-10). Como mapeia para esta lição. Seções 5 e 9: dashboards AI/BI mais o Genie como camada de serviço governada, com as duas portas (ACL do warehouse + grant do UC) fazendo o trabalho de conformidade. ⏳ Nota temporal: página sem data, acesso em out de 2026.

---

---

Perguntas de Prática (Practice Questions)