---
marp: true
theme: bda
paginate: true
size: 16:9
title: M01 · Almacenamiento y ecosistema de datos
description: Introducción a Hadoop, HDFS y las decisiones de almacenamiento
---
<!-- _class: lead -->

<div class="presentation-title">Almacenamiento y ecosistema de datos</div>

## M01 · Introducción a Hadoop y HDFS

**Big Data Aplicado · CE IA y Big Data**

Josep Garcia · 2026/2027

<!--
NOTAS DOCENTE:
Presentación de apertura del módulo. La explicación detallada y los comandos están en los ocho bloques de M01. Recuperar rutas, permisos, usuarios y contenedores trabajados en M00.
-->

---

## El problema de partida

Una empresa acumula registros de ventas y actividad durante años.

El histórico crece y calcular los totales diarios tarda demasiado.

> ¿Necesita una máquina mayor, repartir el trabajo o cambiar cómo guarda los datos?

<!--
NOTAS DOCENTE:
Recoger hipótesis. No hay una solución automática: antes de elegir tecnología debemos identificar tamaño, frecuencia de llegada, patrón de consulta y tiempo de respuesta necesario.
-->

---

## Big Data y capacidad del sistema

El reto aparece cuando el volumen, la velocidad de llegada o la diversidad de los datos dificultan su tratamiento con los recursos disponibles.

**No existe una cifra universal de gigabytes que obligue a usar Hadoop.**

El sistema debe almacenar los datos y procesarlos dentro del tiempo que necesita el caso de uso.

<!--
NOTAS DOCENTE:
Evitar la equivalencia Big Data = Hadoop. Una base de datos relacional o un único equipo pueden resolver muchos casos si el diseño y los recursos son adecuados.
-->

---

## Escalabilidad vertical y horizontal

| Estrategia | Cambio | Condición |
|---|---|---|
| Vertical | Más CPU, RAM o disco en un equipo | Depende de sus límites y coste |
| Horizontal | Más equipos que colaboran | Requiere distribuir datos y trabajo |

Un clúster es un conjunto de nodos que cooperan para prestar un servicio o ejecutar tareas.

<!--
NOTAS DOCENTE:
Commodity hardware significa equipos de propósito general, no una garantía de precio bajo. La red, operación y redundancia también cuestan.
-->

---

## Paralelismo y tiempo de ejecución

Repartir una tarea puede reducir su duración si las partes pueden trabajar en paralelo.

El tiempo también incluye coordinación, transferencia de datos y combinación de resultados.

> Una tarea que tarda 10 minutos en un nodo no tiene por qué tardar 1 minuto en diez nodos.

<!--
NOTAS DOCENTE:
Ejemplo oral: dividir un archivo entre diez trabajadores exige preparar las partes y reunir las respuestas. Una tarea pequeña puede tardar más al distribuirla. No presentar una estimación inventada como medición.
-->

---

## Componentes de Hadoop

| Componente | Responsabilidad |
|---|---|
| Hadoop Common | Bibliotecas y utilidades compartidas |
| HDFS | Almacenamiento distribuido de archivos |
| YARN | Asignación de recursos a aplicaciones |
| MapReduce | Procesamiento por lotes mediante tareas |

Hive y Spark pertenecen al ecosistema y aportan otras formas de trabajar con los datos.

<!--
FUENTE: https://hadoop.apache.org/docs/r3.4.1/
NOTAS DOCENTE:
Separar claramente YARN y MapReduce. Hive es un proyecto del ecosistema, no uno de los cuatro módulos del núcleo de Hadoop.
-->

---

## Almacenamiento, recursos y procesamiento

| Pregunta | Componente |
|---|---|
| ¿Dónde están los archivos y sus bloques? | HDFS |
| ¿Qué aplicación recibe CPU y memoria? | YARN |
| ¿Cómo se transforma y agrupa la entrada? | MapReduce |
| ¿Cómo expreso una consulta analítica en SQL? | Hive |

Un DataNode guarda bloques. Un NodeManager administra recursos de ejecución. Pueden compartir máquina y mantienen funciones distintas.

<!--
FUENTES:
https://hadoop.apache.org/docs/r3.4.1/
M01/03-yarn-y-ejecucion-de-jobs.md
-->

---

## Patrones de acceso y elección de sistema

| Necesidad | Encaje inicial |
|---|---|
| Recorrer archivos grandes para obtener agregados | HDFS y un motor de procesamiento |
| Actualizar filas y resolver consultas puntuales | Base de datos como PostgreSQL |
| Compartir archivos entre motores independientes | Almacenamiento de objetos S3/MinIO |

