Étiquettes de requête : Le contexte qui manquait à vos requêtes d'entrepôt

Databricks SQL enregistre automatiquement les attributs clés de chaque requête : qui l'a exécutée, sur quel entrepôt et depuis quel outil. Mais ce n'est souvent pas suffisant.

Lorsqu'une requête Power BI est lente, vous savez qu'elle provient de Power BI, mais pas quel tableau de bord corriger. Lorsque les coûts augmentent, vous pouvez voir quels utilisateurs ont exécuté des requêtes, mais pas quel centre de coûts ou projet facturer. L'élément manquant est le contexte personnalisé, et c'est exactement ce qu'ajoutent les balises de requête.

Aujourd'hui, nous introduisons les balises de requête en aperçu public. Les balises de requête vous permettent d'attacher un contexte métier sous forme de paires clé-valeur à chaque exécution SQL, et de les interroger toutes via les tables système avec SQL standard — ou simplement en demandant à Genie. Les balises de requête sont également visibles dans l'interface utilisateur du profil de requête (la recherche dans l'interface utilisateur de l'historique des requêtes sera bientôt disponible).

Les balises de requête ont déjà connu une forte adoption, avec des centaines de clients marquant des millions de requêtes chaque semaine.

Il suffit de baliser : introduction des balises de requête

Avec les balises de requête, vous attachez des paires clé-valeur personnalisées (par exemple, « projet » : « planification_financière ») à chaque exécution SQL. Ces balises accompagnent la requête et sont enregistrées dans la table système de l'historique des requêtes, ce qui les rend disponibles pour le regroupement, le filtrage et l'analyse des charges de travail.

Les balises apportent de la valeur dans trois scénarios :

1. Outils partenaires : lors de l'utilisation de dbt, Power BI ou Tableau, propagez des identifiants tels que le nom du modèle dbt, l'ID du rapport Power BI ou le nom du classeur Tableau dans chaque requête.
2. Applications personnalisées : lors de la création d'applications via l'API d'exécution d'instructions SQL ou les connecteurs, attachez des métadonnées telles que `customerid`, `applicationname` ou `app_version` à chaque exécution.
3. Travaux ad hoc dans l'interface utilisateur Databricks : balisez les requêtes avec des dimensions pertinentes pour vous — environnement de développement ou de production, centre de coûts, nom d'expérience ou équipe.

Plongeons plus profondément dans ces scénarios.

(1) Remontez chaque requête d'outil partenaire à sa source

Les requêtes de dbt, Power BI et Tableau affluent dans votre entrepôt — mais sans balises, elles sont intraçables au-delà d'un ID utilisateur et de l'outil dont elles proviennent. Ces outils résolvent ce problème en injectant automatiquement des balises de requête, sans aucune balise manuelle requise.

dbt balise automatiquement chaque requête avec le nom du modèle, la version principale, la version de l'adaptateur et le type de matérialisation. Si un modèle dbt régresse soudainement en termes de performances, vous pouvez identifier exactement quel modèle, quelle version et quand :

Les responsables de l'ingénierie chez ASOS, Dipesh Bhundia et Dave Couse, ont ajouté :

« Sans avoir à configurer quoi que ce soit, nous pouvons mapper chaque charge de travail SQL au modèle dbt dont elle provient. Avec les balises de requête, nous pouvons enfin répartir avec précision les coûts de l'entrepôt par les équipes qui exécutent dbt dessus. »

Power BI et Tableau prennent en charge les balises de requête personnalisées au niveau de la connexion. Définissez-les une fois, et chaque requête provenant de cette connexion les portera automatiquement. Pour Tableau, les clients ont trouvé utile d'utiliser des paramètres comme [NomDuClasseur] comme valeur de balise, de sorte que l'attribution est préservée même lorsque le classeur est renommé.

Pour une liste complète des outils partenaires qui prennent en charge les balises de requête, consultez la documentation. Si votre outil n'est pas répertorié, contactez votre équipe commerciale.

(2) Transformez les requêtes API anonymes en charges de travail traçables

Les applications personnalisées accèdent à votre entrepôt via des API et des connecteurs, mais les requêtes qu'elles génèrent ne contiennent aucun contexte d'application — pas de nom d'application, pas de nom d'équipe, pas d'ID client. Les balises de requête vous permettent d'attacher ces métadonnées au niveau de la connexion ou de l'instruction.

L'API d'exécution d'instructions SQL prend en charge le balisage au niveau de l'instruction. Les balises passées en paramètre s'appliquent à cette exécution spécifique :

Le connecteur Python prend en charge le balisage au niveau de la connexion et de l'instruction. Définissez un nom d'équipe sur la connexion ; remplacez-le par instruction si nécessaire :

Matthew Haber, ingénieur DevOps chez Unit21, a partagé :

