Aller au contenu principal
Dernière mise à jour le

Bonnes pratiques pour l'optimisation des coûts

Ces bonnes pratiques vous aident à faire correspondre les ressources aux charges de travail et à contrôler les dépenses sur Databricks, organisées selon les principes architecturaux des sections suivantes.

1. Choisissez des Ressources optimales​

Utiliser des formats de données optimisés pour la performance​

Pour tirer le meilleur parti de la Databricks Data Intelligence Platform, vous devez utiliser Delta Lake comme framework de stockage. Il aide à construire des pipelines ETL plus simples et plus fiables, et s'accompagne de nombreuses améliorations de performances qui peuvent accélérer considérablement les charges de travail par rapport à l'utilisation de Parquet, ORC et JSON. Consultez les recommandations d'optimisation sur Databricks. Si la charge de travail s'exécute également sur un compute de Job, cela se traduit directement par un temps de disponibilité plus court des ressources de compute, ce qui entraîne une réduction des coûts.

Utiliser le compute de Job​

Un job est un moyen d'exécuter du code non interactif sur une instance de compute Databricks. Par exemple, vous pouvez exécuter une charge de travail d'extraction, de transformation et de chargement (ETL) de manière interactive ou selon un calendrier. Bien sûr, vous pouvez également exécuter des jobs de manière interactive dans l'interface utilisateur du notebook. Cependant, sur le compute de job, les charges de travail non interactives coûteront beaucoup moins cher que sur le compute multifonction. Consultez la présentation des tarifs pour comparer Jobs Compute et Compute multifonction.

Un avantage supplémentaire pour certains Jobs est que chaque Job peut s'exécuter sur une nouvelle instance de compute, isolant ainsi les charges de travail les unes des autres. Cependant, les Jobs multitâches peuvent également réutiliser les Ressources de compute pour toutes les tâches, de sorte que le temps de Startup du compute ne se produit qu'une seule fois par Job. Voir Configurer le compute pour les jobs.

Utiliser un SQL Warehouse pour les workloads SQL​

Pour les charges de travail SQL interactives, un Databricks SQL warehouse est le moteur le plus rentable. Consultez la vue d'ensemble des tarifs. Tous les SQL Warehouse incluent Photon par default, ce qui accélère vos appels API SQL et DataFrame existants et réduit votre coût global par charge de travail.

