amazon-ec2 - SparkException:大师删除了我们的应用程序

Question

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

建立

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

问题

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

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

错误说明

在Spark或Shark外壳上，经过约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转储。其余执行者的转储看起来基本相同。

工人我


worker.log
Executor (ID 10) stdout
Executor (ID 10) stderr


工人二


worker.log
Executor (ID 3) stdout
Executor (ID 3) stderr


执行程序转储似乎表明许可和/或超时存在一些问题。但是从转储中我找不到任何细节。

尝试次数

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


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数据中心恢复其数据）。

Answer 1

如尝试中所述，根本原因是主节点与一个或多个工作程序之间的超时。

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

就我而言，问题是群集运行在没有DNS的AWS子网中。随着时间的流逝，群集通过旋转节点而增加，并将节点添加到群集中。构建主服务器时，仅知道集群中地址的一个子集，并且仅将该子集添加到了/ etc / hosts文件中。
当从“新”节点运行dse spark时，主服务器使用工作人员的主机名的通信失败，主服务器终止了该作业。