Configurez des budgets et des alertes pour les coûts de data warehouse cloud

Toutes les équipes d'analyse sont passées par là : une facture de fin de mois arrive, et un seul SQL warehouse a explosé son budget, peut-être à cause d'une ressource de calcul restée active toute la nuit, ou d'une requête ad hoc qui a fait l'objet d'une mise à l'échelle automatique pour répondre aux besoins de 80 utilisateurs Tableau lors d'une revue trimestrielle. Le coût est bien réel, mais la frustration est encore plus profonde : personne ne le savait avant qu'il ne soit trop tard.

La gestion proactive des coûts inverse ce modèle. Au lieu d'analyser les factures après coup de manière quasi chirurgicale, vous définissez des garde-fous avant même de dépenser le moindre dollar : les budgets sont associés aux SQL warehouses, aux équipes ou aux charges de travail BI. Des alertes se déclenchent aux seuils que vous choisissez, et des tableaux de bord affichent les tendances d'utilisation en temps réel, le tout sur la plateforme  Databricks Data & AI Platform. Si vous êtes en pleine migration depuis un système sur site ou un autre cloud data warehouse, c'est le moment idéal pour mettre en place cette gouvernance.

Pourquoi la gestion réactive des coûts échoue-t-elle ?

Les charges de travail de data warehousing présentent des défis uniques en matière de coûts. Les SQL warehouses gèrent des charges de travail interactives et pilotées par l'humain (tableaux de bord BI, analyses ad hoc, analyses intégrées) où la demande est imprévisible et irrégulière. Une simple réunion générale de la direction qui déclenche 200 rafraîchissements simultanés de tableaux de bord peut faire grimper les coûts en quelques minutes. La plupart des organisations commencent leur parcours FinOps de la même manière : quelqu'un télécharge le fichier CSV d'utilisation du mois dernier, ouvre un tableau croisé dynamique et commence à se poser des questions. Cette approche échoue pour quatre raisons :

• Vous ne pouvez pas voir qui dépense. L'utilisation est agrégée au niveau de la plateforme, et non de l'équipe ou de la requête qui l'a générée, de sorte que personne ne peut être tenu responsable d'un montant précis.
• Personne ne gère de budget. Sans objectifs de dépenses associés à un SQL warehouse ou à une équipe, l'analyste qui exécute SELECT * sur une table de 2 TB ne se rend jamais compte du coût. L'équipe en charge de la plateforme l'absorbe en silence.
• Vous le découvrez trop tard. Au moment où les rapports Excel du mois dernier révèlent le dépassement de budget, celui-ci remonte déjà à deux cycles de facturation et la décision qui l'a provoqué est devenue invisible.
• L'examen manuel n'est pas évolutif. Cinq SQL warehouses peuvent faire l'objet d'un examen mensuel par tableau croisé dynamique. Cependant, une fois passée à des dizaines de SQL warehouses, la prise en charge de centaines d'analystes sur Tableau, Power BI et Looker devient impossible à gérer.

La gestion proactive des coûts — attribution, budgets, alertes, tableaux de bord et optimisation — répond à ces cinq points.

Commencez par le serverless : la première décision en matière de coûts.

Avant de configurer des budgets, choisissez le bon type de SQL warehouse. Les SQL warehouses Serverless sont l'option recommandée par Databricks pour la plupart des charges de travail. Ils démarrent en quelques secondes, s'arrêtent dès que les requêtes sont terminées et permettent à la gestion intelligente des charges de travail (Intelligent Workload Management) d'allouer les ressources de calcul pour vous, de sorte que vous ne payez que pour l'exécution réelle des requêtes, et non pour l'inactivité.

Si vous migrez depuis un data warehouse cloud hérité, il s'agit d'un changement majeur. La plupart des plateformes héritées facturent les ressources de calcul toujours actives ou nécessitent des décisions de mise à l'échelle manuelles. Le Serverless élimine toute cette catégorie d'erreurs de coût.

