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 ...
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)? –
Ähnlich wie https://stackoverflow.com/questions/42689304/spark-job-that-use-hive-context-failing-in-oozie –
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