TL;DR
Les gains rapides de l'optimisation des coûts Databricks (auto-termination, timeouts, autoscaling, compute correctement dimensionné) offrent le meilleur retour sur effort que vous obtiendrez jamais : ils réduisent souvent la facture de 20 à 40 % et s'appliquent en quelques minutes. Au-delà, 20 à 40 % supplémentaires restent généralement accessibles, mais au prix de jours ou de semaines d'effort, et uniquement sur les workloads où l'équation reste rentable. Ce guide porte sur ce second palier : comment identifier les jobs qui méritent l'effort, et comment réduire le travail qu'ils effectuent avant de choisir sur quel compute les exécuter.
Introduction
La plupart des conseils sur les coûts Databricks s'arrêtent à la configuration. Activez l'auto-termination, ajoutez des timeouts, activez l'autoscaling, cessez de surdimensionner vos clusters. Ces conseils sont justes, et vous devriez tous les appliquer en premier, car c'est, de loin, l'effort le plus rentable à votre disposition. Selon votre point de départ, ces gains rapides récupèrent couramment 20 à 40 % de votre facture, et la plupart prennent quelques minutes. Personne ne devrait les ignorer, et cet article ne prétend pas qu'ils sont négligeables.
Le problème, c'est qu'ils ont un plafond. Une fois les clusters inactifs éliminés, les timeouts configurés et le compute correctement dimensionné, vous avez capté une économie ponctuelle importante et la courbe s'aplatit. Les workloads eux-mêmes effectuent toujours exactement autant de travail qu'avant. Obtenir les 20 à 40 % suivants implique de changer ce que font réellement les jobs : un pipeline qui retraite tout son historique chaque nuit, une requête qui scanne cent fois plus de données qu'elle n'en retourne, un dashboard temps réel que personne n'ouvre plus d'une fois par jour. Aucun de ces cas ne devient moins cher en redimensionnant le cluster. Ils deviennent moins chers quand vous repensez le travail, et cela coûte des jours ou des semaines plutôt que des minutes. Et cela ne paie que sur certains workloads, raison pour laquelle la première vraie étape consiste à déterminer lesquels. Ce guide porte sur ce second palier.
Pourquoi la plupart des démarches d'optimisation des coûts Databricks s'essoufflent-elles après les gains faciles ?
La première passe sur les coûts Databricks cible presque toujours la même poignée de réglages, et à juste titre. Ce sont les correctifs au meilleur rapport gain/effort, et les ignorer, c'est laisser la facture s'emballer. Si vous ne les avez pas encore appliqués, commencez par là : notre article Databricks Pricing Explained détaille l'auto-termination, les timeouts et le Job Compute par rapport au compute all-purpose. Considérez cet article comme le prérequis, et celui-ci comme la suite.
Voici le problème quand on s'arrête là : chacun de ces réglages est une correction ponctuelle. L'auto-termination vous évite de payer des clusters inactifs, mais une fois le temps d'inactivité à zéro, il n'y a plus rien à récupérer. Migrer un pipeline d'un cluster all-purpose à 0,55 $ par DBU vers Jobs Classic à 0,30 $ par DBU réduit le tarif de ce job d'environ 45 %, mais vous ne pouvez faire cette bascule qu'une seule fois. Ce sont des gains importants et rapides, souvent un cinquième à deux cinquièmes de la facture, puis c'est terminé. La courbe s'aplatit et la facture se stabilise à un nouveau niveau de référence, plus bas, qui ne bouge plus.
Ce niveau de référence est déterminé par la quantité de travail de vos jobs, et c'est la variable que les gains rapides ne touchent jamais. Un pipeline quotidien qui réécrit intégralement une table d'un milliard de lignes reste coûteux sur le cluster Jobs le moins cher et le mieux dimensionné que vous puissiez provisionner. Le palier d'économies suivant se situe dans le workload lui-même : traiter moins de données, exécuter moins souvent, calculer les résultats une fois plutôt qu'à répétition. C'est plus difficile que de basculer un réglage, cela prend des jours ou des semaines au lieu de minutes, et cela ne paie pas partout. Sur un pipeline peu coûteux ou peu fréquent, le temps d'ingénierie coûtera plus qu'il n'économise. C'est précisément pourquoi l'étape suivante n'est pas de commencer à optimiser, mais de découvrir quels workloads valent la peine d'être optimisés.
Comment identifier les workloads qui valent la peine d'être optimisés ?
Avant d'optimiser quoi que ce soit, découvrez ce qui coûte réellement cher. C'est plus important qu'il n'y paraît, car l'instinct des ingénieurs et la facture pointent rarement vers la même chose. Le pipeline qui vous agace est souvent bon marché. Celui auquel personne ne pense tourne sur un gros cluster trois fois par jour et domine discrètement la facture.
Le moyen le plus rapide de classer vos dépenses, ce sont les tables système de facturation. Joignez system.billing.usage (chaque DBU consommé) à system.billing.list_prices (le prix effectif par SKU) pour convertir les quantités en dollars, puis joignez system.lakeflow.jobs pour attacher un nom de job lisible, afin que le classement soit réellement exploitable :
WITH price AS ( SELECT sku_name, pricing.effective_list.default AS price_effective FROM system.billing.list_prices WHERE price_end_time IS NULL),usage AS ( SELECT * FROM system.billing.usage WHERE usage.billing_origin_product = 'JOBS'Développer le code
Cette requête classe vos jobs par coût quotidien, noms inclus, ce qui répond à la seule question qui compte à ce stade : quels jobs nommés tirent la facture vers le haut ? La jointure avec system.lakeflow.jobs est d'ailleurs ce qui rend le tagging rentable. Les tags ne réduisent jamais une facture par eux-mêmes, mais ils vous permettent de regrouper ce résultat par équipe, environnement ou projet au lieu de vous noyer dans des identifiants de jobs et des noms qui changent au fil du temps.
La raison de classer avant d'agir, c'est que l'optimisation a elle-même un coût, et il est facile de dépenser plus de temps d'ingénierie qu'on n'en économise. Réécrire un pipeline qui représente 1 % de votre facture est un exercice satisfaisant qui n'apparaîtra jamais sur la facture, et les heures que vous y consacrez dépasseront généralement de loin les économies pendant des années. Triez par coût, examinez la poignée de workloads en tête, et ignorez la longue traîne jusqu'à ce que les plus coûteux soient traités. Optimisez les cas hors norme, pas tout.
Classer soi-même ses dépenses par workload implique d'écrire et de maintenir ces requêtes, puis de garder les dashboards à jour à mesure que les jobs sont renommés et que les pipelines évoluent. SELECT effectue cette attribution automatiquement et fait remonter vos workloads les plus coûteux, le compute inactif et les types de compute inadaptés, sans construction manuelle de requêtes. Découvrez ce qu'il détecte dans votre environnement.
Pourquoi optimiser le job plutôt que redimensionner le cluster ?
Cette section justifie tout le reste. Quand un job est lent ou coûteux, le réflexe est de prendre un cluster plus gros, parce que c'est un seul réglage et que cela fonctionne généralement. C'est aussi le correctif le plus coûteux qui soit, et il laisse le gaspillage sous-jacent en place. Un job qui scanne plus de données que nécessaire, effectue des shuffles inutiles ou retraite un historique déjà traité brûlera du compute en excès à n'importe quelle taille de cluster. Monter en puissance revient simplement à payer cette taxe plus vite.
Pour rendre cela concret : un de mes clients exécutait un pipeline de données IoT dont nous avons réduit le temps d'exécution d'environ 85 % et le coût de 75 %, soit environ 10 000 $ par an, sur le même environnement. Le compute n'était pas mal dimensionné au départ : pas optimal, mais pas aberrant non plus. Le redimensionner aurait fait bouger la facture de quelques points de pourcentage. Les économies sont venues entièrement du changement de ce que faisait le pipeline : chargement incrémental des couches bronze et silver au lieu d'un retraitement complet, report d'une jointure coûteuse sur une table de faits après que l'agrégation quotidienne a réduit les données, réécriture de la transformation la plus lourde, et exposition de la consommation via des vues au lieu de dupliquer les données dans de nouvelles tables. Chacun de ces points correspond à l'un des leviers ci-dessous. Aucun n'expliquait tout à lui seul, et le dimensionnement du compute ne figurait pas sur la liste.
Lire le profil de requête, puis repenser la partie coûteuse
Databricks expose un profil de requête détaillé pour chaque exécution, montrant où le temps est passé à chaque étape du plan. Depuis l'historique des requêtes, ou directement depuis un job ou une requête SQL, vous pouvez ouvrir le profil et télécharger le plan d'exécution complet au format JSON. Ce JSON est la matière première de l'astuce la plus puissante et la moins connue du workflow moderne de data engineering : le confier à un LLM.
Un LLM excelle à lire un profil de requête et à vous dire où se trouve le coût : quelle étape a débordé sur disque, quelle jointure a explosé, où un shuffle a tourné sur bien plus de partitions que les données ne le justifiaient. Sur un job réel, l'un d'eux a signalé que le goulot d'étranglement était une transformation SQL qui construisait un calendrier complet de dates (une ligne par entité et par jour, sur environ quatorze ans d'historique) avant de le réduire à nouveau, produisant des dizaines de millions de lignes intermédiaires pour calculer un résultat qui n'en nécessitait qu'une infime fraction. Il ne s'est pas arrêté au diagnostic. Il a proposé une première réécriture en PySpark reposant sur une approche événementielle par balayage d'intervalles qui ne matérialise jamais le calendrier, puis est devenu un véritable collaborateur sur la solution. Je pointais un cas limite que la première version ne gérait pas, il intégrait un correctif, nous capturions ce cas sous forme de test unitaire, et nous avons itéré cette boucle pendant deux à trois jours jusqu'à ce que les résultats soient corrects sur toute la ligne. Le job quotidien est passé d'environ deux heures à dix minutes, soit une réduction d'environ 15x du temps d'exécution comme du coût en DBU.
L'essentiel, c'est la répartition du travail, et ce n'est pas l'IA remonte les problèmes, l'humain fait le vrai travail. Le modèle a trouvé le goulot d'étranglement, proposé l'algorithme et écrit l'essentiel du code. Mon rôle était de piloter : repérer les cas qu'il manquait, décider quand la solution était réellement correcte, et garder l'itération honnête avec des tests. C'est un usage véritablement différent et plus puissant que de coller un message d'erreur. Si vous travaillez dans le workspace Databricks, Genie s'en charge très bien ; si vous êtes dans votre IDE, l'assistant déjà intégré fonctionne tout aussi bien. L'outil compte moins que l'habitude de lire le profil et de reconstruire la partie coûteuse au lieu d'opter pour un cluster plus gros.
Passer à l'incrémental plutôt que réécrire toute la table
La réécriture complète est le pattern de pipeline le plus simple, et pour des tables petites ou de taille modérée, c'est souvent le bon choix. La complexité du traitement incrémental n'en vaut pas toujours la peine. Mais quand les volumes de données sont élevés, en particulier pour des données transactionnelles, de la télémétrie ou des séries temporelles, retraiter la table entière à chaque exécution devient plus coûteux et plus difficile à justifier à mesure que la table grandit.
L'alternative incrémentale consiste à ajouter les nouveaux enregistrements pour les données immuables, ou à fusionner les enregistrements modifiés pour les données qui évoluent, et à appliquer ce pattern à travers autant de couches de votre architecture médaillon que possible. Ce n'est que lorsque les données sont agrégées en quelque chose de petit qu'une réécriture complète redevient raisonnable. Spark Structured Streaming est l'outil pratique ici : associé à Auto Loader pour l'ingestion de fichiers ou en lisant nativement depuis une table Delta, il gère automatiquement les checkpoints, de sorte que chaque exécution ne traite que ce qui est arrivé depuis la précédente. Le plus grand gain pour la plupart des équipes n'est pas le traitement continu en temps réel, mais le pattern fiable de batch incrémental que le streaming rend facile : traiter les nouvelles données sans rescanner ce qui existe déjà.
Remettre en question l'exigence de temps réel avant de l'accepter
Nous avons besoin de données en quasi temps réel est l'une des exigences les plus coûteuses qu'une équipe data puisse accepter sans la questionner, et elle est très rarement vraie. Les parties prenantes n'ont presque jamais besoin d'un flux continu de données fraîches. Elles ont besoin d'une vue suffisamment récente au moment où elles consultent réellement les données, ce qui est une chose complètement différente et bien moins chère. Avant de construire pour le temps réel, découvrez à quelle fréquence le dashboard est réellement ouvert et le rapport réellement lu. Des rafraîchissements horaires, quotidiens, voire hebdomadaires suffisent bien plus souvent que la demande initiale ne le laisse entendre.
La différence de coût n'est pas marginale. Prenons un pipeline type, à travail constant, en ne faisant varier que la cadence : exécuté en continu, il peut coûter 58 unités ; toutes les heures, le même travail tombe à environ 5 unités ; trois fois par jour, vous frôlez 1 unité. Ce n'est pas une différence d'arrondi : c'est environ 12x entre le continu et l'horaire, et encore un net palier supplémentaire en dessous.
La démarche pratique consiste à construire chaque pipeline avec Structured Streaming, quelle que soit la fréquence demandée au départ, car le streaming rend triviale la bascule entre batch planifié et fonctionnement continu. Commencez ensuite à la fréquence la plus basse qui satisfait le besoin métier réel, et augmentez-la seulement lorsqu'il existe des preuves concrètes qu'une fraîcheur accrue est nécessaire. La capacité à monter en fréquence est là quand vous en avez besoin ; les économies réalisées en évitant de monter prématurément, elles, sont immédiates.
Construire des vues plutôt que des tables
Toutes les tables n'ont pas besoin de contenir physiquement des données. Une grande partie des tables d'un environnement Databricks typique n'existent pas à cause de transformations complexes, mais pour exposer les données sous une autre forme : un schéma différent, un filtre, un sous-ensemble de colonnes, un autre jeu de droits d'accès. Dans ces cas, copier physiquement les données ajoute du coût de stockage, du coût de compute et de la complexité de pipeline sans bénéfice réel.
Une vue est le bon outil pour cela. C'est une couche virtuelle définie par une requête, sans rien de copié ni stocké, et pour une simple sélection de colonnes ou un filtre, l'expérience de lecture est indiscernable d'une table. Réservez les tables physiques aux sorties de transformations réellement coûteuses, où matérialiser le résultat évite un recalcul significatif. Pour tout le reste, une vue garde le stockage léger et les pipelines plus simples. Pour approfondir ces patterns de workflow, notre ebook gratuit sur l'optimisation des coûts les passe en revue, avec l'organigramme de diagnostic que nous utilisons pour décider quel levier s'applique à un workload donné.
Comment choisir le bon compute une fois le job efficace ?
Notez l'ordre. Le choix du compute vient après l'optimisation du workload, pas avant, et cette séquence est tout le propos de cet article. Dimensionner le compute pour un job inefficace ne fait que verrouiller le gaspillage à l'échelle choisie. Une fois que le job effectue la bonne quantité de travail, la décision de compute devient plus simple et les enjeux diminuent.
Le choix par défaut devrait être le serverless, partout : jobs, notebooks et SQL. Cela peut sembler contre-intuitif, car le serverless affiche un tarif par DBU plus élevé : sur Azure Premium, Jobs Serverless coûte 0,45 $ par DBU contre 0,30 $ pour Jobs Classic, et le Serverless interactif 0,95 $ contre 0,55 $ pour l'all-purpose classique. Mais le tarif par DBU n'est que la moitié de l'histoire, et c'est la partie que les équipes manquent le plus souvent dans leurs comparaisons. Sur le compute classique, les DBU ne représentent pas toute la facture. Vous payez aussi séparément votre fournisseur cloud pour les VM sous-jacentes, et ce montant est réellement difficile à estimer à l'avance. Le serverless intègre l'infrastructure dans le tarif DBU : le prix affiché est le prix payé.
Cette intégration renverse la comparaison naïve plus souvent qu'on ne le croit. Le pipeline ETL horaire d'un client en est un exemple parlant. Sur Job Classic à 0,30 $ par DBU, il consommait environ 44 DBU par jour, soit à peu près 13 $ de DBU plus 10 $ de VM cloud, environ 23 $ par jour au total. La version serverless du même workload utilisait moins de DBU (environ 38, car elle s'ajustait plus finement au travail réel) à 0,45 $ par DBU, soit environ 18 $ par jour, sans aucune facture cloud distincte. L'option au tarif affiché le plus élevé était la moins chère une fois les VM comptées, et sans le moindre réglage.
Il existe un second coût qui n'apparaît sur aucune des deux factures : le temps d'ingénierie pour dimensionner et régler correctement un cluster classique (type d'instance, ratio mémoire/cœurs, comportement d'autoscaling, et révision de tout cela à mesure que le workload évolue). Pour la plupart des workloads, ce temps coûte plus que n'importe quel surcoût de DBU. Une journée de réglage pour gagner 10 % sur un pipeline modeste peut mettre un an à s'amortir. Le serverless élimine aussi toute une classe de problèmes opérationnels : pas de démarrage de cluster, pas de gestion de versions, pas de clusters inactifs à oublier.
Pour être tout à fait honnête : le serverless est rarement l'option la moins chère pour un pipeline donné pris isolément, mais pour la plupart des pipelines, il vous amène à 80 ou 90 % du résultat sans aucun effort de réglage. À l'échelle de tout votre portefeuille, c'est gagnant en coût total de possession, car la grande majorité de vos pipelines finit raisonnablement efficace sans que vous y passiez une minute. Vous utilisez ensuite votre classement des coûts pour identifier la poignée de jobs fréquents, coûteux et prévisibles, et ce sont ceux-là qui valent la peine d'être migrés vers le compute classique et réglés à la main, calcul des VM cloud inclus. Optimisez les cas hors norme, et mettez tout le reste en serverless par défaut.
Quand vous configurez du compute classique, commencez avec la plus petite ressource qui fonctionne et montez sur la base de preuves. Le surdimensionnement est l'état par défaut de la plupart des déploiements Databricks, parce que les configurations sont copiées d'un collègue, héritées d'un vieux projet, ou laissées à ce que l'interface a suggéré. Choisissez la plus petite taille de SQL warehouse et ne montez que lorsque les temps de requête deviennent inacceptables ; pour les clusters, commencez avec un type de nœud généraliste et configurez l'autoscaling de un à deux ou quatre workers. Un compute deux fois plus gros n'exécute pas les jobs deux fois plus vite, mais il coûte, à coup sûr, deux fois plus cher.
Comment empêcher les coûts de remonter ?
L'optimisation ponctuelle est un point de départ, pas un état stable. Les équipes grandissent, les workloads se multiplient, de nouveaux ingénieurs arrivent avec leurs propres habitudes, et les coûts remontent à moins que quelque chose ne les retienne. Ce quelque chose, c'est une couche de gouvernance, et c'est ce qui transforme un nettoyage ponctuel en niveau de référence durable.
La mesure la plus fiable consiste à ne plus laisser créer du compute à la volée. Quand les ingénieurs provisionnent leurs propres clusters, les réglages qui comptent (auto-termination, limites de scaling, types d'instance, tags) sont définis de façon incohérente, voire pas du tout, et chaque optimisation soigneuse réalisée ailleurs s'évapore. Définissez vos clusters et warehouses en infrastructure as code, déployez-les via CI/CD, et faites choisir les ingénieurs dans un ensemble pré-approuvé plutôt que de les laisser construire les leurs. Pour les utilisateurs avancés qui ont réellement besoin de compute sur mesure, les cluster policies sont le juste milieu : une policy peut imposer l'auto-termination, plafonner la taille du cluster et restreindre les types d'instance, tout en laissant de la marge pour ajuster dans ces limites. Le choix économe devient le seul choix disponible. Pour comprendre pourquoi nous pensons que ce problème mérite un outillage dédié, lisez pourquoi nous avons construit SELECT pour Databricks.
La prévention n'attrape pas tout, alors associez-la à des alertes. Databricks propose une fonctionnalité native de budgets dans la console de compte pour définir des seuils de dépense, ce qui est un bon point de départ. Mais le signal le plus sensible est statistique, pas une limite fixe : mesurez l'écart-type du coût quotidien ou hebdomadaire par workload et alertez sur les sorties de la plage normale. Un seuil fixe ne se déclenche qu'une fois la limite déjà franchie. Surveiller la dérive permet de détecter un problème le jour même où un job commence à dérailler, pas en fin de cycle de facturation quand le mal est fait. Cette visibilité au jour le jour fait la différence entre une petite correction et une facture salée.
L'optimisation des coûts Databricks n'est pas un projet ponctuel. La plateforme évolue, les équipes ajoutent des workloads, et le niveau de référence que vous avez travaillé à abaisser remontera sans visibilité continue. SELECT donne aux équipes data platform cette visibilité en un seul endroit : classement des dépenses par workload, détection de la dérive dès qu'elle commence, et mise en lumière des économies qui se cumulent dans le temps. Réservez une démo pour voir ce qu'il révèle dans votre environnement.
FAQ
Quel est le moyen le plus rapide de réduire les coûts Databricks ?
Deux changements de configuration rapportent le plus pour le moins d'effort : activer l'auto-termination sur chaque cluster et SQL warehouse pour que les ressources inactives cessent d'être facturées, et migrer les pipelines planifiés du compute all-purpose vers Jobs Compute. Sur Azure Premium, cela fait passer un job de 0,55 $ à 0,30 $ par DBU, soit environ 45 % de réduction sur le tarif de ce workload. Les deux se font en une après-midi. Soyons honnêtes : aucun des deux ne corrige un pipeline mal conçu. Si un job retraite tout son historique chaque nuit ou scanne bien plus de données qu'il n'en retourne, il reste coûteux sur le cluster le moins cher et le mieux dimensionné que vous puissiez lui donner. Les gains rapides établissent un niveau de référence plus bas ; l'abaisser davantage implique de repenser le travail.
Le serverless est-il moins cher que le compute classique ?
Pas au tarif par DBU, et pas toujours au total : il n'y a donc pas de oui ou de non tranché. Le serverless affiche un tarif plus élevé (sur Azure Premium, 0,45 $ par DBU pour Jobs Serverless contre 0,30 $ pour Jobs Classic), mais intègre l'infrastructure que vous paieriez et régleriez autrement vous-même. Pour la plupart des workloads, le temps d'ingénierie économisé l'emporte sur le surcoût tarifaire, ce qui fait du serverless un bon choix par défaut. Le piège à surveiller : le serverless scale si fluidement que les hausses de coût se cachent mieux que sur le compute classique. Deux exécutions peuvent afficher la même durée tout en consommant des quantités de DBU très différentes, parce que le serverless a discrètement monté en puissance pour la plus lourde. La durée semble stable pendant que la facture double. Surveillez la consommation de DBU, pas seulement le temps d'exécution.
Unity Catalog alourdit-il ma facture Databricks ?
Unity Catalog n'est pas un produit facturé séparément, mais son activation change votre surface de coûts d'une manière qu'il vaut mieux comprendre avant de migrer. Predictive Optimization, qui exécute automatiquement OPTIMIZE et VACUUM sur les tables managées Unity Catalog, consomme des DBU (il se rentabilise généralement par les économies sur les requêtes, mais c'est une vraie ligne de facture). Les fonctionnalités de gouvernance, la maintenance des tables managées et le compute serverless sur lequel tournent plusieurs opérations de catalogue apparaissent tous quelque part. Nous détaillons l'impact d'Unity Catalog sur les coûts dans un guide dédié ; en bref, la gouvernance en vaut la peine, mais elle n'est pas gratuite, et vous devriez savoir où elle atterrit sur la facture avant de l'activer.