Cabecera personalizada

El blog de Mikel Niño
Emprendimiento digital, startups, Big Data Analytics y nuevos modelos de negocio

YARN: la evolución interna de Apache Hadoop

Al revisar el origen y motivación en el desarrollo de Apache Spark, ya veíamos que su objetivo era proporcionar una mejor alternativa para determinados casos de uso de procesamiento de datos en los que el modelo MapReduce no era del todo eficiente, tal y como estaba concebido de inicio e implementado por ejemplo en Apache Hadoop. El propio Hadoop ha ido haciendo frente a alguna de estas limitaciones, dentro de su evolución en sus sucesivas versiones. El hito más significativo lo marca la revisión que a finales de 2011 sufre en una parte importante de su implementación del modelo MapReduce, con la mejora aportada por YARN (Yet Another Resource Negotiatior), su nuevo gestor interno de tareas y recursos.

En esta detallada entrada publicada en agosto de 2012 en el blog de la empresa Hortonworks, Arun Murthy (una de las personas más representativas en el desarrollo y evolución de Hadoop en sus últimas versiones) explica los detalles principales de YARN, los objetivos que persigue y cómo se relacionan con la implementación original de Apache Hadoop y sus limitaciones.

Uno de los aportes principales de dicha entrada, y que proporciona una visión muy clara de dónde entra en juego este nuevo desarrollo, es la división de la implementación que Apache Hadoop hace del modelo MapReduce en tres componentes principales: (1) el interfaz de programación (API) para crear una aplicación sobre el modelo MapReduce, (2) el framework que implementa por debajo las diferentes fases del modelo (la parte común a cualquier "map" o cualquier "reduce" que se programe), y (3) el "sistema" o infraestructura interna encargada de gestionar la distribución de las tareas concurrentes, los recursos de los diferentes nodos del clúster, etc. Es precisamente este último componente interno el que sufre una revisión completa con el desarrolllo de su nueva versión denominada YARN. La relevancia de este cambio en la desarrollo de Hadoop es tal que de hecho algunos se refieren a esta evolución como "NextGen MapReduce" o "MapReduce 2.0".

El principal cambio que implementa YARN es la revisión del componente interno JobTracker, encargado de la gestión de los diferentes nodos del clúster a los que se les asignan tareas (cada uno con su TaskTracker), así como de la supervisión de la disponibilidad de recursos, programación y seguimiento de las tareas, acciones de recuperación ante fallos, etc. La implementación hasta la fecha de dicho componente no ofrecía la suficiente flexibilidad como para adaptarse a otras necesidades de procesamiento de datos (por ejemplo procesos iterativos, uno de los problemas a los que también Apache Spark hace frente), o para "exprimir" al máximo la capacidad de cómputo de los nodos del clúster y reducir los tiempos de inactividad al asignarles tareas "map" o "reduce". La principal virtud de YARN, aparte de proporcionar una nueva implementación del JobTracker mejor preparada para ofrecer esa flexibilidad, es la de hacerlo sin alterar los otros componentes (API, framework) de la implementación del modelo MapReduce en Hadoop, facilitando así la compatibilidad con las aplicaciones anteriores.

No hay comentarios:

Publicar un comentario