Apache spark 如何处理纱线簇模式下Spark应用程序的异常驱动程序终止

我们正在使用AWS EMR进行spark作业。我们所有的作业都是以集群模式提交的，因此驱动程序将在其中一个集群节点中运行。主节点使用按需节点，核心节点使用现场实例。现在，尽管我们几乎总是选择中断率小于5%的实例，但有时我们的集群节点中有相当一部分会提前终止（可能是因为更高的需求）

---

因此，我想知道，在上述情况下，如果包含驱动程序进程的节点发生故障，会发生什么情况？在那种情况下，spark的工作有恢复的机会吗？还是作业永远消失了？

Spark驱动程序是单点故障，因为它保存了正在运行的应用程序的所有群集状态

实际上，经过昂贵的转换后，非临时存储可用于检查点批处理应用程序。也就是说，在这种情况下尝试重新开始是可以做到的，但当我研究它时，至少很难说。前段时间我以我的名义问了这样一个问题，你可以找到它。我很有技术性，但我觉得：天哪，多么辛苦的工作啊

---

因此，恢复意味着你自己的东西，或接受重新运行。自从我上次评估EMR以来，我看到驱动程序可以在主控机上运行，并且可以进行故障转移，但就我所见，这不是同一件事，也不是您所希望的。

EMR为纱线中的核心节点进行节点调平。spark驱动程序/应用程序主机仅在核心节点中创建。HDFS也仅驻留在核心节点中。 因此，以最好的方式处理你的情况，你可以考虑使用核心和任务组。 你能做些什么来解决这个问题-

船长：随需应变

核心：随需应变。实例的最少数量可以是1

任务：具有最小EBS体积的自动缩放的Spot。在这种情况下，实例的最小数量可以为0

这将降低您的成本，还可以确保包含驱动程序进程的节点永不停机

---

您好，谢谢您的见解。我并不反对在EMR master上运行驱动程序，只是我们从未认真考虑过。我认为为驱动程序选择按需或现场块实例是一个可行的选择。在这种情况下，我假设作业必须在客户机模式下运行。您对此有何想法？我不太确定，因为如果驱动程序出现故障，它也可能在另一台机器上出现故障。这就是为什么我说“不一样的事情”。我的印象是，在所有情况下，它都是单点故障。类似ORACLE RAC的东西在协调器和心跳方面的工作方式不同。我同意，这是单点故障。但是选择在非现场实例上运行它至少可以防止实例终止失败，对吗？虽然我不知道纱线客户端模式可能还有其他问题。哦，当然。但对于当前运行的驱动程序，仍然存在单点故障。我的第一句话，谢谢。事实上，我们不可能只有一个核心节点，因为有大量数据写入hdfs（然后通过s3 dist cp复制到s3），问题就出在这里。为核心节点添加自动缩放功能。如果可能的话。另一种可能的选择是使用EMRFS而不是HDFS，因为您最终会将数据写入S3。