La elección depende de cómo se escriben y consultan los datos.

<!--
FUENTES:
https://hadoop.apache.org/docs/r3.4.1/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
M01/05-formatos-de-datos.md
M01/06-postgresql.md
NOTAS DOCENTE:
Son patrones orientativos, no exclusividades ni garantías de rendimiento. Una solución puede combinar capas. Las comparaciones detalladas llegan durante M01.
-->

---

## HDFS y archivos grandes

HDFS divide un archivo en bloques y distribuye sus copias entre DataNodes.

Su diseño favorece **lecturas de gran caudal** y archivos que se escriben para leerse muchas veces.

Las actualizaciones arbitrarias dentro de un archivo y las peticiones de muy baja latencia no son su patrón principal.

<!--
FUENTE: https://hadoop.apache.org/docs/r3.4.1/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
NOTAS DOCENTE:
Definir caudal frente a latencia. HDFS admite append y truncate. Muchos archivos pequeños aumentan la carga de metadatos, aunque cada uno no reserve físicamente un bloque completo de 128 MiB.
-->

---

## NameNode, DataNode y cliente

| Participante | Función |
|---|---|
| NameNode | Mantiene nombres, permisos y ubicaciones de bloques |
| DataNode | Guarda bloques y atiende lecturas y escrituras |
| Cliente HDFS | Consulta ubicaciones y transfiere datos |

**Los bytes de usuario circulan entre el cliente y los DataNodes.**

<!--
FUENTE: https://hadoop.apache.org/docs/r3.4.1/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
NOTAS DOCENTE:
Evitar la pareja maestro/esclavo como explicación única. Usar los nombres y funciones concretas de los servicios.
-->

---

## Lectura de un archivo

1. El cliente pide al NameNode las ubicaciones de sus bloques.
2. El NameNode devuelve las ubicaciones disponibles.
3. El cliente obtiene los bytes directamente de los DataNodes.
4. Si una réplica falla, el cliente puede intentar otra disponible.

> ¿Qué componente conoce la ruta del archivo y cuál conserva sus bytes?

<!--
FUENTE: https://hadoop.apache.org/docs/r3.4.1/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
NOTAS DOCENTE:
Respuesta oral: NameNode y DataNodes. Una lectura puede necesitar varios DataNodes si el archivo contiene varios bloques. Puede haber reintentos y esperas ante un fallo.
-->

---

## Bloques y replicación

Archivo lógico de **300 MiB** con bloques de hasta 128 MiB y factor de replicación 3.

| Bloque | DataNode A | DataNode B | DataNode C |
|---|---:|---:|---:|
| 1 | 128 MiB | 128 MiB | 128 MiB |
| 2 | 128 MiB | 128 MiB | 128 MiB |
| 3 | 44 MiB | 44 MiB | 44 MiB |

Cada fila representa un bloque lógico y sus tres copias.

<!--
FUENTES:
M01/01-hadoop-y-hdfs.md
https://hadoop.apache.org/docs/r3.4.1/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
NOTAS DOCENTE:
La tabla muestra la colocación final de las copias, no los mensajes de escritura. El tamaño de bloque y la replicación son configurables. No hay tres archivos distintos en el espacio de nombres.
-->

---

## Tamaño lógico y espacio replicado

| Magnitud | Ejemplo |
|---|---:|
| Tamaño del archivo | 300 MiB |
| Bloques lógicos | 3 |
| Copias de bloques con réplica 3 | 9 |
| Datos replicados, sin otras sobrecargas | Aproximadamente 900 MiB |

El último bloque contiene 44 MiB. No reserva 128 MiB de datos útiles.

<!--
FUENTE: M01/01-hadoop-y-hdfs.md
NOTAS DOCENTE:
Mantener MiB y no mezclar con MB. El espacio lógico presenta un solo archivo. El coste real incluye también metadatos y otras sobrecargas.
-->

---

## Fallos y límites de la replicación

| Situación | Alcance de la protección |
|---|---|
| Cae un DataNode | Otra copia disponible puede atender la lectura |
| Cae el único NameNode | Hace falta recuperar el servicio de metadatos |
| Se borra un archivo en HDFS | El borrado afecta a sus réplicas |
| Falla el portátil del laboratorio | Caen los contenedores que dependen de él |

La réplica conserva copias disponibles. Las copias externas cubren otros riesgos.

