2017-10-31 1 views
2

Der Oozie-Workflow-Launcher schlägt manchmal aufgrund der Ladereihenfolge des Klassenpfads fehl (Status KILLED). In SparkSubmit existiert ein Aufruf der Methode in efeu 2.4.0, aber diese spezielle Methode ist nicht in efeu 2.0.0-rc2. Der Workflow-Prozess läuft normalerweise für die meisten stündlichen nominalen Zeiten gut (SUCCEEDED), aber der Start schlägt selten fehl, da efeu 2.0 anstelle von efeu 2.4 geladen wird. Bei Ausfall zeigt die (geschwärzt) Oozie Launcher log diesen Stapel Aufruf:Oozies Spark Submit verwendet Efeu 2.4 Methode fehlt in CDH 5.9.2

2017-10-31 20:37:30,339 WARN org.apache.oozie.action.hadoop.SparkActionExecutor: SERVER[xxxx-oozie-lv-102.xxx.net] USER[xxxxx] GROUP[-] TOKEN[] APP[xxxx-proc-oozie] JOB[0143924-170929213137940-oozie-oozi-W] ACTION[[email protected]] Launcher exception: org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor.setDefaultConf(Ljava/lang/String;)V 
java.lang.NoSuchMethodError: org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor.setDefaultConf(Ljava/lang/String;)V 
    at org.apache.spark.deploy.SparkSubmitUtils$.resolveMavenCoordinates(SparkSubmit.scala:1054) 
    at org.apache.spark.deploy.SparkSubmit$.prepareSubmitEnvironment(SparkSubmit.scala:287) 
    at org.apache.spark.deploy.SparkSubmit$.submit(SparkSubmit.scala:154) 
    at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:121) 
    at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala) 
    at org.apache.oozie.action.hadoop.SparkMain.runSpark(SparkMain.java:264) 
    at org.apache.oozie.action.hadoop.SparkMain.run(SparkMain.java:214) 
    at org.apache.oozie.action.hadoop.LauncherMain.run(LauncherMain.java:60) 
    at org.apache.oozie.action.hadoop.SparkMain.main(SparkMain.java:52) 
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
    at java.lang.reflect.Method.invoke(Method.java:498) 
    at org.apache.oozie.action.hadoop.LauncherMapper.map(LauncherMapper.java:233) 
    at org.apache.hadoop.mapred.MapRunner.run(MapRunner.java:54) 
    at org.apache.hadoop.mapred.MapTask.runOldMapper(MapTask.java:453) 
    at org.apache.hadoop.mapred.MapTask.run(MapTask.java:343) 
    at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:164) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at javax.security.auth.Subject.doAs(Subject.java:422) 
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1912) 
    at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:158) 

Es scheint, dass Cloudera Distributed Hadoop Efeu 2.0.0-RC2 enthält, aber seine SparkSubmit scheint Efeu Version 2.4.0 zu verlangen. Ich habe versucht, efeu 2.4 in mein Glas und 2.0 auszuschließen, aber das ist noch bevor mein Prozess gestartet wird (also vielleicht ist das ein bisschen lächerlich). Ich denke, es muss eine Möglichkeit geben, die 2.4.0-Version im oozie loading-Prozess Vorrang zu haben und oozie.launcher.mapreduce.user.classpath.first entweder wahr oder falsch versucht haben - In jedem Fall muss/muss die Job-Eigenschaften-Datei enthalten:

oozie.libpath=${nameNode}/user/spark/share/XXXX-spark/ 
oozie.use.system.libpath=true 

Hinweis: Dropping ivy im Libpath oben schien keinen Unterschied zu machen.

It's likely that the workflow needs an extra flag or ... like this: 

<configuration> 
    <property> 
     <name>oozie.launcher.mapreduce.map.java.opts</name> 
     <value>-verbose</value> 
    </property> 
</configuration> 

Das Team (SRE), die den Cluster verwaltet zieht die ursprünglichen Gläser mit der CDH 5.9.2 zu verwenden.

Wie kann ich spark-submit zwingen, ivy 2.4 (und nicht 2.0) zu verwenden, indem ich die workflow.xml, Jobeigenschaften, mein Build oder ... so ändere, dass die SRE-Anforderungen erfüllt werden, um den CDH intakt zu halten? Kann ich dies lösen, indem ich den Cache ungültig mache.

Bitte beachten Sie, dass die Efeu 2.4.0 Glas zu einem Classpath, wo einige Details genau muss hinzufügen, die Erwähnung das Efeu Glas auf hdfs setzen, das Glas in einem gewissen Pfad zugreifen oder ...

+1

Führen Sie Ihren Spark-Job im lokalen Modus (d. H. Nur im Oozie-Launcher-Container) oder im Garn-Client-Modus aus? Wenn 'Garn-Client', tritt die Ausnahme im Treiber oder in den Executoren auf (die Oozie libpath und 'oozie.launcher' Requisiten nicht erben)? –

+0

Ähnlich wie https://stackoverflow.com/questions/42689304/spark-job-that-use-hive-context-failing-in-oozie –

+0

1st: Dieses Problem ähnelt community.cloudera.com/t5/Batch- Verarbeitungs- und Workflow/.... 2. @SamsonScharfrichter ... Dieses Problem tritt auf, wenn der Garn-Cluster-Modus mit dem Standard-Client-Modus verwendet wird und im Workflow-Protokoll angezeigt wird. Ich bin mir nicht sicher, ob ich den zweiten Teil Ihrer Frage beantworte. Ich habe versucht, die Vorschläge in den Link, aber immer noch nicht über Lauf # 17 - ein typisches scheitern. – codeaperature

Antwort

1

Cloudera Spark , das ist https://github.com/cloudera/spark/blob/cdh5-1.6.0_5.9.2/pom.xml, verwendet Ivy 2.4.0, aber die CDH-Distribution kommt mit Ivy 2.0.0-rc2.

um dieses Problem zu lösen, in hdfs folder = /user/oozie/share/lib/lib_{timestamp}/spark wurde das Efeu 2.0.0-RC2 Glas mit der Version 2.4 ersetzt (die seltsam org.apache.ivy_ivy-2.4.0.jar benannt ... aber ich glaube nicht, dass Angelegenheiten). Nach dem Ersetzen des Jars, Ausführen einer Oozie-Admin-Aktion (oozie admin -sharelibupdate spark, um diesen Ordner zu leeren/erneut zu scannen), funktionierte der Prozess gut, als der Workflow danach gestartet wurde.

Entlang der Linien von Samsons Kommentaren variierte der Efeu-Cache über einige Knoten, da neue Knoten zu einem späteren Zeitpunkt hinzugefügt wurden und dies ein seltenes/intermittierendes Problem verursachte.

Verwandte Themen