Configurer les performances de calcul

La configuration des ressources de calcul implique l’équilibrage des exigences de performances avec des considérations relatives aux coûts. Le surapprovisionnement entraîne des dépenses inutiles, tandis que le sous-approvisionnement peut entraîner des problèmes de stabilité et ralentir l’exécution des requêtes. Comprendre comment configurer les paramètres de calcul vous permet d’optimiser les ressources pour votre charge de travail.

Comprendre les composants de ressources de calcul

Les performances de calcul dépendent de trois facteurs clés qui fonctionnent ensemble. Chaque facteur influence l’efficacité de l’exécution de votre charge de travail et son coût.

Les cœurs d’exécuteur total déterminent le parallélisme maximal disponible pour le traitement des données. D’autres cœurs permettent à Spark de traiter plus de tâches simultanément. Un cluster avec 8 travailleurs, chacun ayant 4 cœurs, fournit un total de 32 cœurs pour le traitement en parallèle.

La mémoire totale de l’exécuteur affecte la quantité de données pouvant être traitées en mémoire avant de se déverser sur le disque. Les opérations gourmandes en mémoire, telles que les jointures et les agrégations, bénéficient de configurations de mémoire plus volumineuses. Lorsque la mémoire est insuffisante, Spark écrit des données sur le disque, ce qui ralentit considérablement les performances.

Le stockage local fournit un espace temporaire pour les opérations aléatoires et la mise en cache. Pendant les opérations de shuffle, Spark écrit des données intermédiaires sur des disques locaux des nœuds de travail. Le stockage local rapide réduit le temps consacré à ces opérations.

Avec cette compréhension des composants de calcul, vous pouvez prendre des décisions éclairées sur les types de nœuds et la taille du cluster.

Configurer les types de nœuds et la taille du cluster

La sélection de type de nœud a un impact direct sur les performances et le coût. Différentes familles d’instances présentent différentes caractéristiques de charge de travail.

Les instances optimisées en mémoire fonctionnent bien pour les charges de travail avec des jointures, des agrégations ou des données volumineuses qui doivent rester en mémoire. Ces instances fournissent davantage de RAM par cœur, ce qui réduit la probabilité de spill des données sur disque. Les exemples incluent des machines virtuelles de série E , qui offrent des ratios mémoire-cœur élevés idéals pour l’analytique en mémoire.

Les instances optimisées pour le calcul conviennent aux charges de travail qui effectuent des calculs complexes, mais qui ne nécessitent pas de grandes quantités de mémoire. Les travaux ETL avec des transformations simples s’exécutent souvent efficacement sur ces instances. Par exemple, les machines virtuelles de la série F fournissent des performances de processeur élevées avec des ratios de mémoire inférieurs.

Les instances optimisées pour le stockage bénéficient de charges de travail qui lisent à plusieurs reprises les mêmes données ou nécessitent un accès rapide au disque local. Les charges de travail d’analyse des données avec la mise en cache activée fonctionnent mieux avec ces instances. Par exemple, les machines virtuelles de la série L offrent un stockage NVMe local rapide pour les charges de travail d’E/S élevées.

Les instances accélérées par GPU fournissent des unités de traitement graphique conçues pour des charges de travail gourmandes en calcul, comme le Machine Learning, le Deep Learning et le traitement d’images. Ces instances peuvent accélérer l’entraînement du modèle de 10 à 100 fois par rapport aux clusters processeur uniquement. Les exemples incluent des machines virtuelles de série NC et ND avec des GPU NVIDIA. Les instances GPU nécessitent Databricks Runtime ML et fonctionnent mieux pour les tâches telles que l’entraînement de réseaux neuronaux, le réglage des modèles de langage volumineux ou l’exécution d’inférence sur des modèles complexes.

L’équilibre entre le nombre de workers et la taille de l’instance affecte les performances différemment selon votre charge de travail. Deux workers avec 16 cœurs et 128 Go de RAM fournissent chacun le même nombre total de calcul et de mémoire que huit workers avec 4 cœurs et 32 Go de RAM chacun. Toutefois, la configuration avec moins de Workers plus volumineux réduit le trafic réseau lors des opérations de shuffle, tandis qu'une configuration avec davantage de Workers plus petits peut offrir un meilleur parallélisme pour des charges de travail fortement distribuées.

