Defina orçamentos e alertas para custos de data warehouse em nuvem

Toda equipe de analytics já passou por isso: a fatura de fim de mês chega e um único SQL warehouse estourou o orçamento, talvez por causa de um recurso de computação que ficou rodando a noite toda, ou talvez um ad hoc que escalou automaticamente para atender 80 usuários do Tableau durante uma revisão trimestral. O custo é real, mas a frustração é ainda maior: ninguém sabia de nada até que fosse tarde demais.

A gestão proativa de custos inverte esse modelo. Em vez de fazer uma análise forense da fatura depois que ela chega, você define limites antes mesmo de gastar o primeiro centavo — os orçamentos são vinculados a warehouses, equipes ou cargas de trabalho de BI. Alertas que disparam nos limites que você escolher e dashboards que mostram tendências de uso em tempo real, tudo na Databricks Data & AI Platform. Se você estiver no meio de uma migração de um sistema on-premises ou de outro cloud data warehouse, este é o momento ideal para implementar essa governança.

Por que a gestão reativa de custos falha?

As cargas de trabalho de data warehousing apresentam desafios de custo exclusivos. Os SQL warehouses atendem a cargas de trabalho interativas e orientadas por humanos (dashboards de BI, análises ad hoc, analytics incorporado) onde a demanda é imprevisível e instável. Uma única reunião geral da diretoria que acione 200 atualizações simultâneas de dashboards pode fazer os custos dispararem em minutos. A maioria das organizações começa sua jornada de FinOps da mesma forma: alguém baixa o CSV de uso do mês passado, abre uma tabela dinâmica e começa a fazer perguntas. Essa abordagem falha por quatro motivos:

• Você não consegue ver quem está gastando. O uso é consolidado no nível da plataforma, e não na equipe ou consulta que o gerou, de modo que ninguém pode ser responsabilizado por um valor específico.
• Ninguém é dono de um orçamento. Sem metas de gastos vinculadas a um warehouse ou equipe, o analista que executa SELECT * em uma tabela de 2 TB nunca sente o impacto do custo. A equipe da plataforma acaba absorvendo o valor silenciosamente.
• Você descobre tarde demais. Quando os relatórios do Excel do mês passado mostram o gasto excessivo, ele já tem dois ciclos de faturamento de atraso e a decisão que o causou já não pode mais ser rastreada.
• A revisão manual não escala. Cinco warehouses podem até passar por uma revisão mensal de tabela dinâmica. No entanto, ao escalar para dezenas, dar suporte a centenas de analistas no Tableau, Power BI e Looker torna-se inviável.

A gestão proativa de custos — atribuição, orçamentos, alertas, dashboards e otimização — resolve todos esses cinco problemas.

Comece com serverless: a primeira decisão de custo.

Antes de definir os orçamentos, escolha o tipo de warehouse correto. SQL Serverless warehouses são a opção recomendada da Databricks para a maioria das cargas de trabalho. Eles iniciam em segundos, reduzem a escala no momento em que as consultas terminam e permitem que o Intelligent Workload Management aloque computação para você, para que você pague apenas pela execução real da consulta, e não pelo tempo ocioso.

Se você estiver migrando de um cloud data warehouse legado, essa é uma grande mudança. A maioria das plataformas legadas cobra por computação sempre ativa ou exige decisões manuais de dimensionamento. O Serverless elimina toda essa categoria de erros de custo.

Lumen Technologies viu isso de perto: a migração de dois sistemas de telecomunicações essenciais de um data warehouse on-premises para o SQL Serverless reduziu os custos de computação em 30% a 40% e aumentou a velocidade das consultas em 90%. O sistema agora escala automaticamente para processar cerca de 7 GB a cada 10 minutos, com o Serverless eliminando a "taxa de atividade constante" normalmente associada a cargas de trabalho instáveis em tempo real.

Os cinco pilares da gestão proativa de custos

O framework consiste em cinco pilares. Os quatro primeiros tornam seus gastos visíveis; o quinto é o que realmente os reduz:

• Atribuição de custos. Adicione tags a tudo para saber quem gastou o quê e em qual warehouse.
• Orçamentos. Defina metas de gastos mensais no nível de conta, workspace ou equipe.
• Alertas. Receba notificações no momento em que os gastos se aproximarem ou ultrapassarem um limite.
• Dashboards. Visualize as tendências do warehouse e torne o custo uma métrica operacional de primeira classe.
• Otimizações. Reduza o custo do trabalho logo de início.

