Otimização de Custo e Economia de DBU na AWS

Todas as outras lições deste curso constroem alguma coisa; esta mantém a fatura honesta. Um lakehouse de dados da Databricks na AWS gera duas faturas independentes: a Databricks cobra você em DBUs (Databricks Units, a licença da plataforma, medida por segundo) e a AWS cobra o EC2, EBS, S3, NAT e CloudWatch que estão por baixo. Esqueça qualquer um dos dois medidores e sua "otimização de custo" é ficção: a metade de DBU pode estar perfeitamente ajustada enquanto um NAT Gateway adiciona discretamente $0.045 por GB de tráfego do S3, e a metade da AWS pode ser toda spot enquanto um cluster all-purpose fica ocioso a $0.55/DBU o fim de semana inteiro.

A boa notícia é que o custo da Databricks é aritmética, não vibe. Toda taxa desta lição está datada de outubro de 2026 e rastreada até uma fonte primária ou documental: as páginas de preços e os arquivos page-data da Databricks (lidos em 2026-10), o registro de fornecedor UK G-Cloud 15 das taxas de lista de Jobs/All-Purpose (capturado em 2026-09-25), a documentação da Databricks para as tabelas de cobrança e o auto-stop (atualizada em 2026-09-11 / 2026-10-08), o AWS Price List para EC2/S3 (lido em 2026-10-12) e as páginas de preços da AWS para NAT, Spot e CloudWatch (lidas em 2026-10). Faça as contas você mesmo: é a única maneira de operar um lakehouse que ainda seja acessível no terceiro ano.

Nesta lição você vai:

• ler a tabela de preços de DBU de out-2026 por SKU de compute, jobs, all-purpose, SQL Classic/Pro/Serverless, Lakeflow pipelines, com a procedência de cada número explicada;
• aplicar as duas equações (clusters: nós × emissão × taxa × horas; warehouses: taxa do tamanho × tempo ligado) em cinco exemplos resolvidos à mão;
• tomar a decisão de break-even serverless vs classic com aritmética em vez de doutrina;
• configurar auto-stop, auto-termination, workers spot, instance pools e cluster policies como controles de custo, com os padrões documentados e seus mínimos;
• atribuir cada dólar com system.billing.usage, budgets e tags, e saber exatamente quais custos nunca aparecem lá;
• rodar o caso TCO mensal resolvido para um time de cinco pessoas (três pipelines, um warehouse de BI, S3/NAT/logs) e cortá-lo em 34.1% com três alavancas;
• pesar o Veredito Comparativo: DBUs vs créditos do Snowflake vs os $5/TB escaneados do Athena;
• estudar histórias nomeadas de custo de clientes na AWS (Addepar, Nubank, Comcast), ler a caixa de atualização de 2026 e praticar com doze questões mais cinco verificações interativas.

---

1. Duas faturas, não uma: o modelo de custo da Databricks na AWS

1.1 O que é um DBU

A própria definição da Databricks: "A Databricks cobra com base em unidades Databricks (DBUs), que são unidades de capacidade de processamento por hora com base no tipo de instância de VM" (docs.databricks.com/aws/en/getting-started/concepts, data do doc 2026-09-25). A página de preços diz o contrário: "A Databricks Unit (DBU) é uma unidade normalizada de poder de processamento na Databricks Lakehouse Platform usada para fins de medição e precificação" e "Pague apenas pelos produtos que você usa, com granularidade de segundo" (databricks.com/product/pricing, lida em 2026-10).

Três consequências decidem tudo o que segue:

1. Para compute de cluster, consumo de DBU = (nós) × (DBU/h daquele tipo de nó) × horas, o blog de gestão de custos de 2022 diz isso sem rodeios: "Com exceção de um SQL Warehouse, a quantidade de DBUs consumida se baseia no número de nós e no poder computacional dos tipos de instância de VM subjacentes" (databricks.com/blog/best-practices-cost-management-databricks, 2022-10-18; a aritmética continua valendo nas taxas de out-2026).
2. Para SQL warehouses, consumo de DBU = (o DBU/h fixo do tamanho) × horas em que o warehouse está ligado: rodando ou não, o medidor gira enquanto o warehouse está ativo (docs de preços, lidos em 2026-10).
3. O medidor é por segundo, e ele não sabe se você está trabalhando. Um cluster all-purpose ocioso e um que está processando emitem DBUs na mesma taxa. É por isso que tempo ocioso, e não velocidade de consulta, é o problema central de otimização de custo em compute classic.

1.2 Os dois medidores

