Attribution granulaire de l'utilisation pour les pipelines dbt avec étiquettes de requête

Votre projet dbt exécute 80 modèles chaque nuit. La facture d'entrepôt a doublé le trimestre dernier. Les performances des modèles varient considérablement et les effets des optimisations les plus récentes ne sont pas clairs. Finance demande quelle équipe est responsable. Ouvrez l'historique des requêtes et voyez... 80 lignes identiques étiquetées 'Databricks Dbt'. Bonne chance.

Grâce aux étiquettes de requête (désormais disponibles en version préliminaire publique), les équipes chargées des données peuvent désormais bénéficier de étiquettes prédéfinies et injectées automatiquement, telles que dbt_model_name, qui enrichissent chaque exécution. Vous pouvez également associer vos propres étiquettes personnalisées (équipe, centre de coûts, environnement, etc.) à chaque requête générée par votre pipeline.

Les balises sont enregistrées dans system.query.history, ce qui permet d'attribuer les coûts, de déboguer les performances et de surveiller la charge de travail en une simple requête SQL (voir la documentation pour plus de détails).

Ce blog présente un projet dbt complet et open source qui présente Query Tags de bout en bout : de la configuration aux tableaux de bord d'attribution des coûts. Tout ce qui est décrit ici est disponible sous forme de référentiel GitHub que vous pouvez cloner et déployer sur votre propre espace de travail, ou simplement demander à Génie.

Comment dbt-databricks s'intègre aux étiquettes de requête

L'dbt-databricksadaptateur (version 1.11+) prend en charge les étiquettes de requête en natif. Il existe trois niveaux auxquels les étiquettes peuvent être appliquées, chacune s'appuyant sur la précédente :

Étiquettes auto-injectées

Outre vos balises personnalisées, dbt-databricksle module injecte automatiquement des métadonnées relatives à chaque exécution de modèle :

Ces étiquettes automatiques vous permettent d'obtenir une visibilité par modèle sans aucune configuration : l'adaptateur le fait à votre place.

Tags au niveau du profil

L'approche la plus simple consiste à ajouter un champ query_tags à une cible spécifique dans votre profil dbt. Chaque requête du projet hérite automatiquement de ces étiquettes.

Par exemple, cette ligne unique étiquette chaque requête avec quatre dimensions : à qui appartient la requête (équipe), où vont les coûts (cost_center), à quel pipeline elle appartient (project_name) et dans quel environnement elle s'exécute (env).

Tags au niveau du modèle

Pour une attribution plus détaillée, vous pouvez fournir des étiquettes sur des modèles spécifiques dans dbt_project.yml ou sur la configuration du modèle dans sa définition SQL. 

Les étiquettes de niveau modèle fusionnent avec les étiquettes de niveau profil. Si les deux définissent la même clé, la valeur au niveau du modèle est prioritaire.

Où apparaissent les étiquettes – system.query.history

Après avoir exécuté dbt run, chaque instruction SQL apparaît dans system.query.history avec la colonne query_tags remplie sous la forme d'une MAP<STRING, STRING>. Vous pouvez l'interroger en utilisant la syntaxe standard d'accès aux cartes :

Cette option renvoie toutes les requêtes étiquetées des sept derniers jours, les étiquettes personnalisées et injectées automatiquement étant extraites dans des colonnes individuelles et prêtes à être regroupées.

Vous pouvez également trouver les étiquettes de requête de la requête que vous avez exécutée dans l'interface utilisateur Historique des requêtes ou dans l'interface utilisateur SQL Warehouse Monitoring.

Dans l'angle inférieur droit du profil de requête, vous verrez les étiquettes de requête que vous avez définies, vous fournissant toutes les informations nécessaires en un coup d'œil.

Attribution des coûts avec les étiquettes de requête

Les étiquettes de requête permettent de déterminer l'attribution granulaire de l'utilisation directement via des requêtes SQL, éliminant ainsi le besoin d'analyser manuellement les journaux ou de diviser les ressources de l'entrepôt.

Quels modèles dbt consomment le plus de ressources d'entrepôt ?

Vous pouvez répondre à cette question de deux façons : demandez à Genie en langage clair de procéder à une exploration ad hoc ou écrivez vous-même le code SQL pour obtenir un résultat reproductible et prêt à être utilisé dans un tableau de bord. Les deux lisent à partir des mêmes données system.query.history.

Option 1 : Génie

Genie écrit et exécute la requête équivalente, et vous continuez à analyser les questions de suivi sans toucher à SQL.

Option 2 : SQL

Les deux chemins renvoient la même image. Dans notre projet de référence, les quatre tables mart (matérialisées sous forme de tableau) dominent le temps de calcul, tandis que les vues de mise en scène et les vues de métriques sont quasi instantanées. Cela vous indique immédiatement où concentrer les efforts d'optimisation.

Création d'un tableau de bord d'autosurveillance

Notre projet de référence inclut un tableau de bord IA/BI qui interroge system.query.history filtré par les balises de requête propres au projet. Résultat : le pipeline qui analyse les données de facturation suit également ses propres coûts – il nourrit lui-même les balises de requête.

Le tableau de bord comprend :

