Top 5 des requêtes sur les tables système pour comprendre vos coûts Databricks

Databricks les tables système fournissent une mine d'informations sur la façon dont vous utilisez Databricks et sur ce que cela coûte. En se concentrant sur les coûts, la table `system.billing.usage` fournit une vue globale et agrégée des coûts pour l'ensemble de votre compte Databricks. Associée à la table `system.billing.list_prices`, elle vous permet de comprendre précisément comment les dépenses sont réparties. Databricks propose un tableau de bord d'utilisation prédéfini qui constitue un excellent point de départ pour comprendre les coûts. Cependant, comprendre les tables sous-jacentes et créer des requêtes sur celles-ci vous permet d'aller plus loin dans vos analyses, en particulier en tirant parti des fonctionnalités de visualisation de Databricks.

Voici cinq requêtes pour commencer à mieux comprendre vos dépenses. Nous commençons par une ventilation quotidienne simple des dépenses par produit, puis nous progressons vers la compréhension des dépenses sous l'angle de SQL Warehouses et de balises spécifiques, pour enfin identifier les jours de dépenses anormales et prévoir les dépenses futures grâce à l'AI. Toutes ces requêtes fournissent des informations précieuses via les résultats retournés, mais elles sont encore plus efficaces lorsqu'elles sont utilisées comme ensembles de données dans un tableau de bord AI/BI où les données peuvent être visualisées et explorées plus en détail avec Genie.

Requête 1 : Dépenses quotidiennes par produit

Ce que montre la requête

Notre première requête est simplement une ventilation des dépenses par jour et par produit. Nous joignons la table d'utilisation (notre table de faits) à notre table de tarification (une dimension SCD de type 2) pour obtenir nos dépenses au fil du temps au tarif catalogue. Comme mentionné ci-dessus, vous pouvez remplacer la table des tarifs catalogue fournie par une table personnalisée intégrant les remises applicables afin de visualiser les coûts exacts.

Quand utiliser cette requête

Cette requête est idéale pour se faire une idée de la manière dont votre environnement Databricks est utilisé, des produits dont l'usage augmente ou diminue, et du montant total des dépenses. Je commencerais toujours par là lors de l'examen des dépenses Databricks.

Points de vigilance

La table `system.billing.usage` ne contient que les coûts Databricks. Cela signifie que dans tous les cas où un calcul non serverless est utilisé, les dépenses d'infrastructure cloud ne sont pas incluses et doivent être examinées via la console cloud correspondante (calcul, réseau, stockage, etc.).

Requête 2 : Tendances des coûts des Warehouses

Ce que montre la requête

Les Databricks SQL Warehouses sont un outil incroyablement puissant pour accompagner les analystes SQL, les tableaux de bord et les agents Genie. Comprendre l'évolution de leurs coûts est essentiel pour toute personne gérant un compte Databricks. La requête 2 vous permet de voir les tendances de l'utilisation quotidienne des warehouses, ce qui, puisque vous payez à la consommation, est analogue à leur utilisation.

Quand utiliser cette requête

Avec Databricks, vous payez à la consommation. Ainsi, pouvoir observer les tendances des coûts d'un warehouse revient à observer les tendances de son utilisation (du moins dans le sens où le temps de fonctionnement est lié à l'utilisation). Cette requête peut donc essentiellement montrer l'utilisation des warehouses, où une utilisation plus élevée pourrait être due à un temps de fonctionnement plus long ou à un dimensionnement supérieur plus fréquent. Après avoir identifié un warehouse à analyser plus en détail avec cette requête, vous pouvez approfondir vos recherches sur ce warehouse à l'aide de la table système `system.compute.warehouse_events` ou de la page de surveillance du warehouse, et vérifier si celui-ci pourrait bénéficier de paramètres de mise à l'échelle ou d'arrêt automatique différents. L'utilisation du warehouse peut également donner un aperçu rapide de la manière dont les tableaux de bord ou les espaces Genie créés à partir de ceux-ci sont utilisés, et s'il convient de faire davantage pour les promouvoir auprès des utilisateurs métier.

Points de vigilance

Par défaut, cette requête inclut tous les warehouses qui étaient actifs au cours de la période examinée, y compris ceux qui ont été supprimés. Une colonne incluse (is_deleted) peut être utilisée comme filtre supplémentaire si vous souhaitez exclure les warehouses supprimés de l'analyse.

Requête 3 : Attribution des coûts basée sur les balises

Ce que montre la requête