Serverless custa a máquina dentro de uma taxa de DBU mais alta. SQL Serverless a $0.70/DBU contra SQL Classic a $0.22/DBU (databricks.com/product/pricing/databricks-sql, instantâneo de página 2026-10) é um prêmio de $0.48 por DBU-hora que paga a frota, a operação e o tempo ocioso que você deixou de possuir. Jobs Serverless $0.35 menos Jobs Classic $0.15 é o mesmo quadro a $0.20 por DBU-hora. Classic não é grátis: ele só move metade da fatura para a AWS, onde você pode atacá-la com spot e right-sizing.

⚠️ system.billing.usage não é sua fatura total. A Databricks é explícita: "O system.billing.usage contém apenas custos da Databricks. Isso significa que em qualquer caso em que compute não-serverless está sendo usado, o gasto com infraestrutura de nuvem não está incluído e precisaria ser revisado pelo console de nuvem relevante (compute, rede, armazenamento etc.)" (databricks.com/blog/top-5-system-table-queries-understanding-your-databricks-costs, 2026-09-22). Um budget só de Databricks subconta o número real pela coluna inteira da AWS.

• 📚 Você sabia? A Databricks mede DBUs por segundo (FAQ de preços, lido em 2026-10), enquanto o Snowflake cobra créditos "por segundo com mínimo de 60 segundos" (visão geral de warehouses do Snowflake + tabela de consumo de serviço, lida em 2026-10). Em jobs curtos e frequentes, essa diferença de 55 segundos é uma linha de conta real: um dos motivos discretos pelas quais cargas de trabalho em rajada preferem jobs Databricks serverless a uma frota classic sempre retomada.

1.3 A tabela de preços de out-2026 (AWS, regiões dos EUA, tier Premium, lista)

Leia a coluna de procedência antes de citar uma taxa. Os valores de SQL e Lakeflow Pipelines vêm das próprias superfícies de preços da Databricks (instantâneos de página e o arquivo page-data do site de preços). Os valores de Jobs e All-Purpose são documentais e corroborados, o registro público de fornecedor UK G-Cloud 15 (uma declaração legal da Databricks Inc.) mais seis leituras independentes de 2026 que concordam entre si, porque o databricks.com renderiza esses cartões no cliente. Trate todo valor como lista dos EUA, tier Premium: o FAQ de preços afirma "Os preços da Databricks e os preços da Infraestrutura de Nuvem podem variar conforme a região geográfica e o provedor de serviços de nuvem" (lido em 2026-10), e a verdade dentro da conta vive em system.billing.list_prices (o preço do seu contrato).

Duas regras práticas com respaldo oficial:

• Mesmo pipeline, all-purpose vs jobs = 3.7× a taxa por DBU ($0.55 ÷$0.15 ≈ 3.7): antes de você contar um único minuto ocioso.
• Serverless custa ~1.3×: 2.3× mais por DBU que o classic para a mesma família de SKU, e remove junto a fatura de EC2, a gestão de pools e o tempo ocioso.

Efeito de região: as taxas classic são planas entre as regiões da AWS porque você paga o preço local do EC2 separadamente; as taxas serverless acompanham a infraestrutura regional: SQL Serverless $0.70 em us-east-1 contra $0.91 em eu-central-1 (leitura de hejlsvigconsulting.com do arquivo de dados de preços, 2026-08-07). Uma cotação dos EUA nunca se transfere para Frankfurt.

1.4 Exemplo resolvido E1: a equação básica e uma fatura combinada

O próprio padrão resolvido do blog de gestão de custos de 2022, reprecificado na taxa Premium de jobs de hoje (blog, 2022-10-18; lista de preços do EC2, us-east-1, lida em 2026-10-12):

Essa última linha é o número que você vai reusar a lição inteira: $0.214 all-in por DBU-hora em jobs classic contra $0.35 de jobs serverless, é por isso que o classic vence em formas quentes, longas e previsíveis, e o serverless vence em formas curtas, em rajada ou erráticas (seção 3). A ressalva que o próprio blog implica: pareie a taxa de emissão do seu tipo de nó com o preço de EC2 daquele tipo de nó, e leia ambos na calculadora de preços ou em system.billing.list_prices, o par 3 DBU/hr + m5.xlarge acima é ilustrativo, não é uma forma pareada.

---

2. A escada de SKU: sua alavanca de precificação mais poderosa

Antes de ajustar uma única consulta, verifique se a carga de trabalho está no SKU certo. A escolha de SKU é grátis, instantânea e, segundo os próprios relatos de campo da Databricks, vale mais que a maior parte do trabalho de performance.

2.1 Os três crimes da escada

