J'essaie de comprendre la relation entre le nombre de cœurs et le nombre d'exécuteurs lors de l'exécution d'un travail Spark sur YARN.
L'environnement de test est le suivant:
- Nombre de nœuds de données: 3
- Spécifications de la machine du nœud de données:
- CPU: Core i7-4790 (nombre de cœurs: 4, nombre de threads: 8)
- Mémoire vive: 32 Go (8 Go x 4)
- Disque dur: 8 To (2 To x 4)
Réseau: 1 Go
Version Spark: 1.0.0
Version Hadoop: 2.4.0 (Hortonworks HDP 2.1)
Flux de travail Spark: sc.textFile -> filtre -> carte -> filtre -> mapToPair -> reductionByKey -> carte -> saveAsTextFile
Des données d'entrée
- Type: fichier texte unique
- Taille: 165 Go
- Nombre de lignes: 454.568.833
Production
- Nombre de lignes après le deuxième filtre: 310640717
- Nombre de lignes du fichier résultat: 99848268
- Taille du fichier résultat: 41 Go
Le travail a été exécuté avec les configurations suivantes:
--master yarn-client --executor-memory 19G --executor-cores 7 --num-executors 3
(exécuteurs par nœud de données, utilisez autant que les cœurs)--master yarn-client --executor-memory 19G --executor-cores 4 --num-executors 3
(nombre de cœurs réduit)--master yarn-client --executor-memory 4G --executor-cores 2 --num-executors 12
(moins de noyau, plus d'exécuteur)
Temps écoulés:
50 min 15 s
55 min 48 s
31 min 23 s
À ma grande surprise, (3) était beaucoup plus rapide.
Je pensais que (1) serait plus rapide, car il y aurait moins de communication entre exécuteurs lors du brassage.
Bien que le nombre de cœurs de (1) soit inférieur à (3), le nombre de cœurs n'est pas le facteur clé car 2) ont bien fonctionné.
(Les éléments suivants ont été ajoutés après la réponse de pwilmot.)
Pour plus d'informations, la capture d'écran du moniteur de performances est la suivante:
- Résumé du nœud de données Ganglia pour (1) - travail commencé à 04:37.
- Résumé du nœud de données Ganglia pour (3) - travail commencé à 19:47. Veuillez ignorer le graphique avant cette heure.
Le graphique se divise approximativement en 2 sections:
- Premièrement: du début à la réductionByKey: intensif en CPU, pas d'activité réseau
- Deuxièmement: après reductionByKey: le processeur diminue, les E / S réseau sont effectuées.
Comme le montre le graphique, (1) peut utiliser autant de puissance CPU qu'il a été donné. Donc, ce n'est peut-être pas le problème du nombre de threads.
Comment expliquer ce résultat?