3.2 · Hadoop y YARN: gestión de recursos del clúster

El problema: ¿quién reparte los recursos del clúster?

Un clúster de Big Data tiene cientos o miles de nodos, cada uno con CPU y memoria. Muchos usuarios y aplicaciones compiten por esos recursos al mismo tiempo. YARN (Yet Another Resource Negotiator), introducido en Hadoop 2.0, es la capa que se encarga de gestionar y asignar los recursos del clúster a las aplicaciones.

Antes de YARN, MapReduce hacía dos cosas a la vez: procesar datos y gestionar recursos. YARN separa ambas responsabilidades, lo que permitió que otros motores (Spark, Tez, Flink) corrieran sobre el mismo clúster Hadoop.

Arquitectura de YARN

YARN tiene cuatro componentes principales:

graph TD
CLI["Cliente (envía el job)"] --> RM
subgraph Maestro["Nodo maestro"]
  RM["ResourceManager<br/>(scheduler global)"]
end
subgraph N1["Nodo trabajador 1"]
  NM1["NodeManager"]
  AM["ApplicationMaster<br/>(contenedor 0)"]
  C1["Contenedor: tarea map"]
end
subgraph N2["Nodo trabajador 2"]
  NM2["NodeManager"]
  C2["Contenedor: tarea map"]
  C3["Contenedor: tarea reduce"]
end
RM --> NM1
RM --> NM2
AM --> C1
AM --> C2
AM --> C3
NM1 -. "heartbeat + estado" .-> RM
NM2 -. "heartbeat + estado" .-> RM

Ciclo de vida de un job en YARN

Así se ejecuta un job (por ejemplo, un MapReduce) paso a paso:

1. El cliente envía la aplicación al ResourceManager.
2. El RM busca un nodo con recursos libres y lanza ahí el ApplicationMaster en un primer contenedor.
3. El AM se registra ante el RM y negocia contenedores adicionales: “necesito 10 contenedores de 2 GB para mis tareas map”.
4. El RM, según su scheduler (FIFO, Capacity o Fair), asigna contenedores en distintos nodos.
5. El AM se comunica con los NodeManagers para lanzar las tareas dentro de esos contenedores.
6. Los NodeManagers reportan el estado (heartbeat) al RM; el AM vigila el progreso y reintenta tareas fallidas en otros nodos.
7. Al terminar, el AM se desregistra y libera los recursos.

Idea clave: el ResourceManager no sabe nada de la lógica de la aplicación (no sabe qué es un map o un reduce). Solo reparte recursos. La lógica del job vive en el ApplicationMaster, que es específico de cada framework (hay un AM de MapReduce, otro de Spark, etc.).

El ecosistema Hadoop

Alrededor de HDFS (almacenamiento) y YARN (recursos) creció un ecosistema de herramientas:

Hive es especialmente importante: permitió que perfiles de negocio (que conocen SQL pero no Java) consultaran petabytes de datos sin escribir MapReduce a mano.

Ejercicio: consulta Hive sobre el clúster

-- (1) Lanzar un job MapReduce de ejemplo (word count) desde bash:
-- hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \
--   wordcount /datos/entrada /datos/salida

-- (2) Consulta HiveQL: total vendido por región
CREATE EXTERNAL TABLE IF NOT EXISTS ventas (
region   STRING,
producto STRING,
monto    DOUBLE
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ','
LOCATION '/datos/ventas';

SELECT region, SUM(monto) AS total_ventas
FROM ventas
GROUP BY region
HAVING SUM(monto) > 1000000
ORDER BY total_ventas DESC;

Comprueba lo aprendido

Resumen

• YARN separa la gestión de recursos del procesamiento, permitiendo múltiples motores sobre el mismo clúster.
• ResourceManager (global) asigna recursos; NodeManager (por nodo) los administra localmente; ApplicationMaster (por aplicación) coordina el job; los contenedores son las unidades de CPU+RAM donde corren las tareas.
• Un job sigue el ciclo: cliente → RM → AM → negociación de contenedores → tareas en nodos → liberación.
• El ecosistema Hadoop incluye Hive (SQL), Pig (scripts ETL), HBase (NoSQL) y Sqoop (ingesta desde bases relacionales).

📚 Lecturas y fuentes