2015-12-11 6 views
5

Ich arbeite an einem Projekt in Spark und wechselte kürzlich von der Verwendung von Spark Standalone zu Mesos für Cluster-Management. Ich bin jetzt verwirrt darüber, wie Ressourcen zugewiesen werden, wenn ein Job unter dem neuen System eingereicht wird.Die Ressourcenzuweisung für Spark-Jobs auf Mesos verstehen

Im Standalone-Modus, ich war so etwas wie dies mit (nach ein paar Empfehlungen von this Cloudera blog post.

/opt/spark/bin/spark-submit --executor-memory 16G --executor-cores 8 
    --total-executor-cores 240 myscript.py 

Dieses auf einem Cluster ist, wo jede Maschine 16 Kerne hat und ~ 32 GB RAM

Was Es war schön, dass ich die Kontrolle über die Anzahl der ausführenden Executoren und die zugewiesenen Ressourcen hatte.Im obigen Beispiel wusste ich, dass ich 240/8 = 30 Executoren mit je 16 GB Arbeitsspeicher und 8 Kernen bekam Wenn der Speicher auf jeder Maschine im Cluster nicht mehr als zwei Executoren umfasst, die auf jeder Maschine ausgeführt werden mehr Testamentsvollstrecker wollte, könnte ich so etwas wie

/opt/spark/bin/spark-submit --executor-memory 10G --executor-cores 5 
    --total-executor-cores 240 myscript.py 

tun Dies würde mir jetzt geben 240/5 = 47 Vollstrecker, die jeweils mit 5 Adern und 10 GB Speicher, und würde bis zu drei Testamentsvollstrecker pro Maschine ermöglichen.

Aber jetzt, wo ich auf Mesos bin, bin ich ein bisschen verwirrt. Zunächst einmal bin ich im grobkörnigen Modus gelaufen, um sicherzustellen, dass ich meine Ressourcenzuweisung reparieren und kontrollieren kann (dies liegt im Dienst eines ziemlich komplexen Modells, in dem wir Ressourcen vorab zuweisen möchten).

Jetzt kann ich angeben --total-executor-cores und --executor-memory, aber die Dokumentation sagt mir, dass --exeuctor-cores eigenständige und GARN nur Spark gilt, was macht für jeden schwierig zugeteilt, um die Gesamtzahl der Testamentsvollstrecker und Ressourcen angeben. Sagen wir, ich betreibe diese:

/opt/spark/bin/spark-submit --total-executor-cores 240 --executor-memory 16G --conf spark.mesos.coarse=true myscript.py 

Als ich diesen Job in der Mesos Web-UI zu untersuchen, werden die Dinge verwirrend zu bekommen. Also, hier sind meine Fragen:

  1. Terminologie. Die Web-Benutzeroberfläche listet "Frameworks" auf, von denen ich annehme, dass sie "Jobs" in der eigenständigen Benutzeroberfläche entsprechen. Aber wenn ich auf das Detail für ein bestimmtes Framework klicke, listet es "Aufgaben" auf. Aber das können keine echten Spark-Aufgaben sein, oder? Soweit ich das beurteilen kann, muss "Aufgabe" hier eigentlich "ausführender" bedeuten, was Spark betrifft. Dies entspricht der Benutzeroberfläche, die besagt, dass mein Framework (Job) über 15 aktive Tasks, 240 CPUs und 264 GB Arbeitsspeicher verfügt.

    264/15 = 17,6, die mit den 16 GB Speicher pro Executor übereinstimmt, die ich angegeben habe (plus etwas Overhead, denke ich). Habe ich recht, wie ich das alles interpretiere?

  2. Angenommen ja, wenn ich eine dieser "Aufgaben" (Executoren) untersuche, sehe ich, dass jeder 16 Kerne zugewiesen hat. Wenn wir 16 Kerne pro Maschine haben, würde dies darauf hindeuten, dass ich grundsätzlich einen Executor auf jeder der 16 Maschinen laufen lasse und dass jeder Executor die vollen 16 Kerne bekommt, aber nur 16 GB RAM. (Beachten Sie, dass, selbst wenn ich --executor-memory weit nach unten auf etwas wie 4GB fallen lasse, läuft Mesos nur noch einen Executor pro Knoten, mit 16 Kernen und 4GB RAM). Aber was ich erreichen möchte, ist etwas wie meine ersten beiden Beispiele. Das heißt, ich möchte mehrere Executoren pro Knoten ausführen, von denen sich jeder den RAM und die Kerne dieses Knotens teilt (d. H. Eine moderate Anzahl von Kernen vor dem Executor, 5-8). Wenn ich bedenke, dass ich --executor-cores in Mesos nicht spezifizieren kann, wie erreiche ich das? Oder bin ich aus irgendeinem Grund nicht in der Lage, dies überhaupt zu erreichen? Werden Mesos einfach nicht mehrere Executoren pro Knoten zulassen?

Antwort

4

Frage 1: In grobkörnig Modus Spark Testamentsvollstrecker (org.apache.spark.executor.CoarseGrainedExecutorBackend) als Mesos Aufgabe gestartet. Mesos Framework ist eigentlich Spark Driver. Ein Spark-Treiber könnte mehrere Spark-Jobs senden. Das hängt von Ihrer Spark-Anwendung ab. Spark und Mesos kommen beide von AMPLab von UC Berkeley und sind parallel entwickelt, daher verwenden sie ähnliche Terminologien (Executor, Task ...), die Sie verwirren können :-).