Pilar 1: Atribuição de custos em dois níveis

Não é possível gerenciar o que não se pode atribuir e, com os warehouses, isso significa dois níveis: o próprio warehouse e a consulta individual. Um mostra qual warehouse gastou o dinheiro; o outro mostra quem fez isso dentro dele.

Nível 1: Adicionando tags ao warehouse

Os SQL warehouses oferecem suporte a tags personalizadas como pares key:value que se propagam para system.billing.usage, vinculando cada DBU consumida a uma equipe, projeto ou centro de custo. A marcação com tags funciona da mesma forma para todos os tipos de warehouse — Classic, Pro e Serverless são todos marcados no nível do warehouse, para que você aprenda um padrão e o aplique em qualquer lugar.

Defina as tags na UI em SQL Warehouses > seu warehouse > Edit > Tags, ou crie o warehouse por meio da REST API:

Adicionando tags por meio da REST API

Aplique pelo menos três dimensões: equipe (quem é o proprietário), centro de custo (quem paga) e caso de uso (atendimento de BI, ad hoc, atualização agendada).

Não existe hoje uma política nativa que exija tags de warehouse, portanto, qualquer pessoa pode criar um sem tags. Em vez disso, incorpore essa exigência ao seu processo de provisionamento — crie warehouses com Terraform, Declarative Automation Bundles ou a REST API com tags na definição e trate a UI como a exceção. A consulta de lacuna de atribuição mais adiante neste post captura o que passar despercebido.

Nível 2: Adicionando tags à consulta

As tags de warehouse informam que um warehouse custou US$ 4.000 no mês passado. Elas não informam que 60% desse valor veio de um único dashboard do Power BI atualizado a cada 15 minutos. Essa lacuna é importante porque os warehouses são compartilhados — um único warehouse de BI atende a dezenas de dashboards, vários modelos dbt e um fluxo de consultas ad hoc.

Tags de consulta (Public Preview) fecham essa lacuna ao anexar o contexto de negócios a instruções SQL individuais:

As tags vão para a coluna query_tags de system.query.history (Public Preview), junto com executed_by e statement_id, para que você possa agrupar os gastos por dashboard, modelo ou centro de custo, em vez de por warehouse. Algumas ferramentas definem isso para você: a partir do dbt-databricks 1.11.0, as consultas de modelo são marcadas automaticamente com o nome do modelo dbt, e o Power BI passa os identificadores de workspace e dataset por meio do driver ADBC.

Duas observações: as tags de consulta se aplicam apenas a consultas de SQL warehouse e, como elas ficam no histórico de consultas em vez dos dados de faturamento, você mesmo deve fazer a junção das duas para obter o custo por consulta.

Antes de escrever qualquer SQL, verifique a página de Custos no Governance Hub (Beta) — uma visualização em nível de conta de gastos, direcionadores de custos, orçamentos e cobertura de tags, e a maneira mais rápida de ver quanto do seu uso é realmente atribuível. Um administrador de conta pode ativá-lo na página de Previews do console da conta.

Pilar 2: Definindo orçamentos no console da conta

Criando um orçamento

No Console da Conta, acesse Usage > Budgets, clique em Add budget e configure:

• Name: Descritivo (ex: "Analytics SQL Warehouses, Mensal")
• Amount: Meta mensal em USD
• Scope: Filtre por workspaces e/ou tags (ex: Team:Analytics)
• Email notifications: Destinatários notificados quando os gastos atingirem o valor do orçamento

Exemplos de configurações de orçamento

O padrão ideal é usar orçamentos em camadas: orçamentos no nível da equipe para fins de responsabilidade, além de um orçamento para toda a conta como uma rede de segurança para capturar qualquer desvio. 

Lembre-se de que os orçamentos são um mecanismo de monitoramento, não um limite rígido. Eles não interrompem o uso nem evitam cobranças, portanto, sua fatura ainda pode exceder o valor definido. O objetivo é a conscientização e a resposta rápida, e não bloqueios que possam corromper um painel de produção no meio de uma atualização.