1. Um pipeline em compute all-purpose. Um job apontado para um cluster all-purpose existente é cobrado nas taxas de All-Purpose e marcado como uma carga de trabalho interativa (Jobs API 2.0; digest 06, lido em 2026-10). A Databricks "não recomenda essa configuração para jobs de produção." A diferença de taxa sozinha é de $0.55 →$0.15 por DBU.
2. O tier Standard aposentado no seu runbook. Jobs a $0.10/DBU era o Standard; workspaces Standard da AWS/GCP foram atualizados para Premium em 2025-10-01 (Azure 2026-10-01) conforme a página de preços (lida em 2026-10). Qualquer tabela de taxas anterior a 2025 que você copiar está desatualizada em 50%.
3. Confusão Premium-vs-Enterprise entre clouds. O "Premium" da AWS/GCP é o cartão "Enterprise" do Azure: Jobs na AWS é $0.15 Premium / $0.20 Enterprise (uma diferença de 33%) e todo SKU serverless se move junto (registro G-Cloud 2026-09-25; licenseware 2026-10-06). Sempre rotule a cloud e o tier.

2.2 Exemplo resolvido E2: um pipeline, um mês, all-purpose vs jobs

O mesmo pipeline de 12 DBU/hr, 400 horas de cluster por mês, os mesmos 4 × m5.xlarge no lado da AWS (taxas em out 2026):

Um pipeline. Um dropdown na definição do job. O próprio resumo da Databricks sobre a versão em toda a base: "Vimos clientes que economizaram dezenas de milhares de dólares simplesmente movendo apenas dez por cento de suas cargas de trabalho de clusters all-purpose para job clusters" (blog de gestão de custos, 2022-10-18: fonte antiga, aritmética inalterada).

• 📚 Você sabia? Atualizações de materialized view são cobradas como uso de pipeline serverless, não como uso de warehouse, então uma aba de custo de "warehouse" não vai mostrá-las (blog da Databricks, 2026-10-07). O predictive optimization está ligado por padrão para contas criadas em ou depois de 2024-11-11, e ele também é cobrado sob registros de uso serverless. Se suas consultas de atribuição agrupam apenas por warehouse, esses dois SKUs são vazios invisíveis.

---

3. Serverless vs classic: a aritmética de break-even

"Serverless é 4× mais caro" é a frase mais cara das discussões de custo da Databricks, porque compara taxas de DBU enquanto ignora a coluna da AWS no lado classic. A comparação honesta é o all-in por DBU-hora emitido.

Três leituras práticas:

• O classic vence quando o cluster roda quente e longo em uma forma previsível: janelas de ETL batch, backfills noturnos grandes, treino de ML com contagem de nós conhecida. Você já está pagando cerca de $0.192/h por um m5.xlarge (lista de preços do EC2, lida em 2026-10-12); o classic dobra isso em uma licença de $0.15/DBU em vez de um pacote de $0.35/DBU.
• O serverless vence em trabalho curto, em rajada, interativo ou imprevisível, dashboards com intervalos entre refreshes, notebooks ad-hoc, jobs orientados a eventos, porque "você não é cobrado enquanto ele está ocioso" (Databricks Answers, 2026-08-27) e a frota, o patching e o planejamento de capacidade desaparecem.
• As restrições operacionais pesam tanto quanto o preço. Jobs serverless têm tempo máximo de execução documentado de 7 dias, sem tarefas JAR/Spark-Submit, sem notebooks R/Scala, sem APIs RDD, sem instance profiles, e gatilhos de Structured Streaming limitados a Trigger.AvailableNow() (recomendado): enquanto o classic existe justamente onde essas restrições apertam (digest 06, docs lidos em 2026-10). Migrate o padrão (volumes em vez de DBFS, DataFrame API em vez de RDDs) antes de virar o SKU.

---

4. Tempo ocioso: auto-stop, auto-termination e a regra de cobrado-enquanto-ligado

A própria frase da Databricks sobre warehouses: "SQL warehouses ociosos continuam acumulando DBU e cobranças de instância de nuvem até serem parados" (docs.databricks.com/aws/en/compute/sql-warehouse/create, última atualização 2026-09-11). Não existe maneira mais branda de dizer isso: um warehouse que está ligado é um warehouse que é cobrado. Dez horas deixadas ligadas para quarenta minutos de dashboards cobram dez horas.

4.1 Os padrões documentados (em out 2026)

Duas sutilezas. Primeiro, os padrões de auto-stop diferem por um fator de 4.5 entre classic/Pro (45 min) e serverless (10 min): se seus dashboards dão refresh a cada 20 minutos, o padrão classic garante que você pague por 25 minutos ociosos após cada sessão. Segundo, autotermination_minutes = 0 (desativado) é um valor legal de API e a fonte mais comum de gasto descontrolado de fim de semana; uma policy imposta vence uma varredura manual semanal (seção 6.3).

4.2 Exemplo resolvido E4: aritmética de auto-stop no warehouse de BI

Do caso TCO mensal da seção 9: um SQL warehouse serverless que atende o BI fica ligado 10 horas por dia por 21 dias úteis (210 horas, 2,520 DBU com uma emissão de camiseta assumida de 12 DBU/h). O uso medido mostra que os dashboards realmente consultam em uma janela de 6 horas:

Nenhuma consulta foi reescrita. Nenhum dado foi movido. O warehouse simplesmente não foi deixado ligado. (A cifra de 12 DBU/h é a emissão de camiseta Small assumida por este caso: os tamanhos de medidor por camiseta de warehouse não são publicados como tabela oficial, então leia o seu em system.billing.list_prices na sua conta antes de reusar a aritmética.)

4.3 Exemplo resolvido E5: uma policy de auto-stop / auto-termination imposta

Cluster policies são conjuntos de regras JSON gerenciados por admin sobre atributos da Clusters-API, cujos benefícios incluem "controle de custo via atributos que dirigem o preço" (docs, lidos em 2026-10). A referência de policies (lida em out 2026) documenta o caminho do atributo autotermination_minutes e um range virtual de dbus_per_hour que atua como um teto duro de DBU; a restrição de node-type é igualmente uma capacidade de policy. Uma policy mínima de guardrail de custo para um workspace de time:

A mecânica que faz isso ser um guardrail e não uma sugestão: uma limitação por atributo; compute criado por API ignora os valores padrão da policy a menos que apply_policy_default_values: true seja definido; spark_version: auto:latest-lts só resolve quando o compute é editado, não continuamente; e o entitlement Unrestricted contorna tudo, então ele "deve ser suprimido para usuários não-admin" (orientação de onboarding de policy, blog 2025-04-17). A grafia das chaves de atributo varia entre superfícies de API: confirme-as no editor de policies do seu workspace antes de depender deste JSON literalmente.

⚠️ Budgets e policies monitoram e restringem; eles não param um gastador determinado. Budgets são "monitoramento e alertas, não um teto rígido" (doc de budgets, atualizada em 2026-10-07): um usuário com permissões suficientes ainda pode criar um warehouse que roda além do tempo ou fica escalado além do esperado. O próprio enquadramento da Databricks: "Bons controles via compute policies, configurações de timeout de job e budgets ajudam os administradores da plataforma Databricks a manter o gasto dentro de limites, mas sempre existe a possibilidade de um usuário com permissões suficientes criar um job ou warehouse que roda além do tempo ou fica escalado além do esperado e causa um pico inesperado de gasto" (blog das top-5 consultas de system table, 2026-09-22). Guardrails são em camadas ou são teatro.

---

5. Spot na AWS: o que ele economiza e o que ele nunca toca

Spot Instances da AWS "economizam até 90% nos preços sob demanda" (aws.amazon.com/ec2/spot, lido em 2026-10), e a AWS emite um aviso de interrupção de dois minutos antes de parar ou terminar uma instância Spot (docs do EC2 da AWS, lidos em 2026-10). Na Databricks a regra de topologia é fixa: quando você marca spot, "o driver node é sempre on-demand, as instâncias seguintes serão spot" (doc de configuração de compute, atualizado em 2026-10-06).

5.1 Exemplo resolvido E6: aritmética de spot, e a coluna que ele nunca toca

Cinco workers m5.xlarge por 200 horas por mês (lista do EC2, us-east-1, lida em 2026-10-12):

Quatro fatos operacionais para precificar no design: o driver continua sob demanda (docs de compute 2026-10-06); a evicção de dois minutos chega no meio da task, então pipelines precisam de estágios reiniciáveis e idempotentes (docs da AWS 2026-10), o gatilho AVAILABLE_NOW e o Structured Streaming com checkpoint das lições 05 e 13 são os padrões compatíveis; pools são todos-spot ou todos-sob-demanda (a API adiciona SPOT_WITH_FALLBACK), e a orientação da Databricks é "Não use um pool com spot instances como o seu driver type"; e spot não economiza nada em serverless, serverless é embutido, e nenhuma fonte afirma que descontos de EC2 spot fluem para as taxas de DBU serverless.

• 📚 Você sabia? Spot pode economizar até 90% e ainda ser a decisão errada para um job de 20 minutos com SLA estrito: a orientação atual da Databricks pareia pools spot para cargas de trabalho tolerantes a custo com pools sob demanda para jobs curtos e de SLA estrito, e recomenda serverless em vez de pools sempre que a carga de trabalho suportar (docs, lidos em 2026-10). Spot é uma decisão de carga de trabalho, não um interruptor de economia para a conta inteira.

---

6. Right-sizing, autoscaling, pools e desempenho-como-custo

6.1 Right-sizing do warehouse (a alavanca proporcional)

