Atribuição granular de uso para pipelines de dbt com Query Tags – Clonado

Seu projeto dbt executa 80 modelos todas as noites. A conta de armazém dobrou no último trimestre. O desempenho do modelo varia muito, e os efeitos das otimizações mais recentes não são claros. O departamento de Finanças pergunta qual equipe é responsável. Você abre o histórico de queries e vê... 80 linhas idênticas rotuladas 'Databricks Dbt.' Boa sorte.

Com os Query Tags (agora em versão pública), as equipes de dados agora podem se beneficiar de tags injetadas automaticamente prontas para uso, como dbt_model_name, que enriquecem cada execução. Você também pode anexar suas próprias tags personalizadas — equipe, centro de custo, ambiente ou qualquer coisa — a cada query que seu pipeline gera.

As tags são registradas em system.query.history, tornando a atribuição de custos, a depuração de desempenho e o monitoramento da carga de trabalho uma simples query SQL (detalhes completos na documentação).

Este post apresenta um projeto de dbt completo e de código aberto que demonstra o Query Tags de ponta a ponta: da configuração aos painéis de atribuição de custos. Tudo o que está descrito aqui está disponível como um repositório do GitHub que você pode clonar e implantar em seu próprio workspace, ou apenas pedir ao Genie.

Como o dbt-databricks se integra aos Query Tags

O adaptador dbt-databricks (versão 1.11+) é compatível com Query Tags nativamente. Há três níveis nos quais as tags podem ser aplicadas, cada uma com base no

anterior:Tags injetadas automaticamente

Além de suas tags personalizadas, o dbt-databricks injeta automaticamente metadados sobre cada execução de modelo:

Essas tags automáticas significam que você obtém visibilidade por modelo com configuração zero — o adaptador faz isso para você.Tag

s em nível de

perfilA abordagem mais simples: adicione um campo query_tags a um destino específico em seu perfil dbt. Cada query no projeto herda essas tags automaticamente.

Por exemplo, esta única linha marca cada query com quatro dimensões: quem é o proprietário (team), para onde vai o custo (cost_center), a qual pipeline ela pertence (project_name) e em qual ambiente ela é executada (env).

Tags em nível de modelo

Para uma atribuição mais granular, você pode fornecer tags em modelos específicos em dbt_project.yml ou na configuração do modelo em sua definição sql. 

As tags em nível de modelo são integradas às tags em nível de perfil. Se ambos definirem a mesma chave, o valor em nível de modelo terá prioridade.

Where tags appear – system.query.history

Após a execução do dbt run, cada instrução SQL aparece em system.query.history com a coluna query_tags preenchida como uma MAP. Você pode consultá-lo usando a sintaxe padrão de acesso ao mapa:

This retorna cada query taggada dos últimos 7 dias, com as tags personalizadas e injetadas automaticamente extraídas em colunas individuais, prontas para agregação.

Você também pode encontrar as Query Tags da query que você executou na UI do histórico de queries ou na UI do SQL Warehouse Monitoring.

Na na parte inferior direita do Query Profile, você verá as Query Tags que você definiu, fornecendo a você todas as informações necessárias rapidamente.

Atribuição de custo com Query Tags

As Query Tags permitem que a atribuição de uso granular seja determinada diretamente por meio de queries SQL, eliminando a necessidade de análise manual de logs ou dividiendo os recursos do warehouse.

Quais modelos de dbt consomem mais recursos do warehouse?

Você pode responder de duas maneiras: peça ao Genie em linguagem simples para uma exploração ad-hoc ou escreva o SQL você mesmo para obter um resultado repetível e pronto para o painel. Ambos leem os mesmos dados de system.query.history.

Opção 1: o Genie

Genie escreve e executa a query equivalente, e você continua fazendo drill em perguntas de acompanhamento sem tocar em nenhum SQL.

Opção 2: SQL

Ambos os caminhos retornam a mesma imagem. Em nosso projeto de referência, as quatro tabelas de mercado (materializadas como tabela) dominam o tempo de compute, enquanto as visualizações de preparação e as visualizações de métricas são quase instantâneas. Isso informa imediatamente onde deve ser feito o esforço de otimização.

Criar um painel de automonitoramento

Nosso projeto de referência inclui um painel de IA/BI que consulta system.query.history filtrado pelas tags de query do próprio projeto. O resultado: o pipeline que analisa os dados de cobrança também monitora seus próprios custos, alimentando query tags em si mesmo.

O painel inclui:

• KPIs: total de queries com tags, total de segundos de compute, modelos de dbt distintos
• Atividade diária: contagem de queries e tempo de compute por dia, divididos por ambiente
• Detalhamento do modelo: Tempo de compute por modelo, colorido por tipo de materialização
• Divisão de materialização: gráfico circular mostrando como o compute se distribui entre a tabela de detalhes, a visualização e a tabela de detalhes do metric_view
• Query: Cada query marcada com modelo, duração, ambiente e executor

Em nosso projeto de referência, os quatro modelos de mart representavam 92% do tempo de compute — sem as query tags, esse insight era invisível.

Criar esse painel você mesmo leva minutos com o Genie Code: solicite o tempo de compute por modelo dbt do system.query.history filtrado por suas query tags, e ele escreve o SQL e monta os visuais. Se você preferir ir ir direto para o resultado final, o painel também vem com o projeto de referência e é implantado com um pacote Databricks deploy junto com o job dbt (consulte o repositório do Github para obter o guia detalhado).

Tagging Metrics

Views Databricks (disponíveis com dbt-databricks 1.12+) são um novo tipo de materialização que define semântica de negócio reutilizável na forma de dimensões e medidas diretamente no Unity Catalog (consulte a documentação completa). Eles podem carregar Query Tags como qualquer outro modelo, usando o parâmetro de configuração query_tags:

Observe a distinção: query_tags estão anexadas às queries SQL que criam ou atualizam a visualização da métrica (rastreada em system.query.history), enquanto databricks_tags são tags do Unity Catalog no próprio objeto (para governança e descoberta). O primeiro é para acompanhamento em nível de query, enquanto o último é no nível de objeto do Unity Catalog para descoberta geral de dados. 

Práticas recomendadas para etiquetar projetos de dbt

Neste artigo, abordamos o processo holístico para construir uma prática sólida de FinOps, onde Query Tags são fundamentais para a atribuição de custos. Veja o que aprendemos criando o projeto de referência e conversando com usuários avançados do dbt:

• Use uma hierarquia de tags consistente. Defina tags para toda a organização no nível do perfil (team, cost_center, project_name, env) e reserve tags no nível do modelo para casos excepcionais. Isso mantém as tags previsíveis e evita a expansão da configuração por modelo.
• Sempre marque o ambiente. Use valores de ambiente diferentes para o desenvolvimento local (desenvolvimento local) e os trabalhos implantados (desenvolvimento, preparação, produção). Isso permite separar queries de desenvolvimento ad-hoc de execuções de produção programadas em suas análises. Em nosso projeto de referência, o perfil local define "env": "local-dev", enquanto o perfil implantado define "env": "dev".
• Use `project_name` para distinguir pipelines. Quando vários projetos de dbt compartilham um warehouse, o project_name permite atribuir custos por pipeline sem dividir warehouses. Combinado com o @@dbt_model_name injetado automaticamente, você obtém rastreabilidade total: projeto → modelo → materialização.
• Não exagere. As tags injetadas automaticamente já abrangem o nome do modelo, o tipo de materialização e as versões do adaptador. Você raramente precisa duplicar essas informações em tags personalizadas. Concentre as tags personalizadas no contexto de negócios que o dbt não consegue inferir: propriedade da equipe, centro de custo, identidade do projeto.
• Marque visões de métricas explicitamente. Como as visualizações de métricas são uma materialização mais recente, é útil marcá-las com uma chave de recurso (por exemplo, "feature": "metric_view") para que você possa filtrar facilmente as queries de criação de visualização de métricas em sua análise de custos.

Experimente você mesmo

O projeto de referência completo está disponível no GitHub: github.com/databricks-solutions/dbt-query-tags

Para começar:

1. Clone o repositório
2. Crie um ambiente virtual Python 3.12 e instale as dependências: pip install dbt-databricks>=1.12.0a1
3. Update profiles.yml com o host do workspace, o caminho HTTP do SQL warehouse, o catálogo e as tags de query personalizadas
4. Run dbt deps && dbt run --profiles-dir . para executar o pipeline
5. Query system.query.history para ver suas tags em ação
6. Atualize dbt_profiles/profiles.yml e databricks.yml para apontar para a configuração correta.
7. Implante com databricks bundle deploy para execuções agendadas e o painel de análises

Swap para sua própria equipe e para os valores do centro de custos. O padrão funciona para qualquer projeto de dbt no Databricks.

Clone o repositório hoje mesmo! É preciso uma linha no seu perfil para desbloquear a visibilidade da atribuição de uso em nível de modelo em todo o seu warehouse.

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