GetYourGuide testou isso diretamente: consolidar todas as suas cargas de trabalho do Looker no SQL Serverless reduziu os custos de atendimento de BI em cerca de 20% e acelerou as consultas em 35%, embora a equipe esperasse que os clusters Classic fossem mais baratos. A escolha do tipo de SQL warehouse é uma decisão de orçamento que vale a pena reavaliar constantemente, e não uma escolha única.

Analisando seu ritmo de consumo (burn rate)

Clique em qualquer orçamento para ver os gastos atuais em relação à meta, o orçamento restante e uma visualização diária do ritmo de consumo (burn rate). Para data warehousing, este gráfico é especialmente revelador:

• Consumo diário linear significa custos estáveis de atendimento de BI.
• Dente de serra com picos de segunda a sexta-feira indica exploração ad-hoc concentrada nos dias úteis.
• Um aumento repentino no meio do mês significa que um novo painel foi implantado sem uma revisão de custos.
• Uma tendência gradual de alta significa que a adoção orgânica está superando suas premissas de orçamento.

Pilar 3: Alertas, o sistema nervoso da governança de custos

Os orçamentos mostram onde você está. Os alertas dizem quando agir.

Alertas de orçamento por e-mail

Ao criar um orçamento, adicione destinatários de e-mail que serão notificados quando os gastos excederem o valor do orçamento. Não é necessário nenhum código.

Para alertas baseados em limites, crie Databricks SQL Alerts que consultem `system.billing.usage` diretamente. Aqui estão os padrões mais importantes:

Alerta quando o gasto diário do SQL warehouse excede um limite

Alerta de ritmo: projeção de gastos de fim de mês excederá o orçamento

Este é o padrão do qual as equipes extraem mais valor. Em vez de alertar após a violação, ele projeta os gastos do fim do mês e dispara antes que essa projeção ultrapasse seu orçamento, enquanto você ainda tem tempo para agir:

Agende isso a cada quatro horas e envie para o Slack ou e-mail. Isso dá às equipes dias para reagir (ajustar o tamanho de um warehouse, otimizar uma consulta cara, adiar um lote) antes que o orçamento seja estourado.

Detecte custos ocultos de atualizações de materialized views

Os custos de atualização de materialized views são os que as equipes mais costumam deixar passar, porque são faturados como uso de pipeline serverless em vez de uso de warehouse. Uma view configurada para atualizar a cada 15 minutos em uma origem que é atualizada duas vezes por dia gera gastos desnecessários. Alinhe o cronograma de atualização com a frequência com que os dados subjacentes realmente mudam e, em seguida, acompanhe os gastos do pipeline diretamente:

Pilar 4: Painéis e monitoramento contínuo

Alertas são gatilhos pontuais. Os dashboards oferecem contexto contínuo. A Databricks fornece dashboards de uso pré-configurados que os administradores de conta podem importar para qualquer workspace habilitado para o Unity Catalog. Eles abrangem tendências de gastos, análise dos top-N, filtragem de tags e detalhamentos por warehouse. Para monitoramento personalizado, duas consultas são especialmente úteis:

Custo de SQL warehouse por equipe

Uso de SQL não atribuído (lacuna de atribuição)

O uso de SQL sem tag é a sua lacuna de atribuição, ou seja, gastos com warehouse que não podem ser rastreados para nenhuma equipe. Reduza isso a zero.

Raiffeisen Bank International criou sua própria plataforma de monitoramento de custos e previsão diretamente nas tabelas de sistema da Databricks, com visibilidade por warehouse, por usuário e por carga de trabalho. O retorno foi tanto cultural quanto técnico: cargas de trabalho de 3 a 4 vezes mais rápidas e, mais importante, quando as equipes conseguem ver seus próprios gastos e precisam explicá-los, o comportamento muda sem a necessidade de imposições.

Pilar 5: Otimização, o pilar que realmente muda a conta

Os primeiros quatro pilares servem para visualizar seus gastos. Este serve para reduzi-los, e é o que a maioria das equipes ignora. Comece com as duas mudanças que melhoram o custo e o desempenho ao mesmo tempo.

Ative a otimização preditiva para tabelas gerenciadas do Unity Catalog. A Databricks executa OPTIMIZE, VACUUM e ANALYZE para você com base em como cada tabela é realmente consultada e, com o CLUSTER BY AUTO, ela ajusta as chaves de clustering conforme os padrões de consulta mudam. Menos dados verificados significam consultas mais rápidas e menos DBUs, sem a necessidade de manter um cronograma de manutenção. O recurso está ativado por padrão para contas criadas em ou após 11 de novembro de 2024, e chegará às contas mais antigas ao longo de 2026.

