Please enable JavaScript.
Coggle requires JavaScript to display documents.
YARN(Yet Another Resource Negotiator) (Anatomía de la ejecución de una…
YARN(Yet Another Resource Negotiator)
es
El sistema de administración de recursos del cluster de Hadoop
Puede ser usado
API de YARN
Poco usado por usuarios
Frameworks de computación distribuída que corren sobre YARN
como
Esconden los detalles del manejo de recursos a los usuarios
Anatomía de la ejecución de una aplicación YARN
Provee sus servicios core mediante dos tipos de demonios long-running
Resource manager
uno por cluster
Maneja los recursos del cluster
Node manager
Uno por nodo
lanza y monitorea
Contenedores
ejecutan
Procesos de aplicaciones con restricciones de recursos (Memoria, CPU, etc)
Pueden ser
Unix process
Linux cgroup
Pasos en "detalle"
Paso 1
Cliente contacta con el resourceManager y le solicita la ejecución de una app maestra
Paso 2
Resource manager encuentra un nodeManager que pueda lanzar la app maestra en un contenedor
Paso 3
Si la app maestra lo pide, el contenedor puede solicitar más recursos al ResourceManager
Paso 4
Usar los recursos del paso 3 para hacer computación distribuída.
YARN no provee un canal de comunicación entre las partes de una aplicación. Esa parte le corresponde a la aplicación misma.
Petición de recursos
se piden
Cantidad de recursos de computadores
acompañada de
Restricciones de localidad
Especifica cuál es el rack e incluso el nodo concreto que se solicita
Pueden no ser cumplidas
YARN tratará de usar un nodo "cercano"
Se pueden hacer en cualquier momento(dinámico)
como lo hace
MapReduce
a diferencia de
Spark
Esperanza de vida de la aplicación
existen tres tipos
Una aplicación por sesión(Spark)
Puede ser
Más eficiente
Una aplicación compartida por muchos usuarios(Apache Slider Impala).
Una aplicaciíon por Job(MapReduce)
Para crear aplicaciones YARN
Apache Slider
Apache Twill
conparación con
MapReduce 1
// Existen 2 API MapReduce (Vieja y nueva) y 2 implementaciones. Todas las combinaciones entre APIs e implementaciones son posibles
Tiene dos demonios para controlar la ejecución de procesos
JobTracker
Tareas
Monitorea y administra el progreso de las tareas
Programa tareas en los TaskTracker (Job Scheduling)
en YARN se divide en
Application master
Rsource manager
Timeline Server
TaskTracker
Tareas
Reporta el progreso de las tareas
Ejecuta tareas
En YARN
NodeManager
Tiene limitaciones en
Disponibilidad
EL status del jobtracker debe cambiar todo el tiempo
YARN
Usa dividey vencerás al partir el jobtracker
Utilización
Los taskTracker se definen desde el principio para correr mapper o reducers
En YARN
Los nodeManager pueden dinámicamente ser mapper o reducers
Escalabilidad
Tiene cuellos de botellas con 4.000 nodos y 40.000 tareas.
debido a
El jobtracker debe administrar jobs y tasks
YARN puede
Escalar a 10.000 nodos y 100.000 tareas
Multitenancy
Hadoop solo sirve para ejecutar MapReduce
En YARN
Existen otros frameworks de programación distribuída sobre YARN
Programación de tareas en YARN
mediante
Políticas(Schedulers) configurables
Capacity
implementa
Colas de jobs independiente para procesar varios usuarios
Ventajas
En cluster compartido
Desventajas
Retraso en los jobs grandes
Config
Es flexible mediante
Elasticidad de la cola
Una cola puede usar más recursos de los asignados inicialmente pero debe configurarse un límite para que no se coma el 100% de los recursos y haga que otras colas no puedan reiniciarse con facilidad
Fair Scheduler
implementa
"Balanceador de carga"
Ventajas
No preocuparse por la carga que hay que asignara cada job
Desventajas
Overhead al reasignar recursos
Configurable
Preemption
Mata contenedores injustos
Desventajas
Costo en la eficiencia global del cluster
Permite
Asignar aplicaciones en las colas
FIFO
Ventajas
Fácil de entender
No config
Los jobs grandes terminan más rápido
Desventajas
En Cluster compartido
Scheduling con retraso (Delay Scheduling)
Espera por localidad una unidad determinada de reportes desde los nodemanagers
Justicia en el recurso dominante (Dominant Resource Fairness)
Busca cuál es el recurso dominante de cada usuario y a partir de este computa una medida para compararse con los demás usuarios y en esa misma medida asignar los recursos
Ejemplo
100 CPU, 10 TB de memoria
App A
2 CPU, 300 GB
uso porcentual del cluster
App B
6 CPU, 100 GB
2%, 3%
1 more item...
6%, 1%
1 more item...