Talend vs. Spark Submit Konfiguration: Wo liegt der Unterschied?

Talend vs. Spark Submit Konfiguration: Wo liegt der Unterschied?

  • Petros Nomikos
    I have 3 years of experience with installation, configuration, and troubleshooting of Big Data platforms such as Cloudera, MapR, and HortonWorks. I joined Talend in 2014, and prior to Talend I held positions as manager of technical support, and project manager for data warehouse implementations. In my current role, I assist companies in understanding how to implement Talend in their Big Data Ecosystem.

In meinem letzten Blog-Post, „Talend & Apache Spark: technische Grundlagen“, ging es um die Gemeinsamkeit von Talend Spark Jobs und Spark Submit. Heute möchte ich nun genau da ansetzen und Talend Spark Konfigurationen mit Apache Spark Submit evaluieren. Als erstes schauen wir uns an, wie man die Optionen des Apache Spark Konfigurations-Tabs, die sich als Argumente an Spark Submit übermitteln lassen, im Talend Spark Job mappen und nutzen kann. Los geht’s!

Abweichende Befehle

Wenn Sie in Ihrer Umgebung einen Apache Spark Job ausführen (wie z. B. eines der Apache Spark Beispiele, die zur Verifizierung einer einwandfreien Spark Funktionalität standardmäßig auf dem Hadoop-Cluster angeboten werden), verwenden Sie folgende Befehle:

export HADOOP_CONF_DIR=XXX./bin/spark-submit  --class org.apache.spark.examples.SparkPi --master yarn --deploy-mode client  --executor-memory 5G --num-executors 10 /path/to/examples.jar 1000

Die beiden oben genannten Befehle richten das Verzeichnis an dem Ort ein, von dem aus unser Spark Submit Job die Cluster-Konfigurations-Dateien lesen wird. Dann lassen wir den Befehl Spark Submit folgen, der Spark auf einem YARN Cluster in einem Client-Modus ausführt. Dabei kommen 10 Executors mit jeweils 5 GB Speicher zum Einsatz.

Betrachten wir nun, wie derselbe Spark Beispieljob in Talend ausgeführt wird. Hier werden die gesamten Konfigurationsdaten innerhalb des Run-Tabs in den folgenden Tab eingegeben:

Figure 1

Das wirft ein paar Fragen auf: Wie lassen sich die von uns in Talend eingegebenen Informationen mit den zur Ausführung eines Spark Jobs ins Terminal eingegebenen Daten mappen? Woher wissen wir, wie viele Executors und wie viel Speicherkapazität wir angefordert haben? Und wie sieht es mit Troubleshooting aus? All diese Fragen werden wir in unserem Blog-Post beantworten.

Bevor wir weitermachen, möchte ich ein paar Spark Submit Optionen vorstellen, die in diesem Blog-Post durchgehend verwendet werden. Laut der Apache Spark Dokumentation sind dies einige der meistverwendeten Optionen, die man an ein Spark Submit Script weitergeben kann:

--class: Dies ist der Haupteingabepunkt für Ihre Spark Anwendung.

--master: Bei dieser Option spezifizieren Sie, ob Ihr Spark Master ein Standalone Spark ist oder ob Sie Spark auf YARN ausführen wollen.

--deploy-mode: Wie in meinem letzten Blog-Post erwähnt, bezieht sich diese Option auf die zwei verfügbaren YARN Modi und legt fest, wie Ihr Spark Driver genutzt wird.

--conf: Bei dieser Option übermitteln Sie zusätzliche Spark Konfigurationen, die Ihr Job nutzen soll, wie z. B. „spark.executor.userClassPathFirst=true“.

--application-jar: Dies bezieht sich auf den Pfad mit Ihrem kompilierten Spark Code, den Apache Spark ausführen wird.

--application-arguments: Bei dieser Option geben Sie alle Argumente weiter, die sich spezifisch auf Ihren Spark Code beziehen.

Schauen wir uns nun an, wie diese Optionen innerhalb eines Talend Spark Jobs genutzt werden. Die einzelnen Optionen, die Sie nutzen können, sind im Spark Konfigurations-Tab unter dem Run-Tab in folgenden logischen Kategorien gruppiert:

  1. Cluster Version
  2. Configuration
  3. Authentication
  4. Tuning
  5. Spark History