Lumen Technologies l'a constaté de visu : la migration de deux systèmes de télécommunications essentiels d'un data warehouse sur site vers SQL Serverless a permis de réduire les coûts de calcul de 30 à 40 % et d'accélérer la vitesse des requêtes de 90 %. Le système s'adapte désormais automatiquement pour traiter environ 7 GB toutes les 10 minutes, le Serverless éliminant la « taxe de fonctionnement continu » généralement associée aux charges de travail irrégulières en temps réel.

Les cinq piliers de la gestion proactive des coûts

Le framework repose sur Microsoft cinq piliers. Les quatre premiers rendent vos dépenses visibles ; le cinquième est celui qui permet de les réduire concrètement :

• L'attribution des coûts. Marquez tout avec des tags pour savoir qui a dépensé quoi et sur quel SQL warehouse.
• Les budgets. Définissez des objectifs de dépenses mensuels au niveau du compte, de l'espace de travail ou de l'équipe.
• Les alertes. Soyez averti dès que les dépenses approchent ou dépassent un seuil.
• Les tableaux de bord. Visualisez les tendances des SQL warehouses et faites du coût une métrique opérationnelle de premier plan.
• Les optimisations. Réduisez le coût initial du travail.

Pilier 1 : L'attribution des coûts à deux niveaux

Vous ne pouvez pas gérer ce que vous ne pouvez pas attribuer, et avec les SQL warehouses, cela implique deux niveaux : le SQL warehouse lui-même et la requête individuelle. L'un vous indique quel SQL warehouse a dépensé l'argent ; l'autre vous indique qui l'a fait au sein de celui-ci.

Niveau 1 : Taguer le SQL warehouse

Les SQL warehouses prennent en charge les tags personnalisés sous forme de paires key:value qui se propagent dans system.billing.usage, associant chaque DBU consommée à une équipe, un projet ou un centre de coûts. Le marquage fonctionne de la même manière pour chaque type de SQL warehouse — Classic, Pro et Serverless sont tous tagués au niveau du SQL warehouse, ce qui vous permet d'apprendre un seul modèle et de l'appliquer partout.

Définissez des tags dans l'UI sous SQL Warehouses > votre SQL warehouse > Edit > Tags, ou créez le SQL warehouse via l'API REST :

Taguer via l'API REST

Appliquez au moins trois dimensions : l'équipe (à qui il appartient), le centre de coûts (qui paie) et le cas d'usage (service BI, ad hoc, rafraîchissement planifié).

Il n'existe pas aujourd'hui de politique native qui impose les tags sur les SQL warehouses, de sorte que n'importe qui peut en créer un sans tag. Intégrez plutôt cette obligation dans votre processus de provisionnement — créez des SQL warehouses avec Terraform, Declarative Automation Bundles ou l'API REST avec des tags dans la définition, et considérez l'UI comme l'exception. La requête sur l'écart d'attribution présentée plus bas dans cet article interceptera tout ce qui passe à travers les mailles du filet.

Niveau 2 : Taguer la requête

Les tags de SQL warehouse vous indiquent qu'un SQL warehouse a coûté 4 000 $ le mois dernier. Ils ne vous disent pas que 60 % de ce coût provient d'un seul tableau de bord Power BI qui se rafraîchit toutes les 15 minutes. Cet écart est important car les SQL warehouses sont partagés — un seul SQL warehouse BI dessert des dizaines de tableaux de bord, plusieurs modèles d'outils d'ingénierie de données dbt et un flux de requêtes ad hoc.

Les tags de requête (Public Preview) comblent ce manque en associant un contexte métier à chaque instruction SQL :