Frage 2: Im grobkörnigen Modus startet Spark nur einen Executor pro Host (Details siehe https://issues.apache.org/jira/browse/SPARK-5095). Also wird Spark für jeden Fall einen Executor pro Host starten (jeder Executor verbraucht 16 G Speicher und alle verfügbaren Cores im Host, die 16 Cores sind, wenn keine andere Workload vorhanden ist), bis die Executionorenkerne insgesamt 240 Cores erreichen. Es wird 240/16 = 15 Executoren geben.

In Bezug auf spark.mesos.mesosExecutor.cores funktioniert es nur für feinkörnigen Modus. Im feinkörnigen Modus startet Spark einen Executor (org.apache.spark.executor.MesosExecutorBackend) pro Host. Der Executor verbraucht die Anzahl der Cores von spark.mesos.mesosExecutor.cores, obwohl keine Task vorhanden ist. Jede Aufgabe wird eine weitere Anzahl von Kernen von spark.task.cpus verbrauchen.

+1

[Spark Doc] (https://spark.apache.org/docs/2.1.0/running-on-mesos.html#mesos-run-modes) "Spark kann Mesos in zwei Modi durchlaufen:" grobkörnig "(Standard) und * * "Feinkörnig" (veraltet) **. " Ab Spark-Version 2.0.0 – Vezir

0

1 Betreffend)

Das ist mein Verständnis auch. Ein Mesos Task ist eigentlich ein Spark Executor (Task).

In Bezug auf 2)

Von meinem Verständnis, sollten Sie in der Lage sein, die spark.mesos.mesosExecutor.cores Konfigurationseigenschaften zu verwenden:

(Feinkörnige Modus) Anzahl der Kerne jedes Mesos Testamentsvollstrecker zu geben. Dies beinhaltet nicht die Kerne, die zum Ausführen der Spark-Tasks verwendet werden. Mit anderen Worten, selbst wenn keine Spark-Task ausgeführt wird, belegt jeder Mesos-Executor die Anzahl der hier konfigurierten Kerne. Der Wert kann eine Fließkommazahl sein.

Siehe

+0

Hmm ... vielleicht lag ich falsch, wenn ich dachte, ich sollte grobkörnigen Modus verwenden? Wenn ich richtig verstehe, würde dies uns erlauben, die Anzahl der Kerne/Executoren zu korrigieren, aber dann würden wir immer noch die automatische Skalierung von Ressourcen ausführen, die ich hier nicht haben möchte ... – moustachio

Verwandte Themen