Apache YARN

El componente Apache YARN (Yet Another Resources Negotiator) surge con la versión de Apache Hadoop 2, usualmente conocido con su función MR2, anteriormente en la versión uno de Apache Hadoop solo nos ofrecía una forma de procesar la información, el famoso Map Reduce, Hadoop por si mismo esta configurado para tomar todos los recursos disponibles para sus jobs, ¿Qué significa esto?, Qué si queremos ejecutar dos  jobs al mismo tiempo, no se podrá, ¿Pero entonces que hace hadoop en estos casos?, Hadoop encola los jobs y cuando tiene recursos disponibles empieza la ejecución de el siguiente jobs inmediatamente.

El YARN nace con la necesidad de separar las funcionalidades de un Manejador de Recursos y el Programador/Monitoreador de Tareas en diferentes demonios. Esto implicaría que tendríamos un manejador de recursos maestro (RM) y un AM(Application Master) por aplicación, una aplicación se ve definida como un job o un DAG de jobs, Pero, ¿Qué es un DAG?, DAG (directed acyclic graph)  y un DAG, no es más que la generalización de un proceso MapReduce, permitiéndonos definir flujos paralelizados y no solo tener dos componentes principales un Map y un Reduce, este tipo de procesamiento con DAG's lo ofrecen TEZ y SPARK.

Empecemos a listar los componentes básicos de el YARN.

• ResourceManager: El ResourceManager es la última autoridad que se encarga de proporcionar los recursos entre todas las aplicaciones del clúster, el ResourceManager se compone de dos elementos principales:
• Scheduler
• ApplicationsManager
• NodeManager: Es un agente hospedado en cada máquina encargada del procesamiento, el es responsable de los containers y al mismo tiempo esta encargado de monitorear el uso de los recursos (cpu, memoria, disco, red) y reportarle este monitoreo al ResourceManager/Scheduler.
• ApplicationMaster: Por cada aplicación que ejecutemos con YARN se crea un ApplicationMaster que esta encargado de negociar recursos con el ResourceManager, trabaja en conjunto con el NodeManager, para la ejecución y monitoreo de sus tareas de cada ApplicationMaster.
• Container: En este componente es donde toda la magia sucede, puede haber n containers asociados a un ApplicationMaster que será el encargado de monitorear estos contenedores, para reportarle al NodeManager, en los containers es donde las tasks de cada job o DAG son ejecutadas.
• Scheduler: El scheluder es responsable de asignar los recursos a todas las aplicaciones en ejecución, el scheluder solo se encarga de optimizar el asignamiento de recursos, el no monitorea o maneja el status de las aplicaciones, para eso esta el ApplicationMaster, el se encarga de optimizar su pila de aplicaciones en base al requerimientos de recursos que cada una demanda, su medida del scheluder para el asignamiento de recursos tiene su propia medida que lo hace con el concepto abstracto de container, que engloba elementos como memoria, disco duro, red, cpu, etc.
• Client: El cliente es el encargado de lanzar los jobs o los DAGs mandando una solicitud al ResourceManager de ejecución.

En la imagen siguiente se puede mostrar un flujo de un clúster utilizando YARN como manejador de recursos del clúster de hadoop.

Usualmente el componente maestro si así se quiere ver es el Resource Manager, y los NodeManager son como los esclavos, el Resource Manager es el único que puede interectuar directo con el NameNode, y en cada nodo que será encargado del procesamiento de los jobs, deberá existir un NodeManager. Las versiones en MR 1 del RM y NM eran respectivamente JobTracker y tasktracker.

En la siguiente imagen podemos ver un flujo de la solicitud de dos jobs.

Otro manejador de recursos que nos proporciona Apache es Mesos, aunque los dos manejan recursos, tienen importantes diferencias, mientras YARN fue diseñado para manipular los recursos de tu clúster y las aplicaciones en el, Mesos es un manejador de recursos más global, como para manejar los recursos de un Data Center.