Use warehouses serverless por padrão para aproveitar a economia de inicialização e tempo ocioso descrita anteriormente — para a maioria das equipes, essa é a maior parte da economia, sem esforço contínuo.

A partir daí, vale a pena ajustar algumas configurações:

• Reduza o tempo de parada automática. O Pro e o Classic têm como padrão 45 minutos de inatividade antes de parar; o serverless tem como padrão 10 minutos, e você pode reduzir para 5 na UI ou para 1 via API. Cada minuto ocioso em um warehouse de BI após o fechamento do último dashboard é desperdício.
• Defina um limite de tempo de instrução (Beta — ative a visualização prévia e defina-o por warehouse via API). Uma consulta fora de controle não deve consumir um fim de semana inteiro de computação; mantenha o tempo curto em warehouses de BI e mais longo em ETL.
• Designe um warehouse padrão (Configurações do administrador > Computação) para que uma rápida visualização de dez linhas não ative um cluster do tamanho de um ETL, e comece com Small ou Medium em vez de superdimensionar.
• Aumente a escala vertical ou horizontalmente com um propósito. O escalonamento vertical (scaling up) — tamanhos maiores, agora até 5X-Large (Visualização pública) — torna uma única consulta pesada mais rápida; o escalonamento horizontal (scaling out — um número máximo de clusters maior) atende a mais usuários simultâneos. Escolher a opção errada é um erro comum e caro.

A camada de dados também importa: OPTIMIZE, VACUUM e liquid clustering reduzem a computação que uma consulta precisa, e isso se acumula em milhares de consultas de BI por dia.

No fundo, a maioria dos problemas de custo são problemas de consulta. A falta de uma chave de join ou um SELECT * em uma tabela larga custa o mesmo, não importa como o warehouse esteja ajustado — e a atribuição do Pilar 1 é o que diz quais consultas e dashboards você deve corrigir.

Principais conclusões

1. Incorpore serverless e atribuição na plataforma desde o primeiro dia. Use warehouses SQL Serverless por padrão para inicialização instantânea, escalonamento automático e sem custo de tempo ocioso, e imponha tags personalizadas desde o início, pois o uso não atribuído é invisível e o uso invisível sempre cresce.

2. Defina orçamentos e alertas proativamente, em mais de um nível. Combine orçamentos por equipe para fins de responsabilidade com um orçamento para toda a conta para anomalias, e envie alertas com base no ritmo de consumo, não apenas em limites, para que você saiba de um estouro de orçamento com tempo para agir, e não após a violação.

3. Torne os gastos visíveis e faça disso parte da cultura.  A economia mais duradoura vem da transparência, não de restrições, portanto, coloque os dashboards de custos onde as equipes trabalham. Como o RBI descobriu, quando as equipes conseguem ver seus próprios gastos, o comportamento muda sem a necessidade de imposições.

Primeiros passos

Este é o caminho mais rápido para começar e manter o controle das contas antes que elas disparem:

• Crie seu primeiro orçamento no console da conta. 
• Atribua o uso adicionando tags ao seu SQL warehouse e consultas
• Monitore custos com tabelas de sistema, consulte system.billing.usage para obter insights específicos do warehouse
• Comportamento de dimensionamento e escalonamento do SQL warehouse, entenda o IWM e a economia do serverless
• Melhores práticas de otimização de custos, dimensionamento de warehouse, Photon e otimização do Delta Lake
• Do Caos ao Controle: Uma Jornada de Maturidade de Custos com a Databricks, a estrutura "engatinhar-andar-correr" para a maturidade de FinOps

Pronto para assumir o controle dos custos do seu data warehouse na nuvem? Configure uma conta de avaliação gratuita da Databricks, crie seu primeiro SQL Serverless warehouse e configure um orçamento com alertas por e-mail no Console da Conta. Leva apenas cinco minutos e não custa nada.

Para se aprofundar na observabilidade de custos, explore a documentação das tabelas de sistema de faturamento e importe o dashboard de uso pré-configurado para começar a monitorar os gastos desde o primeiro dia.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original