Les tags sont une fonctionnalité puissante qui peut être utilisée pour suivre l'utilisation par utilisateur, projet, équipe ou espace de travail. Plus précisément, les tags personnalisés peuvent être appliqués via des politiques de calcul et des politiques d'utilisation serverless, puis vous pouvez utiliser ces tags lors de l'analyse des données d'utilisation des tables système. Par exemple, vous pourriez choisir d'imposer le marquage par équipe, où les valeurs autorisées correspondent à des unités commerciales, comme le marketing, la finance et l'ingénierie. Ensuite, en utilisant cette requête dans laquelle vous avez paramétré le tag sur lequel vous effectuez le regroupement, vous pouvez voir l'utilisation par équipe.

Quand utiliser la requête

Cette requête peut être utilisée dès qu'une stratégie de marquage est en place et que vous souhaitez voir les coûts en fonction des valeurs du tag. Chaque enregistrement de votre table n'a pas besoin d'être tagué ; si la clé de tag n'existe pas sur l'enregistrement, il sera enregistré comme non tagué. Il pourra alors être exclu de votre analyse par filtrage ou être utilisé pour identifier les endroits où le marquage n'est pas correctement appliqué.

Points d'attention

Comme mentionné précédemment, les enregistrements qui ne sont pas tagués apparaîtront comme non tagués, ce qui peut être utile pour identifier les zones où le marquage n'est pas appliqué, mais peut également être indésirable car le tag peut ne s'appliquer qu'à une partie de l'utilisation. Vous pouvez modifier la requête en incluant `u.custom_tags[:tag_key] is not null` dans la clause where pour filtrer complètement les enregistrements sans tag, ou aller plus loin en filtrant sur plusieurs tags ou en ajoutant plusieurs tags au regroupement (group by) de la requête.

Requête 4 : Détection des anomalies de coût quotidien

Ce que montre la requête

De bons contrôles via des politiques de calcul, des paramètres de délai d'expiration des tâches et des budgets aident les administrateurs de la plateforme Databricks à maintenir les dépenses dans les limites fixées, mais il est toujours possible qu'un utilisateur disposant d'autorisations suffisantes crée une tâche ou un entrepôt qui s'exécute trop longtemps ou reste dimensionné au-delà des prévisions, provoquant ainsi une hausse inattendue des dépenses. La requête 4 est conçue pour aider à détecter cela le plus rapidement possible. En toute simplicité, elle utilise la moyenne mobile des dépenses sur 14 jours et classe les dépenses quotidiennes comme élevées si elles dépassent la moyenne de plus d'un écart-type, ou comme une anomalie si elles la dépassent de plus de deux.

Quand utiliser la requête

Cette requête est idéale pour être intégrée dans un tableau de bord de suivi des coûts, ou vous pouvez utiliser cette idée comme base pour une alerte qui enverrait automatiquement un e-mail aux administrateurs si les dépenses de la veille étaient élevées ou anormales.

Points d'attention

Si votre charge de travail est très irrégulière d'un jour à l'autre, les écarts-types de votre utilisation peuvent être très élevés et cette requête risque de ne détecter que les pics d'utilisation les plus importants.

Requête 5 : Prévision des dépenses

Ce que montre la requête

Dans les quatre requêtes précédentes, nous nous sommes concentrés sur l'analyse des dépenses passées, mais les dépenses futures sont essentielles pour obtenir une vue d'ensemble de votre utilisation de Databricks. Normalement, cela nécessiterait une modélisation complexe des prévisions, mais parmi les fonctions SQL AI de Databricks se trouve la puissante fonction ai_forecast, qui vous permet d'extrapoler dans le futur un ensemble de données de séries chronologiques, comme vos données d'utilisation de Databricks. Vous pouvez ajuster la quantité de données fournies à la fonction, visualiser les résultats dans un graphique et générer très rapidement une prévision de vos dépenses Databricks.

Quand utiliser la requête

Là encore, cette requête est idéale à ajouter à un tableau de bord de suivi des coûts afin d'avoir une idée de vos dépenses futures pour faciliter la planification et la budgétisation.

Points d'attention

Cette requête effectue des prévisions basées sur des données antérieures. Si vous l'utilisez pour votre planification future, veillez à prendre en compte les nouvelles charges de travail nettes que vous pourriez planifier et qui ne seraient pas prédites par cette prévision.

Essayer les requêtes de table système 

Exécuter ces requêtes une fois vous indique ce qui s'est passé. Les épingler à un tableau de bord AI/BI change la façon dont votre équipe gère les dépenses. Intégrez chacune d'elles en tant que jeu de données, configurez les paramètres de plage de dates et de balises, et faites de ce tableau de bord votre outil de suivi hebdomadaire des coûts. Pour aller plus loin, voici deux étapes suivantes : ajoutez aux favoris la référence des tables système Databricks pour accéder au catalogue complet des tables que vous pouvez interroger, et explorez d'autres exemples de requêtes pour enrichir votre boîte à outils au-delà de ces cinq exemples. Vous n'avez pas encore d'espace de travail ? Commencer un essai gratuit.    

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