Pour les charges de travail analytiques avec de nombreuses opérations de shuffle, moins de Workers plus volumineux offrent généralement de meilleures performances. Pour un traitement par lots simple qui bénéficie d’un parallélisme élevé, les travailleurs plus petits peuvent être plus rentables.

Utiliser des types de nœuds flexibles

Lorsque Azure Databricks lance une ressource de calcul, votre fournisseur de cloud peut parfois manquer de capacité pour votre type d’instance spécifié. Cela entraîne une CLOUD_PROVIDER_RESOURCE_STOCKOUT erreur, qui peut retarder ou échouer l’exécution du travail sans avertissement.

Les types de nœuds flexibles répondent à ce problème en revenant automatiquement aux types d’instances alternatifs compatibles lorsque le type préféré n’est pas disponible. Les alternatives compatibles partagent le même nombre de vCPU, la mémoire (dans la plage de 100 à 110 %), la configuration de disque local, l’architecture du processeur et la prise en charge de l’image du système d’exploitation comme le type d’instance principal, ce qui garantit que votre charge de travail s’exécute correctement, quel que soit le type acquis.

Les administrateurs d’espace de travail activent cette fonctionnalité en basculant Activer les types de nœuds flexibles automatiquement dans les paramètres d’administrateur de Calcul de l’espace de travail. Une fois activée, toutes les nouvelles ressources de calcul classiques utilisent automatiquement les types d’instances de secours. Ceci est particulièrement utile pour les instances spot : les types de nœuds flexibles peuvent tenter d’acquérir parmi plusieurs types compatibles avant de revenir aux instances à la demande, augmentant ainsi le pourcentage d’instances spot utilisées et réduisant les coûts de calcul totaux.

Pour les charges de travail avec des exigences strictes en matière de type d’instance, vous pouvez désactiver les types de nœuds flexibles pour une ressource de calcul individuelle en définissant alternate_node_type_ids sur une liste vide via l’API Clusters. Vous pouvez également spécifier une liste de secours personnalisée par le biais de l’API si vous préférez contrôler les autres types utilisés plutôt que de s’appuyer sur la sélection automatique.

Configurer la mise à l’échelle automatique

La mise à l’échelle automatique ajuste le nombre de workers en fonction des demandes de charge de travail, ce qui vous permet de maintenir les performances tout en contrôlant les coûts.

Lorsque vous activez la mise à l’échelle automatique, vous définissez le nombre minimal et maximal de workers. Azure Databricks surveille les exigences de charge de travail et ajoute des workers si nécessaire, jusqu’au maximum que vous avez spécifié. Lorsque la demande diminue, les travailleurs sont supprimés au minimum.

Azure Databricks utilise la mise à l’échelle automatique optimisée par défaut lorsque vous activez la mise à l’échelle automatique. La mise à l’échelle automatique optimisée s’effectue rapidement en deux étapes de minimum à maximum. La mise à l'échelle peut diminuer même lorsque le cluster n'est pas inactif, en surveillant l'état des fichiers de shuffle. Pour le calcul du travail, il évalue l’utilisation toutes les 40 secondes. Pour le calcul à usage entier, il vérifie toutes les 150 secondes.

Envisagez la mise à l’échelle automatique des charges de travail avec des besoins de ressources variables tout au long de l’exécution. Les sessions d’exploration de données commencent souvent par de petits exemples de données et traitent ultérieurement des jeux de données plus volumineux. La mise à l’échelle automatique ajoute des travailleurs lorsque vous traitez des ensembles de données plus volumineux et les supprime lorsque vous revenez à des échantillons plus petits.

Pour les charges de travail prévisibles qui conservent une utilisation cohérente des ressources, un nombre fixe de workers offre souvent des performances plus stables et une planification plus simple de la capacité. La surcharge des décisions de mise à l’échelle peut avoir un impact sur les performances des charges de travail à état stable.

La mise à l’échelle automatique fonctionne particulièrement bien avec les pools d’instances. Définissez vos travailleurs minimaux égaux ou inférieurs au nombre minimal d'instances inactives dans le pool. Cela garantit une mise à l’échelle rapide, car les instances sont déjà approvisionnées et prêtes.

Configurer les paramètres d’arrêt

L’arrêt automatique empêche les ressources de calcul inactives d’accumuler des coûts inutiles tout en conservant la disponibilité des charges de travail planifiées.

Lorsque vous configurez l’arrêt automatique, vous spécifiez une période d’inactivité en minutes. Si aucune commande n’est exécutée sur le cluster pendant plus de cette période, Azure Databricks met fin au cluster. La configuration du cluster reste disponible pour le redémarrage si nécessaire.

