Atribuição granular de uso para pipelines de dbt com query tags

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, etc.) a cada query gerada pelo seu pipeline.

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.

Integraçãodbt-databricks-se a Query Tags

O dbt-databricksadaptador (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 na anterior:

Tags injetadas automaticamente

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

Essas tags automáticas permitem que você obtenha visibilidade por modelo sem configuração. O adaptador faz isso para você.

Tags no nível do perfil

A 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, essa única linha marca cada query com quatro dimensões: quem é o proprietário (team), para onde vai o custo (cost_center), a qual pipeline pertence (project_name) e em qual ambiente é executado (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 no nível do modelo terá prioridade.

Onde as tags aparecem – system.query.history

Depois de executar o dbt run, cada instrução SQL aparece em system.query.history com a coluna query_tags preenchida como MAP<STRING, STRING>. Você pode consultá-lo usando a sintaxe padrão de acesso ao mapa:

Isso retorna todas as queries marcadas 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 executada na UI do histórico de queries ou na UI do SQL Warehouse Monitoring.

No canto inferior direito do Query Profile, você verá as Query Tags que você definiu, fornecendo todas as informações necessárias rapidamente.

Atribuição de custo com Query Tags

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

Quais modelos de DBT consomem mais recursos de warehouse?

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

Opção 1: Genie

O Genie escreve e executa a query equivalente, e você continua inserindo 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.

Criação de 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. Resultado: o pipeline que analisa os dados de cobrança também monitora seus próprios custos, alimentando query tags para si mesmo.

O painel inclui:

• KPIs: total de queries com tags, total de segundos de compute, modelos de dados distintos
• Atividade diária: contagem de queries e tempo de compute por dia, divididos por ambiente
• Detalhe 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 table, view e metric_view
• Tabela de detalhes da query: cada query marcada com modelo, duração, ambiente e executor

Em nosso projeto de referência, os quatro modelos de mercado representaram 92% do tempo de compute. Sem o Query Tags, esse insight era invisível.

Criar esse painel você mesmo leva minutos com o Genie Code: peça o tempo de compute por modelo dbt do system.query.history filtrado pelas tags de query, e ele escreve o SQL e monta os elementos 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 of métricas views

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

Observe a distinção: os query_tags estão anexados às queries SQL que criam ou atualizam a visualização da métrica (rastreada em system.query.history), enquanto os 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 criar 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, auto-injetado, 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 explicitamente as visualizações de métricas. 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. Atualize o arquivo profiles.yml com o host do workspace, o caminho HTTP do SQL warehouse, o catálogo e as tags de query personalizadas
4. Execute o dbt deps && dbt run --profiles-dir . para executar o pipeline
5. Consulte system.query.history para ver suas tags em ação
6. Atualize o dbt_profiles/profiles.yml e o databricks.yml para apontar para a configuração correta.
7. Deploy with databricks bundle deploy para execuções agendadas e o painel de análise

Troque os valores de sua própria equipe e centro de custo. 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