Commencer par challenger le service
Databricks, Synapse ou Fabric sont des outils puissants, et chers. Avant d'optimiser leurs réglages, nous vérifions avec l'équipe que le service correspond au besoin : volumes, fréquence, latence attendue, compétences de l'équipe. Pour un traitement simple sur quelques gigaoctets, une base SQL, une Azure Function ou une activité Data Factory peuvent suffire. C'est la logique du build vs buy, appliquée à la data.
Pour un nouveau projet sur Databricks, nous recommandons de commencer avec des job clusters, et de n'ouvrir des clusters all-purpose que pour des besoins précis.
Databricks
- Job clusters plutôt qu'all-purpose pour les traitements planifiés : le tarif par DBU est nettement plus bas, et le cluster s'arrête avec le job.
- Auto-termination courte sur les clusters interactifs : 10 à 30 minutes d'inactivité plutôt que la valeur par défaut.
- Autoscaling avec un maximum de workers raisonnable, et une alerte quand il est atteint.
- Cluster policies pour imposer ces règles à tous, plutôt que de compter sur chaque développeur.
- Spot instances pour les workers en non-prod et sur les traitements qui supportent une interruption.
- Delta Lake bien entretenu (OPTIMIZE, clustering des données, traitements incrémentaux) : moins de données lues, donc moins de compute.
Azure Data Factory
Son modèle de prix est déroutant : exécutions d'activités, heures de DIU pour les copies, vCore-heures pour les data flows, integration runtime. Les leviers les plus efficaces :
- Revoir la fréquence et les volumes avec le product owner et le métier : un rafraîchissement toutes les cinq minutes est rarement nécessaire.
- Supprimer les pipelines inactifs, qui restent facturés.
- Vérifier le coût d'un integration runtime en managed VNet avant de migrer : il peut doubler la facture d'une factory.
- Poser une alerte de coût sur chaque factory : un pipeline bloqué coûte tous les jours (voir nos cas réels).
Azure Synapse
- Auto-pause courte sur les Spark pools, et taille de nœud la plus petite qui tient la charge.
- Nombre maximum de nœuds de l'autoscaling abaissé : une limite haute trop généreuse est vite atteinte.
- Mutualisation des Spark pools entre équipes et projets.
- Chargement en delta mode plutôt que des rechargements complets.
- Arrêt des planifications en DEV et en recette, suppression des node pools et des bases SQL inutilisés.
- Pause des dedicated SQL pools hors usage, et réservation quand ils tournent en continu.
Microsoft Fabric et Power BI
- Capacité au bon SKU, mesurée avec l'application de suivi de capacité, et autoscale plutôt qu'un SKU dimensionné pour le pic.
- Pause des capacités non-prod en dehors des heures d'usage.
- Réservation de la capacité de prod, qui tourne en continu.
- Nettoyage des datasets Power BI inutilisés, et fréquence de rafraîchissement adaptée au besoin réel.
Mesurer, puis suivre
Nous suivons la dépense data à part dans le dashboard, avec la répartition prod et non-prod, et nous mesurons l'effet de chaque action sur la facture. Sur une plateforme data, la combinaison nettoyage, réservations Synapse et Fabric, autoscaling et réduction des rafraîchissements a fait baisser la dépense mensuelle d'environ un quart en trois mois. Toute modification de taille ou de fréquence se fait en surveillant les performances.