Bienvenidos. Hoy vamos a dedicar este video a explicar el sistema de gestión de recursos de Hadoop que se denomina YARN. Como ya conocemos, la estructura de Hadoop se divide en tres niveles básicos que tenemos por encima del hardware que estamos utilizando, que sería, por un lado, el sistema de archivos HDFS, después, lo que sería el gestor de recursos YARN y, después, lo que sería MapReduce que es el modelo de programación. El sistema, originalmente, empezó a partir del concepto del modelo de programación MapReduce, que ya hemos descrito en un video anterior, y sobre este sistema de programación MapReduce se utilizó un sistema de archivos. Este conjunto de MapReduce y sistema de archivos funcionaba de una forma correcta, pero se vio que ofrecía ciertas limitaciones y era interesante introducir un sistema gestor de recursos que nos permitiese introducir nuevas características y nuevos modelos de programación que fuesen gestionados por este sistema que pueda gestionar grandes cantidades de datos con un sistema de archivos en la base, con un sistema distribuido con muchos archivos muy grandes y gestionando muchos, muchos datos. Por tanto, se introdujo este gestor de recursos que se denominó "YARN", que significa "Yet Another Resource Negotiator". Este gestor de recursos pretende extender el modelo de programación MapReduce de modo que se puedan gestionar distintos tipos de aplicaciones y va a incluir dos niveles fundamentales, por un lado, lo que es un gestor de recursos, y por otro lado lo que es la planificación y monitorización de las aplicaciones o tareas que vamos a ejecutar dentro de ese sistema. Entonces, nosotros disponemos de nuestro sistema con un conjunto de nodos y vamos a utilizar una estructura "Master Slave", "Master Worker", según queramos denominarla, en la que tendremos un "Resource Manager" en uno de los nodos, que va a ser el que va a controlar toda la gestión de recursos de nuestro sistema. Después tendremos, en cada uno de los nodos restantes del sistema, tenemos un "Nodo Manager", "Node Manager", que va a gestionar los recursos locales de cada uno de estos nodos. Después disponemos, en cada uno de estos nodos, se van a ejecutar una serie de "Containers", que a continuación veremos qué son y, en particular, uno de esos "Containers" va a encargarse de ejecutar lo que se denomina el "Application Master" que va a ser el encargado de controlar la ejecución de la aplicación. Así, en este sistema gestor de recursos tenemos cuatro componentes, por un lado, lo que es el Resource Manager que va a ser el encargado de gestionar todo el sistema de archivos, va a incluir lo que era un planificador o un "Scheduler" que se va a encargar de asignar las tareas entre los distintos nodos del sistema. Además, este sistema de "scheduling", de planificación, se puede programar introduciendo diferentes "plugins" en el sistema, introduciendo diferentes políticas de planificación dentro del sistema. Además, este Resource Manager va a ejecutar lo que se denomina un "Application Manager" que va a ser el gestor de las aplicaciones. Es decir, una cosa son los recursos y la otra son las aplicaciones que van a utilizar estos recursos, de modo que el Resource Manager se va a encargar de controlar toda la gestión del sistema. Este Resource Manager va a recibir las peticiones de ejecución de las tareas por parte de los usuarios de los clientes y, entonces, va a realizar la asignación como veremos a continuación. El segundo componente de este sistema sería la parte del "Worker" que sería el Node Manager. Estos Node Managers van a controlar unos recursos locales del nodo y van a recibir las peticiones, o los envíos, o las asignaciones, las tareas que les va asignando el Resource Manager. De modo que tendremos que el Node Manager, lo único que va a controlar va a ser la gestión local de la ejecución dentro de ese nodo en particular, atendiendo a las asignaciones que le vaya realizando el Resource Manager general. Después tenemos lo que es el Application Master que va a ser el nodo encargado de controlar la ejecución de una aplicación. Ahora veremos exactamente el proceso que se realiza para controlar la asignación de la aplicación. Y, por último, vamos a tener los distintos "Containers" que van a ser aquellos recursos que se van a utilizar para ejecutar una tarea, una parte de una tarea en particular. Un "Container" va a incluir un conjunto de "cores" del sistema de una CPU, se le van a asignar tantos núcleos, se le va a asignar una cierta cantidad de memoria, de modo que va a ser un conjunto de recursos que se van a utilizar para ejecutar esa tarea en particular. Entonces, cuando tenemos el sistema funcionando con el Resource Manager por un lado, y los Node Managers funcionando, los Node Managers les van mandando periódicamente información al Resource Manager, indicándole el estado de ocupación de cada uno de los nodos y mostrándole la disponibilidad de los recursos que incluye ese nodo en particular. Entonces, cuando un cliente quiere ejecutar una aplicación, la petición de ejecución le va a llegar al Resource Manager que lo que va a hacer va a ser, en función del estado de ocupación de los distintos recursos, va a ejecutar, va a abrir un "Container" para ejecutar el Application Master correspondiente a esa aplicación. A partir de ahí, este Application Master le va a pedir al Resource Manager los recursos para poder ejecutarse, y el Resource Manager va a ver el estado de los distintos nodos con la información que le van mandando los Node Managers, y va a decidir mandar unas peticiones de Containers para que se habiliten estos Containers para ponerlos a disposición de esta aplicación en particular, y van a empezar estos Containers a estar disponibles para la ejecución de esta aplicación. De modo que el Application Master, que es el que controla la ejecución de la aplicación, va a comunicarse con los Containers asignados y se va a empezar a realizar la ejecución de la aplicación. A partir de ese momento, el Resource Manager ya no va a participar en la gestión de la aplicación y va a ser, directamente, el Application Master el que va a estar controlando los distintos Containers que le han sido asignados. El Application Master va a comunicarse con el cliente mandándole resultados, recibiendo instrucciones del usuario para poder ir ejecutando la aplicación de la forma correcta. Si ahora llega otro cliente y pide ejecutar otra aplicación, se va a abrir otro Application Master en otro Container, y este Application Master nuevo va a volver a pedir al Resource Manager los recursos necesarios para poder ejecutar la aplicación, y el Resource Manager va a activar los distintos Containers necesarios para poder ejecutar la aplicación. De modo que, simultáneamente, vamos a tener distintas aplicaciones ejecutándose en nuestros nodos con un Application Master por aplicación y distintos Containers distribuidos entre los distintos nodos de nuestra aplicación. La asignación de los recursos de los Containers se va realizando en función del estado de ocupación de los distintos nodos, según la información que le van mandando los Node Managers al Resource Manager.