Cluster Version

Beginnen wir mit einer der ersten Optionen, die Ihnen bei Ihrem Talend Job in der Kategorie Cluster Version begegnen, der Option „Spark Mode“.

Über diese Option können Sie festlegen, ob Ihr Spark Master auf YARN läuft oder ob Sie eine Standalone-Lösung nutzen werden. Sie entspricht den oben beschriebenen Spark Submit Optionen „--deploy-mode“ und „--master“. Wählen Sie zum Beispiel in Talend den Spark Modus „YARN Client“ aus, entspricht das der Spark Submit Auswahl „--master yarn --deploy-mode client“. Wird in dem Einblendmenü als Modus Standalone ausgewählt, fordert Talend Sie auf, genau wie bei Spark Submit, Ihre Spark Master URL einzugeben. Dadurch wird das folgende Argument an Spark Submit weitergegeben: „--master spark://127.0.0.1:7077“.

Configuration

In Talend gibt es die Kategorie „Configuration“, die folgende Angaben anfordert:

Mit den ersten Kontrollfeldern fragt Talend Angaben zu Resource Manager, Scheduler Address, Jobhistory Address und Staging Directory ab.

Bei Nutzung von Spark Submit werden all diese Daten über HADOOP_CONF_DIR in den Job implementiert. Wir können das vor Ausführung des Spark Submit Scripts in /etc/environment oder /etc/profile entweder als Umgebungsvariable, oder als festes Profil definieren. Zudem werden all diese Umgebungsvariablen auch in einem Environment-Shell-Script abgelegt, auf den Spark Jobs bei Ausführung per Spark Submit zugreifen. Der Name der Datei lautet spark-env.sh und sie befindet sich stets im Verzeichnis „/etc/spark/conf“ auf dem Spark Host. Hier ein Beispiel dafür, wie diese Konfigurationsdatei im Cluster aussieht:

Beim nächsten Kontrollfeld werden Sie dann gefragt, ob Sie das Hadoop Hauptverzeichnis definieren wollen, da das bei Spark Jobs manchmal erforderlich ist. Bei Spark Submit Jobs werden diese Informationen genauso weitergegeben, nur lautet der Name der Umgebungsvariable hier HADOOP_HOME. Bei einem Talend Spark Job übernehmen die Kontrollfelder die Aufgabe, die beim Spark Submit Script von der Datei „spark-env.sh“ (die auf diese Werte während der Laufzeit Ihres Spark Jobs zugreift) ausgeführt wird.

Mit der letzten Option für die Spark Konfiguration in Talend definieren Sie den Hostnamen oder die IP-Adresse des Spark Drivers. Das ist ein nützliches Feature, wenn das System von dem aus der Spark Job ausgeführt wird, interne und externe IPs verwendet oder wenn Probleme mit der Hostnamen-Auflösung die Kommunikation von Spark Master und Executor mit dem Spark Driver behindern.

Wurde diese Option nicht vorab angegeben, wird versucht, den lokalen Hostnamen zu verwenden und seine IP-Adresse aufzulösen. Wie bereits im vorigen Blog-Post erwähnt, nutzt Talend derzeit den YARN Client-Modus, sodass der Spark Driver stets auf dem System läuft, von den aus der Spark Job gestartet wird. Vergleicht man das mit den bei Spark Submit verfügbaren Optionen ab, würde hier die Option „--conf“, gefolgt von dem Key-/Value-Paar „spark.driver.host=127.0.0.1“ zum Einsatz kommen. Damit ist das Mappen der Konfigurationsoptionen im Untermenü des Tabs Spark Konfiguration abgeschlossen.

Authentication

In dieser Kategorie können wir die von Hadoop-Cluster verwendete Authentifizierungsmethode auswählen:

Falls wir in dieser Kategorie nichts ankreuzen, nimmt unser Job an, dass der Cluster eine simple Authentifizierung verwendet und wird versuchen, sich über den von uns angegebenen User-Namen mit unserem Hadoop-Cluster zu verbinden. Bei Spark Submit würden wir diese Angaben in der von uns erstellten Spark Konfiguration der Anwendung eingeben.

