TL;DR
L'optimisation des coûts Databricks repose sur cinq habitudes : savoir d'où viennent réellement vos coûts (le tarif DBU plus une facture d'infrastructure cloud distincte), éliminer le compute inactif grâce à l'auto-termination et aux timeouts, dimensionner correctement le compute en optant par défaut pour le serverless et en réservant le compute classique à vos workloads les plus coûteux, repenser les workflows autour de la fréquence d'exécution et du traitement incrémental, et verrouiller les paramètres de stockage et de gouvernance pour que les gains ne s'érodent pas avec le temps. Quelques chiffres concrets issus du webinaire : un cluster GPU non surveillé a ajouté 4 000 $ à une facture mensuelle de 20 000 $ avant que quiconque ne s'en aperçoive, et réduire la fréquence d'exécution d'un job de 472 fois par jour à une fois par heure a permis d'économiser 95 % de son coût, soit environ 19 000 $ par an.
Pourquoi les coûts Databricks sont difficiles à maîtriser
Databricks offre aux équipes data une liberté inhabituelle. Vous pouvez exécuter le même pipeline sous forme de cluster interactif, de job planifié ou de job serverless, sur du compute classique ou serverless, avec une douzaine de types de nœuds et de configurations de scaling différents entre les deux. Cette flexibilité est précisément ce qui complique le contrôle des coûts. Plus d'options, c'est plus de façons de mal configurer quelque chose, et les factures Databricks ne permettent pas toujours de s'en apercevoir.
C'était le point de départ d'un récent webinaire animé par Ian Whitestone, cofondateur de SELECT, et Olivier Soucy, consultant Databricks qui a passé des années à construire des plateformes data de zéro, notamment en tant que head of data d'une plateforme d'échange de cryptomonnaies où il a bâti un environnement Databricks à partir de rien. Soucy dirige aujourd'hui son propre cabinet de conseil spécialisé dans les coûts et les performances Databricks, et il a profité de la session pour présenter cinq stratégies concrètes pour maîtriser les dépenses Databricks, chacune étayée par des chiffres réels issus de missions clients.
Voici un récapitulatif de ce qu'il a abordé.
Commencez par comprendre où part réellement l'argent
Avant d'optimiser quoi que ce soit, vous devez savoir ce que vous payez, et Databricks ne vous facilite pas la tâche. Les coûts proviennent de deux sources distinctes : le tarif Databricks Unit (DBU) facturé par Databricks lui-même, et le compute cloud sous-jacent facturé par AWS, Azure ou GCP pour les instances provisionnées par Databricks.
Le tarif DBU à lui seul peut être trompeur. Soucy a passé en revue un même pipeline ETL facturé de trois façons différentes : exécuté comme cluster interactif, il coûte 55 cents par DBU ; comme job sur du compute classique, 30 cents par DBU ; comme job serverless, 45 cents par DBU. Si l'on s'en tient au seul prix du DBU, le serverless semble l'option la plus chère. Mais le compute classique s'accompagne aussi d'une facture d'infrastructure cloud distincte, ce qui n'est pas le cas du serverless : la réalité est donc souvent très différente une fois les deux coûts additionnés.
La plupart des équipes ne les additionnent jamais. Soucy l'a dit sans détour lorsque Whitestone lui a demandé si les clients suivaient conjointement le coût DBU et le coût d'infrastructure cloud au niveau des jobs : en général, non, parce que des équipes différentes gèrent chaque volet. Une équipe Databricks surveille les tables système et les workflows ; une équipe cloud regarde la facture AWS ou Azure et traite Databricks comme une simple ligne de facturation. Croiser les deux sources de données avec les bons tags représente un effort suffisant pour que la plupart des organisations y renoncent, même en sachant que c'est important.
Databricks expose bien des tables système contenant des données d'utilisation et de tarification, ce qui suffit à construire un modèle de coût raisonnablement précis pour les dépenses DBU. Pour le compute classique (non serverless), la règle empirique de Soucy est de considérer que le coût de l'infrastructure cloud sous-jacente est à peu près égal au coût DBU : une facture DBU de 50 000 $ frôle donc souvent les 100 000 $ une fois le compute cloud ajouté. C'est une estimation grossière, qui varie beaucoup pour les workloads GPU, mais c'est un point de départ raisonnable si vous n'avez pas encore de meilleur modèle. Pour une analyse plus poussée du fonctionnement réel de la tarification Databricks, SELECT a détaillé les trois leviers qui comptent le plus.
Éliminez le gaspillage avant toute autre optimisation
Le compute inactif est, selon Soucy, l'erreur la plus coûteuse qu'une équipe puisse commettre, car vous payez pour des ressources qui ne produisent aucune valeur pendant qu'elles tournent. Il a partagé deux exemples tirés de ses propres missions. Dans un cas, un nouveau stagiaire a lancé un cluster GPU sans auto-termination ni garde-fous. Il a tourné pendant des semaines, ajoutant environ 4 000 $ à une facture mensuelle de 20 000 $, avant que quiconque ne s'en aperçoive. Dans un autre, un job qui s'exécutait sans problème en une vingtaine de minutes en QA a rencontré des données différentes en production et a tourné pendant 47 heures avant d'être repéré.
Les correctifs sont simples et méritent d'être appliqués indépendamment de tout le reste :
- Configurez l'auto-termination sur chaque cluster et chaque warehouse. Soucy a suggéré environ 30 minutes d'inactivité pour les clusters et 10 minutes pour les warehouses comme valeurs par défaut raisonnables, même si le chiffre exact importe moins que le fait d'en avoir un.
- Activez l'auto-scaling pour que le compute s'adapte à la demande réelle au lieu de rester provisionné à pleine capacité en permanence.
- Définissez des timeouts pour les jobs et les requêtes. Le timeout par défaut des instructions SQL dans Databricks est de deux jours, ce que les deux intervenants ont jugé beaucoup trop long. Whitestone l'a dit sans ambages : si une requête tourne depuis plus d'un jour, elle ne devrait probablement plus tourner, et cette valeur par défaut mérite d'être abaissée à l'échelle du compte.
- Utilisez les cluster policies pour l'imposer. Plutôt que de compter sur chacun pour penser à l'auto-termination, les cluster policies peuvent l'exiger au niveau du compte.
Dimensionnez le compute en fonction du job
Une fois le gaspillage maîtrisé, l'erreur suivante la plus fréquente est le surprovisionnement : allouer plus de compute qu'un workload n'en a besoin. La recommandation par défaut de Soucy, dont il reconnaît qu'elle est un peu controversée, est d'utiliser le serverless par défaut, sauf raison précise de faire autrement.
Il a illustré ce point avec le pipeline ETL horaire d'un client. Sur du compute classique, le job consommait environ 44 DBU par jour à 30 cents par DBU (soit environ 13 $ par jour en coût DBU), plus 10 $ par jour d'infrastructure cloud, pour un total proche de 23 $ par jour. Migré vers le serverless, le même job consommait 38 DBU à un tarif par DBU plus élevé, mais le coût total s'est révélé similaire, et même légèrement inférieur dans ce cas, principalement parce que le serverless élimine les deux à quatre minutes de démarrage de cluster que le compute classique paie à chaque exécution. Cette suppression du démarrage a aussi fait passer la durée totale du job de 20 à 12 minutes.
Le conseil pratique de Soucy : si vous débutez avec Databricks ou n'avez pas encore optimisé vos workflows, passez tout en serverless par défaut, puis identifiez les cinq à dix workloads qui pèsent le plus sur votre facture et envisagez de ne rebasculer que ceux-là sur du compute classique, où vous disposez de davantage de leviers pour arbitrer entre coût et performance. Pour tout le reste, le temps de tuning n'en vaut généralement pas la peine. Le point de bascule tient le plus souvent à la durée du workload : les jobs qui tournent plusieurs heures d'affilée ont plus de chances de bénéficier du compute classique, où vous pouvez ajuster finement le type de nœud, l'autoscaling et le nombre de workers.
Pour le compute classique, Soucy recommande de commencer avec la plus petite taille d'instance disponible et de ne monter en gamme qu'en cas de véritables goulets d'étranglement, en s'appuyant sur les métriques de la Spark UI comme l'utilisation du CPU et des nœuds. Démarrer trop gros tend à produire ce qu'il appelle une facture silencieuse : pas d'erreurs, pas d'échecs, juste un coût constamment plus élevé que nécessaire. Il vaut aussi la peine d'adapter le type de compute au workload. Le travail purement SQL a sa place sur les SQL warehouses, la logique générale des jobs sur le job compute, et les clusters interactifs (all-purpose) devraient être réservés au travail réellement interactif. Whitestone a souligné qu'il s'agit de l'un des pièges les plus fréquents observés par SELECT : exécuter un job planifié sur un cluster interactif plutôt que sur un cluster de job dédié peut quasiment doubler le coût Databricks de ce job, sans aucun bénéfice.
Repensez le workflow lui-même
Au-delà du dimensionnement du compute, plusieurs changements dans la façon de concevoir les pipelines se sont révélés parmi les optimisations à plus fort effet de levier.
La fréquence d'exécution compte plus que la plupart des équipes ne l'imaginent. En prenant une mise à jour quotidienne comme référence, passer à des exécutions horaires multiplie le coût par environ cinq, et les mises à jour en quasi temps réel le multiplient par environ 60. Le conseil de Soucy : remettez en question les exigences de temps réel ou de quasi temps réel des parties prenantes métier, car la plupart des demandes de dashboards temps réel signifient simplement que le rapport doit refléter un instant précis, pas un flux continu.
Utilisez des vues plutôt que de dupliquer des tables. Pour de simples filtres ou sélections de colonnes, créer une vue plutôt qu'une nouvelle table physique évite de copier les données et d'assumer le coût récurrent de maintenance de cette copie, sans réel inconvénient pour ceux qui l'interrogent.
Traitez en incrémental plutôt que de tout retraiter. L'Auto Loader de Databricks peut identifier automatiquement les fichiers nouveaux ou modifiés sur le stockage cloud et, combiné au structured streaming, il permet à un pipeline de ne traiter que ce qui a changé plutôt que l'ensemble du jeu de données à chaque exécution. Soucy a qualifié cette approche de plus complexe à mettre en place, mais essentielle pour tout workload à fort volume.
Profilez et réécrivez les requêtes coûteuses. La vue de profil de requête de Databricks montre comment Spark a réellement exécuté une transformation, y compris les shuffles et les spills qui passent facilement inaperçus. Soucy a indiqué que fournir ces informations de profil, avec le code de transformation sous-jacent, à un assistant de code IA a produit des réécritures réellement exploitables dans son propre travail, transformant une tâche qui exigeait autrefois une expertise Spark pointue en quelque chose de bien plus accessible.
Ne négligez pas le stockage, et pérennisez le tout
Côté stockage, le conseil de Soucy est d'éviter le réglage manuel du partitionnement et du Z-ordering pour s'appuyer plutôt sur les tables managées d'Unity Catalog, qui prennent en charge l'optimisation prédictive. L'optimisation prédictive exécute automatiquement et de façon planifiée les opérations vacuum, optimize et analyze : nettoyage des fichiers obsolètes, compactage des petits fichiers en fichiers plus volumineux et rafraîchissement des métadonnées pour que les requêtes puissent ignorer les fichiers qu'elles n'ont pas besoin de lire. Son exécution a un coût, mais l'effet net est généralement une facture plus basse que ce que produirait une maintenance manuelle. Le liquid clustering, qui a largement remplacé le Z-ordering manuel, offre un avantage similaire : il ne nécessite pas de réécrire les données existantes lorsque les colonnes de clustering doivent changer.
Rien de tout cela ne tient dans la durée sans gouvernance. Soucy recommande de gérer l'ensemble sous forme de code, avec des outils comme Terraform ou les Databricks Asset Bundles, déployés via la CI/CD, afin que les configurations restent cohérentes entre environnements et ne dérivent pas en silence. Les cluster policies sont ici le principal levier : définissez des valeurs par défaut raisonnables pour la plupart des utilisateurs, imposez l'auto-termination et des limites de types de nœuds, et laissez aux utilisateurs avancés qui ont réellement besoin de plus de flexibilité la possibilité d'en faire la demande. Les cluster pools peuvent également aider en gardant un ensemble d'instances prêtes côté fournisseur cloud, afin que les jobs n'attendent pas le démarrage d'un cluster — mais vous payez tout de même cette capacité inactive au fournisseur cloud, même si Databricks ne vous la facture pas.
Soucy a aussi signalé une catégorie de coûts souvent négligée : les fonctionnalités Databricks plus récentes comme les apps, les endpoints de model serving, la vector search et les quality monitors. Il a raconté avoir lui-même mal configuré un quality monitor sur une grande table, ce qui a augmenté la facture quotidienne de cette table de 50 % avant qu'il ne s'en rende compte. Whitestone a ajouté que les fonctionnalités liées à l'IA devraient devenir un poste croissant des factures Databricks en général, citant la décision récente de Databricks de commencer à facturer des outils jusque-là gratuits comme Genie. La conclusion des deux intervenants : configurez des alertes de coûts avant d'activer quoi que ce soit de nouveau, pas après.
Le fil conducteur
À travers ces cinq stratégies, le même schéma se répète : les dérives de coûts sur Databricks se produisent rarement de manière bruyante. Les clusters inactifs tournent en silence, les jobs exécutés trop fréquemment tournent en silence, le compute surdimensionné tourne en silence, et les nouvelles fonctionnalités sont activées sans que personne ne vérifie ce qu'elles coûteront avant l'arrivée de la facture. Les correctifs présentés ici n'ont rien d'exotique. L'auto-termination, des timeouts raisonnables, l'adéquation du type de compute au workload et la gestion de la configuration sous forme de code suffisent à traiter l'essentiel des dépenses évitables pour la plupart des équipes.
Pour les équipes qui préfèrent automatiser plutôt que tout gérer à la main, SELECT pour Databricks met directement en évidence ce type de gaspillage : auto-termination manquante, jobs exécutés trop fréquemment (dans un exemple réel partagé pendant la session, faire passer un job de 472 exécutions par jour à une par heure a permis d'économiser 95 % de son coût, soit environ 19 000 $ par an), et warehouses ou jobs responsables d'une part disproportionnée des dépenses, jusqu'à la requête individuelle. Découvrez son fonctionnement sur select.dev.
FAQ
Quel est le principal facteur de coûts Databricks inutiles ? Le compute inactif. Les clusters et warehouses laissés en fonctionnement sans auto-termination, ou les jobs qui tournent indéfiniment sans timeout, génèrent des coûts sans aucune valeur en retour. Corriger ce point avant tout le reste offre généralement les gains les plus rapides.
Faut-il choisir le serverless ou le compute classique par défaut sur Databricks ? Le serverless est un choix par défaut raisonnable pour la plupart des workloads, puisqu'il supprime le temps de démarrage des clusters et place la plupart des équipes dans la bonne fourchette de coûts sans réglage manuel. L'exception : vos cinq à dix workloads les plus coûteux, qui bénéficient généralement du contrôle supplémentaire qu'offre le compute classique sur le type de nœud, l'autoscaling et le nombre de workers.
Quelle est la différence entre le coût DBU et le coût d'infrastructure cloud ? Le tarif DBU (Databricks Unit) correspond à ce que Databricks lui-même facture pour le compute, et il varie selon le type de compute. Le compute classique entraîne en plus une facture d'infrastructure cloud distincte auprès d'AWS, Azure ou GCP pour les instances sous-jacentes, ce qui n'est pas le cas du serverless. En règle générale, considérez que le coût d'infrastructure cloud est à peu près égal au coût DBU pour le compute classique.
Combien l'auto-termination permet-elle réellement d'économiser ? Cela varie selon les workloads, mais le coût de son absence peut être élevé. Dans un exemple réel, un cluster GPU mal configuré sans auto-termination a ajouté environ 4 000 $ à la facture d'un seul mois avant que quiconque ne s'en aperçoive.
Quel est l'impact de la fréquence d'exécution des jobs sur les coûts Databricks ? Considérable. En prenant une mise à jour quotidienne comme référence, exécuter le même job toutes les heures coûte environ cinq fois plus cher, et les mises à jour en quasi temps réel environ 60 fois plus. Remettre en question la nécessité d'une telle fréquence est souvent le levier de réduction des coûts le plus puissant qui soit.
Databricks facture-t-il les fonctionnalités d'IA comme Genie ? Databricks a commencé à facturer des outils auparavant gratuits, dont Genie, et les fonctionnalités liées à l'IA devraient devenir un poste croissant des factures Databricks. Configurer des alertes de coûts avant d'activer de nouvelles fonctionnalités reste la meilleure protection contre les mauvaises surprises.