hadoop - official - ¿Qué beneficio adicional aporta Yarn al mapa existente?

hadoop para windows

Question

El hilo se diferencia en su capa de infraestructura del mapa original y reduce la arquitectura de la siguiente manera:

En YARN, el rastreador de trabajos se divide en dos demonios diferentes llamados Resource Manager y Node Manager (específico del nodo). El administrador de recursos solo administra la asignación de recursos a los diferentes trabajos, aparte de incluir un programador que solo se encarga de los trabajos de programación sin preocuparse por ninguna supervisión o actualizaciones de estado. Los diferentes recursos, como la memoria, el tiempo de CPU, el ancho de banda de la red, etc., se colocan en una unidad llamada el Resource Container . Hay diferentes AppMasters ejecutan en diferentes nodos que hablan con varios de estos contenedores de recursos y, en consecuencia, actualizan el Administrador de nodos con los detalles de monitoreo / estado.

Quiero saber que ¿de qué manera el uso de este tipo de enfoque aumenta el rendimiento desde la perspectiva de reducir el mapa? Además, si hay algún contenido definitivo sobre la motivación detrás de Yarn y sus beneficios sobre la implementación existente de Map-reduce, indíqueme el mismo.

Answer 1

Estos son algunos de los artículos ( 1 , 2 , 3 ) sobre YARN. Estos hablan de los beneficios de usar YARN.

YARN es más general que MR y debería ser posible ejecutar otros modelos informáticos como BSP además de MR. Antes de YARN, se requería un grupo separado para MR, BSP y otros. Ahora pueden coexistir en un solo clúster, lo que lleva a un mayor uso del clúster. Here son algunas de las aplicaciones portadas a YARN.

Desde la perspectiva de MapReduce en MR heredado, hay ranuras separadas para las tareas de Map y Reduce, pero en YARN no hay un propósito fijo para un contenedor. El mismo contenedor se puede utilizar para una tarea de mapa, una tarea de reducción, una tarea BSP de Hama u otra cosa. Esto conduce a una mejor utilización.

Además, hace posible ejecutar diferentes versiones de Hadoop en el mismo clúster, lo que no es posible con MR heredado, lo que facilita el mantenimiento desde un punto.

Here son algunos de los enlaces adicionales para YARN. Además, Hadoop: The Definitive Guide, 3rd Edition tiene una sección completa dedicada a YARN.

Para su información, había sido un poco controversial desarrollar YARN en lugar de usar algunos de los marcos que habían estado haciendo algo similar y habían estado funcionando durante años con éxito con los errores solucionados.

Answer 2

No creo que Yarn acelere el marco de MR existente. Al observar la arquitectura, podemos ver que el sistema ahora es más modular, pero la modularidad generalmente contradice un mayor rendimiento.
Se puede afirmar que YARN no tiene nada que ver con MapReduce. MapReduce se convirtió en una de las aplicaciones YARN. Puede verlo como un movimiento desde un programa integrado a un sistema operativo integrado con un programa dentro de él.
Al mismo tiempo, Yarn abre la puerta a diferentes implementaciones de MR con diferentes marcos. Por ejemplo, si asumimos que nuestro conjunto de datos es más pequeño que la memoria del clúster, podemos obtener un rendimiento mucho mejor. Creo que http://www.spark-project.org/ es uno de esos ejemplos
Para resumir: Yarn no mejora el MR existente, pero permitirá que otras implementaciones de MR sean mejores en todos los aspectos.

Answer 3

Parece que este enlace podría ser lo que está buscando: 1 .

Mi entendimiento es que YARN se supone que es más genérico. Puede crear sus propias aplicaciones YARN que negocian directamente con el Administrador de recursos para los recursos ( 1 ), y MapReduce es solo uno de los varios administradores de aplicaciones que ya existen ( Here ).

Answer 4

Todas las respuestas anteriores cubren gran cantidad de información: estoy simplificando toda la información de la siguiente manera:

MapReduce: YARN: 1. It is Platform plus Application It is a Platform in Hadoop 2.0 and in Hadoop 1. 0 and it is only of doesn''t exist in Hadoop 1.0 the applications in Hadoop 2.0 2. It is single use system i.e., It is multi purpose system, We can run We can run MapReduce jobs only. MapReduce, Spark, Tez, Flink, BSP, MPP, MPI, Giraph etc... (General Purpose) 3. JobTracker scalability i.e., Both Resource Management and Both Resource Management and Application Management gets separated & Job Management managed by RM+NM, Paradigm specific AMs respectively. 4. Poor Resource Management Flexible Resource Management i.e., system i.e., slots (map/reduce) containers. 5. It is not highly available High availability and reliability. 6. Scaled out up to 5000 nodes Scaled out 10000 plus nodes. 7. Job->tasks Application -> DAG of Jobs -> tasks 8. Classical MapReduce = MapReduce Yarn MapReduce = MapReduce API + API + MapReduce FrameWork MapReduce FrameWork + YARN System + MapReduce System So MR programs which were written over Hadoop 1.0 run over Yarn also with out changing a single line of code i.e., backward compatibility.

Answer 5

Veamos los inconvenientes de Hadoop 1.0, que han sido resueltos por Hadoop 2.0 con la adición de Yarn.

1. Problema de escalabilidad : Job Tracker se ejecuta en una sola máquina aunque tenga miles de nodos en el clúster de Hadoop. Las responsabilidades del Rastreador de trabajos: administración de recursos, programación y supervisión de trabajos y tareas. Dado que todos estos procesos se ejecutan en un solo nodo, este modelo no es escalable.
2. Problema de disponibilidad (punto único de falla) : Job Tracker es un punto único de falla.
3. Utilización de recursos : debido a la cantidad predefinida de ranuras de tareas de Map & Reduce, los recursos no se utilizan correctamente. Cuando todos los nodos de Mapper están ocupados, los nodos Reductor están inactivos y no se pueden utilizar para procesar las tareas de Mapper.
4. Integración estrecha con el marco Map Reducir : Hadoop 1.x puede ejecutar trabajos de Reducción de mapa solamente. No existe soporte para trabajos que no sean Map Reduce.

Ahora solo se eliminó el cuello de botella de Job Tracker con la arquitectura YARN en Hadoop 2.x

La idea fundamental de YARN es dividir las funcionalidades de la administración de recursos y la programación / supervisión de trabajos en demonios separados. La idea es tener un ResourceManager (RM) global y un ApplicationMaster (AM) por aplicación. Una aplicación es un solo trabajo o un DAG de trabajos.

El ResourceManager tiene dos componentes principales: Scheduler y ApplicationsManager .

El Programador es responsable de asignar recursos a las diversas aplicaciones en ejecución sujetas a restricciones familiares de capacidades, colas, etc. El Programador es un programador puro en el sentido de que no realiza monitoreo ni seguimiento del estado de la aplicación.

El Administrador de Aplicaciones es responsable de aceptar envíos de trabajos, negociar el primer contenedor para ejecutar ApplicationMaster and provides the service for restarting the ApplicationMaster container on failure. específico de la ApplicationMaster and provides the service for restarting the ApplicationMaster container on failure.

El ApplicationMaster por aplicación tiene la responsabilidad de negociar contenedores de recursos apropiados desde el Programador, hacer un seguimiento de su estado y monitorear el progreso.

Ahora ventajas de YARN.

1. Se han resuelto los problemas de escalabilidad .
2. No hay un solo punto de fracaso . Todos los componentes están altamente disponibles.
3. La utilización de recursos se ha mejorado con la utilización adecuada de Map y reducir las ranuras.
4. No se pueden enviar trabajos sin reducción de mapa