在尝试为群集模式部署Yarn时，我试图了解Spark Driver是否是单点故障。因此，我想在这种情况下更好地掌握有关火花驱动程序的YARN容器的故障转移过程的内部结构。
我知道Spark Driver将在Yarn Container内的Spark Application Master中运行。如果需要，Spark Application Master将向YARN资源管理器请求资源。但是，如果Spark Application Master（和Spark驱动程序）的YARN容器出现故障，我还没能找到有关故障转移过程详细信息的文档。
我试图找出一些详细资源，这可以让我回答一些与以下情况相关的问题：如果运行Spark Application Master的YARN Container的主机/ Spark Driver将网络连接丢失1小时：
YARN资源管理器是否使用其他Spark Application Master / Spark驱动程序生成新的YARN容器？
在这种情况下（产生一个新的YARN容器），如果1个Executors中至少有1个阶段已完成并在失败之前通知原始驱动程序，它是否从头开始启动Spark驱动程序？ persist（）中使用的选项是否会产生影响？新的Spark Driver会不会知道执行者已经完成了1个阶段？ Tachyon会在这种情况下提供帮助吗？
如果在原始Spark Application Master的YARN Container主机中恢复网络连接，是否会触发故障恢复过程？我猜这种行为可以从YARN控制，但我不知道在群集模式下部署SPARK时的默认行为。
如果您能指出一些文档/网页，我会非常感激。在这些文档/网页中，详细探讨了纱线群集模式中的Spark架构和故障转移过程。
答案 0 :(得分：5)
我们刚刚开始在YARN上运行，所以我不太了解。但我几乎可以肯定，我们在驾驶员级别没有自动故障转移。 （我们自己实施了一些。）
我不希望驱动程序有任何默认的故障转移解决方案。您（驱动程序作者）是唯一知道如何健康检查您的应用程序的人。生活在驱动程序中的状态不是可以自动序列化的状态。当SparkContext被销毁时，在其中创建的所有RDD都会丢失，因为没有正在运行的应用程序它们就毫无意义。
我们实施的恢复策略非常简单。在每次昂贵的Spark操作后，我们都会制作一个手动检查点我们将RDD保存到磁盘（想想saveAsTextFile）并立即加载回来。这会擦除RDD的谱系，因此如果分区丢失，它将被重新加载而不是重新计算。
我们还存储我们所做的和文件名。因此，如果驱动程序重新启动，它可以按照此类操作的粒度从中断处继续。