Transferencia al proyecto transversal

Este documento aplica los contenidos ya estudiados y acumula las decisiones de almacenamiento de M01 en un componente reutilizable en M02. El proyecto transversal integrado se desarrollará del 26 de abril al 28 de mayo de 2027.

Aprendizaje de M01	Decisión que permite tomar
HDFS, bloques y replicación	Diseñar la capa de histórico y su disponibilidad.
fsck, checksums y snapshots	Definir evidencias de integridad y recuperación.
MapReduce y YARN	Comprender el procesamiento batch que Spark desarrollará después.
Avro, Parquet, ORC y particionado	Elegir formato y organización física del histórico.
PostgreSQL	Guardar metadatos, ejecuciones o resultados operacionales.
Hive y tablas externas	Consultar históricos compartidos sin apropiarse de ficheros.
S3/MinIO y data lake	Separar almacenamiento de objetos y motores de cómputo.
Iceberg	Planificar cuándo un histórico necesita tabla, catálogo y versiones consistentes.

Proyecto

M01-PROY-01 — Entregable de transferencia

Cada equipo elaborará un Blueprint de almacenamiento con:

1. Formato, compresión y estrategia inicial de particionado.
2. Qué información correspondería a HDFS, PostgreSQL y S3/MinIO, con una justificación por patrón de acceso.
3. Estructura propuesta de bucket y prefijos para el histórico analítico.
4. Decisión razonada: Parquet como archivos o Iceberg como formato de tabla; catálogo y snapshots necesarios si se elige Iceberg.
5. Evidencias técnicas que M02 y M03 deberán conservar: esquema, rutas, consultas, resultados de integridad y versión de datos. El esquema deberá documentar cómo podrá mapearse después con el futuro contrato de evento: símbolo, divisa, instante de mercado, instante de ingesta, precio y procedencia.

El producto se prepara en un único documento Markdown. Incluye la tabla de decisión siguiente, un diagrama o esquema de las capas elegidas y una justificación de entre dos y cuatro frases para cada decisión. Su comprobación es formativa: decisiones trazables sustentadas en M01 y referencias a evidencias propias obtenidas durante las prácticas. No constituye por sí mismo una calificación del proyecto transversal ni una entrega calificable de Aules sin anuncio docente expreso.

Comprobación antes de entregar

El Blueprint está preparado para continuar en M02 si responde con claridad a estas preguntas:

• ¿Qué dato se guarda en cada capa y qué consulta o proceso lo necesita?
• ¿Qué formato, esquema y compresión se han elegido y cuál es la razón?
• ¿Qué parte de la organización es una ruta HDFS, qué parte es un prefijo de objetos y qué parte es una tabla?
• ¿Qué evidencia permitiría detectar una ruta errónea, una réplica insuficiente o un dato con un esquema incompatible?
• ¿Qué decisión se mantiene abierta hasta que M02 defina la ingesta y M03 implemente Spark?

Plantilla de decisión por patrón de acceso

El blueprint no debe repartir tecnologías por costumbre. Para cada capa, indica qué dato guarda, cómo se consulta o actualiza y qué evidencia justifica la decisión:

Capa candidata	Datos posibles	Patrón de acceso que debe justificarse	Decisión del equipo
PostgreSQL	Configuración del pipeline, ejecuciones, alertas o metadatos operacionales	Consultas exactas, transacciones y actualizaciones puntuales	¿Qué tablas y qué consultas requiere?
S3/MinIO + Parquet	Histórico de velas OHLC o eventos masivos	Lecturas analíticas por periodo o activo; escritura de archivos y acceso compartido entre motores	¿Qué bucket, prefijos, formato, compresión y particiones se usarán?
Hive con tabla externa	El histórico Parquet compartido	Exploración SQL sin mover ni apropiarse de los ficheros de otro proceso	¿Qué LOCATION y qué esquema tendría la tabla?
Apache Iceberg sobre el histórico	Tabla analítica con cambios, auditoría o varias versiones	Snapshots, evolución de esquema o lectura consistente durante escrituras	¿Es necesario? Justifica explícitamente sí o no, junto con el catálogo y la política de versiones.
HDFS	Entorno de aprendizaje, procesamiento batch heredado o un requisito concreto justificado	Bloques, replicación y localidad de datos	¿Aporta una necesidad que no cubre el almacenamiento de objetos del diseño propuesto?

La tabla no obliga a desplegar todas las capas. Su finalidad es dejar una decisión de arquitectura trazable: PostgreSQL no sustituye al histórico analítico; MinIO no convierte por sí solo unos archivos en una tabla Lakehouse; e Iceberg solo se adopta cuando resuelve una necesidad concreta.

Este blueprint continúa en M02 con la ingesta y en M03 con Spark. No se implementará aún una migración HDFS–S3 ni procesamiento streaming.