<!--
FUENTES:
https://hadoop.apache.org/docs/r3.4.1/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
M01/01-hadoop-y-hdfs.md
NOTAS DOCENTE:
Evitar afirmar disponibilidad permanente o recuperación inmediata. Una réplica debe seguir siendo accesible y válida. Un NameNode con alta disponibilidad necesita una arquitectura adicional.
-->

---

## Secondary NameNode y checkpoints

El NameNode registra el espacio de nombres en `fsimage` y los cambios recientes en `edits`.

El Secondary NameNode consolida ambos en un **checkpoint de metadatos**.

La sustitución automática de un NameNode requiere una arquitectura de alta disponibilidad con servicios activos y en espera.

<!--
FUENTE: https://hadoop.apache.org/docs/r3.4.1/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html
NOTAS DOCENTE:
Recuperar la analogía del contable asistente de los apuntes. El Secondary NameNode no atiende clientes ni se convierte automáticamente en NameNode activo.
-->

---

## Integridad de bytes y calidad del contenido

Un archivo puede conservar exactamente sus bytes y contener un precio incorrecto.

| Mecanismo | Qué aporta |
|---|---|
| Checksum | Detección de corrupción de bytes |
| Replicación | Copias de bloques para mantener disponibilidad |
| Snapshot | Vista de un estado anterior del directorio |
| Regla de calidad | Validación del significado de los datos |

<!--
FUENTES: M01/02-operaciones-administracion-hdfs.md y M04.md
NOTAS DOCENTE:
M01 introduce integridad y recuperación. M04 desarrolla validación de esquema, nulos, duplicados y rangos. Un snapshot depende del mismo sistema de almacenamiento.
-->

---

## Local, pseudodistribuido y distribuido

| Modo Hadoop | Ejecución | Almacenamiento |
|---|---|---|
| Local | Un trabajo en una JVM | Archivos locales |
| Pseudodistribuido | Demonios separados en una máquina | HDFS |
| Distribuido | Servicios repartidos entre nodos | HDFS distribuido |

Una JVM ejecuta Java. Un contenedor aísla procesos. Un nodo lógico puede compartir equipo físico con otros nodos.

<!--
FUENTE: https://hadoop.apache.org/docs/r3.4.1/hadoop-project-dist/hadoop-common/SingleCluster.html
NOTAS DOCENTE:
No confundir el modo local de Hadoop con Spark Standalone, que es el nombre de un gestor de clúster de Spark. No desplegar aquí una cuarta práctica.
-->

---

## Progresión del laboratorio

| Etapa | Qué construiremos | Qué observaremos |
|---|---|---|
| Instalación manual | HDFS pseudodistribuido en un contenedor | Cuenta, XML, SSH interno y procesos |
| Operaciones y administración | Mismo contenedor del bloque 01 | Integridad, papelera y snapshots |
| Varios servicios | Tres DataNodes y servicios YARN en `modulo01/hadoop/` | Réplicas, tareas y fallo de un trabajador |
| Hive | HiveServer2 y Derby en `modulo01/hive/`, sobre el HDFS del clúster | Consultas SQL, formatos y ciclo de vida de tablas |

**Hadoop 3.4.1 y Java 11** en este laboratorio.