Les tags arrivent dans la colonne query_tags de system.query.history (Public Preview), aux côtés de executed_by et statement_id, ce qui vous permet de regrouper les dépenses par tableau de bord, modèle ou centre de coûts plutôt que par SQL warehouse. Certains outils les configurent pour vous : à partir de dbt-databricks 1.11.0, les requêtes de modèle sont automatiquement taguées avec le nom du modèle dbt, et Power BI transmet les identifiants d'espace de travail et de jeu de données via le pilote ADBC.

Deux remarques : les balises de requête s'appliquent uniquement aux requêtes SQL warehouse, et comme elles figurent dans l'historique des requêtes plutôt que dans les données de facturation, vous devez faire la jointure vous-même pour obtenir le coût par requête.

Avant d'écrire du SQL, consultez la page Coûts dans le Governance Hub (Bêta) — une vue au niveau du compte des dépenses, des facteurs de coûts, des budgets et de la couverture des balises, et le moyen le plus rapide de voir quelle part de votre utilisation est attribuable. Un administrateur de compte l'active depuis la page Previews de la console de compte.

Pilier 2 : Définir des budgets dans la console de compte

Créer un budget

Dans la console de compte, accédez à Usage > Budgets, cliquez Add budget, puis configurez :

• Nom : Descriptif (par ex., « Analytics SQL Warehouses, Monthly »)
• Montant : Objectif mensuel en USD
• Portée : Filtrer par espaces de travail et/ou balises (par ex., Team:Analytics)
• Notifications par e-mail : Destinataires notifiés lorsque les dépenses atteignent le montant du budget

Exemples de configurations de budget

Le modèle clé repose sur des budgets superposés : des budgets au niveau de l'équipe pour la responsabilisation, plus un budget à l'échelle du compte comme filet de sécurité pour intercepter tout ce qui passe à travers les mailles du filet. 

Gardez à l'esprit que les budgets sont un mécanisme de suivi, pas une limite stricte. Ils n'arrêtent pas l'utilisation et n'empêchent pas la facturation, votre facture peut donc tout de même dépasser ce montant. L'objectif est la sensibilisation et la réactivité, et non des coupures qui pourraient interrompre un tableau de bord de production en plein rafraîchissement.

GetYourGuide a testé cela directement : la consolidation de toutes leurs charges de travail Looker sur SQL Serverless a réduit les coûts de service BI d'environ 20 % et a accéléré les requêtes de 35 %, même si l'équipe s'attendait à ce que les clusters Classic soient moins chers. Le choix du type de warehouse est une décision budgétaire qui mérite d'être réévaluée, et non un choix unique.

Analyser votre vitesse de consommation

Cliquez sur n'importe quel budget pour voir les dépenses actuelles par rapport à l'objectif, le budget restant et une visualisation quotidienne de la vitesse de consommation. Pour le data warehousing, ce graphique est particulièrement révélateur :

• Une consommation quotidienne linéaire est synonyme de coûts de service BI stables.
• Un profil en dents de scie avec des pics le lundi et le vendredi indique une exploration ad hoc concentrée sur les jours ouvrables.
• Une hausse soudaine en milieu de mois signifie qu'un nouveau tableau de bord a été déployé sans examen des coûts.
• Une dérive progressive à la hausse signifie que l'adoption organique dépasse vos prévisions budgétaires.

Pilier 3 : Les alertes, le système nerveux de la gouvernance des coûts

Les budgets vous indiquent où vous en êtes. Les alertes vous indiquent quand agir.

Alertes budgétaires par e-mail

Lorsque vous créez un budget, ajoutez des destinataires par e-mail qui seront informés lorsque les dépenses dépassent le montant du budget. Aucun code n'est nécessaire.

Pour les alertes basées sur des seuils, créez des alertes Databricks SQL qui interrogent directement `system.billing.usage`. Voici les modèles les plus importants :

Alerte lorsque les dépenses quotidiennes de SQL warehouse dépassent un seuil

Alerte de rythme : les dépenses prévues pour la fin du mois dépasseront le budget