« Nous sommes passés d'un entrepôt par équipe à des entrepôts partagés pour réduire les coûts, mais nous avons perdu la visibilité sur quelle équipe générait les dépenses. Avec les balises de requête, nous transmettons simplement le nom de l'équipe à partir de notre connecteur Databricks SQL pour les charges de travail Python et nous avons cette attribution en retour — pas besoin de diviser à nouveau les entrepôts »

Pour la liste complète des connecteurs et pilotes pris en charge (Node.js, Go, JDBC, etc.), veuillez consulter la documentation.

(3) Étiquetez votre propre travail pour qu'il ne se perde pas dans le bruit

Les analystes exécutent des centaines de requêtes par semaine (exploration, production, débogage, etc.) et sans étiquettes, elles se ressemblent toutes dans les tables système. Les balises de requête permettent aux praticiens de baliser au fur et à mesure avec une seule ligne de SQL, partout où ils soumettent des requêtes : éditeur SQL, notebooks, tableaux de bord et alertes.

Une fois définies, toutes les instructions ultérieures de la session portent automatiquement ces balises. Pas besoin d'annoter chaque requête individuellement. Par exemple, l'ajout de l'instruction SET QUERY_TAGS à chaque requête de jeu de données dans un tableau de bord IA/BI balise chaque requête de ce tableau de bord avec « environnement : production ».

Les praticiens de données peuvent l'utiliser pour :

• Baliser l'analyse ad hoc par projet ou par équipe
• Marquer les expériences ou les tests A/B
• Identifier les charges de travail de développement ou de production
• Attacher un contexte de débogage lors de l'investigation de problèmes

Des balises aux réponses : surveillance avec les tables système

Une fois les requêtes balisées, les balises sont enregistrées dans la colonne query_tags de la table système de l'historique des requêtes. Désormais, les questions difficiles deviennent des requêtes SQL simples.

Quelle équipe génère les coûts de l'entrepôt ?

De nombreuses organisations doivent répartir les coûts partagés des entrepôts par équipe ou par produit. Avec les balises de requête, il s'agit d'une seule requête, sans division d'entrepôt ni devinettes.

Quel modèle dbt a introduit une régression ?

Lorsqu'un pipeline ralentit, vous devez savoir quel modèle, pas seulement quel entrepôt. Filtrez l'historique des requêtes du système par la balise de nom de modèle dbt auto-injectée pour isoler le problème.

Ou, évitez d'écrire du SQL en demandant à Genie. Étant donné que les balises de requête stockent le contexte métier dans les tables système, Genie peut raisonner sur vos données de charge de travail en langage naturel. Par exemple : « Quel modèle dbt a eu le plus de requêtes ? Lequel a eu les temps de requête moyens les plus longs ? »

Les balises de requête débloquent de nombreux autres cas d'utilisation de surveillance :

1. Grouper par query_tags['cost_center'] pour la refacturation
2. Filtrer par query_tags['@@dbt_model_name'] pour surveiller la santé du pipeline
3. Identifier les requêtes de longue durée par classeur Tableau
4. Comparer query_tags['env'] pour séparer le trafic de développement de la production

Prochaines étapes

Les balises de requête sont actuellement en aperçu public pour les entrepôts SQL, et nous travaillons déjà à les rendre encore plus utiles pour les expériences de surveillance de nos clients. Veuillez vous référer à la documentation pour les mises à jour.

• Balises automatiques Power BI : Power BI joindra automatiquement des métadonnées telles que DatasetId et ReportId à chaque requête sans aucune configuration. Vous pouvez l'activer manuellement dès aujourd'hui en suivant les étapes de la documentation. Le balisage automatique sera activé par défaut dans la prochaine version de Power BI.
• Prise en charge plus large des connecteurs : En plus de Python, le balisage au niveau des instructions est désormais disponible pour Go et Node.js.
• Recherche dans l'interface utilisateur : Nous prendrons bientôt en charge la recherche dans l'interface utilisateur de l'historique des requêtes, afin que vous puissiez rechercher des requêtes avec une balise spécifique (par exemple, « @@dbt_model_name » : « my_model »).
• Prise en charge au-delà des entrepôts SQL : Nous apportons les balises de requête aux notebooks et aux tâches Serverless, de sorte que le même modèle de balisage et d'attribution s'étend aux charges de travail des notebooks.ads.

Essayez les balises de requête dès aujourd'hui

Chaque requête non balisée est une occasion manquée d'attribution. Que vous ayez besoin de répartir les coûts de l'entrepôt par équipe, de retracer une requête lente jusqu'à un tableau de bord spécifique ou d'étiqueter le travail de l'analyste par projet, les balises de requête vous donnent le contexte nécessaire pour le faire.

Si vous utilisez dbt, vous balisez déjà (vérifiez la table système de votre historique de requêtes). Pour Power BI, Tableau et les applications personnalisées, la configuration prend quelques minutes. Pour le travail ad hoc, cela prend une ligne de SQL.

Les balises de requête sont disponibles dès aujourd'hui en aperçu public sur tous les clouds. Commencez par la documentation.

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