Vous pouvez réduire le coût d'un Databricks Serverless SQL Warehouse en associant chaque problème de workload au bon réglage. L'auto-stop réduit le temps d'activité inutile, la taille du warehouse influe sur la performance d'une requête individuelle, et max clusters détermine le volume de requêtes simultanées que le warehouse peut absorber.
La difficulté, c'est que ces signaux se confondent souvent. Un warehouse qui reste actif entre des jobs courts n'a pas besoin de plus de puissance. Des workloads en attente de capacité peuvent nécessiter plus de clusters plutôt qu'un warehouse plus grand. Power BI DirectQuery peut aussi continuer à générer de l'activité Databricks SQL même quand le SQL lui-même est déjà bien optimisé.
Cet article vous montre comment distinguer ces cas, comparer Serverless avec Pro et Classic sur la base du coût total plutôt que du seul tarif DBU, et choisir le réglage qui correspond au comportement réellement observé. Ces décisions au niveau du warehouse s'inscrivent dans le framework complet d'optimisation des coûts Databricks, où dimensionnement, utilisation, attribution et automatisation fonctionnent ensemble.
L'essentiel
- L'auto-stop réduit les périodes d'inactivité entre les pics d'activité SQL.
- La taille du warehouse détermine la puissance de calcul disponible pour chaque requête.
- Max clusters détermine la demande simultanée que le warehouse peut servir.
- Serverless, Pro et Classic doivent être comparés sur le coût total du workload, pas seulement sur le tarif DBU.
- Le mode de connexion Power BI peut modifier sensiblement l'activité du SQL Warehouse lorsque
DirectQueryest utilisé pour une fraîcheur de données dont le métier n'a pas réellement besoin.
Pourquoi les démarrages et le temps d'inactivité font grimper les coûts d'un Databricks SQL Warehouse
Votre facture SQL Warehouse peut croître plus vite que ne le suggère le temps d'exécution des requêtes, car les jobs courts génèrent eux aussi des démarrages et des fenêtres d'activité. Avec les alertes planifiées, le problème passe facilement inaperçu : plusieurs requêtes de moins d'une minute, planifiées séparément, peuvent maintenir un Databricks Serverless SQL Warehouse actif bien plus longtemps que la durée d'exécution du SQL lui-même. La configuration peut aggraver cet écart. Un déploiement de bundle documenté omettait auto_stop_mins et s'est retrouvé avec une valeur de 120 minutes, alors que la documentation actuelle des Databricks Declarative Automation Bundles indique une valeur par défaut de 10 minutes pour Serverless.
Selon nous, une erreur de configuration cachée peut faire plus de dégâts qu'une requête lente, car elle se répète à chaque exécution. Quelle part de votre facture SQL Warehouse provient de requêtes coûteuses, et quelle part de réglages que personne n'a revus ? Le même schéma apparaît dans les cinq habitudes qui font évoluer une facture Databricks et dans le framework complet d'optimisation des coûts.
Les types de SQL warehouse Databricks : Serverless, Pro et Classic
Parmi les principaux types de SQL warehouse, Serverless affiche le tarif Databricks Unit (DBU) visible le plus élevé, car son prix inclut l'infrastructure sous-jacente. Un SQL warehouse Pro a un tarif DBU inférieur, et Classic le plus bas, mais tous deux facturent l'infrastructure cloud séparément. Avec le compute serverless, Databricks gère l'infrastructure sous-jacente au lieu d'exposer une facturation cloud distincte à gérer de votre côté.
Par exemple, les tarifs catalogue AWS Premium publiés pour la région US East situent Serverless à environ 0,70 $ par DBU, un SQL warehouse Pro à 0,55 $ et Classic à 0,22 $ en 2026. Les tarifs réels peuvent varier selon le cloud, la région, l'édition et le contrat. Ces chiffres ne concernent qu'un exemple de tarification régionale, mais ils montrent pourquoi le tarif DBU seul ne vous dit pas quelle option coûte le moins cher au total.
| Type | Tarif DBU relatif | Facturation de l'infrastructure | Démarrage à froid | Cas d'usage idéal |
|---|---|---|---|---|
| Serverless | Le plus élevé | Incluse | Généralement quelques secondes | Workloads BI interactifs et DirectQuery à demande irrégulière |
| Pro | Intermédiaire | Facturée séparément | Généralement quelques minutes | Workloads BI prévisibles nécessitant les fonctionnalités Pro |
| Classic | Le plus bas | Facturée séparément | Généralement quelques minutes | Workloads planifiés prévisibles |
Les SQL warehouses Serverless conviennent mieux à une demande irrégulière, car ils démarrent en quelques secondes et réagissent rapidement aux variations de la demande. Databricks SQL Serverless utilise également l'Intelligent Workload Management (IWM) pour prédire les besoins en ressources des requêtes et gérer la capacité à mesure que la demande évolue. Cela réduit le besoin de garder du compute actif uniquement pour éviter un long délai de démarrage.
Les SQL warehouses Pro et Classic sont plus pertinents lorsque la demande est prévisible. Databricks recommande ces SQL warehouses pour les jobs planifiés en mode Import ou Extract, où la demande est plus facile à anticiper et où un démarrage rapide compte moins. Un SQL warehouse Pro offre des capacités supplémentaires par rapport à Classic SQL, qui reste l'option au tarif DBU le plus bas pour les cas d'usage plus simples.
La comparaison utile porte sur le coût total d'exécution du workload, en incluant l'infrastructure, le comportement au démarrage et la durée pendant laquelle le warehouse doit rester actif. Ne regarder que le tarif DBU revient à ne voir que la moitié de la facture et peut faire paraître Serverless plus cher qu'il ne l'est réellement.
Si vous souhaitez comparer ces coûts au niveau du warehouse, SELECT for Databricks peut vous aider à voir d'où viennent les dépenses, le dimensionnement et l'utilisation de vos SQL Warehouses avant de modifier la configuration.
Auto-stop des SQL warehouses : des minimums différents entre interface et API
Les SQL warehouses Serverless vous laissent plus de marge pour raccourcir l'auto-stop que les SQL warehouses Pro ou Classic. Dans l'interface Databricks, le minimum pour Serverless est de cinq minutes, tandis que l'API et les Declarative Automation Bundles permettent de descendre auto_stop_mins à une minute. Pro et Classic ont un minimum de 10 minutes.
Le réglage le plus court n'est pas toujours le bon. Un auto-stop d'une minute peut convenir à des jobs planifiés isolés, tandis que les workloads interactifs en DirectQuery gagnent parfois à rester actifs plus longtemps. Nos recommandations d'auto-stop pour SQL Warehouse préconisent environ 10 minutes pour un usage SQL général.
Vous pouvez configurer un warehouse Serverless avec un auto-stop d'une minute via la CLI Databricks :
databricks warehouses edit <WAREHOUSE_ID> \ --auto-stop-mins 1Les valeurs par défaut dépendent aussi de la manière dont vous créez vos SQL warehouses. L'interface Databricks applique par défaut 10 minutes pour Serverless et 45 minutes pour Pro ou Classic, tandis que les Declarative Automation Bundles utilisent 10 minutes pour Serverless et 120 minutes pour Pro ou Classic. Définissez auto_stop_mins explicitement afin que le déploiement ne dépende pas de la valeur par défaut de ce chemin de configuration.
Dimensionner un SQL warehouse : taille ou clusters
Dans Databricks SQL, la taille du warehouse et max clusters résolvent des problèmes de performance différents. La taille détermine la puissance de calcul disponible pour chaque requête, tandis que max clusters détermine la demande simultanée que le warehouse peut servir. Serverless utilise aussi l'Intelligent Workload Management pour gérer automatiquement une partie de l'allocation des ressources.
Appuyez-vous sur les signaux de requêtes et de file d'attente pour décider quel réglage ajuster :
| Symptôme | Réglage à ajuster |
|---|---|
| Une requête individuelle est lente ou déborde fortement sur disque | Augmenter la taille du warehouse |
| Les requêtes passent beaucoup de temps en attente de capacité | Augmenter max clusters |
| Le pic de Queued Queries reste au-dessus de zéro | Vérifier à la fois la taille du warehouse et max clusters |
| Longues périodes d'inactivité entre les requêtes | Réduire l'auto-stop |
À lui seul, le pic de Queued Queries n'identifie pas le correctif exact. Un waiting_at_capacity_duration_ms élevé signale une pression sur la capacité, tandis que des requêtes lentes ou qui débordent fortement sur disque pointent plutôt vers la taille du warehouse. Notre préférence : confirmer si la pression se situe au niveau des requêtes ou de la simultanéité avant d'ajouter du compute.
Le temps d'inactivité révèle un autre problème. Lorsque la capacité est suffisante pendant l'exécution des requêtes mais que le warehouse reste actif entre les jobs, c'est l'auto-stop qu'il faut examiner.
Quand Power BI DirectQuery change l'équation du coût serverless
Power BI DirectQuery peut générer bien plus d'activité sur le warehouse que le dashboard ne semble le justifier, car chaque interaction peut envoyer une nouvelle requête à Databricks. Databricks recommande les Serverless SQL Warehouses pour DirectQuery et LiveQuery, avec une fenêtre d'auto-stop de 15 à 30 minutes pour les workloads interactifs.
Lorsque le métier n'a besoin de mises à jour que toutes les quelques minutes, les modèles Import ou Hybrid peuvent réduire l'activité Databricks SQL en servant davantage d'interactions depuis Power BI lui-même. Les vues matérialisées peuvent aussi précalculer le travail SQL répétitif, même si leurs rafraîchissements consomment toujours du compute serverless distinct.
Notre point de vue : DirectQuery devrait être l'une des premières pistes à examiner lorsque le coût Serverless semble déconnecté de la complexité des dashboards. Avant d'incriminer la tarification Serverless, vérifiez si le mode de connexion BI génère plus d'activité que l'exigence réelle de fraîcheur des données ne le nécessite.
Transformer ces réglages en pratique durable
Garder le coût des SQL Warehouses sous contrôle exige une visibilité continue sur le dimensionnement, le temps d'inactivité et la pression sur la capacité. Notre vue des coûts SQL Warehouse rassemble ces signaux pour que vous puissiez voir où la configuration mérite un nouvel examen.
Notre fonctionnalité Automated Savings peut ajuster les paramètres pris en charge de nombre de workers et d'autoscaling des SQL Warehouses à mesure que la demande évolue. L'auto-stop reste un réglage distinct : continuez donc à revoir auto_stop_mins après les déploiements et à auditer les modes de connexion BI lorsque l'activité ne correspond plus au besoin métier de fraîcheur.
Le niveau d'économies suivant consiste à transformer ces vérifications en habitude opérationnelle. La question est de savoir si réviser manuellement la taille, max clusters, l'auto-stop et les modes BI reste un compromis défendable, ou si ce travail récurrent commence à peser de plus en plus lourd.
Coût d'un Databricks Serverless SQL Warehouse : par où commencer
Associez le réglage au signal observé : les périodes d'inactivité pointent vers l'auto-stop, la pression sur la file d'attente vers la capacité, les requêtes individuelles lentes vers la taille du warehouse, et une activité BI inattendue vers le mode de connexion. Comparez Serverless, Pro et Classic sur le coût total plutôt que sur le seul tarif DBU.
Examinez les données avant de modifier la configuration. Notre vue des coûts Databricks rassemble coût des SQL Warehouses, dimensionnement, compute inactif et utilisation pour vous montrer quel réglage mérite votre attention en premier.