C'est le modèle qui apporte le plus de valeur aux équipes. Au lieu de déclencher une alerte après le dépassement, il projette les dépenses de fin de mois et se déclenche avant que cette projection ne dépasse votre budget, vous laissant ainsi le temps d'agir :

Planifiez cela toutes les quatre heures et envoyez les notifications vers Slack ou par e-mail. Cela donne aux équipes plusieurs jours pour réagir (redimensionner un warehouse, optimiser une requête coûteuse, reporter un traitement par lots) avant que le budget ne soit dépassé.

Détecter les coûts cachés des rafraîchissements de vues matérialisées

Les coûts de rafraîchissement des vues matérialisées sont ceux que les équipes oublient le plus souvent, car ils sont facturés en tant qu'utilisation de pipeline serverless plutôt qu'en tant qu'utilisation de warehouse. Une vue configurée pour se rafraîchir toutes les 15 minutes par rapport à une source mise à jour deux fois par jour génère des dépenses inutiles. Adaptez la fréquence de rafraîchissement à la fréquence réelle de modification des données sous-jacentes, puis surveillez directement les dépenses du pipeline :

Pilier 4 : Tableaux de bord et surveillance continue

Les alertes sont des déclencheurs ponctuels. Les tableaux de bord offrent un contexte continu. Databricks fournit des tableaux de bord d'utilisation prédéfinis que les administrateurs de compte peuvent importer dans n'importe quel espace de travail activé pour Unity Catalog. Ceux-ci couvrent les tendances de dépenses, l'analyse des N premiers, le filtrage par tag et les analyses détaillées par entrepôt. Pour un suivi personnalisé, deux requêtes sont particulièrement utiles :

Coût de l'entrepôt SQL par équipe

