据我所知，Apache Spark是围绕弹性数据结构设计的，但是在运行系统期间是否会出现故障，或者这通常表明存在问题？
当我开始将系统扩展到不同的配置时，我看到ExecutorLostFailure和No more replicas（见下文）。系统恢复并且程序结束。
我是否应该关注这一点，我们通常可以做些什么来避免这种情况;或者这是因为执行人数增加了吗？
18/05/18 23:59:00 WARN TaskSetManager: Lost task 87.0 in stage 4044.0 (TID 391338, ip-10-0-0-68.eu-west-1.compute.internal, executor 11): ExecutorLostFailure (executor 11 exited caused by one of the running tasks) Reason: Container marked as failed: container_1526667532988_0010_01_000012 on host: ip-10-0-0-68.eu-west-1.compute.internal. Exit status: -100. Diagnostics: Container released on a *lost* node
18/05/18 23:59:00 WARN BlockManagerMasterEndpoint: No more replicas available for rdd_193_7 !
18/05/18 23:59:00 WARN BlockManagerMasterEndpoint: No more replicas available for rdd_582_50 !
18/05/18 23:59:00 WARN BlockManagerMasterEndpoint: No more replicas available for rdd_401_91 !
18/05/18 23:59:00 WARN BlockManagerMasterEndpoint: No more replicas available for rdd_582_186 !
18/05/18 23:59:00 WARN BlockManagerMasterEndpoint: No more replicas available for rdd_115_139 !
答案 0 :(得分：0)
当我开始将系统扩展到不同的配置时，我看到 ExecutorLostFailure和更多副本（请参见下文）。我可以做 担心吗？
您是对的，此异常并不一定意味着您的Spark作业有问题，因为即使在服务器由于物理原因（例如中断）而停止工作的情况下，也会抛出该错误。
但是，如果您在工作中看到多个执行器失败，则可能表明可能有一些改进之处。更具体地说，火花配置包含一个名为spark.task.maxFailures的参数，该参数对应于每个任务的最大失败次数，此后一个作业将被视为失败。结果，在行为良好的Spark作业中，您可能会看到一些执行器故障，但是这种情况很少发生，并且您很少应该看到某个特定任务多次失败，因为这可能意味着这不是执行器的故障，但是任务非常艰巨。
通常有什么方法可以避免这种情况吗？
这在很大程度上取决于您的工作性质。但是，正如之前通常所说的那样，对于执行者来说，所创建的任务过于繁重（例如，就所需的内存而言）。 Spark根据size of your cluster等多种因素为每个RDD创建多个分区。但是，例如，如果您的群集很小，Spark可能会创建很大的分区，并给执行程序造成问题。因此，您可以尝试在代码中重新划分RDD，以实施更多，更小的分区，从而可以更轻松地对其进行处理。
答案 1 :(得分：0)
比要接收多少故障更重要，您应该查看造成这些故障的原因。
如果失败原因与网络问题有关，则可以。这在分布式系统上是可以预期的。当您有许多机器互相交谈时，有时您会遇到一些通信问题。
但是，如果错误原因与资源消耗有关，那么您可能会遇到危险的问题。通常，所有奴隶都有类似的规格。如果某项工作需要的资源比某个从属服务器上可用的资源多，那么可能会在下一个从属服务器中一次又一次地发生。他们会不断失败，直到多米诺骨牌效应变得不负责任为止。
在最后一种情况下，您可能需要重新考虑并重写代码，以减少每个从属服务器上执行此步骤所需的内存或磁盘数量。一些常见的改进是将所有过滤器置于分组之前，或者按关键策略更改分组。