【问题标题】：SparkException: Master removed our applicationSparkException：Master 删除了我们的应用程序
【发布时间】：2015-11-21 14:34:08
【问题描述】：

我知道 Stackoverflow 上有 other very similar 问题，但这些问题要么没有得到回答，要么没有帮助我。与这些问题相比，我在这个问题中加入了更多的堆栈跟踪和日志文件信息。我希望这会有所帮助，尽管它使问题变得有点长而丑陋。对不起。

设置

我在 Amazon EC2 上运行一个 9 节点集群，使用安装了 DSE (DataStax Enterprise) 4.6 版的 m3.xlarge 实例。对于每个工作负载（Cassandra、搜索和分析），使用 3 个节点。 DSE 4.6 捆绑 Spark 1.1 和 Cassandra 2.0。

问题

应用程序（Spark/Shark-Shell）在大约 3 分钟后被删除即使我没有运行任何查询。只要在约 3 分钟内完成，对小型数据集的查询就会成功运行。

我想分析更大的数据集。因此，我需要应用程序（shell）在约 3 分钟后不要被删除。

错误说明

在 Spark 或 Shark shell 上，闲置约 3 分钟后或在执行（长时间运行）查询时，Spark 最终将中止并给出以下堆栈跟踪：

15/08/25 14:58:09 ERROR cluster.SparkDeploySchedulerBackend: Application has been killed. Reason: Master removed our application: FAILED
org.apache.spark.SparkException: Job aborted due to stage failure: Master removed our application: FAILED
    at org.apache.spark.scheduler.DAGScheduler.org$apache$spark$scheduler$DAGScheduler$$failJobAndIndependentStages(DAGScheduler.scala:1185)
    at org.apache.spark.scheduler.DAGScheduler$$anonfun$abortStage$1.apply(DAGScheduler.scala:1174)
    at org.apache.spark.scheduler.DAGScheduler$$anonfun$abortStage$1.apply(DAGScheduler.scala:1173)
    at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
    at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:47)
    at org.apache.spark.scheduler.DAGScheduler.abortStage(DAGScheduler.scala:1173)
    at org.apache.spark.scheduler.DAGScheduler$$anonfun$handleTaskSetFailed$1.apply(DAGScheduler.scala:688)
    at org.apache.spark.scheduler.DAGScheduler$$anonfun$handleTaskSetFailed$1.apply(DAGScheduler.scala:688)
    at scala.Option.foreach(Option.scala:236)
    at org.apache.spark.scheduler.DAGScheduler.handleTaskSetFailed(DAGScheduler.scala:688)
    at org.apache.spark.scheduler.DAGSchedulerEventProcessActor$$anonfun$receive$2.applyOrElse(DAGScheduler.scala:1391)
    at akka.actor.ActorCell.receiveMessage(ActorCell.scala:498)
    at akka.actor.ActorCell.invoke(ActorCell.scala:456)
    at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:237)
    at akka.dispatch.Mailbox.run(Mailbox.scala:219)
    at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:386)
    at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
    at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
    at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
    at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
FAILED: Execution Error, return code -101 from shark.execution.SparkTask

这对我来说不是很有帮助，这就是为什么我要向你展示更多的日志文件信息。

错误详情/日志文件

大师

来自master.log，我认为有趣的部分是

INFO 2015-08-25 09:19:59 org.apache.spark.deploy.master.DseSparkMaster: akka.tcp://sparkWorker@172.31.46.48:46715 got disassociated, removing it.
INFO 2015-08-25 09:19:59 org.apache.spark.deploy.master.DseSparkMaster: akka.tcp://sparkWorker@172.31.33.35:42136 got disassociated, removing it.

和

ERROR 2015-08-25 09:21:01 org.apache.spark.deploy.master.DseSparkMaster: Application Shark::ip-172-31-46-49 with ID app-20150825091745-0007 failed 10 times, removing it
INFO 2015-08-25 09:21:01 org.apache.spark.deploy.master.DseSparkMaster: Removing app app-20150825091745-0007

为什么工作节点会解除关联？

如果您需要查看，我也附上了master's executor (ID 1) stdout。执行者stderr 为空。但是，我认为它对解决这个问题没有任何用处。

在 Spark Master UI 上，我验证看到所有工作节点都是 ALIVE。第二个屏幕截图显示了应用程序的详细信息。

主实例上生成了一个执行器，而两个工作节点上的执行器重新生成，直到整个应用程序被删除。没关系还是表明有问题？我认为这可能与上面的“（它）失败 10 次”错误消息有关。

工作人员日志

此外，我可以向您展示两个 Spark 工作节点的日志。我删除了大部分类路径参数以缩短日志。让我知道你是否需要看它。当每个工作节点产生多个执行程序时，我将链接附加到一些（不是全部）执行程序 stdout 和 stderr 转储。其余执行者的转储看起来基本相同。

工人 I

工人 II

执行程序转储似乎表明权限和/或超时存在一些问题。但是从转储中我无法弄清楚任何细节。

尝试

如上所述，有一些类似的问题，但没有一个得到回答，或者没有帮助我解决问题。无论如何，我尝试并验证的事情是：

Opened port 2552。没有任何变化。
Increased spark.akka.askTimeout 这会导致 Spark/Shark 应用程序的寿命更长，但最终仍会被删除。
Ran the Spark shell locally 和 spark.master=local[4]。一方面，这让我能够成功运行超过约 3 分钟的查询，另一方面，它显然没有利用分布式环境。

总结

总而言之，可以说超时和长时间运行的查询在本地模式下成功执行的事实都表明存在配置错误。虽然我不能确定，也不知道如何解决。

非常感谢任何帮助。

编辑：在集群初始设置后添加了两个 Analytics 节点和两个 Solr 节点。以防万一。

编辑 (2)：我能够通过将 Analytics 节点替换为三个新安装的 Analytics 节点来解决上述问题。我现在可以在更大的数据集上运行查询，而无需移除外壳。我不打算将此作为问题的答案，因为目前尚不清楚三个原始 Analytics 节点有什么问题。但是，由于它是一个用于测试目的的集群，因此可以简单地替换节点（替换节点后，我在每个新节点上执行了nodetool rebuild -- Cassandra 以从 Cassandra 数据中心恢复它们的数据）。

【问题讨论】：

标签： amazon-ec2 apache-spark datastax-enterprise

【解决方案1】：

正如在尝试中提到的，根本原因是主节点与一个或多个工作节点之间的超时。

要尝试的另一件事：验证是否可以通过主机名通过 dns 或 /etc/hosts 文件中的条目访问所有工作人员。

就我而言，问题在于集群在没有 DNS 的 AWS 子网中运行。集群随着时间的推移通过旋转节点而增长，将节点添加到集群中。在构建主服务器时，只有集群中的一部分地址是已知的，并且只有该子集被添加到 /etc/hosts 文件中。当 dse spark 从“新”节点运行时，使用 worker 主机名的 master 通信失败，master 终止了作业。

【讨论】：