Wenn wir fortfahren und die Option „Use Kerberos Authentication“ ankreuzen, werden wir aufgefordert, die folgenden Angaben zu machen:

Die ersten beiden Felder sind die Service Principal Names, die von den Services Resource Manager und Job History verwendet werden. Wird die Option, ein Keytab zu verwenden, nicht angekreuzt, sucht der Job auf dem ausführenden System im Kerberos Cache sowie im Cache des Anwenders, der den Job initiiert hat, nach gültigen Kerberos Tickets.

Wurde die Option Keytab angekreuzt, müssen Sie den zu verwendenden Keytab sowie den Namen des entsprechenden Anwenders spezifizieren. So kann der Job beim Start der Ausführung, basierend auf dem Keytab des Users, ein Kerberos Ticket generieren. Bei Spark Submit würde die Spark Konfiguration herangezogen, in der Sie spezifiziert haben, dass die Authentifizierung über Kerberos läuft. Wird kein Keytab verwendet, würden Sie vor Ausführung von Spark Submit über den Kerberos Befehl Kinit ein Ticket erstellen. Bei Verwendung eines Keytab können Sie den Kinit Befehl mit den nötigen Flags ausführen, um ein Keytab für die Ticketerstellung zu nutzen oder Sie spezifizieren innerhalb Ihres Spark Anwendungscodes, dass Sie per Keytab einloggen wollen.

Tuning

Kommen wir nun zur Talend Kategorie „Tuning“. Sie stellt Ihnen die Option „Set Tuning Properties“ zur Verfügung, die in der Standardeinstellung nicht aktiviert ist. Wird die Option „Set Tuning Properties“ aktiviert, werden wir automatisch mit diesen Optionen begrüßt:

Vergleichen wir nun all diese Optionen mit Spark Submit.

Die erste Option ist „Set Application Master Tuning Properties“. Über diese lassen sich die Speicherkapazität und die Anzahl an Cores definieren, die der YARN Application Master nutzen sollte.

Der Zweck des YARN Application Masters ist es, die Ressourcen vom Resource Manager abzurufen und dann mit den Node Managers zu kommunizieren, um die Nutzung der Ressourcen zu kontrollieren und Container auszuführen. Ist diese Option nicht eingestellt, teilt sie dem YARN Application Master als Standard 512 MB und ein Core zu. Bei Spark Submit würde man analog dazu die Option „--conf“ nutzen und dann diese zwei Key-/Value-Paare folgen lassen: „spark.yarn.am.memory=512m,spark.yarn.am.cores=1“.

Zudem lassen sich einige weitere Einstellungen definieren, wie die Anzahl der Executors, die ihnen zugeteilte Speicherkapazität und die Anzahl an Cores sowie der Overhead-Speicher. Dieser lässt sich mithilfe der nächsten Optionen allokieren.

Als Standardwerte gelten 1 GB je Executor-Speicher und 1 Core je Executor. Der Executor-Overhead-Speicher beträgt als Standard 10 % des verwendeten Executor-Speichers, wobei das Minimum bei 384 MB und 2 Executors liegt. Wenn wir das auf Spark Submit übertragen, stehen zwei verschieden Ausführungsoptionen zur Wahl. Eine davon entspricht dem Spark Submit Beispielbefehl oben: „--executor-memory 5G --num-executors 10“ oder wir geben die Angaben über die Option „--conf“, gefolgt von den Key-/Value-Paaren „spark.executor.instances=2, spark.executor.cores=1, spark.executor.memory=2, spark.yarn.executor.memoryOverhead=384m“ weiter.

Bei der nächsten verfügbaren Option geht es um die Allokation von YARN Ressourcen.

Die hier verwendeten Optionen sind Auto, Fixed und Dynamic, aber was bedeutet das? Nun, Spark lässt uns auswählen, wie die Executors allokiert werden sollen.

