Par défaut, Cloud Data Fusion utilisait Autoscale comme profil de calcul. Il est difficile d'estimer le nombre optimal de nœuds de calcul du cluster pour une charge de travail ; la plupart du temps, une taille de cluster unique pour un pipeline entier n'est pas la solution idéale. L'autoscaling Dataproc fournit un mécanisme d'automatisation la gestion des ressources de cluster et active l'autoscaling des VM de nœud de calcul de cluster. Pour plus consultez la page Autoscaling
Sur la page Compute config (Configuration de calcul), qui affiche une liste de profils, se trouve une colonne Total cores (Nombre total de cœurs), qui indique le nombre maximal de processeurs virtuels que le profil peut mettre à l'échelle, par exemple Up to 84.
Si vous souhaitez utiliser le profil Compute Dataproc, vous pouvez gérer la taille des clusters en fonction de la taille du pipeline.
Nœud maître
Les nœuds maîtres utilisent des ressources proportionnellement au nombre de pipelines ou d'applications supplémentaires en cours d'exécution sur le cluster. Si vous exécutez des pipelines les clusters éphémères, utilisent 2 processeurs et 8 Go de mémoire pour le maître. nœuds. Si vous utilisez des clusters persistants, vous devrez peut-être disposer de nœuds maîtres plus importants pour faire face au workflow. Pour savoir si vous avez besoin de nœuds maîtres plus volumineux, peut surveiller l'utilisation de la mémoire et du processeur sur le nœud. Nous vous recommandons de dimensionner nœuds de calcul avec au moins 2 processeurs et 8 Go de mémoire. Si vous avez configuré vos pipelines pour utiliser de plus grandes quantités de mémoire, vous devez utiliser les nœuds de calcul plus volumineux.
Pour minimiser le temps d'exécution, assurez-vous que votre cluster dispose de suffisamment de nœuds pour permettre un traitement en parallèle autant que possible.
Nœuds de calcul
Les sections suivantes décrivent certains aspects de la mise à l'échelle des nœuds de travail.
Processeur et mémoire
Nous vous recommandons de dimensionner vos nœuds de calcul avec au moins 2 processeurs et 8 Go
mémoire. Si vous avez configuré vos pipelines pour utiliser une plus grande quantité de mémoire, utilisez des nœuds de calcul plus volumineux. Par exemple, avec un nœud de calcul à quatre CPU et 15 Go, chaque nœud de calcul dispose de quatre CPU et de 12 Go pour exécuter des conteneurs YARN. Si votre pipeline est configuré pour exécuter un processeur et des exécuteurs de 8 Go, YARN ne peut pas exécuter plus d'un conteneur par nœud de calcul. Chaque nœud de calcul
avec 3 processeurs supplémentaires et 4 Go supplémentaires, qui est gaspillé, car il est inutilisable
exécuter ce que vous voulez. Pour maximiser l'utilisation des ressources sur votre cluster, vous devez définir la mémoire YARN et les processeurs sur un multiple exact de la quantité requise par exécuteur Spark. Vous pouvez vérifier la quantité de mémoire que chaque nœud de calcul a réservée pour YARN en consultant la propriété yarn.nodemanager.resource.memory-mb dans YARN.
Si vous utilisez Dataproc, la mémoire disponible pour les conteneurs YARN correspond à environ 75 % de la mémoire de la VM. Taille minimale du conteneur YARN est également ajustée en fonction de la taille des VM de nœud de calcul. Certaines tailles de nœuds de travail courantes et leurs paramètres YARN correspondants sont indiquées dans le tableau suivant.
| Processeur du nœud de calcul | Mémoire du nœud de calcul (Go) | Mémoire du nœud YARN (Go) | Mémoire d'allocation minimale YARN (Mo) |
|---|---|---|---|
| 1 | 4 | 3 | 256 |
| 2 | 8 | 6 | 512 |
| 4 | 16 | 12 | 1 024 |
| 8 | 32 | 24 | 1 024 |
| 16 | 64 | 51 | 1 024 |
N'oubliez pas que Spark demande plus de mémoire que la mémoire de l'exécuteur définie pour le pipeline, et que YARN arrondit cette quantité demandée. Pour
Par exemple, supposons que vous ayez défini la mémoire de l'exécuteur sur 2 048 Mo, mais que vous n'ayez pas
une valeur pour spark.yarn.executor.memoryOverhead, ce qui signifie que la valeur par défaut
384 Mo est utilisé. Cela signifie que Spark demande 2 048 Mo + 384 Mo pour chaque exécuteur, ce que YARN arrondit à un multiple exact de l'allocation minimale de YARN. Lorsqu'il s'exécute sur un nœud de calcul de 8 Go, l'allocation minimale YARN étant de 512 Mo, elle est arrondie à 2,5 Go. Ce
signifie que chaque nœud de calcul peut exécuter deux conteneurs, en utilisant
de processeurs disponibles, mais en laissant 1 Go de mémoire YARN (de 6 Go à
2,5 Go à 2,5 Go) non utilisés. Cela signifie que le nœud de calcul peut être un peu plus petit ou que les exécuteurs peuvent disposer d'un peu plus de mémoire.
Lorsqu'il s'exécute sur un nœud de travail de 16 Go, 2 048 Mo + 1 024 Mo sont arrondis à 3 Go, car l'allocation minimale de YARN est de 1 024 Mo.
Cela signifie que chaque nœud de calcul peut exécuter quatre conteneurs, avec tous les processeurs.
et la mémoire YARN utilisée.
Pour vous donner plus de contexte, le tableau suivant présente les tailles de nœuds de calcul recommandées pour certaines tailles d'exécuteur courantes.
| CPU de l'exécuteur | Mémoire de l'exécuteur (Mo) | CPU du nœud de calcul | Mémoire des workers (Go) |
|---|---|---|---|
| 1 | 2 048 | 4 | 15 |
| 1 | 3 072 | 4 | 21 |
| 1 | 4 096 | 4 | 26 |
| 2 | 8 192 | 4 | 26 |
Par exemple, un nœud de calcul de 26 Go se traduit par 20 Go de mémoire utilisable pour exécuter des conteneurs YARN. Avec la mémoire de l'exécuteur définie sur 4 Go, 1 Go correspond en tant que frais généraux, soit 5 Go de conteneurs YARN pour chaque exécuteur. Ce signifie que le nœud de calcul peut exécuter quatre conteneurs sans qu'il ne reste de ressources supplémentaires. Vous pouvez également multiplier la taille des nœuds de calcul. Par exemple, si la mémoire de l'exécuteur est définie sur 4 096 Go, un nœud de calcul avec 8 CPU et 52 Go de mémoire fonctionnera également. Les VM Compute Engine limitent la quantité de mémoire qu'une VM peut avoir en fonction du nombre de cœurs. Par exemple, une VM avec quatre cœurs doit avoir au moins 7,25 Go de mémoire et 26 Go de mémoire au maximum Cela signifie qu'un exécuteur configuré pour utiliser 1 processeur et 8 Go de mémoire utilisent 2 processeurs et 26 Go de mémoire sur la VM. Si les exécuteurs sont configurés pour utiliser deux processeurs et 8 Go de mémoire, tous les processeurs sont utilisés.
Disque
Le disque est important pour certains pipelines, mais pas pour tous. Si votre pipeline ne contient aucun brassage, le disque n'est utilisé que lorsque Spark manque de mémoire et doit déverser des données sur le disque. Pour ces types de pipelines, la taille et le type de disque n'ont généralement pas d'impact majeur sur vos performances. Si votre pipeline brasse une grande quantité de données, les performances du disque auront une incidence. Si vous utilisez Dataproc, nous vous recommandons d'utiliser des disques d'au moins 1 To, car leurs performances augmentent avec leur taille. Pour plus d'informations sur les performances des disques, consultez la section Configurer les disques pour atteindre exigences.
Nombre de nœuds de calcul
Pour minimiser le temps d'exécution, vous devez vous assurer que votre cluster est suffisamment grand pour pouvoir s'exécuter autant que possible en parallèle. Par exemple, si la source de votre pipeline lit les données avec 100 divisions, vous devez vous assurer est suffisamment volumineux pour exécuter 100 exécuteurs à la fois.
Le moyen le plus simple de savoir si votre cluster est sous-dimensionné est de surveiller la mémoire en attente de YARN au fil du temps. Si vous utilisez Dataproc, vous pouvez créer un graphique sont disponibles sur la page des détails du cluster.
Si la mémoire en attente est élevée pendant de longues périodes, vous pouvez augmenter le nombre de nœuds de calcul pour ajouter autant de capacité supplémentaire à votre cluster. Dans l'exemple précédent, le cluster doit être augmenté d'environ 28 Go pour s'assurer que le niveau maximal de parallélisme est atteint.
Mode de flexibilité améliorée (EFM)
EFM vous permet de spécifier que seuls les nœuds de calcul principaux doivent être impliqués lors du brassage des données. Étant donné que les nœuds de calcul secondaires ne sont plus responsables du brassage intermédiaire Lorsqu'elles sont supprimées d'un cluster, les jobs Spark ne subissent plus de retards les erreurs. Étant donné que les nœuds de calcul primaires ne sont jamais réduits, le cluster est réduit avec plus de stabilité et d'efficacité. Si vous exécutez des pipelines avec des brassages un cluster statique, nous vous recommandons d'utiliser EFM.
Pour en savoir plus sur le mode de flexibilité améliorée, consultez la page Mode de flexibilité améliorée de Dataproc.