Para um warehouse, o custo de DBU é taxa do tamanho × tempo ligado, então um tamanho de camiseta para baixo é um corte proporcional de DBU por cada hora em que o warehouse está ligado: a economia linear mais limpa da plataforma. A escada classic/Pro é construída sobre workers i3.2xlarge (2X-Small = 1 worker, dobrando até X-Large = 32, até 4X-Large = 256) com "um cluster para cada 10 consultas concorrentes" como regra de concorrência (docs, lidos em 2026-10). Dimensione para a concorrência que você atende, não para o pico que você já viu; adicione clusters (autoscaling no nível do warehouse) em vez de inflar a camiseta para uma fila que esvazia em minutos.

6.2 Autoscaling, pools e AVAILABLE_NOW

• Autoscaling encolhe o pico. Autoscaling otimizado (Premium+) vai de min→max em ≤2 eventos de resize, escala para baixo em uma janela de subutilização de 40 segundos para compute de jobs e 150 segundos para all-purpose (docs, atualizados em 2026-10-06). Nunca combine isso com spark.dynamicAllocation.enabled: os docs alertam sobre churn de executores e NODES_LOST.
• Pools custam zero DBUs enquanto ociosos, e AWS cheio enquanto ociosos. "A Databricks não cobra DBUs enquanto as instâncias estão ociosas no pool. A cobrança do provedor de instâncias se aplica" (melhores práticas de custo, 2026-09-11). Dimensione min_idle_instances e idle_instance_autotermination_minutes deliberadamente; mantenha o tamanho máximo do cluster ≤ max_capacity do pool, ou o scale-out falha com INSTANCE_POOL_MAX_CAPACITY_FAILURE.
• AVAILABLE_NOW dá forma ao pipeline. Rode um pipeline acionado (Trigger.AvailableNow()) em um job cluster que termina ao concluir, em vez de um cluster contínuo que fica ocioso entre micro-batches: a lista oficial de alavancas recomenda isso (melhores práticas, 2026-09-11).

6.3 Photon como alavanca de custo (com cuidado)

Photon é o engine vetorial em C++ que "substitui o engine de execução Spark SQL baseado no JVM" enquanto o Catalyst ainda planeja a consulta (docs do Photon, atualizados em 2026-09-11). A história de custo dele é segundos faturáveis, não desconto: terminar mais cedo significa menos segundos medidos por segundo, mas o Photon também "consome DBUs a uma taxa diferente da mesma tipo de instância rodando o runtime não-Photon", então "Photon é mais rápido" nunca implica "Photon é mais barato" (docs; faça benchmark da sua própria carga de trabalho). Ele acelera SQL, ETL com DataFrame e streaming stateless, e não acelera corpos de UDF Python, RDDs, Datasets nem streaming stateful, consultas abaixo de ~2 segundos não veem ganho significativo (docs, 2026-09-11). Photon está ligado por padrão em serverless, SQL warehouses e na UI; clusters criados por API precisam definir runtime_engine: "PHOTON" explicitamente (lição 06).

6.4 O loop de quatro estágios

O próprio enquadramento da Databricks para controlar gasto (Databricks Answers, lido em 2026-10):

A maioria dos times inverte essa ordem e começa no estágio 4: reescrevendo consultas enquanto um cluster all-purpose ocioso cobra $0.55/DBU no canto. Os estágios 1 e 2 são baratos (os dados do medidor já estão na sua conta); o estágio 3 é configuração; só o estágio 4 é engenharia.

---

7. Atribuição de custo: system tables, budgets e o console da AWS

7.1 system.billing.usage: todo DBU tem um endereço

A system table de cobrança (docs, atualizados em 2026-10-08) traz, entre outros: account_id, workspace_id, workspace_name, region, billable_usage_timestamp, billing_origin_time, billing_month, cloud, sku, usage_type, product_feature, record_type, run_as, metered_quantity, list_price, unblended_cost, databricks_contract_quantity, aws_public_list_price e tags. As três que fazem o trabalho em toda consulta de atribuição:

• sku / usage_type / product_feature: que tipo de compute (jobs vs all-purpose vs SQL vs pipelines serverless);
• run_as: se o run foi interativo, um job, serverless e assim por diante;
• tags / workspace_name: de quem é.

record_type separa linhas de uso de linhas de preço, e a Databricks entrega joins prontos para system.billing.list_prices e system.compute.clusters, mais instruções para publicar o resultado em um dashboard AI/BI e levantar um alerta (docs, 2026-09-11). Também existe um Usage Dashboard pronto (blog, 2026-09-22): comece por ele antes de escrever SQL.

7.2 Exemplo resolvido E7: a auditoria de "cortar a fatura" em SQL

Classifique a saída e trabalhe de cima para baixo na lista de alavancas: (1) clusters all-purpose ociosos e a configuração de auto-termination deles → (2) warehouses com auto-stop "never" ou 45 minutos atendendo dashboards de 20 minutos → (3) cargas de trabalho em All-Purpose que na verdade são jobs → (4) um tamanho para baixo / autoscaling → (5) spot para workers → (6) pool nos nós quentes → (7) lifecycle do S3 + um gateway endpoint → (8) budgets + alertas para isso não regenerar. Duas tabelas de apoio fecham o loop: system.billing.list_prices (os preços do seu contrato, o substituto dentro da conta de qualquer tabela pública de taxas) e system.compute.warehouse_events para forense do ciclo de vida dos warehouses.

