Bonnes pratiques de configuration du compute classique
Cette page présente les meilleures pratiques pour la configuration des ressources de compute classiques. Pour la plupart des nouvelles charges de travail, Databricks recommande d’utiliser le compute serverless, qui ne nécessite aucune configuration. Si votre charge de travail n’est pas prise en charge sur le compute serverless (voir Limitations de Serverless), utilisez les bonnes pratiques suivantes pour configurer une ressource de compute classique.
Les workflows Structured Streaming ont des recommandations de configuration spécifiques. Consultez Considérations relatives à la production pour Structured Streaming.
Mode d'accès
Les ressources de compute classiques peuvent être affectées au mode d'accès standard ou dédié, ce qui détermine qui peut se connecter à la ressource de compute et l'utiliser.
Databricks recommande d'utiliser le mode d'accès standard pour la plupart des charges de travail. Le compute standard peut être partagé par plusieurs utilisateurs et groupes tout en assurant l'isolation des utilisateurs et toutes les autorisations d'accès aux données. Cela en fait une option plus facile à gérer et économique pour la plupart des charges de travail.
N'utilisez le mode d'accès dédié que si votre charge de travail présente des limitations spécifiques de compute standard, telles que ML Runtime sur GPU, les APIs RDD ou R. Pour plus d'informations, consultez les exigences et limitations du compute standard.
Si Unity Catalog est activé, ne définissez pas spark.databricks.passthrough.enabled. Le pass-through des identifiants est un mode d’accès hérité qui n’est pas compatible avec Unity Catalog.
Voir les Modes d'accès.
Version de Databricks Runtime
Utilisez la dernière version de Databricks Runtime à support à long terme (LTS). Les versions LTS bénéficient de correctifs de sécurité et de corrections de bogues étendus, garantissant que vos charges de travail restent stables et compatibles avec les dernières fonctionnalités de la plateforme.
Ne sélectionnez un runtime de machine learning que si votre charge de travail utilise des GPU, un entraînement ML distribué ou AutoML. Databricks Runtime pour ML installe un grand nombre de bibliothèques qui peuvent entrer en conflit avec vos propres dépendances si elles ne sont pas nécessaires, causant des erreurs ou des problèmes de justesse silencieux. Consultez Entraîner les modèles d'IA et de ML.
Hygiène de la configuration
Ces pratiques maintiennent vos configurations de compute propres et vos workloads portables.
Évitez d'utiliser des scripts d'initialisation
Les scripts d'initialisation peuvent introduire des comportements inattendus, notamment des conflits de bibliothèques qui perturbent les charges de travail et rendent les environnements moins prévisibles. Au lieu de cela, ajoutez des bibliothèques à vos politiques de compute, utilisez %pip install dans les Notebooks, ou définissez les dépendances dans une spécification d'environnement. Consultez Ajouter des bibliothèques à une politique.
Évitez de coder en dur les configurations Spark
Évitez de coder en dur les configurations Spark (telles que spark.executor.memory ou spark.dynamicAllocation.*) dans les définitions de compute ou de job. Les valeurs codées en dur annulent les optimisations intégrées fournies par Databricks, ce qui entraîne souvent des dépenses inutiles ou des performances dégradées. Utilisez les configurations de session propres au Notebook uniquement si vous avez une raison spécifique de remplacer un default.
Éviter les chemins de stockage locaux de compute
Ne stockez pas de données sur des chemins locaux au compute, qui ne persistent pas au-delà du cycle de vie du compute. Utilisez plutôt les volumes Unity Catalog ou le stockage temporaire. Voir Que sont les volumes ?.
Évitez les montages DBFS
Les montages DBFS ne disposent pas de listes de contrôle d'accès (ACL) appropriées. Utilisez plutôt les volumes Unity Catalog ou les systèmes de fichiers du Workspace (WSFS). Voir Que sont les volumes ?.
Évitez d’installer des bibliothèques à l’échelle du compute
L’installation de bibliothèques au niveau du compute crée un drift d’environnement entre les jobs. Utilisez plutôt %pip install dans les notebooks ou définissez les dépendances dans une spécification d’environnement. Cela facilite également la migration des charges de travail classiques vers le Serverless.
Performance
Évaluez si vous pourriez bénéficier de Photon
De nombreuses charges de travail bénéficient de Photon, mais il est particulièrement avantageux pour les charges de travail SQL et les Opérations de DataFrame impliquant des Transformations complexes, telles que les jointures, les agrégations et les analyses de données sur de grandes tables. Les charges de travail avec un accès disque fréquent, des tables larges ou un traitement de données répété voient également leurs performances améliorées.
Les Jobs ETL batch simples qui n’impliquent pas de Transformations étendues ou de grands volumes de données peuvent voir un impact minimal de l’activation de Photon, en particulier si les query se terminent généralement en moins de deux secondes.
Utiliser le dimensionnement automatique
Configurez la mise à l'échelle automatique afin que les tâches de longue durée puissent ajouter et supprimer dynamiquement des nœuds worker pendant les exécutions de Job. Consultez Activer le dimensionnement automatique.
Utilisez les pools d'instances pour réduire les temps de start
Les Pools d'instances réservent des ressources de compute auprès de votre fournisseur cloud. Les Pools réduisent le temps de start des nouveaux clusters et garantissent la disponibilité des ressources de compute. Voir la référence de configuration du Pool.
Optimisation des coûts
Utiliser les politiques de compute
Databricks recommande d'utiliser des politiques de compute. Les politiques de compute vous permettent de créer des ressources de compute préconfigurées, conçues à des fins spécifiques, telles que le compute personnel, le compute partagé, les utilisateurs avancés et les jobs. Les politiques limitent les décisions que vous devez prendre lors de la configuration des paramètres de compute.
Si vous n'avez pas accès aux stratégies, contactez l'administrateur de votre workspace. Consultez les stratégies default et les familles de stratégies.
Utiliser des instances spot
Configurez des instances ponctuelles pour les charges de travail qui ont des exigences de latence souples afin d'optimiser les coûts. Voir les instances ponctuelles.
Configurez les zones de disponibilité
Spécifiez une zone de disponibilité (AZ) si votre organisation a acheté des instances réservées, ou utilisez Auto-AZ pour réessayer dans d'autres zones de disponibilité si AWS renvoie des erreurs de capacité insuffisante. Consultez les Zones de disponibilité.
Considérations relatives au dimensionnement du compute
Les recommandations suivantes supposent que vous disposez d'une création de clusters sans restriction. Les administrateurs de Workspace ne devraient accorder ce privilège qu'aux utilisateurs avancés.
Les gens pensent souvent à la taille du compute en termes de nombre de Worker, mais il existe d’autres facteurs importants à prendre en compte :
- Cœurs d'exécuteur totaux (compute) : le nombre total de cœurs sur tous les exécuteurs. Ceci détermine le parallélisme maximal d'un 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 ci-dessus. Lorsque vous dimensionnez votre compute, tenez compte de ce qui suit :
- 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 ?
Il y a un équilibre à trouver entre le nombre de Worker et la taille des types d'instances de Worker. La configuration du compute avec deux Workers, chacun avec 16 cœurs et 128 Go de RAM, a le même compute et la même mémoire que la configuration du compute avec 8 Workers, chacun avec 4 cœurs et 32 Go de RAM.
Exemples de configuration compute
Les exemples suivants présentent des recommandations de compute basées sur des types de charges de travail spécifiques. Ces exemples incluent également les configurations à éviter et les raisons pour lesquelles ces configurations ne conviennent pas aux types de charges de travail.
Tous les exemples de cette section pourraient bénéficier de l'utilisation du compute serverless plutôt que de la création d'une nouvelle ressource de compute. Si votre charge de travail n'est pas prise en charge sur Serverless, utilisez les recommandations ci-dessous pour vous aider à configurer votre ressource de compute classique.
Analyse de données
Les data analyst effectuent généralement un traitement qui nécessite des données de plusieurs partitions, ce qui entraîne de nombreuses Opérations de brassage. Une ressource de compute avec un plus petit nombre de nœuds plus grands peut réduire les E/S réseau et disque nécessaires pour effectuer ces brassages.
Un compute à nœud unique avec un type de VM volumineux est probablement le meilleur choix, en particulier pour un seul analyste.
Les charges de travail analytiques nécessiteront probablement de lire les mêmes données à plusieurs reprises. Par conséquent, les types de nœuds recommandés sont optimisés pour le stockage avec cache disque activé ou les instances avec stockage local.
Les fonctionnalités supplémentaires recommandées pour les charges de travail analytiques incluent :
- Activez l'arrêt automatique pour vous assurer que le compute est arrêté après une période d'inactivité.
- Envisagez d'activer l'autoscaling en fonction de la charge de travail habituelle de l'analyste.
ETL de batch de base
Pour les Job ETL batch simples qui ne nécessitent pas de Transformations étendues, telles que des jointures ou des agrégations, utilisez des instances avec des exigences moindres en matière de mémoire et de stockage. Cela pourrait entraîner des économies par rapport à d’autres types de Worker.
ETL batch complexe
Pour un Job ETL complexe, tel que celui qui exige des unions et des jointures sur plusieurs tables, Databricks recommande l'utilisation d'un nombre réduit de workers afin de diminuer la quantité de données brassées. Pour compenser le nombre réduit de Workers, augmentez la taille de vos instances.
Les transformations complexes peuvent nécessiter beaucoup de compute. Si vous observez un spill important sur le disque ou des erreurs OOM, augmentez la quantité de mémoire disponible sur vos instances.
En option, utilisez des pools d'instances pour diminuer les temps de démarrage du compute et réduire la durée d'exécution totale lors de l'exécution de pipelines de Job.
Entraîner des modèles de machine learning
Pour entraîner des modèles de machine learning, Databricks vous recommande de créer une ressource de compute à l’aide de la politique Personal compute .
Utilisez un compute à nœud unique avec un type de nœud de grande taille pour l'expérimentation initiale. Un nombre réduit de nœuds diminue l'impact des brassages.
L'ajout de Worker supplémentaires peut améliorer la stabilité, mais évitez d'en ajouter trop en raison de la surcharge liée au brassage des données.
Les types de Worker recommandés sont ceux optimisés pour le stockage avec mise en cache sur disque activée, ou une instance avec stockage local pour tenir compte des lectures répétées des mêmes données et pour permettre la mise en cache des données d'entraînement.
Les fonctionnalités supplémentaires recommandées pour les charges de travail de machine learning incluent :
- Activez l'arrêt automatique pour vous assurer que le compute est arrêté après une période d'inactivité.
- Utilisez des pools d'instances, ce qui permet de restreindre le compute à un type d'instance pré-approuvé.
- Assurez des configurations de compute cohérentes à l'aide de politiques.