L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
Azure Databricks – Planification de la capacité pour un cluster Spark optimal
Aperçu:
Aujourd’hui, la terminologie « Data Analytics » devient un buzz dans toutes les industries et entreprises. Chaque organisation croit fermement que l’analyse des données aide grandement à obtenir des informations et à accélérer les stratégies commerciales afin de croître et de diriger sur leurs marchés rapides et en constante évolution.
Azure Databrick :
Azure Databricks est une plateforme d’analyse de données optimisée pour la plateforme de services cloud Microsoft Azure. Azure Databricks propose trois environnements pour développer des applications gourmandes en données : Databricks SQL, Databricks Data Science & Engineering et Databricks Machine Learning.
| Databrick SQL | Fournit une plate-forme facile à utiliser pour les analystes qui souhaitent exécuter des requêtes SQL sur leur lac de données, créer plusieurs types de visualisation significatifs pour explorer les résultats des requêtes sous différentes perspectives, et créer et partager des tableaux de bord permettant aux parties prenantes de prendre des décisions commerciales. |
| Science et ingénierie des données Databricks | Fournit un espace de travail interactif qui permet la collaboration entre les ingénieurs de données, les scientifiques des données et les ingénieurs en apprentissage automatique. Dans un pipeline Big Data, les données sont ingérées dans le cloud Azure via Azure Data Factory par lots, ou diffusées en temps quasi réel à l’aide d’Apache Kafka, Event Hub ou IoT Hub. Les données atterrissent dans Azure Blob Storage ou Azure Data Lake Storage. Pour l’analyse, Azure Databricks lit les données de différentes sources de données et les transforme en informations à l’aide de Spark. |
| Apprentissage automatique Databricks | Un environnement d’apprentissage automatique intégré de bout en bout intégrant des services gérés pour le suivi des expériences, la formation des modèles, le développement et la gestion des fonctionnalités, le test des modèles ML et le service. |
Architecture de haut niveau :
Azure Databricks est conçu pour permettre une collaboration d’équipe interfonctionnelle sécurisée en conservant autant de services backend gérés par Azure Databricks afin que les ingénieurs de données puissent rester concentrés sur les tâches d’analyse de données.
Azure Databricks fonctionne dans le plan de contrôle et le plan de données.
- Le plan de contrôle inclut les services principaux qu’Azure Databricks gère avec son propre compte Azure. Les blocs-notes des développeurs, les tâches et les requêtes, les configurations de l’espace de travail sont stockés et gérés dans le plan de contrôle.
- Data Plane est géré par son compte Azure. Toutes les données sont stockées et traitées dans ce plan. En outre, les connecteurs Azure Databricks peuvent être utilisés pour se connecter à des sources de données externes en dehors du compte Azure pour ingérer des données.
Le diagramme ci-dessous fournit l’architecture de haut niveau de la plate-forme Azure Databricks,
Azure Databricks – Planification de la capacité du cluster :
Il est très important de choisir le bon mode de cluster et les bons types de travail lors de la création d’un cluster Databricks dans le cloud Azure pour obtenir les performances souhaitées à un coût optimal. Lors de la création de la solution Azure Databricks Enterprise Data Analytics, il incombe à l’architecte de données / responsable des données d’effectuer la planification de la capacité du cluster, en tenant compte des besoins de l’entreprise, du débit de performance et des facteurs de coût.
Azure Databricks propose plusieurs options de type de travail qui exploitent diverses capacités de calcul et de stockage pouvant être choisies pour les objectifs de performances souhaités.
Vous trouverez ci-dessous un résumé des différentes options de cluster proposées par Azure Databricks :
| Usage général | Offre un rapport CPU/mémoire équilibré. Convient aux tests et au développement, aux bases de données petites à moyennes et aux serveurs Web à trafic faible à moyen. |
| Calcul optimisé | Offre un rapport CPU/mémoire élevé. Idéal pour les serveurs Web à trafic moyen, les appareils réseau, les processus par lots et les serveurs d’applications. |
| Mémoire optimisée | Offre un rapport mémoire/processeur élevé. Convient aux serveurs de base de données de relations, aux caches moyens à grands et aux analyses en mémoire. |
| Stockage optimisé | Débit de disque élevé et charges de travail d’E/S. Idéal pour les bases de données Big Data, SQL, No SQL, l’entreposage de données et les grandes bases de données transactionnelles. |
| GPU | Machines virtuelles spécialisées ciblées pour le rendu graphique lourd et le montage vidéo, ainsi que la formation et l’inférence de modèles avec des charges de travail d’apprentissage en profondeur. |
| Calcul haute performance | Offre les machines virtuelles CPU les plus rapides et les plus puissantes avec des interfaces réseau à haut débit en option. |
Groupe d’étincelles :
Pour notre discussion, considérons General Purpose (HDD) « Norme_D16_v3” instance qui offre 16 processeurs Core avec une capacité de RAM de 64 Go pour l’exercice de planification de la capacité du cluster. Cependant, on peut choisir la bonne option d’instance en fonction de ses besoins commerciaux. Diverses options d’instance et prix peuvent être référencés dans Tarification Azure Databricks lien.
Pour tracer une configuration d’exécuteur efficace, la première étape consiste à déterminer le nombre de processeurs réels requis sur les nœuds de notre cluster. Avec l’instance considérée ci-dessus de « Standard_D16_v3 », il y aura 16 processeurs disponibles à utiliser.
Lorsqu’une tâche Spark est soumise, nous devons allouer au moins un processeur pour le gestionnaire de cluster, le gestionnaire de ressources, le programme pilote et d’autres opérations du système d’exploitation. Avec un processeur alloué aux opérations de gestion, nous devons utiliser 15 processeurs disponibles sur chaque nœud pendant le traitement Spark.
CPU vs exécuteur :
Vient maintenant la partie cruciale de la planification des capacités, à savoir combien de cœurs peuvent être alloués à chaque exécuteur. Le nombre idéal apportera un débit de performance significatif au cluster. Avec 15 cœurs CPU, il y a 4 combinaisons de configuration possibles :
- 1 Executor avec 15 Spark Cores
- 3 exécuteurs avec 5 cœurs Spark
- 5 exécuteurs avec 3 cœurs Spark
- 15 exécuteurs avec 1 Spark Core
1 exécuteur avec 15 cœurs Spark :
Ce type d’exécuteur est appelé « Fat Executor ». Nous pouvons penser qu’un exécuteur avec de nombreux cœurs atteindra les performances les plus élevées. Il peut le faire dans très peu de scénarios commerciaux. En revanche, idéalement pour la plupart des scénarios, cela dégradera les performances. La raison en est qu’un exécuteur avec de nombreux cœurs disposera d’un grand pool de mémoire, ce qui ralentira l’exécution du travail. De tels cas seront très difficiles à identifier lors de l’optimisation des performances.
15 exécuteurs avec 1 noyau :
Ce type de configuration est appelé « Thin Executor ». Avec cette configuration, nous perdrons l’avantage du traitement parallèle exploité par plusieurs cœurs et le considérant comme inefficace et non recommandé.
De plus, trouver l’allocation de mémoire optimale pour les exécuteurs à un seul cœur sera une tâche difficile. En règle générale, 10 % de la taille de la mémoire de l’exécuteur seront alloués par défaut à la mémoire supplémentaire.
Avec une mémoire de nœud de 64 Go, la mémoire supplémentaire pour chaque exécuteur peut être calculée comme ci-dessous,
Considérez que 4 Go sont réservés aux opérations du gestionnaire de cluster et du système d’exploitation.
Mémoire de nœud disponible = 64 Go – 4 Go = 60 Go
Chaque mémoire d’exécuteur = mémoire de nœud disponible / nombre d’exécuteurs = 60 Go / 15 = 4 Go
Mémoire supplémentaire = 10 % de la mémoire de l’exécuteur = 4 Go * 10 % = 409 Mo
La mémoire de surcharge de 409 Mo sera petite, ce qui causera des problèmes lors de l’exécution des tâches Spark. Par conséquent, l’exécuteur à un seul cœur n’est pas une configuration optimale.
3 exécuteurs avec 5 cœurs contre 5 exécuteurs avec 3 cœurs :
En éliminant les options Fat Executor et Thin Executor, nous pouvons maintenant choisir la configuration idéale avec le reste des 2 options : 3 Executors avec 5 Cores ou 5 Executors avec 3 Cores.
Les deux options peuvent sembler idéales en fonction des cas d’utilisation métier. Cependant, la plupart des guides de bonnes pratiques suggèrent de choisir l’option 3 exécuteurs avec 5 cœurs par nœud (Lien)
Pic – 3 exécuteurs avec 5 cœurs
Pic – 5 exécuteurs avec 3 cœurs
Un nombre inférieur d’exécuteurs se traduira par un nombre inférieur de mémoire de nœud de partage de mémoire supplémentaire et permet une capacité de traitement parallèle maximale pour chaque exécuteur.
Conclusion:
Avec la discussion ci-dessus, il est idéal d’opter pour 3 exécuteurs avec 5 cœurs chacun par nœud apportera des performances équilibrées pour le type d’instance donné. Cependant, le dimensionnement du cluster sera souvent un exercice itératif en tentant plusieurs configurations qui conviennent le mieux au cas d’utilisation professionnelle de l’individu. Il n’y a pas de règle écrite sur la pierre dans le dimensionnement du cluster Spark car différents cas d’utilisation nécessiteront des compromis entre performances et coûts pour prendre une décision commerciale.
Source link