Was sind Mitarbeiter, Ausführende und Kerne im Spark Standalone-Cluster?


219

Ich habe die Übersicht über den Cluster-Modus gelesen und kann die verschiedenen Prozesse im Spark Standalone-Cluster und die Parallelität immer noch nicht verstehen .

Ist der Worker ein JVM-Prozess oder nicht? Ich habe das ausgeführt bin\start-slave.shund festgestellt, dass es den Arbeiter hervorgebracht hat, der eigentlich eine JVM ist.

Gemäß dem obigen Link ist ein Executor ein Prozess, der für eine Anwendung auf einem Arbeitsknoten gestartet wird, der Aufgaben ausführt. Ein Executor ist auch eine JVM.

Das sind meine Fragen:

  1. Ausführende sind pro Antrag. Was ist dann die Rolle eines Arbeiters? Koordiniert es mit dem Testamentsvollstrecker und teilt das Ergebnis dem Fahrer mit? Oder spricht der Fahrer direkt mit dem Testamentsvollstrecker? Wenn ja, was ist dann der Zweck des Arbeitnehmers?

  2. Wie steuere ich die Anzahl der Ausführenden für eine Anwendung?

  3. Können die Aufgaben im Executor parallel ausgeführt werden? Wenn ja, wie konfiguriere ich die Anzahl der Threads für einen Executor?

  4. Wie ist die Beziehung zwischen einem Arbeiter, Ausführenden und Ausführerkernen (--total-executor-cores)?

  5. Was bedeutet es, mehr Mitarbeiter pro Knoten zu haben?

Aktualisiert

Nehmen wir Beispiele, um besser zu verstehen.

Beispiel 1: Ein eigenständiger Cluster mit 5 Arbeitsknoten (jeder Knoten hat 8 Kerne) Wenn ich eine Anwendung mit Standardeinstellungen starte.

Beispiel 2 Gleiche Clusterkonfiguration wie in Beispiel 1, aber ich führe eine Anwendung mit den folgenden Einstellungen aus: --executor-cores 10 --total-executor-cores 10.

Beispiel 3 Dieselbe Cluster-Konfiguration wie in Beispiel 1, aber ich führe eine Anwendung mit den folgenden Einstellungen aus: -executor-cores 10 --total-executor-cores 50.

Beispiel 4 Dieselbe Cluster-Konfiguration wie in Beispiel 1, aber ich führe eine Anwendung mit den folgenden Einstellungen aus: -executor-cores 50 --total-executor-cores 50.

Beispiel 5 Gleiche Clusterkonfiguration wie in Beispiel 1, aber ich führe eine Anwendung mit den folgenden Einstellungen aus: --executor-cores 50 --total-executor-cores 10.

Wie viele Testamentsvollstrecker gibt es in jedem dieser Beispiele? Wie viele Threads pro Executor? Wie viele Kerne? Wie wird die Anzahl der Testamentsvollstrecker pro Antrag festgelegt? Ist es immer das gleiche wie die Anzahl der Arbeiter?

Antworten:


274

Geben Sie hier die Bildbeschreibung ein

Spark verwendet eine Master / Slave-Architektur. Wie Sie in der Abbildung sehen können, verfügt es über einen zentralen Koordinator (Treiber), der mit vielen verteilten Mitarbeitern (Ausführenden) kommuniziert. Der Treiber und jeder der Ausführenden werden in ihren eigenen Java-Prozessen ausgeführt.

TREIBER

Der Treiber ist der Prozess, in dem die Hauptmethode ausgeführt wird. Zuerst konvertiert es das Benutzerprogramm in Aufgaben und danach plant es die Aufgaben auf den Ausführenden.

AUSFÜHRER

Ausführende sind Prozesse von Arbeiterknoten, die für die Ausführung einzelner Aufgaben in einem bestimmten Spark-Job verantwortlich sind. Sie werden zu Beginn einer Spark-Anwendung gestartet und normalerweise für die gesamte Lebensdauer einer Anwendung ausgeführt. Sobald sie die Aufgabe ausgeführt haben, senden sie die Ergebnisse an den Treiber. Sie bieten auch In-Memory-Speicher für RDDs, die von Benutzerprogrammen über Block Manager zwischengespeichert werden.

APPLICATION EXECUTION FLOW

