EMR 5.5.0上的简单火花提交作业失败，HDFS上带有__spark_config__.zip的FileNotFoundException

Question

我正在尝试在AWS ERM 5.5.0上部署运行Python 3 Spark应用程序。 我读了几篇有关如何配置群集以要求Python 3的文章。我想测试设置正确的内容，因此创建了一个简单的应用程序来打印sys.version 。 然后，我将此工作提交给集群。

当我使用spark-submit --deploy-mode client /local/path/to/version.py或通过以客户端模式提交步骤在主服务器上运行它时，它可以正常工作，并且我看到版本信息（Python 3，是的） ！）在stdout上。

当我使用spark-submit --deploy-mode cluster /local/path/to/version.py或通过以群集模式提交步骤在群集（1个主spark-submit --deploy-mode cluster /local/path/to/version.py ，1个内核）上运行时，它失败。 作业的stderr日志在一些地方显示“容器以非零退出代码1退出”。 查找此内容，我被定向到实际容器日志的yarn logs日志。 看着这些，我看到了两个容器的日志集。

在容器container_1496243466754_0004_01_000001的标准输出日志中，我看到实际的python代码运行并报告了python版本（Python 3，再次！）。 自从代码运行以来，我希望这项工作能够成功，但事实并非如此。

来自其他容器container_1496243466754_0004_02_000001的日志在stderr日志的末尾显示以下内容：

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）？

更新：

• 我在一个单行程序的末尾添加了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

我得到了完全相同的错误。 读完您的问题后，我意识到我们共同的一件事是我也有一个2节点群集，其中包含1个主节点和1个核心。 在3节点群集（EMR的默认设置）上重复我的工作会导致问题消失。 如果这也解决了您的问题并且是实际的解决方案，则可能存在错误或限制，至少在EMR上，群集部署模式的节点/群集的最少数量。