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 permettant d'automatiser la gestion des ressources de cluster, et permet d'activer l'autoscaling des VM de nœud de calcul du cluster. Pour en savoir plus, consultez la section 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 sur des clusters éphémères, utilisez 2 processeurs et 8 Go de mémoire pour les nœuds maîtres. Si vous utilisez des clusters persistants, vous devrez peut-être disposer de nœuds maîtres plus importants pour faire face au workflow. Pour déterminer si vous avez besoin de nœuds maîtres plus volumineux, vous pouvez surveiller l'utilisation de la mémoire et des processeurs sur le nœud. Nous vous recommandons de dimensionner vos nœuds de calcul avec au moins deux processeurs et huit Go de mémoire. Si vous avez configuré vos pipelines pour utiliser une plus grande quantité de mémoire, vous devez utiliser des 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 deux processeurs et 8 Go de 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 de 4 CPU et 15 Go, chaque nœud de calcul dispose de 4 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 travail dispose de trois CPU et de 4 Go supplémentaires qui sont gaspillés, car ils ne peuvent rien exécuter. 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. La taille minimale du conteneur YARN est également ajustée en fonction de la taille des VM de travail. 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. Par exemple, supposons que vous ayez défini la mémoire de votre exécuteur sur 2 048 Mo et que vous n'ayez pas spécifié de valeur pour spark.yarn.executor.memoryOverhead, ce qui signifie que la valeur par défaut de 384 Mo est utilisée. Cela signifie que Spark demande 2 048 Mo + 384 Mo pour chaque exécuteur, que YARN arrondit à un multiple exact de l'allocation minimale 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. Cela signifie que chaque nœud de calcul peut exécuter deux conteneurs, en utilisant tous les processeurs disponibles, mais en laissant 1 Go de mémoire YARN (6 Go - 2,5 Go - 2,5 Go) inutilisée. 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 est arrondi à 3 Go, car l'allocation minimale de YARN est de 1 024 Mo.
Cela signifie que chaque nœud de travail peut exécuter quatre conteneurs, avec tous les processeurs et la mémoire YARN utilisés.
Pour donner du contexte, le tableau suivant indique les tailles de workers 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 | 4096 | 4 | 26 |
| 2 | 8 192 | 4 | 26 |
Par exemple, un nœud de calcul de 26 Go correspond à 20 Go de mémoire utilisables pour exécuter des conteneurs YARN. Lorsque la mémoire de l'exécuteur est définie sur 4 Go, 1 Go est ajouté en surcharge, ce qui signifie que chaque exécuteur dispose de 5 Go de conteneurs YARN. Cela signifie que le worker peut exécuter quatre conteneurs sans aucune ressource supplémentaire restante. 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 dont elles peuvent disposer en fonction du nombre de cœurs. Par exemple, une VM avec quatre cœurs doit disposer d'au moins 7,25 Go de mémoire et au maximum de 26 Go de mémoire. Cela signifie qu'un exécuteur défini pour utiliser un processeur et 8 Go de mémoire utilise deux 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 en savoir plus sur les performances des disques, consultez la section Configurer des disques pour répondre aux exigences de performances.
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 des données à l'aide de 100 divisions, vous devez vous assurer que le cluster est suffisamment grand pour exécuter 100 exécuteurs à la fois.
Le moyen le plus simple de savoir si votre cluster est sous-dimensionné consiste à examiner la mémoire en attente de YARN au fil du temps. Si vous utilisez Dataproc, un graphique s'affiche sur la page d'informations 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 garantir le niveau maximal de parallélisme.
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 des données de brassage intermédiaires, les tâches Spark ne rencontrent pas de retards ni d'erreurs lorsqu'ils sont supprimés d'un cluster. É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 mélanges sur 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.