2.1 · HDFS: el sistema de archivos distribuido de Hadoop

¿Por qué necesitamos un sistema de archivos distribuido?

Un solo disco duro tiene tres límites: capacidad (no caben los petabytes), velocidad de lectura (leer 1 TB a 150 MB/s toma casi 2 horas) y confiabilidad (si el disco muere, los datos se pierden). La solución de la era Big Data es repartir los archivos entre muchas máquinas y coordinarlas para que el clúster entero se comporte como un único sistema de archivos gigante.

HDFS (Hadoop Distributed File System) es la implementación de referencia de esta idea, inspirada en el Google File System (GFS). Sus supuestos de diseño son clave para entender sus decisiones:

• El hardware barato falla con frecuencia: la tolerancia a fallos no es opcional, es el núcleo del diseño.
• Los archivos son enormes (de GB a TB), no millones de archivos pequeños.
• La carga de trabajo típica es lectura secuencial masiva (análisis), no acceso aleatorio.

Arquitectura: NameNode y DataNodes

HDFS sigue una arquitectura maestro/trabajador:

El NameNode no almacena datos de usuario: solo metadatos en memoria (con respaldo en disco mediante el FsImage y el EditLog). Esto lo hace muy rápido, pero también lo convierte en el punto crítico del clúster — por eso las versiones modernas añaden un NameNode en espera (standby) para alta disponibilidad.

Bloques de 128 MB y replicación

Cuando subes un archivo a HDFS, no se guarda como una unidad. Se divide en bloques de 128 MB (configurable; el valor histórico era 64 MB) y cada bloque se replica en 3 DataNodes distintos (factor de replicación por defecto).

¿Por qué bloques tan grandes, si en un disco local los bloques son de KB?

• Menos metadatos: con bloques de 128 MB, un archivo de 1 TB son solo ~8 000 bloques. El NameNode puede mantener todo el mapa en RAM.
• Menos costo de búsqueda: con discos magnéticos, el tiempo de seek domina; leer bloques grandes en secuencia amortiza ese costo.
• Paralelismo natural: cada bloque puede procesarse en una máquina distinta (esto lo aprovechará MapReduce en el módulo siguiente).

Y la replicación factor 3 garantiza que la pérdida de cualquier máquina — o incluso de un rack completo — no pierda datos. El NameNode detecta un DataNode caído (deja de recibir heartbeats) y ordena re-replicar sus bloques desde las copias sobrevivientes.

graph TD
C["Cliente"] -->|"1. Solicita ubicación de bloques"| NN["NameNode<br/>(metadatos en memoria)"]
NN -->|"2. Mapa: bloque B1 → DN1, DN2, DN5"| C
C -->|"3. Lee/Escribe bloques"| DN1["DataNode 1<br/>B1 · B2"]
C --> DN2["DataNode 2<br/>B1 · B3"]
C --> DN3["DataNode 3<br/>B2 · B3"]
DN1 -.->|"Heartbeats y reporte de bloques"| NN
DN2 -.-> NN
DN3 -.-> NN

Rack awareness: dónde poner las réplicas

Un clúster real se organiza en racks (bastidores) de servidores: las máquinas de un mismo rack comparten switch y fuente de alimentación, así que tienden a fallar juntas. HDFS aplica una política de colocación consciente del rack (rack awareness):

1. Réplica 1: en el nodo local del cliente (o uno aleatorio del clúster).
2. Réplica 2: en un nodo de otro rack (protege contra la caída del rack entero).
3. Réplica 3: en otro nodo del mismo rack que la réplica 2 (equilibrio entre tolerancia y tráfico de red entre racks).

Esta política tolera el fallo de un rack completo sin perder datos, sin pagar el costo de escribir las tres réplicas a través de switches inter-rack.

graph LR
subgraph RackA["Rack A"]
  A1["Nodo 1<br/>Réplica 1"]
  A2["Nodo 2"]
end
subgraph RackB["Rack B"]
  B1["Nodo 3<br/>Réplica 2"]
  B2["Nodo 4<br/>Réplica 3"]
end
W["Escritura del bloque"] --> A1
W --> B1
W --> B2

Write-once-read-many

HDFS no es un sistema de archivos de propósito general. Su modelo de acceso es write-once-read-many: un archivo se escribe una sola vez (en un único flujo, por un único escritor) y luego se lee muchas veces. No se puede editar un byte en medio del archivo; como mucho, se puede añadir al final (append).

¿Por qué esta restricción tan fuerte?

• Coherencia simple: si nadie modifica bloques existentes, todas las réplicas de un bloque son siempre idénticas. No hace falta un protocolo de concurrencia complejo entre cientos de escritores.
• Rendimiento: el análisis de Big Data lee datasets completos de forma secuencial; optimizar para ese caso rinde mucho más que soportar escrituras aleatorias.
• Streaming: la escritura se hace en pipeline (cliente → DataNode 1 → DataNode 2 → DataNode 3), lo que reparte el costo de red de las réplicas.

Consecuencia práctica: HDFS es ideal para data lakes, logs y datasets de análisis, pero no para una base de datos transaccional ni para archivos que cambian constantemente.

Ejercicio: simula la división en bloques y la replicación

def dividir_en_bloques(tamano_mb, bloque_mb=128):
  completos, resto = divmod(tamano_mb, bloque_mb)
  bloques = [bloque_mb] * completos
  if resto > 0:
      bloques.append(resto)
  return bloques

def asignar_replicas(bloques, datanodes, factor=3):
  asignacion = {}
  for i, _ in enumerate(bloques):
      replicas = []
      for r in range(factor):
          nodo = datanodes[(i + r) % len(datanodes)]
          replicas.append(nodo)
      asignacion[f"bloque_{i}"] = replicas
  return asignacion

bloques = dividir_en_bloques(300)
print("Bloques:", bloques)  # [128, 128, 44]

datanodes = ["dn1", "dn2", "dn3", "dn4", "dn5"]
for bloque, replicas in asignar_replicas(bloques, datanodes).items():
  print(f"{bloque}: {replicas}")

Comprueba lo aprendido

Resumen

• HDFS divide archivos grandes en bloques de 128 MB distribuidos entre muchos DataNodes.
• El NameNode guarda solo metadatos (mapa archivo → bloques → ubicaciones); los DataNodes guardan los datos y envían heartbeats.
• La replicación factor 3 con rack awareness (1 réplica local, 2 en otro rack) da tolerancia a fallos de nodos y de racks completos.
• El modelo write-once-read-many simplifica la coherencia y optimiza la lectura secuencial masiva, a costa de no permitir ediciones aleatorias.
• Ante un fallo, el NameNode re-replica automáticamente los bloques afectados desde las copias sobrevivientes.

📚 Lecturas y fuentes