Relación entre YARN y otros componentes

Relación entre YARN y Spark

La computación y programación de Spark pueden implementarse usando el modo YARN. Spark disfruta de los recursos informáticos proporcionados por los clústeres de YARN y ejecuta tareas de forma distribuida. Spark en YARN tiene dos modos: YARN-cluster y YARN-client.

• Modo de YARN Cluster

  Figura 1 describe el marco de operación.

  Figura 1 Marco de operación de Spark on YARN-cluster
  

  Proceso de implementación de Spark on YARN-cluster:

  1. El cliente genera la información de la aplicación y, a continuación, envía la información a ResourceManager.
  2. ResourceManager asigna el primer container (ApplicationMaster) a SparkApplication e inicia el driver en el container.
  3. ApplicationMaster se aplica a los recursos de ResourceManager para ejecutar el container.

     ResourceManager asigna los containers a ApplicationMaster, que se comunica con los NodeManagers relacionados e inicia el executor en el container obtenido. Después de iniciar el executor, se registra con drivers y se aplica a las tareas.

  4. Los controladores asignan tareas a los ejecutores.
  5. Los executors ejecutan tareas e informan el estado de funcionamiento a Drivers.
• Modo de YARN Client

  Figura 2 describe el marco de operación.

  Figura 2 Marco de operación de Spark on YARN-client
  

  Proceso de implementación de Spark on YARN-client:

  

  En el modo YARN-cliente, el controlador se implementa y se inicia en el cliente. En el modo YARN-client, el cliente de una versión anterior es incompatible. Se recomienda utilizar el modo YARN-cluster.

  1. El cliente envía la solicitud de aplicación de Spark a ResourceManager y, a continuación, ResourceManager devuelve los resultados. Los resultados incluyen información como Application ID y los recursos máximos y mínimos disponibles. El cliente empaqueta toda la información necesaria para iniciar ApplicationMaster y envía la información a ResourceManager.
  2. Después de recibir la solicitud, ResourceManager encuentra un nodo apropiado para ApplicationMaster y lo inicia en este nodo. ApplicationMaster es un papel en YARN, y el nombre del proceso en Spark es ExecutorLauncher.
  3. En función de los requerimientos de recursos de cada tarea, ApplicationMaster puede solicitar una serie de containers para ejecutar tareas desde ResourceManager.
  4. Después de recibir la lista de container recién asignados (de ResourceManager), ApplicationMaster envía información a los NodeManagers relacionados para iniciar los containers.

     ResourceManager asigna los containers a ApplicationMaster, que se comunica con los NodeManagers relacionados e inicia el executor en el container obtenido. Después de iniciar el executor, se registra con drivers y se aplica a las tareas.

     

     Los containers en ejecución no se suspenden y los recursos no se liberan.

  5. Drivers asignan task a los executors. Los executors ejecutan tareas e informan el estado de funcionamiento a Drivers.

Relación entre YARN y MapReduce

MapReduce es un marco de computación que se ejecuta en YARN, que se utiliza para el procesamiento por lotes. MRv1 se implementa basado en MapReduce en Hadoop 1.0, que se compone de modelos de programación (Las API de programación nuevas y antiguas), entorno de ejecución (JobTracker y TaskTracker), y motor de procesamiento de datos (MapTask y ReduceTask). Este marco sigue siendo débil en escalabilidad, tolerancia a fallas (JobTracker SPOF) y compatibilidad con varios marcos. (Actualmente, solo se admite el marco de computación de MapReduce.) MRv2 se implementa en base a MapReduce en Hadoop 2.0. El código fuente reutiliza los modelos de programación MRv1 y la implementación del motor de procesamiento de datos, y el entorno de ejecución se compone de ResourceManager y ApplicationMaster. ResourceManager es un nuevo sistema de gestión de recursos, y ApplicationMaster es responsable de cortar los datos de trabajo de MapReduce, asignar tareas, solicitar recursos, programar tareas y tolerar fallos.

Relación entre YARN y ZooKeeper

Figura 3 muestra la relación entre ZooKeeper y YARN.

Figura 3 Relación entre ZooKeeper y YARN

1. Cuando se inicia el sistema, ResourceManager intenta escribir información de estado en el ZooKeeper. ResourceManager que escribe primero información de estado en ZooKeeper se selecciona como ResourceManager activo, y otros son ResourceManagers en espera. Los ResourceManagers en espera monitorean periódicamente la información de elección activa de ResourceManager en ZooKeeper.
2. El ResourceManager activo crea el directorio Statestore de ZooKeeper para almacenar la información de la aplicación. Si el ResourceManager activo es defectuoso, el ResourceManager en espera obtiene la información de la aplicación del directorio Statestore y restaura los datos.

Relación entre YARN y Tez

La información del trabajo de Hive en Tez requiere la capacidad del servidor de TimeLine de YARN para que las tareas de Hive puedan mostrar el estado actual e histórico de las aplicaciones, facilitando el almacenamiento y la recuperación.