Partager via

Bonnes pratiques en matière d’optimisation des coûts

  • Article

Cet article décrit les bonnes pratiques de prise en charge des principes d’optimisation des coûts, organisées par principe.

1. Choisir des ressources optimales

Utiliser des formats de données à performances optimisées

Pour tirer le meilleur parti de la plateforme Databricks Data Intelligence, vous devez utiliser Delta Lake comme infrastructure de stockage. Il permet de créer des pipelines ETL plus simples et plus fiables et offre de nombreuses améliorations des performances pouvant accélérer considérablement les charges de travail par rapport à l’utilisation de Parquet, ORC et JSON. Consultez Recommandations d’optimisation sur Azure Databricks. Si la charge de travail s’exécute également sur un calcul de travaux, cela se traduit directement par une durée de bon fonctionnement plus courte des ressources de calcul, ce qui réduit les coûts.

Utiliser un calcul de travaux

Un travail est un moyen d’exécuter du code non interactif dans une instance de calcul Databricks. Par exemple, vous pouvez exécuter une charge de travail Extraction, transformation et chargement (ETL) de manière interactive ou selon une planification. Bien entendu, vous pouvez également exécuter des travaux de manière interactive dans l'interface utilisateur du notebook. Toutefois, sur un calcul de travaux, les charges de travail non interactives coûteront beaucoup moins cher que sur les calculs à usage général. Consultez la vue d’ensemble des tarifs pour comparer « Calcul des travaux » et « Calcul à usage général ».

Un avantage supplémentaire pour certains travaux est que chaque travail ou flux de travail peut s’exécuter sur une nouvelle instance de calcul, isolant les charges de travail les unes des autres. Cependant, les workflows multitâches peuvent aussi réutiliser des ressources de calcul pour toutes les tâches, de sorte que le temps de démarrage du calcul ne survient qu’une seule fois par workflow. Consultez Configurer le calcul pour les projets.

Utiliser l’entrepôt SQL pour les charges de travail SQL

Pour les charges de travail SQL interactives, un entrepôt Databricks SQL est le moteur le plus économique. Consultez la vue d’ensemble des tarifs. Tous les entrepôts SQL sont fournis avec Photon par défaut, ce qui accélère vos appels d’API SQL et DataFrame existants et réduit votre coût global par charge de travail.

De plus, les entrepôts SQL serverless soutiennent la gestion intelligente des charges de travail (Intelligent Workload Management/IWM), un ensemble de fonctionnalités qui améliore la capacité de Databricks SQL serverless à traiter un grand nombre de requêtes rapidement et de manière rentable.

Utiliser des runtimes à jour pour vos charges de travail

La plateforme Azure Databricks fournit différents runtimes optimisés pour les tâches d’engineering données (Databricks Runtime) ou pour des tâches de machine learning (Databricks Runtime pour Machine Learning). Les runtimes sont conçus pour fournir la meilleure sélection de bibliothèques pour les tâches, et pour garantir que toutes les bibliothèques fournies sont à jour et fonctionnent ensemble de manière optimale. Les runtimes Databricks sont publiés à une cadence régulière et fournissent des améliorations de performances entre les versions majeures. Ces améliorations de performances entraînent souvent des économies de coûts, en raison d’une utilisation plus efficace des ressources de calcul.

Utiliser uniquement des GPU pour les charges de travail appropriées

Les machines virtuelles avec des GPU peuvent accélérer considérablement les processus de calcul pour le deep learning, mais sont considérablement plus chères que des machines processeur (CPU) uniquement. Utilisez des instances GPU uniquement pour les charges de travail qui ont des bibliothèques à accélération GPU.

La plupart des charges de travail n’utilisent pas de bibliothèques à accélération GPU, et ne tirent donc pas partie des instances avec GPU. Les administrateurs de l’espace de travail peuvent restreindre les machines GPU pour éviter toute utilisation inutile. Consultez le billet de blog « Are GPUs Really Expensive? Benchmarking GPUs for Inference on Databricks Clusters ».

Utilisez des services serverless pour vos charges de travail

Cas d’usage de BI

