HDFSで__spark_config__.zipのFileNotFoundExceptionを使用して、EMR 5.5.0で簡単なspark-submitジョブが失敗する

Question

AWS ERM 5.5.0でPython 3 Sparkアプリケーションをデプロイしようとしています。私はPython 3を必要とするようにクラスタを設定する方法についていくつかの記事を読んでいます。私はそれが正しく設定されているので、私はsys.versionを印刷する単純なアプリケーションを作成してテストしたいです。それから私はこの仕事をクラスターに提出します。

spark-submit --deploy-mode client /local/path/to/version.pyのいずれかを使用してマスターで実行するか、クライアントモードで手順を実行すると動作し、stdoutにバージョン情報（Python 3、よろしく！）が表示されます。

spark-submit --deploy-mode cluster /local/path/to/version.pyを使用してクラスタ（1マスター、1コア）上で実行するか、クラスタモードでステップを送信すると失敗します。ジョブからのstderrログには、「コンテナがゼロ以外の終了コード1で終了しました」というメッセージが数箇所に表示されます。これを見て、実際のコンテナのログはyarn logsに送られました。それらを見ると、2つのコンテナのログのセットが表示されます。

コンテナcontainer_1496243466754_0004_01_000001のstdoutログには、実際のP​​ythonコードが実行され、Pythonバージョン（Python 3、もう一度！）が報告されています。コードが実行されて以来、私はその仕事が成功すると期待していますが、そうではありません。

他のコンテナcontainer_1496243466754_0004_02_000001からのログが標準エラーログの最後に次のことを示しています

17/05/31 17:11:58 INFO ApplicationMaster: Preparing Local resources 
Exception in thread "main" java.io.FileNotFoundException: File does not exist: hdfs://ip-10-0-210-27.hwheel.in:8020/user/hadoop/.sparkStaging/application_1496243466754_0004/__spark_conf__.zip 
     at org.apache.hadoop.hdfs.DistributedFileSystem$22.doCall(DistributedFileSystem.java:1309) 
     at org.apache.hadoop.hdfs.DistributedFileSystem$22.doCall(DistributedFileSystem.java:1301) 
     at org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81) 
     at org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1317) 
     at org.apache.spark.deploy.yarn.ApplicationMaster$$anonfun$6.apply(ApplicationMaster.scala:160) 
     at org.apache.spark.deploy.yarn.ApplicationMaster$$anonfun$6.apply(ApplicationMaster.scala:157) 
     at scala.Option.foreach(Option.scala:257) 
     at org.apache.spark.deploy.yarn.ApplicationMaster.<init>(ApplicationMaster.scala:157) 
     at org.apache.spark.deploy.yarn.ApplicationMaster$$anonfun$main$1.apply$mcV$sp(ApplicationMaster.scala:765) 
     at org.apache.spark.deploy.SparkHadoopUtil$$anon$1.run(SparkHadoopUtil.scala:67) 
     at org.apache.spark.deploy.SparkHadoopUtil$$anon$1.run(SparkHadoopUtil.scala:66) 
     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:1698) 
     at org.apache.spark.deploy.SparkHadoopUtil.runAsSparkUser(SparkHadoopUtil.scala:66) 
     at org.apache.spark.deploy.yarn.ApplicationMaster$.main(ApplicationMaster.scala:764) 
     at org.apache.spark.deploy.yarn.ApplicationMaster.main(ApplicationMaster.scala) 

私はそれが私の仕事の失敗の原因となっていると思います。他の容器から戻ってstderrにスキップ、私は以下を参照してください。

17/05/31 17:11:52 INFO ApplicationMaster: Deleting staging directory hdfs://ip-10-0-210-27.hwheel.in:8020/user/hadoop/.sparkStaging/application_1496243466754_0004 

は、だから、アプリケーションが終了したときcontainer_1496243466754_0004_01_000001がHDFSからステージングディレクトリを削除したように私には見えるが、これは、その後を探している他の容器をトリップそのディレクトリに6秒後にファイルします。

Javaバージョンのミスマッチ（Java 8のアプリケーション、Java 7のspark）のために、この種のエラーが発生する可能性がある（おそらく日付のある）説明があります。しかし、私はEMRがJava 8ですべて動作し、それがクラスタのデフォルトであり、私のアプリケーションでJavaを直接呼び出すわけではないと考えています。

どうすれば解決できますか？私のアプリケーションはステージングファイルをあまりにも速く完了したり削除したりしていますか（これは単なる一行のpythonです）？

UPDATES：

• 私はそれがあまりにも早く完了し、私のプログラムの場合ではなかったことを確認するために私の1行プログラムの最後でtime.sleep（10）で追加。変わりはない。
• spark.yarn.preserve.staging.filesのドキュメントが見つかりました。私はこれをspark-defaults.confでtrueに設定しました。私はクラスタモードで同じ仕事をやり直しました。今回は、コンテナはエラーなしで完了まで実行されます。 のFileNotFoundで問題はありません。spark_conf .zip。このファイルがHDFS上の予想される場所に存在することを確認できます。ただし、全体的なジョブは、失敗としてApplication application_1496243466754_0007 failed 2 times due to AM Container for appattempt_1496243466754_0007_000002 exited with exitCode: 0と報告します。 '0'は正しい終了コードのように見え、ログファイルにはエラーは表示されません。今私はなぜ仕事が失敗しているのか分かりません。

Answer 1

まったく同じエラーが発生しました。あなたの質問を読んで私が共通していることの1つは、マスターとコアが1つの2ノードクラスタも持っていることです。 3ノードクラスタ（EMRのデフォルト）で作業を繰り返すことで、問題が解決されます。これがあなたの問題を解決し、実際の解決策であれば、クラスタ展開モードのノード/クラスタの最小数、少なくともEMRではバグや制限があるかもしれません。