Warum weist Yarn on EMR nicht alle Knoten Spark-Jobs zu?

Question

Ich arbeite auf Apache Spark auf Amazon Elastic Map Reduce (EMR). Momentan laufe ich auf emr-4.1.0, welches Amazon Hadoop 2.6.0 und Spark 1.5.0 beinhaltet.

Wenn ich den Job starte, hat YARN alle Worker-Knoten korrekt dem Funke-Job zugewiesen (natürlich mit einem für den Treiber).

Ich habe die magische Eigenschaft "maximizeResourceAllocation" auf "true" gesetzt und die Spark-Eigenschaft "spark.dynamicAllocation.enabled" ebenfalls auf "true" gesetzt.

Wenn ich jedoch die Größe des emr-Clusters durch Hinzufügen von Knoten zum CORE-Pool von Arbeitscomputern ändere, fügt YARN nur einige der neuen Knoten zum Spark-Job hinzu.

Zum Beispiel hatte ich heute Morgen einen Job, der 26 Knoten (m3.2xlarge, wenn das wichtig ist) - 1 für den Treiber, 25 Executoren. Ich wollte den Job beschleunigen, also habe ich versucht, weitere 8 Knoten hinzuzufügen. YARN hat alle neuen Knoten aufgenommen, aber nur eine davon dem Spark-Job zugewiesen. Spark hat den neuen Knoten erfolgreich aufgenommen und benutzt ihn als Executor, aber meine Frage ist, warum YARN die anderen 7 Knoten einfach im Leerlauf lässt.

Es ist ärgerlich für offensichtliche Gründe - ich muss für die Ressourcen bezahlen, auch wenn sie nicht verwendet werden, und mein Job hat sich überhaupt nicht beschleunigt!

Jeder weiß, wie YARN entscheidet, wenn Knoten zu laufenden Funkenjobs hinzugefügt werden? Welche Variablen spielen eine Rolle? Erinnerung? V-Kerne? Etwas?

Vielen Dank im Voraus!

Answer 1

Okay, mit Hilfe von @sean_r_owen konnte ich dies aufspüren.

Das Problem war das: wenn spark.dynamicAllocation.enabled auf true eingestellt wird, sollte spark.executor.instances nicht festgelegt werden - ein expliziter Wert für diese überschreibt dynamische Zuordnung und deaktiviert es. Es stellt sich heraus, dass EMR es in den Hintergrund stellt, wenn Sie es nicht selbst einstellen. Um das gewünschte Verhalten zu erhalten, müssen Sie explizit gesetzt spark.executor.instances auf 0

Für die Aufzeichnungen, hier ist der Inhalt einer der Dateien, die wir auf die --configurations Flag übergeben, wenn ein EMR-Cluster zu erstellen:

[ 
    { 
     "Classification": "capacity-scheduler", 
     "Properties": { 
      "yarn.scheduler.capacity.resource-calculator": "org.apache.hadoop.yarn.util.resource.DominantResourceCalculator" 
     } 
    }, 

    { 
     "Classification": "spark", 
     "Properties": { 
      "maximizeResourceAllocation": "true" 
     } 
    }, 

    { 
     "Classification": "spark-defaults", 
     "Properties": { 
      "spark.dynamicAllocation.enabled": "true", 
      "spark.executor.instances": "0" 
     } 
    } 
] 

Dies gibt uns einen EMR-Cluster, in dem Spark beim Ausführen von Jobs alle Knoten einschließlich hinzugefügter Knoten verwendet. Es scheint auch, alle/den größten Teil des Speichers und alle (?) Die Kerne zu verwenden.

(Ich bin nicht ganz sicher, dass es alle tatsächlichen Kerne verwendet, aber es ist definitiv mehr als 1 VCore verwenden, was es vorher nicht war, aber nach Glennie Helles Rat benimmt es sich jetzt besser und mit der Hälfte von die aufgelisteten VCores, die der tatsächlichen Anzahl der Kerne zu entsprechen scheint ...)