Meilleures pratiques de configuration de calcul classiques

Cette page présente les meilleures pratiques pour la configuration des ressources de calcul classiques. Pour la plupart des nouvelles charges de travail, Databricks recommande d’utiliser le calcul serverless, ce qui ne nécessite aucune configuration. Si votre charge de travail n’est pas prise en charge sur le calcul sans serveur (voir Limitations du mode sans serveur), appliquez les bonnes pratiques suivantes pour configurer une ressource de calcul classique.

Remarque

Les flux de travail de streaming structuré ont des recommandations de configuration spécifiques. Consultez Les considérations relatives à la production pour le Streaming structuré.

Mode d’accès

Les ressources de calcul classiques peuvent être affectées au mode d’accès standard ou dédié, ce qui détermine qui peut attacher et utiliser la ressource de calcul.

Databricks recommande d’utiliser le mode d’accès standard pour la plupart des charges de travail. Le calcul standard peut être partagé par plusieurs utilisateurs et groupes tout en appliquant l’isolation des utilisateurs et toutes les autorisations d’accès aux données. Cela facilite la gestion et la rentabilité de la plupart des charges de travail.

Utilisez uniquement le mode d’accès dédié si votre charge de travail présente des limitations de calcul standard spécifiques, telles que ML Runtime sur GPU, API RDD ou R. Pour plus d’informations, consultez exigences et limitations de calcul standard.

Si Unity Catalog est activé, ne définissez pas spark.databricks.passthrough.enabled. Le passage des informations d’identification est un mode d’accès hérité qui n’est pas compatible avec Unity Catalog.

Voir Modes d'accès.

Version de Databricks Runtime

Utilisez la dernière version de Databricks Runtime avec prise en charge à long terme (LTS). Les versions LTS reçoivent des correctifs de sécurité étendus et des correctifs de bogues, ce qui garantit que vos charges de travail restent stables et compatibles avec les dernières fonctionnalités de la plateforme.

Sélectionnez uniquement un runtime De Machine Learning si votre charge de travail utilise des GPU, une formation ml distribuée ou AutoML. Databricks Runtime pour ML installe un grand ensemble de bibliothèques qui peuvent entrer en conflit avec vos propres dépendances si ce n’est pas nécessaire, provoquant des erreurs ou des problèmes de correction silencieuse. Consultez Entraîner des modèles d’IA et de ML.

Hygiène de configuration

Ces pratiques permettent de nettoyer vos configurations de calcul et vos charges de travail portables.

Éviter d’utiliser des scripts init

Les scripts Init peuvent introduire des comportements inattendus, notamment des conflits de bibliothèque qui interrompent les charges de travail et rendent les environnements moins prévisibles. Au lieu de cela, ajoutez des bibliothèques à vos stratégies de calcul, utilisez %pip install dans des notebooks ou définissez des dépendances dans une spécification d’environnement. Consultez Ajouter des bibliothèques à une stratégie.

Éviter de coder en dur les configurations Spark

Évitez de coder en dur les configurations Spark (par spark.executor.memoryspark.dynamicAllocation.*exemple) dans les définitions de calcul ou de travail. Les valeurs codées en dur remplacent les optimisations intégrées que Azure Databricks fournit, ce qui entraîne souvent des dépenses perdues ou des performances dégradées. Utilisez des configurations de session propres au notebook uniquement lorsque vous avez une raison précise de redéfinir un paramètre par défaut.

Éviter les chemins de stockage locaux de calcul

Ne stockez pas de données sur des chemins locaux de calcul, qui ne sont pas conservés au-delà du cycle de vie du calcul. Utilisez plutôt des volumes de catalogue Unity ou un stockage temporaire. Voir Qu’est-ce que les volumes ?.

Éviter les montages DBFS

Les montages DBFS ne disposent pas de listes de contrôle d’accès appropriées (ACL). Utilisez plutôt des volumes de catalogue Unity ou des systèmes de fichiers d’espace de travail (WSFS). Voir Qu’est-ce que les volumes ?.

Éviter d’installer des bibliothèques délimitées par le calcul

L’installation de bibliothèques au niveau des ressources de calcul crée une dérive de l’environnement d’un job à l’autre. Utilisez plutôt %pip install dans les notebooks ou définissez des dépendances dans une spécification d’environnement. Cela facilite également la migration des charges de travail classiques vers serverless.

Efficacité

Évaluer si vous bénéficieriez de Photon

De nombreuses charges de travail bénéficient de Photon, mais il est le plus avantageux pour les charges de travail SQL et les opérations dataFrame impliquant des transformations complexes, telles que des jointures, des agrégations et des analyses de données sur des tables volumineuses. Les charges de travail avec accès fréquent au disque, tables larges ou traitement de données répétés voient également des performances améliorées.

Les travaux ETL par lots simples qui n’impliquent pas de transformations larges ou de volumes de données volumineux peuvent avoir un impact minimal sur l’activation de Photon, en particulier si les requêtes se terminent généralement en moins de deux secondes.

Utiliser la mise à l’échelle automatique

Configurez la mise à l’échelle automatique afin que les tâches longues puissent ajouter et supprimer dynamiquement des nœuds de travail pendant leur exécution. Consultez Activer la mise à l’échelle automatique.

Utiliser des pools d’instances pour réduire les heures de début

