Estoy tratando de entender si el Spark Driver es un punto único de falla cuando se implementa en modo de clúster para Yarn. Por lo tanto, me gustaría obtener una mejor comprensión de las entrañas del proceso de conmutación por error con respecto al Contenedor YARN del Spark Driver en este contexto.

Sé que el Spark Driver se ejecutará en el Spark Application Master dentro de un Yarn Container. Spark Application Master solicitará recursos al Administrador de recursos de YARN si es necesario. Pero no he podido encontrar un documento con suficientes detalles sobre el proceso de conmutación por error en caso de que falle el Contenedor YARN del Spark Application Master (y el controlador Spark).

Estoy tratando de encontrar algunos recursos detallados. eso puede permitirme responder algunas preguntas relacionadas con el siguiente escenario: Si la máquina host del Contenedor YARN que ejecuta el Spark Application Master / Spark Driver pierde la conectividad de red durante 1 hora:

¿El Administrador de recursos de YARN genera un nuevo Contenedor de YARN con otro Spark Application Master / Spark Driver?

En ese caso (generando un nuevo Contenedor YARN), ¿inicia el Spark Driver desde cero si al menos 1 etapa en 1 de los Ejecutores se ha completado y notificado como tal al Controlador original antes de que fallara? ¿La opción utilizada en persist () hace alguna diferencia aquí? ¿Y sabrá el nuevo Spark Driver que el ejecutor había completado 1 etapa? ¿Tachyon ayudaría en este escenario?

¿Se desencadena un proceso de recuperación si la conectividad de red se recupera en la máquina host del Contenedor YARN del Spark Application Master original? Supongo que este comportamiento se puede controlar desde YARN, pero no sé cuál es el valor predeterminado al implementar SPARK en modo de clúster.

Realmente lo agradecería si me puede señalar algunos documentos / páginas web donde se explora en detalle la Arquitectura de Spark en modo cluster de hilo y el proceso de conmutación por error.