7.3 Budgets, tags e o lado da AWS

Budgets (doc, atualizada em 2026-10-07): até 1,000 budgets por conta, cada um com até 4 thresholds (%), expressos em USD ao preço de lista incluindo add-ons (sem descontos/créditos aplicados), com escopo por time/projeto/workspace com filtros, criados por admins de conta (admins de workspace para budgets com escopo de UC). De novo: budgets monitoram, não limitam.

Tags são a junta entre as duas faturas, com uma pegadinha. Tags da Databricks e tags customizadas impostas via compute policies e serverless usage policies caem em system.billing.usage (blog, 2026-09-22), e a propagação de tags para recursos de nuvem é o caminho documentado para a atribuição do lado da AWS (melhores práticas, 2026-09-11). Mas uma tag team definida apenas em um cluster Databricks não se torna por si só uma tag de alocação de custo da AWS; e tags não fazem backfill, a dimensão CostCenter da fatura da AWS só existe a partir do dia em que você a cria. No lado da AWS, o Cost Explorer mantém "até os últimos 13 meses" de histórico e projeta "os próximos 18 meses" (docs da AWS, lidos em 2026-10).

• 📚 Você sabia? As novas query tags (Public Preview) caem em system.query.history, o dbt-databricks 1.11.0 adiciona auto-tagging, e uma Governance Hub Cost page (Beta) agrega a superfície de gasto (blog da Databricks, 2026-10-07). O RBI reconstruiu monitoramento e previsão de custo sobre as system tables e relatou isso rodando 3 to 4× mais rápido do que o processo anterior (mesmo blog): os dados do medidor já estão na sua conta; o dashboard é a parte barata.

---

8. O lado AWS da fatura: EC2, EBS, S3, NAT, CloudWatch

As ofertas do AWS Price List (us-east-1; EC2 lido em 2026-10-12, oferta do S3 publicada em 2026-09-28) e as páginas de preços da AWS (lidas em 2026-10):

Três vazios discretos vivem nesta tabela. Processamento de dados da NAT no tráfego do S3: cada list/get do S3 por um NAT Gateway custa $0.045/GB mais $0.045/h, enquanto um gateway endpoint do S3 é grátis, a correção de rede mais barata da AWS (a seção 9 a usa). CloudWatch a $0.50/GB ingerido é o preço de deixar os logs do driver e do cluster rodarem sem gestão. E o desperdício de armazenamento compõe silenciosamente: a própria orientação de custo da Databricks cita um bucket de cliente de 2.5 PB onde só 800 TB eram dados reais e 1.7 PB eram versões antigas de objetos, a $0.023/GB-month isso dá cerca de $39,000 por mês de puro desperdício, deletável por uma regra de lifecycle do S3 sem tocar um único DBU (blog de gestão de custos, 2022-10-18; taxa do S3 da oferta de 2026-09-28).

---

9. O caso TCO mensal: $3,011 →$1,985 em três alavancas

9.1 Premissas declaradas (AWS us-east-1, lista, out 2026)

Um time de dados de cinco pessoas: 21 dias úteis; um cluster de dev all-purpose compartilhado (4 × m5.xlarge, emissão 12 DBU/h: a aritmética ilustrativa de nós do E1: ligado 6 h/dia); 3 pipelines em jobs compute (4 nós, 0.5 h/dia cada, 30 dias); BI em um SQL warehouse serverless medido em 2,520 DBU no mês (10 h/dia × 21 dias com uma emissão de camiseta assumida de 12 DBU/h: confirme a taxa do tamanho em system.billing.list_prices); 5 TB no S3; 500 GB de processamento de NAT; 60 GB de logs para o CloudWatch.

9.2 O quadro antes

9.3 Três alavancas com fonte

Leia o gráfico de cima para baixo e a estratégia aparece: a linha do BI é a baleia (59% da fatura original) e cai 40% com uma única configuração de auto-stop; o cluster de dev cai 33% com auto-termination; os pipelines mal se movem porque já estavam no SKU mais barato (jobs) com ociosidade estrutural zero. O gráfico de cada conta é diferente: é exatamente por isso que o passo de atribuição da seção 7 vem antes de qualquer otimização.

---

10. Armazenamento, disposição e scan: as alavancas que não tocam nenhuma taxa de DBU