En outre, les SQL Warehouses Serverless prennent en charge la gestion intelligente de la charge de travail (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.

Utilisez des runtimes à jour pour vos charges de travail​

La plateforme Databricks fournit différents runtimes optimisés pour les tâches d'ingénierie des données (Databricks Runtime) ou les tâches de Machine Learning (Databricks Runtime for Machine Learning). Les runtimes sont conçus pour offrir 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 Databricks Runtime sont publiés à cadence régulière, offrant des améliorations de performances entre les principales versions. Ces améliorations des performances entraînent souvent des économies grâce à une utilisation plus efficace des ressources de compute.

Utilisez uniquement des GPU pour les charges de travail appropriées​

Les machines virtuelles avec GPU peuvent considérablement accélérer les calculs pour le deep learning, mais sont nettement plus coûteuses que les machines uniquement équipées de CPU. Utilisez les instances GPU uniquement pour les charges de travail qui utilisent des bibliothèques accélérées par GPU.

La plupart des charges de travail n’utilisent pas de bibliothèques accélérées par GPU, elles ne bénéficient donc pas d’instances compatibles GPU. Les administrateurs du Workspace peuvent restreindre les machines GPU et les ressources compute afin d'éviter une utilisation inutile. Consultez le billet de blog « Les GPU sont-ils vraiment coûteux ? Évaluation des performances des GPU pour l'inférence sur les clusters Databricks ».

Utiliser des services serverless pour vos charges de travail​

Cas d'usage BI

Les charges de travail BI consomment généralement des données par rafales et génèrent plusieurs queries concurrentes. Par exemple, une personne utilisant un outil de BI pourrait mettre à jour un tableau de bord ou rédiger une query, puis simplement analyser les résultats sans autre interaction avec la plateforme. Dans ce scénario, la plateforme de données :

  • Arrête les ressources de compute inactives pour économiser les coûts.
  • Fournit rapidement les ressources de compute lorsque l'utilisateur demande des données nouvelles ou mises à jour avec l'outil de BI.

Les warehouses Databricks SQL non Serverless ont un temps de Startup de plusieurs minutes, de sorte que de nombreux utilisateurs ont tendance à accepter le coût plus élevé et ne les arrêtent pas pendant les périodes d'inactivité. D'autre part, les SQL Warehouses Serverless start et montent en charge en quelques secondes, de sorte que la disponibilité instantanée et la terminaison au ralenti peuvent être atteintes. Cela se traduit par une excellente expérience utilisateur et des économies de coûts globales.

De plus, les SQL warehouses Serverless réduisent leur taille plus tôt que les warehouses non Serverless, ce qui entraîne des coûts inférieurs.

Service de modèles ML et d'IA

La plupart des modèles sont servis en tant qu'API REST pour l'intégration dans votre application web ou client ; le service de déploiement de modèles reçoit des charges de requêtes variables au fil du temps, et une plateforme de déploiement de modèles devrait toujours fournir des ressources suffisantes, mais seulement autant que nécessaire (mise à l'échelle et réduction d'échelle).

Model Serving utilise un compute serverless et fournit un service hautement disponible et à faible latence pour le déploiement de modèles. Le service adapte automatiquement ses capacités à la demande, réduisant ainsi les coûts d'infrastructure tout en optimisant les performances en termes de latence.

Utiliser le bon type d'instance​

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 ils offrent les meilleures performances et les dernières fonctionnalités.

En fonction de vos charges de travail, il est également important de choisir la bonne famille d'instances pour obtenir le meilleur rapport performance-prix. Voici quelques règles générales simples :

  • Mémoire optimisée pour les charges de travail ML, heavy shuffle et spill
  • Compute optimisé pour les charges de travail de streaming structuré et les jobs de maintenance (tels que optimize et vacuum)
  • Stockage optimisé pour les charges de travail qui bénéficient de la mise en cache, telles que l'analyse de données ad hoc et interactive
  • GPU optimisé pour les workloads ML et DL spécifiques
  • Usage général en l'absence d'exigences spécifiques

Choisissez la taille de compute la plus efficace​

Databricks exécute un exécuteur par nœud worker. Par conséquent, les termes executor et Worker sont utilisés de manière interchangeable dans le contexte de l'architecture Databricks. On pense souvent à la taille des clusters en fonction du nombre de Worker, mais d'autres facteurs importants sont à prendre en compte :

  • Cœurs d'exécuteur totaux (compute) : le nombre total de cœurs sur tous les exécuteurs. Cela détermine le parallélisme maximal d'une instance de compute.
  • Mémoire totale de l’exécuteur : la quantité totale de RAM pour tous les exécuteurs. Ceci détermine la quantité de données pouvant être stockées en mémoire avant de les spilling sur le disque.
  • Stockage local de l'Executor : Le type et la quantité de stockage sur disque local. Le disque local est principalement utilisé en cas de spills pendant les shuffles et la mise en cache.

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

  • Quelle quantité de données votre charge de travail consommera-t-elle ?
  • Quelle est la complexité de calcul de votre charge de travail ?
  • D'où lisez-vous les données ?
  • Comment les données sont-elles partitionnées dans le stockage externe ?
  • De combien de parallélisme avez-vous besoin ?

Les détails et des exemples peuvent être trouvés sous Considérations de dimensionnement du compute.

Dimensionnez correctement les ressources de compute lors du déploiement​

Établissez des normes de dimensionnement compute et des politiques lors du déploiement pour assurer une allocation de ressources rentable :

Dimensionnement du compute classique pour différents types de charges de travail

  • Développement/tests : compute mononœud ou petit compute classique (de 2 à 4 workers) avec autoscaling.
  • batch ETL : compute classique moyen (8 à 16 Worker) avec des instances optimisées pour la mémoire et l'autoscaling activé.
  • Streaming : Compute classique de petite à moyenne taille (4-8 Workers) avec mise à l'échelle automatique pour un throughput variable.
  • Machine Learning : instances GPU dimensionnées en fonction du modèle et du volume de données.

Dimensionnement du SQL Warehouse : dimensionnez les SQL Warehouses en fonction du nombre d'utilisateurs simultanés et de la complexité de la query. start avec des warehouse Small ou Medium et activez l'autoscaling. Utilisez les SQL Warehouses Serverless pour un Startup instantané et une mise à l'échelle automatique.

Stratégies de calcul classiques pour le contrôle des coûts : Créez des stratégies de calcul classiques pour appliquer des normes de dimensionnement, limiter les types d'instances coûteux, exiger la mise à l'échelle automatique et définir le nombre maximal de workers. Définir des politiques de taille (T-shirt) (c'est-à-dire, Petite, Moyenne ou Grande) pour des configurations de compute standardisées.

Pour des tableaux de dimensionnement détaillés du compute, la configuration du SQL Warehouse et des exemples de politiques de compute classiques, consultez Stratégie de dimensionnement des clusters.

Évaluer les moteurs de requêtes optimisés pour la performance​

Photon est un moteur de requête vectorisé natif de Databricks et haute performance qui accélère vos charges de travail SQL et les appels d'API DataFrame (pour l'ingestion de données, l'ETL, le streaming, la data science et les requêtes interactives). Photon est compatible avec les API Apache Spark. Ainsi, pour **start**, il suffit de l'activer, sans aucune modification de code ni dépendance vis-à-vis d'un fournisseur.

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

2. Allouer dynamiquement des ressources​

Utilisez le compute à mise à l'échelle automatique​

Avec le dimensionnement automatique, Databricks réaffecte dynamiquement les Worker pour tenir compte des caractéristiques de votre Job. Certaines parties de votre pipeline peuvent être plus gourmandes en calcul que d'autres, et Databricks ajoute automatiquement des workers supplémentaires pendant ces phases de votre job (et les supprime lorsqu'ils ne sont plus nécessaires). Le dimensionnement automatique peut réduire les coûts globaux par rapport à une instance de compute de taille statique.

La mise à l'échelle automatique du compute présente des limitations lors de la réduction de la taille des clusters pour les charges de travail de streaming structuré. Databricks recommande d'utiliser les Lakeflow pipelines avec la mise à l'échelle automatique améliorée pour les charges de travail de streaming.

Utiliser l'arrêt automatique​

Databricks offre plusieurs fonctionnalités pour aider à contrôler les coûts en réduisant les Ressources inactives et en contrôlant le moment où les Ressources de compute peuvent être déployées.

  • Configurez l'arrêt automatique pour toutes les Ressources de compute interactives. Après un délai d'inactivité spécifié, la Ressource de compute s'arrête. Consultez l'arrêt automatique.
  • Pour les cas d'utilisation où le compute n'est nécessaire que pendant les heures ouvrables, les ressources de compute peuvent être configurées avec un arrêt automatique, et un processus planifié peut redémarrer le compute (et éventuellement précharger les données si nécessaire) le matin avant que les utilisateurs ne soient de retour à leur bureau. See CACHE SELECT.
  • Si les temps de Startup du compute sont trop longs, envisagez d'utiliser des Pool de clusters, consultez Bonnes pratiques relatives aux Pool. Les pools Databricks sont un ensemble d'instances inactives et prêtes à l'emploi. Lorsque les nœuds de cluster sont créés à l'aide d'instances inactives, les temps de start et de mise à l'échelle automatique des clusters sont réduits. Si les pools ne contiennent pas d'instances inactives, les pools s'étendent en allouant une nouvelle instance auprès du fournisseur d'instances afin de répondre à la demande du cluster.

Databricks ne facture pas les Databricks Units (DBUs) lorsque les instances sont inactives dans le pool, ce qui permet de réaliser des économies. La facturation du fournisseur d'instances s'applique.

Utiliser des politiques de compute pour contrôler les coûts​

Les politiques de Compute peuvent appliquer de nombreuses restrictions spécifiques aux coûts pour les ressources de compute. Voir Excellence opérationnelle - Utiliser des politiques de compute. Par exemple :

3. Surveiller et contrôler les coûts​

La gestion des coûts dans Databricks est un aspect essentiel de l'optimisation des dépenses cloud tout en maintenant les performances. Le processus peut être décomposé en trois domaines clés :

  • Installer
  • Surveillance
  • Gestion

Les bonnes pratiques suivantes couvrent ces trois domaines.

Configurer le balisage pour l'attribution des coûts​

Pour surveiller les coûts en général et pour attribuer avec précision l'utilisation de Databricks aux unités commerciales et aux équipes de votre organisation (par exemple, pour la refacturation au sein de votre organisation), vous pouvez étiqueter les Workspace, les clusters, les SQL Warehouse et les Pool.

Dans la phase de configuration, les organisations doivent mettre en œuvre des pratiques de taggage efficaces. Cela implique la création de conventions de nommage de tags à l'échelle de l'organisation. Il est important d'utiliser à la fois des tags généraux qui attribuent l'utilisation à des groupes d'utilisateurs spécifiques et des tags plus granulaires qui fournissent des insight très spécifiques, par exemple basés sur les rôles, les produit ou les services.

start à baliser dès le début de l'utilisation de Databricks. En plus des balises default définies par Databricks, configurez au minimum les balises personnalisées _Business Units_ et _Projects_ et remplissez-les pour votre organisation spécifique. Si vous avez besoin de faire la distinction entre les coûts de développement, d'assurance qualité et de production, envisagez d'ajouter la balise Environment aux Workspaces et aux ressources de compute.

Les balises sont propagées aux Logs d’utilisation et aux Ressources du fournisseur cloud pour l’analyse des coûts. Les coûts totaux comprennent les Databricks Units (DBU), ainsi que les coûts des machines virtuelles, des disques et des réseaux associés. Notez que pour les services serverless, le coût du DBU inclut déjà les coûts des machines virtuelles.

Étant donné que l'ajout de tags n'affecte que l'utilisation future, il est préférable de start par une structure de tagging plus détaillée. Il est toujours possible d'ignorer les tags si leur utilisation pratique au fil du temps montre qu'ils n'ont aucun impact sur la compréhension et l'attribution des coûts. Mais les balises manquantes ne peuvent pas être ajoutées aux événements passés.

Configurez des budgets et des alertes pour permettre le monitoring des dépenses du compte​

Les budgets vous permettent de surveiller l'utilisation sur l'ensemble de votre compte. Ils offrent un moyen de fixer des objectifs financiers et vous permettent de suivre les dépenses à l'échelle du compte ou d'appliquer des filtres pour suivre les dépenses d'équipes, de projets ou de Workspace spécifiques. Si votre compte utilise le compute serverless, assurez-vous d'utiliser les politiques d'utilisation pour attribuer l'utilisation serverless de votre compte. Voir Attribuer l'utilisation serverless avec des politiques d'utilisation.

Il est recommandé de configurer des notifications e-mail lorsque le budget mensuel est atteint afin d'éviter les dépassements imprévus.

Surveillez les coûts pour aligner les dépenses sur les attentes​

Les tableaux de bord d'observabilité des coûts aident à visualiser les modèles de dépenses, et les politiques d'utilisation aident à attribuer l'utilisation du compute serverless à des utilisateurs, des groupes ou des projets spécifiques, permettant une allocation des coûts plus précise. Pour maîtriser les dépenses, Databricks offre une gamme d'outils et de fonctionnalités pour suivre et analyser les coûts :

  • Surveillez l'utilisation dans la console du compte : Databricks propose des tableaux de bord AI/BI de gestion des coûts dans la console du compte, qui peuvent être importés par les administrateurs de compte vers n'importe quel workspace compatible Unity Catalog de leur compte. Cela vous permet de surveiller soit l'utilisation du compte, soit l'utilisation d'un seul workspace.

  • **Utilisez les budgets pour surveiller les dépenses du compte** : Lesbudgets vous permettent de surveiller l'utilisation de votre compte.
    Les politiques d'utilisation peuvent être utilisées pour attribuer l'utilisation serverless en appliquant des tags à toute activité de compute serverless engendrée par un utilisateur affecté à la politique.

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

  • Surveiller les coûts à l'aide de tables système : la table système system.billing.usage permet de surveiller les coûts. Les balises personnalisées appliquées aux workspaces et aux ressources de compute sont propagées à cette table système. Vous pouvez surveiller les coûts du compute serverless, les coûts des Jobs et les coûts de diffusion de modèles.

  • Download l'utilisation facturable pour une analyse locale : Vous pouvez utiliser l'API REST du compte pour télécharger les journaux d'utilisation facturable au format CSV pour le compte et la plage de dates spécifiés.

Gérer les coûts pour aligner l'utilisation sur les besoins de l'organisation​

La gestion des coûts va au-delà de la mise en œuvre technique pour inclure des stratégies organisationnelles plus larges :

  • Développez et planifiez un Job de maintenance pour appliquer ou nettoyer (incrémentiellement) les tags. Le job doit être résilient afin de ne pas être interrompu par des problèmes liés à une seule ressource. Toutes les modifications doivent être consignées dans un audit Logs.
  • Effectuez des audits de coûts réguliers pour examiner toutes les Ressources actives, leurs dépenses et leur alignement avec les besoins de l'organisation. Le partage des rapports de coûts mensuels aide à suivre les augmentations de consommation et les anomalies, et encourage la gestion proactive des coûts dans toutes les équipes.
  • Optimisez l'allocation des ressources grâce à des stratégies telles que l'autoscaling et l'arrêt automatique, qui allouent dynamiquement des ressources en fonction des exigences de la charge de travail ; consultez les autres bonnes pratiques de ce chapitre.
  • Sensibiliser les équipes aux implications financières de leur utilisation des ressources et les former aux bonnes pratiques d'optimisation des coûts.
  • Utilisez les politiques de compute comme un outil pour contrôler le type et la taille des ressources de compute que certains utilisateurs peuvent créer et auxquelles ils peuvent accéder.

Dans l'ensemble, l'optimisation des coûts doit être considérée comme un processus continu et les stratégies doivent être régulièrement réexaminées en cas de mise à l'échelle, de nouveaux projets ou de pics de coûts imprévus. Utilisez à la fois les capacités natives de gestion des coûts de Databricks et les outils tiers pour un contrôle et une optimisation complets.

4. Concevez des charges de travail rentables​

Équilibrer le streaming en continu et Trigger​

Traditionnellement, lorsque les gens pensent au streaming, des termes tels que « temps réel », « 24h/24 et 7j/7 » ou « toujours disponible » viennent à l'esprit. Si l'ingestion de données se produit en temps réel, les ressources de compute sous-jacentes doivent fonctionner 24h/24 et 7j/7, ce qui entraîne des coûts à chaque heure de la journée.

Cependant, tous les cas d'utilisation qui reposent sur un Stream continu d'événements ne nécessitent pas que ces événements soient immédiatement ajoutés au jeu de données analytique. Si l'exigence métier pour le cas d'utilisation ne nécessite des données fraîches que toutes les quelques heures ou tous les jours, alors cette exigence peut être satisfaite avec seulement quelques exécutions par jour, ce qui entraîne une réduction significative du coût de la charge de travail. Databricks recommande d'utiliser Structured Streaming avec le Trigger AvailableNow pour les charges de travail incrémentielles qui n'ont pas d'exigences de faible latence. Consultez AvailableNow: Traitement par batch incrémentiel.

Équilibre entre les instances à la demande et les instances en excès de capacité​

Les instances préemptibles tirent parti des ressources excédentaires de machines virtuelles dans le cloud qui sont disponibles à un prix inférieur. Pour réduire les coûts, Databricks prend en charge la création de clusters à l'aide d'instances spot. Il est recommandé que la première instance (le Driver Spark) soit toujours une machine virtuelle à la demande. Les instances préemptables sont un bon choix pour les charges de travail où il est acceptable que cela prenne plus de temps, car une ou plusieurs instances ponctuelles ont été évincées par le fournisseur de cloud.

Sur cette page