Les charges de travail BI utilisent généralement des données de consommation en rafales et génèrent plusieurs requêtes simultanées. Par exemple, une personne utilisant un outil de BI peut mettre à jour un tableau de bord, écrire une requête, puis simplement analyser les résultats sans interagir davantage avec la plateforme. Dans ce scénario, la plateforme de données :

  • Suspend des ressources de calcul inactives pour réduire les coûts.
  • Fournit rapidement les ressources de calcul lorsque l’utilisateur demande des données nouvelles ou mises à jour avec l’outil de BI.

Les entrepôts Azure Databricks SQL non serverless ont un temps de démarrage de quelques minutes. De nombreux utilisateurs ont donc tendance à accepter le coût plus élevé et ne les arrêtent pas pendant les périodes d’inactivité. D’autre part, les entrepôts SQL serverless démarrent et effectuent un scale-up en quelques secondes ; la disponibilité immédiate et l’arrêt pendant les temps d’inactivité peuvent donc être obtenus. Cela se traduit par une expérience utilisateur exceptionnelle et des économies de coûts globales.

En outre, les entrepôts SQL serverless effectuent un nouveau scale-down plus tôt que les entrepôts non serverless, ce qui réduit les coûts.

Modèle ML et IA servant

La plupart des modèles sont servis en tant qu’API REST pour l’intégration à votre application web ou cliente ; le service modèle reçoit des charges variables de requêtes au fil du temps, et une plateforme modèle doit toujours fournir des ressources suffisantes, mais seulement autant qu’il est réellement nécessaire (mise à l’échelle ascendante et descendante).

Le Service de modèles Mosaic AI utilise le calcul serverless et fournit un service à haute disponibilité et à faible latence pour le déploiement de modèles. Le service effectue automatiquement un scale-up ou un scale-down pour répondre aux modifications de la demande, ce qui réduit les coûts d’infrastructure tout en optimisant les performances de latence.

Utiliser le type d’instance approprié

L’utilisation de la dernière génération de types d’instances cloud offre presque toujours des avantages en matière de performances, car ces instances offrent les meilleures performances et les dernières fonctionnalités.

En fonction de vos charges de travail, il est également important de choisir la famille d’instances appropriée pour obtenir le meilleur rapport performances/prix. Voici quelques règles simples :

  • Mémoire optimisée pour le ML, les charges de travail aléatoires lourdes et les charges de travail de déversement
  • Calcul optimisé pour les charges de travail en continu structurées et les travaux de maintenance (tels que l’optimisation et le vide)
  • Stockage optimisé pour les charges de travail qui bénéficient de la mise en cache, comme l’analyse ad hoc et interactive de données
  • GPU optimisé pour des charges de travail ML et DL spécifiques
  • Usage général en l’absence d’exigences spécifiques

Choisir la taille de calcul la plus efficace

Azure Databricks exécute un exécuteur par nœud Worker. Par conséquent, les termes exécuteur et Worker sont utilisés de manière interchangeable dans le contexte de l’architecture Azure Databricks. Les gens considèrent souvent la taille de cluster en termes de nombre de Workers, mais il existe d’autres facteurs importants à prendre en compte :

  • Nombre total de cœurs d’exécuteur (calcul) : nombre total de cœurs sur tous les exécuteurs. Cela détermine le parallélisme maximal d’une instance de calcul.
  • Mémoire totale de l’exécuteur : quantité totale de RAM sur tous les exécuteurs. Cela détermine la quantité de données pouvant être stockées en mémoire avant de les déverser sur le disque.
  • Stockage local de l’exécuteur : type et quantité de stockage sur disque local. Le disque local est principalement utilisé en cas de débordement lors des brassages et de la mise en cache.

Les considérations supplémentaires incluent le type et la taille de l’instance de travail, qui influencent également les facteurs précédents. Lors du dimensionnement de votre calcul, tenez compte des éléments suivants :

  • Quelle est la quantité de données consommées par votre charge de travail ?
  • Quelle est la complexité de calcul de votre charge de travail ?
  • Où sont lues les données ?
  • Comment les données sont-elles partitionnées dans un stockage externe ?
  • De quel degré de parallélisme avez-vous besoin ?

Vous trouverez des détails et des exemples sous Considérations relatives au dimensionnement du calcul.

