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

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 attacher vos propres étiquettes personnalisées (équipe, centre de coûts, environnement, etc.) à chaque requête générée par votre pipeline. Les étiquettes 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 tous les détails dans la documentation).

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 s'intègre dbt-databricks aux étiquettes de requête

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

Balises injectées automatiquement

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

pter Adapter

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

profilApproche la plus simple : ajoutez 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 en est propriétaire (équipe), où sont affectés les coûts (centre de coûts), à quel pipeline elle appartient (nom_projet) et dans quel environnement elle s'exécute (env). 

Balises au niveau du modèle

Pour une attribution plus détaillée, vous pouvez fournir des balises 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 balises – 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'un fichier MAP. Vous pouvez l'interroger en utilisant la syntaxe standard d'accès à la carte : 

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

Vous pouvez également trouver les balises 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.

Sur la Dans la partie inférieure droite du profil de requête, vous verrez les étiquettes de requête que vous avez définies, vous donnant ainsi 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 de l'entrepôt ? 

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

Option 1 : Genie

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 vos efforts d'optimisation.

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

Notre projet de référence comprend un tableau de bord IA/BI qui interroge system.query.history filtré par les étiquettes de requête propres au projet. Résultat : le pipeline qui analyse les données de facturation suit également ses propres coûts – alimentant 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 la matérialisation : diagramme circulaire montrant la répartition du calcul entre la table, la vue et la table détaillée metric_view
• Query : 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 balises 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 de métriques Databricks (disponibles avec dbt-databricks 1.12+) 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 (suivis 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 l'étiquetage 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 créant le projet de référence et en discutant avec des utilisateurs expérimentés de dbt :

•  Utilisez une hiérarchie cohérente des balises. 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é au nom du modèle_@dbt_injecté automatiquement, vous obtenez une traçabilité complète : projet → modèle → matérialisation.
• Ne surétirez pas. 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.
• Etiquetez 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'élément (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 : github.com/databricks-solutions/dbt-query-tags

Pour commencer : 

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

Changez les valeurs de votre propre équipe et de votre centre de coûts. Le modèle fonctionne pour n'importe quel 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