TL;DR
A otimização de custos no Databricks se resume a cinco hábitos: saber de onde o custo realmente vem (a taxa de DBU mais uma fatura separada de infraestrutura de nuvem), eliminar computação ociosa com encerramento automático e timeouts, fazer o right-sizing da computação adotando serverless como padrão e reservando a computação clássica para seus workloads mais caros, repensar os workflows em torno da frequência de execução e do processamento incremental, e consolidar configurações de storage e governança para que os ganhos não se percam com o tempo. Números reais do webinar: um cluster de GPU sem monitoramento adicionou US$ 4.000 a uma fatura mensal de US$ 20.000 antes que alguém percebesse, e reduzir a frequência de execução de um job de 472 vezes por dia para uma vez por hora economizou 95% do custo, cerca de US$ 19.000 por ano.
Por que os custos do Databricks são difíceis de controlar
O Databricks dá às equipes de dados uma liberdade incomum. Você pode executar o mesmo pipeline como cluster interativo, job agendado ou job serverless, em computação clássica ou serverless, com uma dúzia de tipos de nós e configurações de escalonamento diferentes no meio do caminho. Essa flexibilidade é exatamente o que torna o controle de custos difícil. Mais opções significam mais formas de configurar algo errado, e as faturas do Databricks nem sempre deixam óbvio quando isso aconteceu.
Esse foi o ponto de partida de um webinar recente apresentado por Ian Whitestone, cofundador da SELECT, e Olivier Soucy, consultor de Databricks que passou anos construindo plataformas de dados do zero, incluindo uma passagem como head de dados em uma corretora de criptomoedas, onde montou um ambiente Databricks desde o início. Soucy hoje tem sua própria consultoria focada em custo e performance no Databricks, e usou a sessão para percorrer cinco estratégias concretas para colocar os gastos com Databricks sob controle, cada uma embasada em números reais de projetos com clientes.
Aqui vai um resumo do que ele apresentou.
Comece entendendo para onde o dinheiro realmente vai
Antes de otimizar qualquer coisa, você precisa saber pelo que está pagando, e o Databricks torna isso mais difícil do que deveria. O custo vem de dois lugares distintos: a taxa de Databricks Unit (DBU) cobrada pelo próprio Databricks e a computação de nuvem subjacente cobrada pela AWS, Azure ou GCP pelas instâncias que o Databricks provisiona.
A taxa de DBU sozinha pode ser enganosa. Soucy mostrou um mesmo pipeline de ETL precificado de três formas diferentes: executado como cluster interativo, custa 55 centavos por DBU; como job em computação clássica, 30 centavos por DBU; como job em serverless, 45 centavos por DBU. Olhando apenas o preço por DBU, o serverless parece a opção cara. Mas a computação clássica também carrega uma fatura separada de infraestrutura de nuvem que o serverless não tem, então o quadro completo costuma ser bem diferente quando os dois custos são combinados.
A maioria das equipes nunca os combina. Soucy foi direto quando Whitestone perguntou se os clientes acompanham o custo de DBU e de infraestrutura de nuvem juntos no nível do job: normalmente não, porque equipes diferentes são responsáveis por cada lado. Uma equipe de Databricks monitora as tabelas de sistema e os workflows; uma equipe de nuvem olha a fatura da AWS ou Azure e trata o Databricks como uma única linha. Cruzar as duas fontes de dados com as tags certas dá trabalho suficiente para que a maioria das organizações simplesmente pule essa etapa, mesmo sabendo que ela importa.
O Databricks expõe tabelas de sistema com dados de uso e preço, o que basta para construir um modelo de custo razoavelmente preciso para o gasto com DBU. Para computação clássica (não serverless), a regra prática de Soucy é assumir que o custo de infraestrutura de nuvem subjacente é aproximadamente igual ao custo de DBU — ou seja, uma fatura de US$ 50.000 em DBU costuma ficar mais perto de US$ 100.000 quando a computação de nuvem entra na conta. É uma estimativa grosseira, e varia bastante para workloads de GPU, mas é um ponto de partida razoável se você ainda não tem um modelo melhor. Para um detalhamento mais profundo de como a precificação do Databricks realmente funciona, a SELECT já cobriu os três controles que mais importam em mais detalhes.
Corte o desperdício antes de otimizar qualquer outra coisa
Computação ociosa é, nas palavras de Soucy, o erro mais caro que uma equipe pode cometer, porque você paga por recursos que não entregam valor algum enquanto rodam. Ele compartilhou dois exemplos do próprio trabalho com clientes. Em um caso, um estagiário recém-chegado subiu um cluster de GPU sem encerramento automático e sem nenhum guardrail. Ele rodou por semanas, adicionando cerca de US$ 4.000 a uma fatura mensal de US$ 20.000, antes que alguém percebesse. Em outro, um job que rodava tranquilamente em QA por cerca de 20 minutos encontrou dados diferentes em produção e rodou por 47 horas antes que alguém notasse.
As correções são simples e valem a pena independentemente de qualquer outro item desta lista:
- Configure encerramento automático em todo cluster e warehouse. Soucy sugeriu cerca de 30 minutos de ociosidade para clusters e 10 minutos para warehouses como padrões razoáveis, embora o número exato importe menos do que simplesmente ter um.
- Ative o auto-scaling para que a computação cresça e encolha conforme a demanda real, em vez de ficar totalmente provisionada 24 horas por dia.
- Defina timeouts para jobs e queries. O timeout padrão de instruções SQL do Databricks é de dois dias, o que ambos os apresentadores concordaram ser longo demais. Whitestone foi direto: se uma query está rodando há mais de um dia, provavelmente não deveria mais estar rodando, e vale a pena reduzir esse padrão em toda a conta.
- Use cluster policies para garantir tudo isso. Em vez de depender de cada pessoa lembrar do encerramento automático, as cluster policies podem exigi-lo no nível da conta.
Faça o right-sizing da computação para cada job
Com o desperdício sob controle, o próximo erro comum é o superprovisionamento: alocar mais computação do que um workload precisa. A recomendação padrão de Soucy, que ele admitiu ser um pouco polêmica, é rodar serverless por padrão, a menos que exista um motivo específico para não fazê-lo.
Ele sustentou isso com um exemplo de um pipeline de ETL horário de um cliente. Em computação clássica, o job usava cerca de 44 DBUs por dia a 30 centavos por DBU (aproximadamente US$ 13 por dia em custo de DBU), mais outros US$ 10 por dia em infraestrutura de nuvem, totalizando perto de US$ 23 por dia. Movido para serverless, o mesmo job usou 38 DBUs a uma taxa por DBU mais alta, mas o custo total ficou parecido — nesse caso, até ligeiramente mais barato —, principalmente porque o serverless elimina os dois a quatro minutos de inicialização de cluster que a computação clássica paga em toda execução. Essa eliminação da inicialização também reduziu o tempo total de execução do job de 20 para 12 minutos.
O conselho prático de Soucy: se você é novo no Databricks ou ainda não ajustou seus workflows, adote serverless como padrão em tudo, depois identifique os cinco a dez workloads que mais pesam na sua fatura e considere mover apenas esses de volta para a computação clássica, onde há mais alavancas para equilibrar custo e performance. O resto normalmente não vale o tempo de ajuste. O fator decisivo costuma ser a duração do workload: jobs que rodam por horas seguidas têm mais chances de se beneficiar da computação clássica, onde você pode ajustar diretamente o tipo de nó, o autoscaling e o número de workers.
Para computação clássica, Soucy recomenda começar com o menor tamanho de instância disponível e escalar apenas ao encontrar gargalos reais, usando métricas da Spark UI, como utilização de CPU e dos nós, para guiar a decisão. Começar grande demais tende a produzir o que ele chamou de "fatura silenciosa": sem erros, sem falhas, apenas um custo consistentemente mais alto do que o necessário. Também vale combinar o tipo de computação com o workload. Trabalho exclusivamente SQL pertence a SQL warehouses, lógica geral de jobs pertence a job compute, e clusters interativos ou all-purpose devem ser reservados para trabalho realmente interativo. Whitestone destacou que esse é um dos erros mais comuns que a SELECT vê: rodar um job agendado em um cluster interativo em vez de um cluster dedicado de job pode quase dobrar o custo de Databricks desse job sem nenhum benefício.
Repense o próprio workflow
Além do dimensionamento de computação, várias mudanças na forma de construir pipelines se destacaram como algumas das otimizações de maior alavancagem disponíveis.
A frequência de execução importa mais do que a maioria das equipes imagina. Usando uma atualização diária como base, passar para execuções horárias multiplica o custo por aproximadamente cinco, e atualizações quase em tempo real custam cerca de 60 vezes mais. O conselho de Soucy é questionar requisitos de tempo real ou quase tempo real vindos de stakeholders do negócio, já que a maioria dos pedidos de dashboards "em tempo real" na verdade significa apenas que o relatório precisa refletir um momento específico, não um fluxo contínuo.
Use views em vez de duplicar tabelas. Para filtros simples ou seleções de colunas, criar uma view em vez de uma nova tabela física evita copiar dados e o custo contínuo de manter essa cópia, sem nenhuma desvantagem real para quem a consulta.
Processe de forma incremental em vez de reprocessar tudo. O Auto Loader do Databricks consegue identificar automaticamente arquivos novos ou alterados no storage em nuvem e, combinado com structured streaming, permite que um pipeline processe apenas o que mudou em vez do dataset completo a cada execução. Soucy classificou essa opção como mais complexa de configurar, mas essencial para qualquer workload de alto volume.
Faça profiling e reescreva queries caras. A visão de query profile do Databricks mostra como o Spark de fato executou uma transformação, incluindo shuffles e spills fáceis de passar despercebidos. Soucy comentou que alimentar essas informações de profile, junto com o código da transformação, em um assistente de código com IA tem produzido reescritas reais e utilizáveis no próprio trabalho dele, transformando uma tarefa que antes exigia profunda expertise em Spark em algo muito mais acessível.
Não ignore o storage — e faça tudo isso durar
No lado do storage, o conselho de Soucy foi evitar o ajuste manual de particionamento e Z-ordering e, em vez disso, confiar nas tabelas gerenciadas do Unity Catalog, que suportam otimização preditiva. A otimização preditiva executa operações de vacuum, optimize e analyze automaticamente, de forma programada, limpando arquivos obsoletos, compactando arquivos pequenos em maiores e atualizando metadados para que as queries possam pular arquivos que não precisam ler. Ela tem um custo de execução, mas o efeito líquido costuma ser uma fatura menor do que a manutenção manual produziria. O liquid clustering, que praticamente substituiu o Z-ordering manual, oferece uma vantagem semelhante: ele não exige reescrever os dados existentes quando as colunas de clusterização precisam mudar.
Nada disso se sustenta ao longo do tempo sem governança. A recomendação de Soucy é gerenciar tudo como código, usando ferramentas como Terraform ou Databricks Asset Bundles, implantadas via CI/CD, para que as configurações permaneçam consistentes entre ambientes e não sofram desvios silenciosos. As cluster policies são a principal alavanca aqui: defina padrões sensatos para a maioria dos usuários, imponha encerramento automático e limites de tipo de nó, e deixe espaço para que power users que realmente precisam de mais flexibilidade possam solicitá-la. Cluster pools também podem ajudar, mantendo um conjunto de instâncias aquecidas do lado do provedor de nuvem para que os jobs não esperem a inicialização do cluster, embora você ainda pague ao provedor por essa capacidade ociosa, mesmo que o Databricks não a cobre.
Soucy também apontou uma categoria de custo fácil de passar despercebida: recursos mais novos do Databricks, como apps, endpoints de model serving, vector search e quality monitors. Ele contou que ele próprio configurou mal um quality monitor em uma tabela grande, o que aumentou a fatura diária dessa tabela em 50% antes que ele percebesse. Whitestone acrescentou que recursos relacionados a IA tendem a se tornar uma linha cada vez maior nas faturas do Databricks em geral, citando o movimento recente do Databricks de começar a cobrar por ferramentas antes gratuitas, como o Genie. A conclusão dos dois: configure alertas de custo antes de ativar qualquer novidade, não depois.
O fio condutor
Em todas as cinco estratégias, o mesmo padrão aparece: o Databricks raramente falha de forma barulhenta quando o assunto é custo. Clusters ociosos rodam em silêncio, jobs agendados em excesso rodam em silêncio, computação superdimensionada roda em silêncio, e novos recursos são ativados sem que ninguém verifique quanto vão custar até a fatura chegar. Nenhuma das correções aqui é exótica. Encerramento automático, timeouts sensatos, combinar o tipo de computação com o workload e tratar configuração como código resolvem a maior parte do gasto evitável para a maioria das equipes.
Para equipes que preferem resolver isso automaticamente em vez de manualmente, o SELECT para Databricks expõe esse tipo de desperdício diretamente, sinalizando encerramento automático ausente, jobs agendados em excesso (em um exemplo real compartilhado durante a sessão, reduzir um job de 472 execuções por dia para uma por hora economizou 95% do custo, ou cerca de US$ 19.000 por ano) e warehouses ou jobs responsáveis por uma fatia desproporcional do gasto, até o nível da query individual. Veja como funciona em select.dev.
FAQ
Qual é o maior gerador de custo desnecessário no Databricks? Computação ociosa. Clusters e warehouses deixados rodando sem encerramento automático, ou jobs travados sem timeout, geram cobranças sem retornar valor algum. Corrigir isso antes de qualquer outro item da lista tende a trazer o retorno mais rápido.
Devo usar serverless ou computação clássica por padrão no Databricks? Serverless é um padrão razoável para a maioria dos workloads, já que elimina o tempo de inicialização de cluster e coloca a maioria das equipes na faixa de custo adequada sem ajuste manual. A exceção são os cinco a dez workloads mais caros em gasto, que geralmente se beneficiam do controle adicional que a computação clássica oferece sobre tipo de nó, autoscaling e número de workers.
Qual é a diferença entre custo de DBU e custo de infraestrutura de nuvem? A taxa de DBU (Databricks Unit) é o que o próprio Databricks cobra pela computação, e varia conforme o tipo de computação. A computação clássica também gera uma fatura separada de infraestrutura de nuvem da AWS, Azure ou GCP pelas instâncias subjacentes, o que não acontece com a computação serverless. Como regra prática aproximada, assuma que o custo de infraestrutura de nuvem é quase igual ao custo de DBU na computação clássica.
Quanto o encerramento automático realmente economiza? Varia por workload, mas o prejuízo de ignorá-lo pode ser grande. Em um exemplo real, um cluster de GPU mal configurado, sem encerramento automático, adicionou cerca de US$ 4.000 à fatura de um único mês antes que alguém percebesse.
Como a frequência de execução dos jobs afeta o custo do Databricks? Significativamente. Usando uma atualização diária como base, rodar o mesmo job de hora em hora custa aproximadamente cinco vezes mais, e atualizações quase em tempo real custam cerca de 60 vezes mais. Questionar se um workload realmente precisa rodar com essa frequência costuma ser a correção de custo de maior alavancagem disponível.
O Databricks cobra por recursos de IA como o Genie? O Databricks passou a cobrar por ferramentas que antes eram gratuitas, incluindo o Genie, e a expectativa é que recursos relacionados a IA se tornem uma linha cada vez maior nas faturas do Databricks. Configurar alertas de custo antes de ativar novos recursos é a melhor defesa contra surpresas aqui.