Salta el contingut

Hadoop, HDFS i YARN

Introducció

Apache Hadoop va néixer d'una necessitat real: Google havia publicat el 2003 el paper del Google File System (GFS) i el 2004 el de MapReduce, però el codi era propietari. Doug Cutting i Mike Cafarella van crear Hadoop el 2006 com a reimplementació open source d'aquests conceptes mentre treballaven en el motor de cerca Nutch. Yahoo va ser el primer gran usuari, utilitzant Hadoop per indexar la web amb un clúster de 10.000 màquines.

Avui, el 2025, l'ecosistema Hadoop ha evolucionat enormement. MapReduce ja no és l'eina de processament principal (Spark l'ha substituït àmpliament), però HDFS i YARN segueixen sent la base de moltes plataformes de Big Data on-premise. Aquesta pàgina cobreix el nucli d'Hadoop; les eines complementàries (Hive, HBase, Sqoop, Oozie, ZooKeeper) es tracten a L'ecosistema Hadoop.

HDFS: Hadoop Distributed File System

Arquitectura

HDFS és un sistema de fitxers distribuït dissenyat per emmagatzemar fitxers molt grans de forma fiable a través d'un clúster de màquines commodity (ordinadors de baix cost estàndard).

graph TB
    subgraph Client
        C[Client HDFS]
    end

    subgraph Master
        NN[NameNode\nMetadades\nEspai de noms\nDirectori de blocs]
        SN[Secondary NameNode\nCheckpoints\nNO es backup!]
        NN -.->|checkpoint periodic| SN
    end

    subgraph Workers
        DN1[DataNode 1\nBloc A1\nBloc B2\nBloc C1]
        DN2[DataNode 2\nBloc A2\nBloc B1\nBloc C3]
        DN3[DataNode 3\nBloc A3\nBloc B3\nBloc C2]
        DN4[DataNode 4\nBloc A1 rep\nBloc B2 rep]
    end

    C -->|1. On estic bloc X?| NN
    NN -->|2. DataNode 2, port 50010| C
    C -->|3. Llegir dades directament| DN2
    DN1 -.->|heartbeat cada 3s| NN
    DN2 -.->|heartbeat cada 3s| NN
    DN3 -.->|heartbeat cada 3s| NN

Components principals:

NameNode: el "cervell" del clúster HDFS. Emmagatzema tots els metadades del sistema de fitxers: l'arbre de directoris, els permisos, i la llista de blocs que formen cada fitxer i quins DataNodes els contenen. NO emmagatzema les dades reals. El NameNode és l'únic punt de fallada (SPOF) en la configuració bàsica, per la qual cosa Hadoop 2+ suporta High Availability amb dos NameNodes (actiu i de reserva).

DataNode: on es guarden físicament els blocs de dades. Cada DataNode envia un "heartbeat" al NameNode cada 3 segons per indicar que està viu. Si el NameNode no rep heartbeat durant 10 minuts, considera el DataNode mort i replica els seus blocs en altres DataNodes per mantenir el factor de replicació.

Secondary NameNode: NOM és un backup del NameNode! És un servei que periòdicament fa un checkpoint de l'estat del NameNode, fusionant el fitxer fsimage (estat del sistema de fitxers) amb el edits log (canvis recents) per evitar que el log creixi indefinidament.

Blocs i replicació

Per defecte, HDFS divideix cada fitxer en blocs de 128 MB (configurable) i emmagatzema 3 còpies de cada bloc en DataNodes diferents (factor de replicació 3). La política de placement per defecte intenta: - Posar la primera còpia al DataNode on s'escriu - La segona còpia en un rack diferent - La tercera còpia en un altre DataNode del segon rack

Això garanteix que si falla tot un rack (tall de corrent, error de switch), les dades segueixen disponibles.

Càlcul d'espai:

Espai físic necessari = Mida de les dades × Factor de replicació

Exemple:
- Dataset: 10 TB
- Factor replicació: 3
- Espai físic necessari: 10 TB × 3 = 30 TB
- Amb un 20% de marge operatiu: 36 TB

Operacions HDFS bàsiques

# Llistar el directori arrel
hdfs dfs -ls /

# Crear un directori
hdfs dfs -mkdir -p /user/alumne/dades

# Pujar un fitxer local a HDFS
hdfs dfs -put fitxer_local.csv /user/alumne/dades/

# Descarregar un fitxer d'HDFS
hdfs dfs -get /user/alumne/dades/fitxer_local.csv ./

# Veure el contingut d'un fitxer (com cat)
hdfs dfs -cat /user/alumne/dades/fitxer_local.csv | head -20

# Copiar dins HDFS
hdfs dfs -cp /user/alumne/dades/a.csv /user/alumne/backup/

# Esborrar un fitxer (va a la paperera per defecte)
hdfs dfs -rm /user/alumne/dades/fitxer_vell.csv

# Esborrar un directori i tot el seu contingut
hdfs dfs -rm -r /user/alumne/dades_velles/

# Veure l'ús de disc
hdfs dfs -du -s -h /user/alumne/

# Informació del sistema de fitxers
hdfs dfsadmin -report

# Comprovar l'estat del sistema (safe mode, blocs sub-replicats)
hdfs dfsadmin -safemode get

# Balancejar les dades entre DataNodes
hdfs balancer -threshold 10

Safe Mode

En iniciar-se, el NameNode entra en "safe mode" mentre verifica que té prou blocs reportats pels DataNodes. En safe mode, HDFS és de lectura i no permet modificacions. Si un clúster es queda en safe mode indefinidament, pot indicar un problema de DataNodes amb blocs perduts.

HDFS en alta disponibilitat

Per a entorns de producció, HDFS HA usa: - Dos NameNodes: un actiu (active) i un standby - JournalNodes: un quorum de nodes (mínim 3) que emmagatzemen el log d'edicions compartit - ZooKeeper: per a l'elecció automàtica del NameNode actiu i el failover

MapReduce: el paradigma original

MapReduce és un model de programació per al processament distribuït de grans datasets. Inspirat en les funcions funcionals map i reduce, simplifica el processament distribuït amagant tota la complexitat de la distribució, la tolerància a fallades i la gestió de la xarxa.

Com funciona

Dataset gran (TB):
[record1, record2, ..., record_N]

FASE MAP (paral·lela, un mapper per split):
Mapper 1: record1 → [(clau_A, val1), (clau_B, val2)]
Mapper 2: record2 → [(clau_A, val3), (clau_C, val4)]
Mapper N: record_N → [(clau_B, val5), (clau_C, val6)]

FASE SHUFFLE & SORT (framework automàtic):
Agrupa per clau:
clau_A → [val1, val3]
clau_B → [val2, val5]
clau_C → [val4, val6]

FASE REDUCE (un reducer per clau o grup):
Reducer 1: clau_A, [val1, val3] → resultat_A
Reducer 2: clau_B, [val2, val5] → resultat_B
Reducer 3: clau_C, [val4, val6] → resultat_C

Exemple: WordCount en Python (Hadoop Streaming)

#!/usr/bin/env python3
# mapper.py - compta les paraules d'un text

import sys

for linia in sys.stdin:
    linia = linia.strip()
    paraules = linia.split()
    for paraula in paraules:
        # Emet (paraula, 1) per a cada paraula
        print(f"{paraula.lower()}\t1")

#!/usr/bin/env python3
# reducer.py - suma les ocurrències de cada paraula

import sys

paraula_actual = None
comptador = 0

for linia in sys.stdin:
    linia = linia.strip()
    paraula, count = linia.split('\t', 1)
    count = int(count)

    if paraula == paraula_actual:
        comptador += count
    else:
        if paraula_actual is not None:
            print(f"{paraula_actual}\t{comptador}")
        paraula_actual = paraula
        comptador = count

# Emet l'última paraula
if paraula_actual:
    print(f"{paraula_actual}\t{comptador}")

# Executar el job MapReduce amb Hadoop Streaming
hadoop jar $HADOOP_HOME/share/hadoop/tools/lib/hadoop-streaming-*.jar \
    -input /user/alumne/text_entrada/ \
    -output /user/alumne/wordcount_resultat/ \
    -mapper mapper.py \
    -reducer reducer.py \
    -file mapper.py \
    -file reducer.py

Quan NO usar MapReduce

MapReduce té limitacions importants que el fan inadequat per a molts casos d'ús moderns:

  • Iteracions: algoritmes com k-means o PageRank requereixen múltiples passades sobre les dades. Cada iteració MapReduce escriu i llegeix d'HDFS, introduint una latència enorme.
  • Interactivitat: no és possible fer una consulta ad-hoc amb MapReduce en segons; cada job triga minuts.
  • Streaming: MapReduce és inherentment batch; no pot processar dades en temps real.
  • Complexitat de programació: expressar lògica complexa en parells Map/Reduce és laboriós.

Per a tots aquests casos, Apache Spark (que llegeix de HDFS però processa en memòria) és la solució actual.

YARN: Yet Another Resource Negotiator

YARN és el sistema de gestió de recursos d'Hadoop 2+. Desacobla la gestió de recursos del model de programació, permetent executar no només jobs MapReduce sinó qualsevol framework de computació distribuïda (Spark, Flink, Tez...).

graph TB
    subgraph YARN
        RM[ResourceManager\nGestiona recursos globals\nPlanífica aplicacions]
        NM1[NodeManager 1\nGestiona contenidors\nMonitora recursos]
        NM2[NodeManager 2\nGestiona contenidors\nMonitora recursos]
        NM3[NodeManager 3\nGestiona contenidors\nMonitora recursos]
    end

    subgraph App["Aplicacio Spark"]
        AM[ApplicationMaster\ns'executa en un contenidor\nNegoci recursos amb RM]
        E1[Executor 1]
        E2[Executor 2]
    end

    Client --> RM
    RM --> NM1
    RM --> NM2
    RM --> NM3
    NM1 --> AM
    NM2 --> E1
    NM3 --> E2
    AM -->|sol·licita contenidors| RM

Conceptes clau YARN:

  • Container: unitat de recursos assignada (CPU + memòria)
  • ApplicationMaster: un procés per aplicació que negocia els recursos amb el ResourceManager
  • NodeManager: el "daemon" que s'executa a cada worker node i gestiona els contenidors locals

Continuació

Aquest tema continua a L'ecosistema Hadoop (Hive, HBase, Sqoop, Oozie, ZooKeeper i la comparativa amb Spark/Flink), a Apache Spark per al motor de processament principal, a Apache NiFi i Apache Kafka per a la ingestió, i a Big Data al núvol per als serveis gestionats (AWS EMR, Dataproc, HDInsight, Databricks).

RA2 | Mòdul 5075 Big Data Aplicat | Institut Sa Palomera (Blanes) | Curs IABD 2026-2027