Utilisation SQL non attribuée (écart d'attribution)

L'utilisation SQL sans tag constitue votre écart d'attribution, c'est-à-dire des dépenses d'entrepôt qui ne peuvent être attribuées à aucune équipe. Réduisez-les à zéro.

Raiffeisen Bank International a développé sa propre plateforme de suivi et de prévision des coûts directement sur les tables système de Databricks, avec une visibilité par entrepôt, par utilisateur et par charge de travail. Le bénéfice a été autant culturel que technique : des charges de travail 3 à 4 fois plus rapides et, plus important encore, lorsque les équipes peuvent voir leurs propres dépenses et doivent les expliquer, les comportements changent d'eux-mêmes sans avoir besoin de directives.

Pilier 5 : L'optimisation, le pilier qui change réellement la facture

Les quatre premiers piliers consistent à visualiser vos dépenses. Celui-ci vise à les réduire, et c'est celui que la plupart des équipes négligent. Commencez par les deux changements qui améliorent simultanément les coûts et les performances.

Activez l'optimisation prédictive pour les tables gérées de Unity Catalog. Databricks exécute OPTIMIZE, VACUUM et ANALYZE pour vous en fonction de la manière dont chaque table est réellement interrogée, et avec CLUSTER BY AUTO, il ajuste les clés de clustering à mesure que les modèles de requête évoluent. Moins de données analysées signifie des requêtes plus rapides et moins de DBU, sans aucun calendrier de maintenance à gérer. Cette fonctionnalité est activée par défaut pour les comptes créés à partir du 11 novembre 2024, et sera déployée sur les comptes plus anciens d'ici 2026.

Utilisez par défaut les entrepôts serverless pour bénéficier des économies de démarrage et d'inactivité décrites précédemment — pour la plupart des équipes, cela représente l'essentiel des économies, sans effort continu.

À partir de là, quelques paramètres méritent d'être ajustés :

• Raccourcissez l'arrêt automatique. Les versions Pro et Classic s'arrêtent par défaut après 45 minutes d'inactivité ; la version serverless s'arrête par défaut après 10 minutes, et vous pouvez descendre à 5 dans l'UI ou à 1 via l'API. Chaque minute d'inactivité sur un entrepôt BI après la fermeture du dernier tableau de bord est un gaspillage.
• Définissez un délai d'expiration des requêtes (Beta — activez la version préliminaire, puis configurez-le par entrepôt via l'API). Une requête hors de contrôle ne devrait pas consommer un week-end entier de calcul ; gardez ce délai court sur les entrepôts BI et plus long sur l'ETL.
• Désignez un entrepôt par défaut (Paramètres d'administration > Calcul) afin qu'un simple coup d'œil à dix lignes ne réveille pas un cluster de la taille d'un ETL, et commencez par une taille Small ou Medium plutôt que de surprovisionner.
• Adaptez la taille ou le nombre d'instances à bon escient. La mise à l'échelle verticale (scaling up — des tailles plus grandes, désormais jusqu'à 5X-Large en Public Preview) accélère une seule requête lourde ; la mise à l'échelle horizontale (scaling out — un nombre maximal de clusters plus élevé) sert plus d'utilisateurs simultanés. Se tromper de méthode est une erreur courante et coûteuse.

La couche de données est également importante : OPTIMIZE, VACUUM, et le liquid clustering réduisent chacun la puissance de calcul requise par une requête, et cet effet s'accumule sur des milliers de requêtes BI par jour.

Au fond, la plupart des problèmes de coûts sont des problèmes de requêtes. Une clé de jointure manquante ou un SELECT * sur une table large coûte le même prix, quelle que soit la configuration de l'entrepôt — et l'attribution du Pilier 1 est ce qui vous indique quelles requêtes et quels tableaux de bord corriger.

Points clés à retenir

1. Intégrez le serverless et l'attribution dans la plateforme dès le premier jour. Utilisez par défaut des entrepôts SQL Serverless pour un démarrage instantané, une mise à l'échelle automatique et aucun coût d'inactivité, et imposez des tags personnalisés dès le départ, car l'utilisation non attribuée est invisible et l'utilisation invisible augmente toujours.

2. Budgétisez et alertez de manière proactive, à plusieurs niveaux. Associez des budgets par équipe pour responsabiliser chacun à un budget global au niveau du compte pour détecter les anomalies, et configurez des alertes basées sur le rythme de consommation, et pas seulement sur des seuils, afin d'être informé d'un dépassement à temps pour agir plutôt qu'après coup.

3. Rendez les dépenses visibles et intégrez-les à votre culture.  Les économies les plus durables proviennent de la transparence, pas des restrictions. Placez donc les tableaux de bord de coûts là où les équipes travaillent. Comme l'a constaté RBI, lorsque les équipes peuvent voir leurs propres dépenses, les comportements changent d'eux-mêmes sans directives.

Commencer

Voici le chemin le plus rapide pour commencer et maîtriser vos factures avant qu'elles n'explosent :

• Créez votre premier budget dans la console de compte. 
• Attribuez l'utilisation en taguant votre entrepôt SQL et vos requêtes
• Suivez les coûts avec les tables système, interrogez system.billing.usage pour obtenir des informations spécifiques à l'entrepôt
• Dimensionnement et comportement de mise à l'échelle des SQL warehouses, comprenez le fonctionnement économique de l'IWM et du serverless
• Meilleures pratiques d'optimisation des coûts, dimensionnement des entrepôts, Photon et optimisation de Delta Lake
• Du chaos au contrôle : un parcours de maturité des coûts avec Databricks, le cadre progressif (ramper, marcher, courir) pour la maturité FinOps

Prêt à prendre le contrôle des coûts de votre entrepôt de données cloud ? Créez un compte d'essai gratuit Databricks, configurez votre premier entrepôt SQL Serverless et définissez un budget avec des alertes e-mail dans la console de compte. Cela prend cinq minutes et ne coûte rien.

Pour approfondir l'observabilité des coûts, explorez la documentation sur les tables système de facturation et importez le tableau de bord d'utilisation prédéfini pour commencer à suivre vos dépenses dès le premier jour.

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