In der Einstellung Auto bemerken wir, dass die oben erwähnte Option für die Einstellung der Anzahl der Executors verschwindet, da hier der von YARN allokierte Standard von 2 Executors greift. In der Einstellung Fixed haben wir hingegen die Möglichkeit, die Zahl der Executors zu definieren, die unser Job anfordern soll. Als letzte Option lässt uns Dynamic auf den Spark Mechanismus zugreifen, mit dem sich die Zahl der für unseren Job genutzten Executors anhand der Laufzeit dynamisch anpassen lässt. Das heißt, unsere Applikation kann bei Bedarf während der Ausführung weitere Executors anfordern und sie an YARN zurückgeben, wenn sie nicht mehr benötigt werden. Wurde diese Option ausgewählt, bietet sie uns die folgende Konfiguration:

Nun können wir auswählen, wie viele Executors wir eingangs von YARN anfordern wollen. Anschließend können wir anhand des Workloads unseres Jobs bei der Ausführung durch Spark festlegen, wie viele Executors minimal und maximal genutzt werden sollen. Um die Option „Dynamic“ auf Spark Submit zu übertragen, nutzt man die Option „--conf“ und die Key-/Value-Paare „spark.dynamicAllocation.enabled=true, spark.shuffle.service.enabled=true“. Laut Spark Dokumentation (https://spark.apache.org/docs/1.6.1/job-scheduling.html#dynamic-resource-allocation target="_blank") sind diese beiden Eigenschaften zur Nutzung dieses Features erforderlich.

Das nächste Kontrollfeld der Kategorie Tuning im Spark Konfigurations-Tab von Talend ist „Set Web UI Port“. Ist diese Option aktiviert, können Sie einen Port spezifizieren. Standardeinstellung ist „4040“. Diese Option lässt den Spark Driver bei laufender Spark Applikation eine Web-Benutzeroberfläche starten, mit der sich die Ausführung des Jobs kontrollieren lässt. Wird die Option nicht ausgewählt, startet die Anwendung mit dem oben genannten Standardport und zählt die Portnummer so lange weiter hoch, bis ein freier Port gefunden wird. Diese Option wird normalerweise gewählt, wenn man weiß, dass Port 4040 auf dem System, das für den Spark Job genutzt wird, nicht verfügbar ist und man einen bestimmten Port definieren möchte, statt die Spark Applikation nach einem freien Port suchen zu lassen. Um diese Option bei Spark Submit auszuwählen, nutzt man die Option „--conf“ und dann das Key-/Value-Paar „spark.ui.port=4041“.

Die nächste Option, die wir jetzt auswählen können, ist „Broadcast Factory“. Hier stehen verschiedene Optionen zur Verfügung:

Broadcast Factory“ dient bei Spark Applikationen dazu, Variable in Ihrem Cluster über alle Executors hinweg zu verteilen. Der Vorteil liegt darin, dass Variable auf diese Weise schnell und einfach verteilt werden können, das es keinen einzelnen Knoten gibt, der alles übernehmen muss. Bei dieser Funktion können wir zwischen drei Optionen wählen. Die erste Option ist „Auto“. Wählt man sie aus, werden die Standardeinstellungen verwendet. Bei der zweiten und dritten Option können Sie auswählen, ob Sie Broadcast Factory als Torrent oder HTTP nutzen wollen. In Spark Submit würde man das mithilfe der Option „--conf“ und dem Key-/Value-Paar „spark.broadcast.factory=org.apache.spark.broadcast.TorrentBroadcastFactory“ tun, wenn man nicht die Standardeinstellung nutzen möchte. In der Regel ist das Torrent.

Als letzte Option in der Kategorie Tuning haben wie die Möglichkeit, den zu verwendenden Spark Serializer individuell anzupassen:

Die Bedeutung der Serialisierung in Spark wird auch in der Spark Dokumentation beschrieben (https://spark.apache.org/docs/latest/tuning.html#data-serialization). Hierbei geht es darum, die Daten zwischen den Executors zu serialisieren, um die Performance in einer verteilten Umgebung zu steigern. Wird diese Option nicht aktiviert, wählt Talend als Standard Kryo Serialization aus, die als effizienteste Variante gilt. Um exakt dieselbe Option in Spark Submit zu nutzen, wählt man die Option „--conf“ und das Key-/Value-Paar „spark.serializer=org.apache.spark.serializer.KryoSerializer“. Wird diese Option nicht in Spark Submit spezifiziert, wird der Standard Java Serializer verwendet. Wird der Spark SQL Thrift Server genutzt, ist der Kryo Serializer als Standard vordefiniert.

Spark History

Kommen wir nun zur letzten Kategorie, „Spark History“. Wenn wir Spark Logging aktivieren, haben wir die folgenden Optionen:

Ist Event Logging aktiviert, haben Sie die Option, ein Verzeichnis in HDFS festzulegen, in dem die Job-History-Dateien vom Spark History Server gelesen werden können. Zudem können Sie die Adresse des History Servers angeben. In Spark Submit aktivieren Sie dieses Feature, indem Sie die Key-/Value-Paare „spark.eventLog.enabled=true,spark.eventLog.dir=hdfs://namenode_host:namenode_port/user/spark/applicationHistory,spark.yarn.historyServer.address=http://spark_history_server:history_port“ an die Option „--conf“ übermitteln.

Zusätzliche Konfiguration

Damit haben wir die verschiedenen Kategorien im Tab Spark Configuration abgeschlossen. Aber es sind noch drei weitere Optionen verfügbar. Die erste ist „Spark „Scratch“ Directory“. Diese Option definiert, welches Scratch Directory auf der lokalen Disk des Systems verwendet werden soll, von dem aus der Spark Job gestartet wird, während Ihre Applikation läuft. Bei Spark Submit würden wir dazu „--conf“ nutzen und dann „spark.local.dir=/tmp“. Wird nichts anderes spezifiziert, verwendet das System als Standard das /tmp Verzeichnis.

Die nächste Option wird zur Aktivierung von Spark Checkpoints genutzt. So lässt sich unser Spark Job im Falle eines Fehlschlags von einem spezifischen Zeitpunkt aus wiederherstellen. Aktiviert man die Option, kann man zur Speicherung des laufenden Jobfortschritts entweder ein Verzeichnis im lokalen Dateisystem oder in HDFS angeben. Um die Funktion in Spark Submit zu aktivieren, muss dies, wie in der Spark Dokumentation beschrieben, innerhalb unseres Spark Codes geschehen. Sie finden in der Spark Dokumentation auf dieser Seite ein entsprechendes Beispiel (https://spark.apache.org/docs/1.6.0/streaming-programming-guide.html#checkpointing).

Die letzte Option ist Advanced Properties. Sie bietet die Möglichkeit, beliebige Spark Properties hinzuzufügen, die wir in unserer Applikation in ein Key-/Value-Paar integrieren wollen. Bei Spark Submit würde man dazu die Option „--conf“ nutzen.

Hinweis: Wenn Sie sich Ihren Hadoop-Cluster und einen der Spark Gateway Knoten genauer anschauen, werden Sie feststellen, dass ein Großteil der oben erwähnten Standardeinstellungen bereits in einer Datei namens spark-defaults.conf enthalten sind. Beim Ausführen von Spark Submit werden diese Standardeinstellungen genutzt. Die Datei ist unter „/etc/spark/conf“ abgelegt. Wenn Sie die Datei öffnen, werden Sie dort die meisten hier angesprochenen Einstellungen vorfinden. Sie können diese aber dennoch, wie oben beschrieben, übergehen, indem Sie sie als Optionen in Ihr Spark Submit weiterleiten. Hier ein Beispiel:

Fazit

Talend bietet umfassende Features und Funktionalitäten zur Konfiguration Ihrer Spark Applikation. Kontrollfelder und Einblendmenüs machen die Auswahl der zu verwendenden Optionen und Standardeinstellungen dabei besonders einfach. Schauen Sie sich am besten all die verschiedenen Einstellungen an, die Sie für Ihre Talend Spark Jobs nutzen können. Sie werden feststellen, dass sie sich extrem einfach für Ihre Umgebung konfigurieren und optimieren lassen.

Quellenangaben

https://spark.apache.org/docs/latest/submitting-applications.html

https://spark.apache.org/docs/1.6.0/streaming-programming-guide.html#checkpointing

https://spark.apache.org/docs/latest/tuning.html#data-serialization

https://spark.apache.org/docs/1.6.1/job-scheduling.html#dynamic-resource-allocation

An der Diskussion teilnehmen

0 Comments

Hinterlasse eine Antwort

Your email address will not be published. Required fields are marked *