Évaluer les moteurs de requête optimisés pour les performances

Photon est un moteur de requête vectorisé natif Databricks haute performance qui accélère vos charges de travail SQL et les appels d’API DataFrame (pour l’ingestion de données, ETL, diffusion en continu, science des données et requêtes interactives). Photon étant compatible avec les API Apache Spark, la prise en main ne requiert qu’une simple activation. Aucune modification du code ni aucun verrouillage ne sont nécessaires.

L’accélération observée peut entraîner des économies significatives, et les travaux qui s’exécutent régulièrement doivent être évalués afin de voir s’ils sont non seulement plus rapides, mais aussi moins chers avec Photon.

2. Allouer des ressources de façon dynamique

Utiliser le calcul de mise à l’échelle automatique

Avec la mise à l'échelle automatique, Databricks réalloue dynamiquement les travailleurs pour tenir compte des caractéristiques de votre travail. Certaines parties de votre pipeline peuvent être plus exigeantes en termes de calcul que d’autres, et Databricks ajoute automatiquement des travailleurs supplémentaires pendant ces phases de votre travail (et les supprime lorsqu’ils ne sont plus nécessaires). La mise à l’échelle automatique peut réduire les coûts globaux par rapport à une instance de calcul de taille statique.

La mise à l’échelle automatique du calcul présente des limitations pour la réduction de la taille du cluster pour les charges de travail structurées de diffusion en continu. Databricks recommande d’utiliser Delta Live Tables avec une mise à l’échelle automatique améliorée pour les charges de travail de diffusion en continu.

Utiliser l’arrêt automatique

Azure Databricks fournit plusieurs fonctionnalités permettant de contrôler les coûts en réduisant les ressources inactives et en contrôlant le moment où les ressources de calcul peuvent être déployées.

  • Configurez l’arrêt automatique pour toutes les ressources de calcul interactives. Après une durée d’inactivité spécifiée, la ressource de calcul s’arrête. Consultez Arrêt automatique.
  • Pour les cas d’usage où les calculs sont nécessaires uniquement pendant les heures de bureau, les ressources de calcul peuvent être configurées avec l’arrêt automatique et un processus planifié peut redémarrer le calcul (et peut-être préchauffer les données si nécessaire) le matin avant que les utilisateurs ne soient de retour à leur bureau. Voir CACHE SELECT.
  • Si les temps de démarrage du calcul sont trop longs, envisagez d’utiliser des pools de clusters, consultez les meilleures pratiques de pool. Les pools Azure Databricks sont un ensemble d’instances inactives et prêtes à l’emploi. Lorsque des nœuds de cluster sont créés à l'aide des instances inactives, les délais de démarrage du cluster et de mise à l'échelle automatique sont réduits. Si les pools n’ont pas d’instances inactives, ils s’étendent en allouant une nouvelle instance à partir du fournisseur d’instances pour répondre à la requête du cluster.

Azure Databricks ne facture pas de Databricks Units (DBU) durant le temps d’inactivité des instances dans le pool, ce qui réduit les coûts. La facturation du fournisseur d’instances s’applique par contre.

Utiliser des stratégies de calcul pour contrôler les coûts

Les stratégies de calcul peuvent appliquer de nombreuses restrictions spécifiques aux coûts pour les ressources de calcul. Consultez Excellence opérationnelle - Utiliser des stratégies de calcul. Par exemple :

3. Superviser et contrôler les coûts

Superviser les coûts

Utilisez Azure Cost Manager pour analyser les coûts d’Azure Databricks. Les balises de calcul et d’espace de travail sont également remises à Azure Cost Manager. Consultez Étiqueter les clusters pour l’attribution des coûts.

Étiqueter les clusters pour l’attribution des coûts

Pour surveiller les coûts en général et attribuer avec précision l’utilisation d’Azure Databricks aux unités commerciales et aux équipes de votre organisation pour les rétrofacturations, vous pouvez étiqueter les clusters, les entrepôts SQL et les pools. Ces étiquettes se propagent aux unités Databricks détaillées (DBU) ainsi qu’aux machines virtuelles de fournisseur de cloud et aux instances de stockage d’objets blob pour l’analyse des coûts.