Los bloques 03, 04 y 07 se ejecutan desde `modulo01/`. [Repositorio del laboratorio](https://github.com/josepgarcia/BigDataAplicadoLab_2627/tree/main/modulo01)

<!--
FUENTES: M01/01-hadoop-y-hdfs.md y PLANIFICACION/M01_DOCENTE.md
NOTAS DOCENTE:
Los contenedores comparten anfitrión y almacenamiento físico. La prueba demuestra distribución lógica y mecanismos, no capacidad añadida real ni alta disponibilidad física. SSH corresponde al arranque clásico de la primera práctica.
-->

---

## MapReduce y procesamiento por lotes

1. **Map:** transforma registros en pares de clave y valor.
2. **Shuffle y ordenación:** reúne los valores de cada clave.
3. **Reduce:** calcula un resultado por grupo.

Ejemplo: obtener el total de ventas de cada categoría.

YARN asigna recursos para ejecutar la aplicación. MapReduce define cómo se procesa la entrada.

<!--
FUENTE: M01/04-mapreduce.md
NOTAS DOCENTE:
Explicación de apertura. El recorrido de claves, los scripts Python y la ejecución Hadoop Streaming se desarrollan en el bloque 04.
-->

---

## Spark en el recorrido del curso

Spark es un motor de procesamiento con operaciones que pueden combinar varias etapas y reutilizar datos en memoria cuando resulta adecuado.

Puede trabajar con HDFS y ejecutarse con distintos gestores de clúster.

En **M03** trabajaremos DataFrames, Spark SQL y Structured Streaming.

<!--
FUENTES:
https://spark.apache.org/docs/4.0.2/
M01/04-mapreduce.md
NOTAS DOCENTE:
Spark no es MapReduce en tiempo real ni exige cargar todos los datos en RAM. El modo habitual de Structured Streaming es microbatch. No convertir esta comparación en una práctica adelantada de M03.
-->

---

## Formatos, objetos y tablas analíticas

| Concepto | Ejemplo | Función |
|---|---|---|
| Formato de archivo | Parquet | Organiza los datos dentro del archivo |
| Almacenamiento de objetos | S3/MinIO | Guarda objetos mediante claves |
| Data lake | Histórico organizado | Reúne datos para distintos usos |
| Formato de tabla | Iceberg | Añade metadatos y snapshots de tabla |

Un lakehouse combina almacenamiento de un data lake con gestión de tablas analíticas.

<!--
FUENTE: M01/05-formatos-de-datos.md
NOTAS DOCENTE:
MinIO por sí solo no proporciona transacciones de tabla. Iceberg necesita catálogo y motor compatible. En M01 lo comparamos conceptualmente. Su uso práctico queda para M03.
-->

---

## PostgreSQL y Hive

| PostgreSQL | Hive |
|---|---|
| Base de datos relacional | Capa SQL analítica sobre archivos |
| Transacciones y restricciones | Esquemas y ubicaciones en un metastore |
| Consultas y actualizaciones de filas | Consultas sobre históricos y particiones |

Con viajes reales de Nueva York, compararemos una consulta por zona antes y después de indexarla y un informe diario de toda la ciudad.

<!--
FUENTES: M01/06-postgresql.md y M01/07-hive.md
NOTAS DOCENTE:
PostgreSQL también realiza analítica. La tabla resume el papel asignado en este curso, no límites exclusivos de los productos. Desde `modulo01/`, usar `make up`, `make hive-up` y `make hive-beeline`. Hive ejecuta MapReduce local dentro de HiveServer2.
-->

---

## Recorrido de M01

1. Hadoop, arquitectura e instalación manual de HDFS
2. Operaciones, permisos e integridad
3. YARN y ejecución de trabajos MapReduce
4. Formatos, objetos y lakehouse
5. PostgreSQL y Hive
6. Decisión de almacenamiento reutilizable en M02

24 horas curriculares · 20 sesiones presenciales previstas

<!--
FUENTES: M01.md y PLANIFICACION/M01_DOCENTE.md
NOTAS DOCENTE:
Este recorrido agrupa los ocho documentos del módulo. No exige completar todo el banco de ejercicios ni convierte la diferencia horaria en deberes. Las actividades de clase son formativas salvo anuncio expreso de actividad calificable.
-->

---

## Proyecto

Al terminar M01 documentaremos una decisión de almacenamiento para el histórico de criptomonedas.

La propuesta justificará formatos, organización y capas según los patrones de acceso.

Las evidencias de las prácticas permitirán continuar con la ingesta de M02 y el procesamiento de M03.

<!--
FUENTE: M01/08-proyecto-cripto.md
NOTAS DOCENTE:
M01-PROY-01 es un entregable acumulativo de transferencia. No obliga a desplegar todas las tecnologías ni sustituye al proyecto conjunto del 26/04 al 28/05/2027. Respetar el futuro contrato de M02.
-->

---

## Preguntas para conectar ideas

1. ¿Qué función cumplen HDFS, YARN y MapReduce?
2. ¿Por dónde circulan los bytes cuando un cliente lee un archivo?
3. ¿Qué riesgo permanece con tres DataNodes en un portátil?
4. ¿Qué necesitas saber antes de elegir dónde guardar un histórico?

<!--
NOTAS DOCENTE:
Conversación formativa, sin calificación. Respuestas: almacenamiento/recursos/procesamiento; cliente y DataNodes; fallo común del anfitrión y posible NameNode único; tamaño, llegada, consultas, cambios, conservación y objetivos de servicio. No se añade un instrumento de evaluación ni una actividad con ID nuevo.
-->

---
<!-- _class: lead -->

# Decisiones de almacenamiento

El patrón de acceso orienta la elección del sistema.

Hadoop permite estudiar cómo se reparten datos, recursos y tareas, y qué ocurre cuando falla una parte del sistema.

<!--
NOTAS DOCENTE:
Volver al caso de ventas de la apertura. Pedir que expliquen qué datos faltan antes de decidir. Continuar con el bloque 01 y la instalación manual.
-->