Los Problemas de MapReduce
Como hemos visto en el post anterior MapReduce se encarga de automatizar el procesado de los datos en paralelo a través de distintos nodos de un cluster gestionando las tareas necesarios para la realización del trabajo. También proporciona la capacidad de reconducir el proceso en el momento en que detecta que uno de los nodos falla .
MapReduce fue concebido para una función muy concreta, indexar el contenido de cada página web hasta completar todo el universo de la World Wide Web. A medida que se extendieron las aplicaciones de Hadoop a otras lógicas de negocio diferentes empezaron a aparecer ciertos problemas con MapReduce.
El primer problema estaba en la escalabilidad de la propuesta original. Como hemos visto en el post sobre el funcionamiento de MapReduce existe un cuello de botella en la arquitectura: el JobTracker. Un sólo nodo, el nodo maestro, se encarga de gestionar todas la tareas y los recursos disponibles en MapReduce . Según datos publicados por Yahoo! el límite de este diseño está en torno a los 5.000 nodos y unas 40.000 tareas concurrentes.
La arquitectura de MapReduce tampoco utilizaba los recursos disponibles de la manera más eficiente. En la configuración del administrador del cluster se establecían unos slots fijos para el proceso de Map y Reduce. La capacidad de realizar tareas en cada parte del proceso está limitada por el número de slots fijados, lo que no permite escalar más allá de la estructura física definida por el administrador. Ni siquiera es posible combinar los recursos dedicados a Map y a Reduce entre ellos.
Adicionalmente MapReduce no aportaba ninguna alternativa para la gestión de los recursos disponibles, sólo permitía usar su framework, un framework que estaba concebido para procesos en lotes (batch). Con la aparición de nuevos modelos de programación se hizo patente la necesidad de soportar otros paradigmas de programación (Impala, Spark…) y una mejor forma de gestionar los recursos.
YARN (Yet Another Resource Negociator) aparece con la versión 2 de Hadoop para intentar dar respuesta a estas necesidades.
Elementos de YARN (Yet Another Resource Negociator)
En YARN seguimos contando con los dos procesos: Map y Reduce, sin embargo la manera en que se gestionan los recursos del ecosistema es completamente diferente. Para realizar un trabajo YARN proporciona una nueva arquitectura en la que se modifica sustancialmente la forma en que se distribuyen las tareas entre los nodos. Para ello YARN incorpora los siguiente nuevos elementos a la ecuación:
- Resource Manager (uno por cada cluster) el responsable de organizar los recursos de los nodos esclavos a la medida de las necesidades de cada tarea. Se encarga de iniciar los trabajos (jobs) en el cluster maestro a petición de los usuarios (cliente). Puede sonar parecido a lo que hacíamos con el JobTracker en la versión uno de MapReduce pero, como veremos más adelante, hay grandes diferencias.
- Node Manager (uno por cada nodo esclavo) sustituye la función que realizaban los TaskTrackers en la versión anterior. Son los responsables de iniciar los procesos de una aplicación en particular y además se encargan de solicitar los recursos necesarios al ResourceManager garantizando que las tareas asignadas no superen la capacidad de los recursos disponibles en el nodo.
- Job History Server (uno por cluster) es un proceso opcional cuya función es mantener un archivo de los logs del trabajo (job).
La Gestión de Tareas en YARN (Yet Another Resource Negociator)
En YARN el cliente inicia un trabajo (job) a través del Resource Manager (Gestor de Recursos) que se encarga de gestionar los recursos necesarios. Cuando el Gestor de Recursos (Resource Manager) manda una tarea a un nodo esclavo éste necesita asignar una serie de sus recursos para la realización de la tarea. El Gestor de Recursos (Resource Manager) es el encargado de asignar los recursos a través de la creación de contenedores (container).
Un contenedor dedica una parte de la memoria y de la capacidad de la CPU del nodo esclavo para realizar la tarea. En un mismo nodo pueden convivir varios contenedores a un mismo tiempo y, por lo tanto, compartiendo una parte de los recursos del nodo.
YARN introduce también el concepto de Application Master (Maestro de Aplicaciones), un sistema que controla las aplicaciones, que es otra manera de llamar a los trabajos o las consultas que realizan los usuarios. Hay un Maestro de Aplicaciones por cada trabajo que se realiza. El maestro de aplicaciones también vive en un contenedor, es decir, también se le asignan unos recursos en el nodo esclavo.
El Maestro de Aplicaciones es el responsable de solicitar los recursos de los contenedores al Gestor de Recursos (Resource Manager). Una vez que éste asigna los recursos al contenedor de un nodo esclavo es cuando se empiezan a ejecutar las tareas. El NodeManager se encarga de supervisar el proceso y de validar el output resultante. Como ya he mencionado un mismo nodo esclavo puede gestionar varios contenedores a la vez pero cada tarea se ejecutará siempre en un contenedor distinto.
El Maestro de Aplicaciones corre en uno de los nodos esclavos, sin embargo recurre al Gestor de Recursos (ResourceManager) en el nodo maestro para solicitar recursos no sólo para el nodo en que se ejecuta, también se encarga de solicitar los recursos (contenedores) para aquellos nodos donde están alojados los bloques de los datos (DataNode) con los que va a trabajar a través del NodeManager correspondiente.
Este forma de llevar la computación a donde residen los datos es lo que se denomina Data Locality y es lo que permite a YARN minimizar la congestión de la red e incrementar el rendimiento de todo el sistema.
Las Tareas en YARN Paso a Paso
He intentado replicar un ejemplo con la arquitectura más parecida posible al que utilicé para explicar MapReduce, sin embargo, como veréis, hay algunas diferencias importantes. Sigamos paso a paso el proceso Map y Reduce en la arquitectura de YARN del diagrama:
- El cliente envía la aplicación (o el trabajo si se prefiere) al Gestor de Recursos (Resource Manager)
- Desde el Gestor de Recursos (Resource Manager) se crea un contenedor en uno de los nodos esclavos para alojar el Maestro de Aplicaciones (Application Master). Iniciamos el Maestro de Aplicaciones y éste establece una conexión con el Gestor de Recursos (Resource Manager) que mantendrá viva mientras dure todo el trabajo.
- El Maestro de Aplicaciones (Application Master) empezará entonces a solicitar los recursos que necesita al Gestor de Recursos (Resource Manager) para realizar el trabajo que se le ha encomendado
- EL Gestor de Recursos (Resource Manager) establecerá nuevos contenedores en los nodos esclavos en los que están alojados los datos necesarios. Para simplificar el ejemplo vamos a suponer que trabajamos con un fichero que sólo tiene dos bloques en HDFS (en azul en el diagrama) y que están alojados en los DataNode 1 y 3.
- El siguiente paso es que los NodeManagers de los nodos anteriores a petición del Maestro de Aplicaciones (Application Master) comienzan la realización de las tareas asignadas en los contenedores asignados. En este caso las tareas asociadas a la parte del proceso del Map.
- El resultado de estas tareas generará un nuevo set de datos intermedio con el que se empezará la parte del Reduce. Estos datos se almacenan localmente de manera temporal. Cuando digo de que se guarda localmente me refiero a que lo guarda fuera de HDFS (Hadoop Distributed File System).
- El Maestro de Aplicaciones (Application Master) volverá a solicitar al Gestor de Recursos (Resource Manager) un nuevo contenedor para procesar el trabajo de Reduce. Reduce puede correr en cualquier nodo del cluster.
- El Reducer leerá los datos intermedios generados por el Mapper y aplicará el proceso definido en la función. El resultado se guardará en HDFS
- El Maestro de Aplicaciones (Application Master) se comunica una vez más con el Gestor de Recursos (Resource Manager) para indicarle que el trabajo a finalizado con éxito. A partir de ahí se liberan los recursos que se habían dedicado a los contenedores devolviendo la capacidad ocupada al cluster.
- Por último el Maestro de Aplicaciones (Application Master) guardará el log del trabajo en el JobHistoryServer en el nodo maestro.