Wenn Sie eine Anwendung mit Spark-Submit an den Cluster senden, geschieht dies intern:

  1. Eine eigenständige Anwendung startet und instanziiert eine SparkContextInstanz (und nur dann können Sie die Anwendung als Treiber bezeichnen).
  2. Das Treiberprogramm fordert den Cluster-Manager auf, Ressourcen für den Start von Executoren bereitzustellen.
  3. Der Cluster-Manager startet Executoren.
  4. Der Treiberprozess wird über die Benutzeranwendung ausgeführt. Abhängig von den Aktionen und Transformationen über RDDs werden Aufgaben an Ausführende gesendet.
  5. Ausführende führen die Aufgaben aus und speichern die Ergebnisse.
  6. Wenn ein Worker abstürzt, werden seine Aufgaben an verschiedene Executoren gesendet, um erneut verarbeitet zu werden. In dem Buch "Learning Spark: Blitzschnelle Big Data-Analyse" sprechen sie über Funken und Fehlertoleranz:

Spark behandelt automatisch ausgefallene oder langsame Maschinen, indem fehlgeschlagene oder langsame Aufgaben erneut ausgeführt werden. Wenn beispielsweise der Knoten, auf dem eine Partition einer map () -Operation ausgeführt wird, abstürzt, führt Spark sie erneut auf einem anderen Knoten aus. und selbst wenn der Knoten nicht abstürzt, sondern einfach viel langsamer als andere Knoten ist, kann Spark präventiv eine "spekulative" Kopie der Aufgabe auf einem anderen Knoten starten und das Ergebnis abrufen, wenn dies abgeschlossen ist.

  1. Mit SparkContext.stop () vom Treiber oder wenn die Hauptmethode beendet wird / abstürzt, werden alle Ausführenden beendet und die Clusterressourcen werden vom Cluster-Manager freigegeben.

DEINE FRAGEN

  1. Wenn Executoren gestartet werden, registrieren sie sich beim Fahrer und kommunizieren von da an direkt. Die Mitarbeiter sind dafür verantwortlich, dem Cluster-Manager die Verfügbarkeit ihrer Ressourcen mitzuteilen.

  2. In einem YARN-Cluster können Sie dies mit --num-executors tun. In einem eigenständigen Cluster erhalten Sie einen Executor pro Worker, es sei denn, Sie spielen mit spark.executor.cores und ein Worker verfügt über genügend Kerne, um mehr als einen Executor aufzunehmen. (Wie @JacekLaskowski betonte, wird --num-executors in YARN nicht mehr verwendet. Https://github.com/apache/spark/commit/16b6d18613e150c7038c613992d80a7828413e66 )

  3. Sie können die Anzahl der Kerne pro Executor mit --executor-cores zuweisen

  4. --total-executor-cores ist die maximale Anzahl von Executor-Kernen pro Anwendung

  5. Wie Sean Owen in diesem Thread sagte : "Es gibt keinen guten Grund, mehr als einen Arbeiter pro Maschine zu betreiben." Sie würden zum Beispiel viele JVM auf einem Computer haben.

AKTUALISIEREN

Ich konnte diese Szenarien nicht testen, aber laut Dokumentation:

BEISPIEL 1: Spark wird gierig so viele Kerne und Ausführende erwerben, wie vom Planer angeboten werden. Am Ende erhalten Sie also 5 Executoren mit jeweils 8 Kernen.

BEISPIEL 2 bis 5: Spark kann nicht so viele Kerne zuweisen, wie in einem einzelnen Worker angefordert werden, daher werden keine Executoren gestartet.


Danke @Marco. Normalerweise sollte man sich also keine Gedanken über den Heapspeicher des Workers machen, da dieser nur die Knotenressourcen verwaltet.
Manikandan Kannan

8
Was für eine großartige Antwort! Danke @Marco. Wie pro github.com/apache/spark/commit/... --num-executors ist nicht mehr in Gebrauch in GARN.
Jacek Laskowski

1
@ Marco danke für die tolle Antwort. Können Sie die fortlaufende Rolle des Cluster-Managers erweitern, während der Treiber ausgeführt wird? ... Es muss den Fall behandeln, in dem Fahrer oder Arbeiter oder beide abstürzen oder nicht mehr reagieren, um zu wissen, welche Ressourcen verfügbar sind.
Iain

1
@lain der Treiber kontaktiert den Cluster-Manager für die Zuweisung von Ressourcen und fordert auch Cluster-Manager auf, die Executoren zu starten
Aravind Yarram

2
Gute Antwort. Detaillierte Informationen zu
Funkeneinbauten

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.