Pour les charges de travail interactives telles que l’analyse des données, définissez la période d’arrêt en fonction des modèles de session classiques. Un délai d’expiration de 45 minutes fonctionne bien pour la plupart des cas d’usage, ce qui permet aux ingénieurs de données de passer en revue les résultats entre les requêtes sans laisser les clusters inactifs pendant des heures.

Pour les tâches de calcul, l'arrêt automatique survient une fois que la tâche est terminée. Le cluster démarre automatiquement lorsque l’exécution planifiée suivante commence. Vous n’avez donc pas besoin de gérer manuellement le démarrage.

Les instances Spot réduisent les coûts, mais sont fournies avec des compromis de disponibilité. Azure peut récupérer des instances spot lorsque la capacité est nécessaire ailleurs. Pour les nœuds Worker, les instances spot fonctionnent bien, car Azure Databricks/Spark peut gérer les défaillances de travail. Toutefois, utilisez toujours des instances à la demande pour les nœuds de pilote. Si le pilote est récupéré, l'ensemble du cluster échoue.

Activez la désaffectation lors de l'utilisation d'instances spot pour réduire les échecs des tâches. Lorsqu'une instance Spot reçoit un avis de préemption, la désactivation migre les données de shuffle et mises en cache vers des Workers sains avant l'arrêt de l'instance. Cela réduit la nécessité de recompiler les données perdues.

Utiliser des pools d’instances

Les pools d’instances gèrent un ensemble d’instances inactives prêtes à être utilisées immédiatement, ce qui réduit le temps de démarrage du cluster de minutes à secondes.

Configurez les instances inactives minimales pour qu’elles correspondent à vos besoins de cluster simultanés standard. Si vous exécutez régulièrement trois notebooks simultanément, conservez au moins trois instances inactives. Ces instances restent disponibles même si elles ne sont pas utilisées, en fournissant un démarrage instantané du cluster.

Définissez la capacité maximale pour contrôler les coûts et empêcher une charge de travail de consommer toutes les ressources disponibles. Lorsque plusieurs équipes partagent un espace de travail, les pools avec des paramètres de capacité maximum garantissent une distribution équitable des ressources. Par exemple, avec un quota de 100 instances, vous pouvez créer deux pools chacun avec un maximum de 50 instances pour deux équipes.

Le paramètre d’arrêt automatique de l’instance inactive supprime les instances qui dépassent votre nombre minimal d’inactivités après la période spécifiée. Si vous définissez l’inactivité minimale sur 3 et l’arrêt automatique sur 30 minutes, un pool qui effectue un scale-up jusqu’à 8 instances revient à 3 instances après 30 minutes d’inactivité.

Le préchargement d’une version databricks Runtime sur les instances de pool accélère encore davantage le lancement du cluster. Lors de la création d’un cluster, si vous sélectionnez le runtime préchargé, le cluster démarre presque immédiatement, car le runtime est déjà installé sur des instances inactives.

Les pools fonctionnent mieux pour les charges de travail avec des cycles fréquents de création et de terminaison de cluster. Les équipes de développement qui créent et détruisent des clusters tout au long de la journée voient des économies de temps significatives. Les travaux de production qui s’exécutent sur des clusters de longue durée dédiés ne bénéficient pas autant des pools.

Équilibrer les coûts et les performances

L’obtention d’un bon équilibre entre les coûts et les performances nécessite de comprendre les caractéristiques de votre charge de travail et d’ajuster les configurations en conséquence.

Commencez par les paramètres conservateurs et surveillez les performances. Si vous constatez un transfert fréquent sur le disque ou une exécution lente des requêtes, augmentez la mémoire ou le nombre de cœurs. Si l’utilisation reste faible, réduisez la taille du cluster ou activez la mise à l’échelle automatique.

Utilisez le calcul serverless lorsque votre charge de travail la prend en charge. Serverless élimine les décisions de configuration et adapte automatiquement l'échelle en fonction de la demande, offrant souvent le meilleur rapport coût/performance sans réglage manuel.

La surveillance régulière vous aide à identifier les opportunités d’optimisation. Passez en revue les métriques de cluster pour voir l’utilisation réelle par rapport à la capacité provisionnée. Ajustez les types de nœuds, les nombres de workers ou les paramètres de mise à l’échelle en fonction des modèles observés plutôt que des hypothèses.