• Higiene de lifecycle e versionamento do S3, o exemplo de desperdício de versões de $39,000/mês da seção 8 é o modelo: regras de lifecycle deletam ou fazem tier de versões antigas de objetos nas taxas do S3 ($0.023/GB-month, oferta de 2026-09-28) e nunca tocam um DBU.
• OPTIMIZE, liquid clustering e particionamento (lições 04 e 14): menos bytes escaneados por consulta significam menos segundos faturáveis em um medidor por segundo, e o autoscaling baseado em carga vê menos picos.
• Propagação de tags para recursos de nuvem (melhores práticas, 2026-09-11): sem ela, o lado da AWS da fatura não pode ser dividido por time.
• NAT → gateway endpoint para S3 (seção 9) e right-sizing da retenção de logs do CloudWatch, a $0.50/GB ingerido.
• O anti-padrão de BI: a intuição por TB não se aplica na Databricks, o warehouse cobra tempo × forma, então um SELECT * que re-escaneia 400 GB cem vezes por dia cobra os mesmos DBUs por janela de scan… até que o trabalho extra alonge o tempo de execução, dispare o autoscaling baseado em carga para mais clusters e empurre o warehouse para uma camiseta maior. O custo aparece como forma, não como bytes.

---

11. Prova do mundo real: o que as alavancas entregaram para os clientes

Resultados documentados de clientes (todos do blog de budgets/alertas da Databricks, 2026-10-07, salvo indicação):

• Lumen migrou relatórios baseados em Looker para SQL warehouses serverless e relatou custos de compute 30 to 40% menores com consultas ~90% mais rápidas contra ~7 GB escaneados a cada 10 minutos: a economia veio de eliminar tempo ocioso de warehouse classic e a fatura de EC2, não de um desconto.
• GetYourGuide rodou o mesmo padrão de migração em serving de BI e relatou custos ~20% menores com consultas ~35% mais rápidas.
• RBI reconstruiu monitoramento e previsão de custo sobre as system tables e relatou 3 to 4× mais rápido do que o processo anterior.

As faixas de praticantes ao redor desses números são consistentes: vitórias rápidas de configuração (migração para jobs compute, auto-termination, workers spot, desligar warehouses ociosos) são relatadas na faixa de 20 to 40% em semanas (DataLane, 2026-04-08; SELECT, 2026-07-16; Cyfra Dane, 2026-07-15: posts escritos por consultores, ou seja, alegações de fornecedor). Tudo além dessa faixa é redesenho de carga de trabalho, não configuração.

Veredito Comparativo: Databricks (DBU) vs Snowflake (créditos) vs nativo da AWS (Athena, $/TB escaneado)

• Medidores. A Databricks cobra DBU/h da forma mais, no classic, a fatura de EC2, dois medidores, as alavancas mais expostas (jobs 0.15 · all-purpose 0.55 · SQL 0.22/0.55/0.70 por DBU, lista de out 2026). O Snowflake cobra créditos com a máquina embutida, X-Small = 1 crédito/hora, dobrando por tamanho (Small 2, Medium 4, Large 8, X-Large 16), por segundo com mínimo de 60 segundos, a $2.00 Standard / $3.00 Enterprise / $4.00 Business Critical por crédito na AWS US East (tabela de consumo de serviço do Snowflake + FAQ da calculadora, lida em 2026-10). O nativo da AWS, representado pelo Athena, cobra dólares por TB escaneado, os exemplos oficiais precificam consultas em $5/TB com mínimo de 10 MB por consulta (aws.amazon.com/athena/pricing, 2026-10), zero custo ocioso, mas orquestração, estado e governança são seus.
• Ociosidade. O classic da Databricks cobra EC2 (e DBUs) enquanto está ligado: auto-stop de 45/10 min, auto-termination e pools são a defesa. O Snowflake auto-suspend para zero. O Athena não tem ociosidade alguma. Se você deixar o compute da Databricks ligado, ele é o mais caro dos três; se você o vigiar, o compute de jobs é o medidor de engenharia de longa duração mais barato.
• Ilustração (168 h = 8 h × 21 d; tamanhos de medidor assumidos como camisetas, confirme dentro da conta): SQL Serverless Small 12 × 168 × $0.70 = $1,411.20; SQL Classic 2X-Small 4 × 168 × $0.22 = $147.84 + máquina; Snowflake X-Small 168 × $2 = $336 (Standard) e Large 168 × 8 × $2 = $2,688; Athena 1 TB/dia × 30 = 30 TB × $5 = $150. Mesmo time, mesmos dados, três medidores, o número depende de qual medidor você esqueceu de vigiar.
• Veredito. Athena vence cargas raras, leves em scan e de forma serverless, e perde no momento em que você precisa de estado de ETL, streaming ou ML. Snowflake tem a fatura mais simples (um medidor, que para sozinho) e é difícil de vencer para BI elástico nos tamanhos X-Small: Large. Databricks é o mais caro se deixado ocioso e o mais econômico para engenharia de longa duração + ML em jobs compute, porque as alavancas: escolha de SKU, auto-termination, spot, pools, atribuição por system table: ficam expostas no nível da carga de trabalho. Escolha o medidor que você está disposto a operar.

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