Assurez-vous que le contrôle et l’attribution des coûts sont pris en compte lors de la configuration des espaces de travail et des clusters pour les équipes et les cas d’usage. Cela simplifie l’étiquetage et améliore la précision de l’attribution de coûts.

Les coûts totaux incluent les coûts de DBU, de machine virtuelle, de disque et tous les coûts réseau associés. Pour les entrepôts SQL serverless, les coûts DBU incluent déjà les coûts des machines virtuelles et des disques.

Les balises des ressources Azure Databricks peuvent être utilisées dans les outils d’analyse des coûts dans le portail Azure

Implémenter l’observabilité pour suivre et refacturer les coûts

Lorsque vous travaillez avec des écosystèmes techniques complexes, la compréhension proactive des inconnues est essentielle pour maintenir la stabilité de la plateforme et contrôler les coûts. L’observabilité permet d’analyser et d’optimiser les systèmes en fonction des données qu’ils génèrent. Cela diffère de la surveillance, qui se concentre sur l’identification de nouveaux modèles plutôt que sur le suivi des problèmes connus.

Databricks offre de grandes fonctionnalités d’observabilité à l’aide de tables système qui sont des magasins analytiques hébergés par Databricks des données opérationnelles d’un compte client trouvées dans le catalogue système. Ces tables système fournissent une observabilité historique sur le compte et incluent des informations tabulaires conviviales sur la télémétrie de plateforme.

Consultez Blog : Équilibrer intelligemment l’optimisation des coûts et la fiabilité sur Databricks

Partager régulièrement les rapports de coûts

Générez des rapports de coûts mensuels pour suivre la croissance et les anomalies de la consommation. Partagez ces rapports par cas d’usage ou par équipe avec les équipes propriétaires des charges de travail qui utilisent l’étiquetage de cluster. Cela élimine les surprises et permet aux équipes d’ajuster de manière proactive leurs charges de travail, si les coûts deviennent trop élevés.

Surveiller et gérer les coûts de sortie Delta Sharing

Contrairement à d’autres plateformes de partage de données, Delta Sharing ne nécessite pas de réplication des données. Ce modèle présente de nombreux avantages, mais il signifie que votre fournisseur de cloud peut facturer des frais de sortie de données lorsque vous partagez des données entre des clouds ou des régions. Consultez Surveiller et gérer les coûts de sortie Delta Sharing (pour les fournisseurs) pour surveiller et gérer les frais de sortie.

4. Concevoir des charges de travail rentables

Équilibrer le streaming toujours activé et déclenché

Traditionnellement, si l’on pense à la diffusion en continu, des termes tels que « temps réel », « 24 heures sur 24, 7 j/7 » ou « toujours diffusé » viennent à l’esprit. Si l’ingestion de données se produit en temps réel, la ressource de calcul sous-jacente doit s’exécuter 24 heures sur 24, 7 jours sur 7, ce qui génère des coûts à toute heure de la journée.

Toutefois, tous les cas d’usage qui reposent sur un flux continu d’événements ne nécessitent pas que ces événements soient ajoutés immédiatement au jeu de données d’analyse. Si l’exigence métier pour le cas d’usage indique le besoin de données nouvelles uniquement à quelques heures d’intervalle ou tous les jours, cette exigence peut être assouvie avec seulement quelques exécutions par jour, ce qui entraîne une réduction significative des coûts de la charge de travail. Databricks recommande d’utiliser Structured Streaming avec le AvailableNow déclencheur pour les charges de travail incrémentielles qui n’ont pas d’exigence de faible latence. Consultez Configuration du traitement par lots incrémentiel.

Équilibre entre les instances à la demande et les instances à capacité excédentaire

Instances Spot bénéficier des ressources de machines virtuelles excédentaires dans le cloud qui sont disponibles à un prix inférieur. Pour réduire les coûts, Azure Databricks prend en charge la création de clusters à l’aide d’instances spot. Databricks recommande que la première instance (le pilote Spark) soit toujours une machine virtuelle à la demande. Les instances spot constituent un bon choix pour les charges de travail là où c’est acceptable de prendre plus de temps, car une ou plusieurs instances spot ont été supprimées par le fournisseur de cloud.