Les pools d’instances réservent des ressources de calcul à partir de votre fournisseur de cloud. Les pools diminuent le temps de démarrage du nouveau cluster et garantissent la disponibilité des ressources de calcul. Consultez Informations de référence sur la configuration de pool.

Optimisation des coûts

Utiliser des stratégies de calcul

Azure Databricks recommande d’utiliser des stratégies de calcul. Les stratégies de calcul vous permettent de créer des ressources de calcul préconfigurées conçues à des fins spécifiques, telles que le calcul personnel, le calcul partagé, les utilisateurs expérimentés et les tâches. Les stratégies limitent les décisions que vous devez prendre lors de la configuration des paramètres de calcul.

Si vous n’avez pas accès aux stratégies, contactez l’administrateur de votre espace de travail. Consultez les stratégies et les familles de stratégies par défaut.

Utiliser des instances spot

Configurez des instances spot pour les charges de travail ayant des exigences de latence souples afin d'optimiser les coûts. Consultez Instances Spot.

Considérations relatives au dimensionnement de la capacité de calcul

Remarque

Les recommandations suivantes supposent que vous disposez d’une création de cluster sans restriction. Les administrateurs d’espace de travail ne doivent accorder ce privilège qu’aux utilisateurs avancés.

Les gens considèrent souvent la taille de calcul 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’un 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 ci-dessus. 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 ?
  • D’où lisez-vous les données ?
  • Comment les données sont-elles partitionnées dans un stockage externe ?
  • De quel degré de parallélisme avez-vous besoin ?

Il existe un acte d’équilibrage entre le nombre de threads de travail et la taille des types d’instance de travail. La configuration d’un calcul avec deux Workers, chacun avec 16 cœurs et 128 Go de RAM, a le même calcul et la même mémoire que la configuration d’un calcul avec 8 Workers, chacun avec 4 cœurs et 32 Go de RAM.

Exemples de configuration de calcul

Les exemples suivants illustrent des recommandations de calcul basées sur des types de charges de travail spécifiques. Ces exemples incluent également des configurations pour éviter et pourquoi ces configurations ne conviennent pas aux types de charges de travail.

Remarque

L’ensemble des exemples de cette section gagneraient à utiliser l’informatique sans serveur plutôt que de provisionner une nouvelle ressource de calcul. Si votre charge de travail n’est pas prise en charge sur serverless, utilisez les recommandations ci-dessous pour configurer votre ressource de calcul classique.

Analyse des données

Les analystes de données effectuent généralement un traitement nécessitant des données à partir de plusieurs partitions, ce qui entraîne de nombreuses opérations de lecture aléatoire. Une ressource de calcul comportant un plus petit nombre de nœuds plus grands peut réduire les E/S réseau et disque nécessaires pour effectuer ces opérations de mélange.

Un calcul à nœud unique avec un type de machine virtuelle volumineux est probablement le meilleur choix, en particulier pour un analyste seul.

Les charges de travail analytiques nécessiteront probablement la lecture répétée des mêmes données. Les types de nœuds recommandés sont donc les nœuds à stockage optimisé avec cache de disque activé ou les instances avec stockage local.

Les fonctionnalités supplémentaires recommandées pour les charges de travail analytiques sont les suivantes :

  • Activez la terminaison automatique pour vous assurer que le calcul est terminé après une période d’inactivité.
  • Envisagez d’activer la mise à l’échelle automatique en fonction de la charge de travail classique de l’analyste.

ETL de base pour le traitement par lots

Pour les travaux ETL par lots simples qui ne nécessitent pas de transformations larges, telles que des jointures ou des agrégations, utilisez des instances avec des exigences inférieures pour la mémoire et le stockage. Cela peut entraîner des économies sur d’autres types de travailleurs.

ETL (traitement par lots) complexe

Pour un travail ETL complexe, tel qu’un travail qui nécessite des unions et des jointures sur plusieurs tables, Azure Databricks recommande d’utiliser moins de workers pour réduire la quantité de données regroupées. Pour compenser le fait d’avoir moins de collaborateurs, augmentez la taille de vos instances.

Les transformations complexes peuvent être gourmandes en calcul. Si vous observez un déversement significatif sur le disque ou les erreurs OOM, augmentez la quantité de mémoire disponible sur vos instances.

Si vous le souhaitez, utilisez des pools d’instances pour réduire les temps de lancement de calcul et réduire le runtime total lors de l’exécution de pipelines de travaux.

Entraînement des modèles de Machine Learning

Pour entraîner des modèles Machine Learning, Azure Databricks recommande de créer une ressource de calcul à l’aide de la stratégie de calcul personnel.

Utilisez un calcul à nœud unique avec un type de nœud volumineux pour l’expérimentation initiale. Le fait d’avoir moins de nœuds réduit l’impact des remaniements.

L’ajout de travailleurs supplémentaires peut aider à la stabilité, mais évitez d’ajouter trop de travailleurs en raison de la surcharge liée à la synchronisation des données.

Les types de collaborateurs recommandés sont un stockage optimisé avec mise en cache du disque activée, ou une instance avec un 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 sont les suivantes :

  • Activez la terminaison automatique pour vous assurer que le calcul est terminé après une période d’inactivité.
  • Utilisez des pools d’instances, qui permettent de restreindre le calcul à un type d’instance pré-approuvé.
  • Vérifiez les configurations de calcul cohérentes à l’aide de stratégies.