---

Casos Reais

📋 Caso A: Addepar (gestão de wealth, Cloud: AWS): $2 milhões a menos em infraestrutura, entrega 5× mais rápida Desafio. Times de engenharia e de dados em silos; entrega lenta de pipelines; custo de infraestrutura crescente em uma plataforma que modela mais de $8 trilhões em investimentos. Stack na AWS. Databricks rodando na AWS, Unity Catalog, notebooks compartilhados, Databricks SQL: Cloud: AWS na página da história. Resultado relatado. "A Addepar modela mais de $8 trilhões em investimentos na Databricks rodando na AWS. Notebooks compartilhados, Unity Catalog e acesso colaborativo a dados unem os times de engenharia e de dados em um só lugar, acelerando a entrega de pipelines em 5x e cortando custos de infraestrutura em $2 milhões." (https://www.databricks.com/customers/addepar/aws, página sem data, acessada em 2026-10). Ângulo da lição. A clássica história de que "unificação é a estratégia de custo": uma plataforma compartilhada em uma única escada de SKU substituiu stacks duplicados, e a métrica de colaboração e a métrica de gasto se moveram juntas. Mapeamento principal: esta lição (L15), secundária L11.

📋 Caso B: Nubank (fintech LATAM, armazenamento em AWS S3): +40% de economia anual de custo enquanto o volume de consultas dobrou Desafio. Uma base altamente regulada e em rápido crescimento (100MM+ de clientes) precisando de eficiência de custo e continuidade através de uma migração de plataforma de warehouse de 12 meses. Stack. Databricks SQL e Unity Catalog; a camada de armazenamento "mostly is based on AWS in S3" (transcript do Databricks Answers, 2026-08-27). Resultado relatado. "Zero-downtime durante todo o período de migração de 12 meses … Escala bem-sucedida da plataforma para absorver 100% de crescimento de consultas (20MM para 40MM de consultas mensais) … 17k usuários globalmente … +40% de economia anual de custo … Uso de UC para governança centralizada de dados em uma indústria FSI altamente regulada" (https://www.databricks.com/dataaisummit/session/how-nubank-migrated-databricks-sql-reducing-costs-40-and-doubling, página de sessão sem data, acessada em 2026-10). Ângulo da lição. Custo por consulta, não gasto total, é a métrica honesta: gasto total praticamente estável enquanto o volume dobrou é uma redução de custo unitário da classe de 50% obtida ao migrar para o medidor certo (Databricks SQL) com governança (UC) acoplada. Mapeamento principal: L15; secundária L08 e L11.

📋 Caso C: Comcast (comunicações e mídia, Cloud: AWS): redução de custo de compute de 10×, 640 máquinas → 64 Desafio. Petabytes de telemetria e bilhões de interações de voz de 20MM+ de remotes de voz; pipelines frágeis; dor de ingestão de arquivos pequenos; centenas de modelos implantados em cloud, on-prem e edge. Stack na AWS. Databricks, Delta Lake (ingest/enrich/optimize de arquivos pequenos), MLflow gerenciado, autoscaling + spot instances, notebooks; Tableau a jusante: Cloud: AWS na página da história; listado entre clientes "already leveraging Databricks on AWS" (press release, 2022-05-10). Resultado relatado. "10x Reduction in overall compute costs to process data · 90% Reduction in required DevOps resources"; "Delta Lake has enabled Comcast to optimize data ingestion, replacing 640 machines with 64 while improving performance"; implantação de modelos "weeks to minutes" (https://www.databricks.com/customers/comcast, página sem data, origem da história 2019, acessada em 2026-10). Ângulo da lição. A otimização mais barata é estrutural: o manejo de arquivos do Delta colapsou a frota em 10× antes de qualquer ajuste de taxa ou de tempo ocioso, e as spot instances atacaram depois a coluna restante da AWS. Ensine as métricas como o que a Comcast relatou na época (história de 2019), não como capacidade atual da plataforma. Mapeamento principal: L14; secundária esta lição.

📋 Caso D: Lumen e GetYourGuide (da seção 11): SQL serverless como corte de custo A migração do Looker para serverless da Lumen cortou o SQL compute em 30 to 40% com consultas ~90% mais rápidas; a GetYourGuide cortou o serving de BI em ~20% com consultas ~35% mais rápidas (blog da Databricks, 2026-10-07). Ambas as economias são histórias de tempo ocioso e eliminação de frota: a mesma aritmética do exemplo resolvido E4, em escala de enterprise.

---

Perguntas de Prática (Practice Questions)