• Indicateurs clés de performance : nombre total de requêtes étiquetées, nombre total de secondes de calcul, modèles DBT distincts
• Activité quotidienne : nombre de requêtes et temps de calcul par jour, divisés par environnement
• Répartition du modèle : temps de calcul par modèle, coloré par type de matérialisation
• Répartition de matérialisation : diagramme circulaire montrant la répartition du calcul entre table, vue et vue_métrique
• Table détaillée de la requête : chaque requête étiquetée avec modèle, durée, environnement et exécuteur

Dans notre projet de référence, les quatre modèles Mart représentaient 92 % du temps de calcul. Sans les étiquettes de requête, cette information était invisible.

Créer vous-même ce tableau de bord prend quelques minutes avec Genie Code : demandez-lui le temps de calcul par modèle dbt à partir de system.query.history filtré par vos balises de requête, et il écrit le code SQL et assemble les visuels. Si vous préférez passer directement au résultat fini, le tableau de bord est également fourni dans le projet de référence et est déployé avec un ensemble de blocs de données déployé parallèlement à la tâche dbt (consultez le référentiel Github pour obtenir le guide détaillé).

Marquage des vues de métriques

Les vues métriques Databricks (disponibles avec dbt-databricks1.12 et versions ultérieures) sont un nouveau type de matérialisation qui définit une sémantique métier réutilisable sous forme de dimensions et de mesures directement dans le catalogue Unity (voir la documentation complète). Ils peuvent contenir des balises de requête comme n'importe quel autre modèle, à l'aide du paramètre de configuration query_tags :

Notez la distinction : les tags de requête sont attachés aux requêtes SQL qui créent ou actualisent la vue de métrique (suivies dans system.query.history), tandis que les tags databricks sont des tags de catalogue Unity sur l'objet lui-même (pour la gouvernance et la découverte). Le premier est destiné au suivi au niveau de la requête, tandis que le second est au niveau de l'objet Unity Catalog pour la découverte globale des données. 

Meilleures pratiques pour le marquage des projets dbt

Dans cet article, nous avons couvert le processus holistique permettant de créer une pratique FinOps solide dans laquelle les étiquettes de requête sont fondamentales pour l'attribution des coûts. Voici ce que nous avons appris en élaborant le projet de référence et en discutant avec les utilisateurs expérimentés de dbt :

• Utilisez une hiérarchie cohérente des étiquettes. Définissez des étiquettes à l'échelle de l'organisation au niveau du profil (équipe, cost_center, project_name, env) et réservez des étiquettes au niveau du modèle pour des cas exceptionnels. Cela permet de garder les étiquettes prévisibles et d'éviter l'étalement de la configuration par modèle.
• Toujours étiqueter l'environnement. Utilisez des valeurs env différentes pour le développement local (local-dev) et les tâches déployées (dev, staging, prod). Cela vous permet de séparer les requêtes de développement ad hoc des exécutions de production planifiées dans vos analyses. Dans notre projet de référence, le profil local définit « env » : « local-dev » tandis que le profil déployé définit « env » : « dev ».
• Utilisez `nom_projet` pour distinguer les pipelines. Lorsque plusieurs projets dbt partagent un entrepôt, project_name vous permet d'attribuer des coûts par pipeline sans diviser les entrepôts. Combiné à l'auto-injected @@dbt_model_name, vous obtenez une traçabilité complète : projet → modèle → matérialisation.
• Ne pas exagérer. Les étiquettes injectées automatiquement couvrent déjà le nom du modèle, le type de matérialisation et les versions de l'adaptateur. Vous avez rarement besoin de dupliquer ces informations dans des étiquettes personnalisées. Concentrez les étiquettes personnalisées sur le contexte métier que dbt ne peut pas déduire : propriété de l'équipe, centre de coûts, identité du projet.
• Marquez explicitement les vues de métriques. Étant donné que les vues de métriques sont une matérialisation plus récente, il est utile de les étiqueter avec une clé d'objet (par exemple, « fonction » : « vue_métrique » ) afin de pouvoir facilement filtrer les requêtes de création de vues de métriques dans votre analyse des coûts.

Essayez vous-même

Le projet de référence complet est disponible sur GitHub à l'adresse : github.com/databricks-solutions/dbt-query-tags

Pour commencer :

1. Cloner le référentiel
2. Créez un environnement virtuel Python 3.12 et installez les dépendances : pip install dbt-databricks>=1.12.0a1
3. Mettre à jour le fichier profiles.yml avec votre hôte d'espace de travail, le chemin HTTP SQL Warehouse, le catalogue et les étiquettes de requête personnalisées
4. Exécutez dbt deps && dbt run --profiles-dir . pour exécuter le pipeline
5. Interrogez system.query.history pour voir vos étiquettes en action
6. Mettez à jour les fichiers dbt_profiles/profiles.yml et databricks.yml pour pointer vers une configuration correcte.
7. Déployer avec databricks Déploiement groupé pour les exécutions planifiées et le tableau de bord d'analyse

Échangez les valeurs de votre équipe et de votre centre de coûts. Le modèle fonctionne pour tout projet dbt sur Databricks.

Clonez le référentiel dès aujourd'hui ! Une ligne de votre profil suffit pour déverrouiller la visibilité de l'attribution d'utilisation au niveau du modèle dans l'ensemble de votre entrepôt.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original