El lago de datos: cuando el warehouse se quedó pequeño

Voy a contarte una historia que he vivido en primera persona. Una historia que se repitió en miles de empresas entre 2005 y 2015, y que explica por qué estás aquí leyendo sobre data lakes en vez de simplemente meter todo en un warehouse como hacíamos antes. Es la historia de cómo el data warehouse — esa maravilla de ingeniería que funcionó perfectamente durante 20 años — se encontró con un muro que no podía escalar.

### El warehouse que funcionó durante dos décadas

Recuerda lo que aprendiste en la Skill 11: un data warehouse es un almacén central, con esquema estrella, optimizado para responder preguntas de negocio. Hechos, dimensiones, granularidad definida. Todo bonito, todo estructurado, todo controlado. Y durante años, eso bastó. Las fuentes de datos eran pocas y predecibles: el ERP (facturación), el CRM (clientes), el sistema de RRHH. Datos transaccionales con estructura clara — tablas con columnas bien definidas.

El modelo funcionaba porque el mundo era relativamente simple: pocos sistemas fuente, datos estructurados, volúmenes manejables (hablamos de gigabytes, no terabytes), y transformaciones predecibles. El DBA conocía cada tabla, cada columna, cada relación. Era un ecosistema controlado. Como un acuario bien mantenido — todo en su sitio, temperatura controlada, peces contados.

### Entonces llegó internet... y rompió todo

A mediados de los 2000, internet pasó de ser un canal más a ser EL canal. Y con ello llegaron datos que el warehouse simplemente no sabía cómo manejar. Piensa en lo que genera una app web moderna en un solo día: logs de servidor (millones de líneas de texto), eventos de click del usuario (JSON anidado con contexto variable), imágenes subidas por usuarios, archivos PDF de contratos, correos electrónicos, datos de sensores IoT, feeds de redes sociales, vídeos.

¿Cómo metes un log de Apache — una línea de texto con formato variable — en una tabla con columnas predefinidas de un warehouse? Spoiler: no puedes. Al menos no sin un trabajo enorme de parsing y transformación ANTES de cargarlo. El warehouse tenía tres limitaciones fundamentales que internet expuso sin piedad:

1. 01.Schema-on-write: tenías que definir la estructura ANTES de cargar los datos. Si no sabías qué forma tenían los datos (o si cambiaban con frecuencia), estabas atrapado.
2. 02.Coste de almacenamiento: los warehouses usaban almacenamiento propietario, caro y limitado. Almacenar terabytes costaba cientos de miles de dólares al año.
3. 03.Solo datos estructurados: tablas con filas y columnas. Los logs, JSONs anidados, imágenes y archivos semi-estructurados no encajaban.

### La idea revolucionaria: almacenar primero, preguntar después

En 2006, Hadoop apareció como respuesta al problema de Google: procesar datos masivos usando clústeres de máquinas baratas. Pero Hadoop trajo algo más profundo que solo procesamiento — trajo una filosofía radicalmente diferente: guarda TODOS los datos en su formato original, sin transformar, sin esquema predefinido. Ya decidirás qué hacer con ellos cuando los necesites. Esto se llamó "schema-on-read" — el esquema se aplica al LEER, no al escribir.

Piensa en la diferencia con una analogía: el warehouse es como un archivador de oficina. Cada documento se clasifica, se etiqueta, se mete en su carpeta correcta ANTES de guardarlo. Si llega un paquete raro que no encaja en ninguna carpeta, no entra. El data lake es como un almacén industrial. Todo entra: cajas, pallets, documentos, maquinaria, líquidos en bidones. Lo guardas sin clasificar. Cuando necesitas algo específico, vas al almacén con un equipo y herramientas adecuadas para buscarlo y procesarlo.

James Dixon, CTO de Pentaho, acuñó el término "data lake" en 2010. Su metáfora original era: "Si piensas en un data mart como una botella de agua — limpia, empaquetada, estructurada, lista para consumir — entonces el data lake es el cuerpo de agua en su estado natural. Múltiples afluentes llenan el lago. Múltiples usuarios pueden examinar, sumergirse o tomar muestras del lago."

### Los pilares técnicos del data lake

Un data lake se construye sobre tres pilares que lo diferencian radicalmente del warehouse:

1. 01.Almacenamiento objeto (object storage): en vez de discos de un servidor de base de datos, usas un sistema como HDFS o Amazon S3 — almacenamiento virtualmente infinito, distribuido y extremadamente barato. S3 cuesta aproximadamente $0.023 por GB al mes. Almacenar 1 TB cuesta $23/mes. En un warehouse propietario podía costar $1000+/mes.
2. 02.Formatos abiertos: los datos se guardan en formatos estándar como Parquet, ORC, Avro, JSON o CSV. No en un formato propietario que te ata a un vendor. Cualquier herramienta puede leerlos.
3. 03.Compute desacoplado del storage: el almacenamiento y el procesamiento son independientes. Puedes escalar uno sin tocar el otro. Si necesitas más potencia de cálculo, añades máquinas de procesamiento temporalmente sin mover los datos.

Esta separación de compute y storage es quizás la idea más importante de la última década en datos. En un warehouse tradicional, tus datos viven DENTRO del motor de consultas — si quieres más potencia, necesitas un servidor más grande (escalado vertical). En un data lake, tus datos viven en S3 y puedes lanzar un clúster de Spark con 100 máquinas para procesarlos, y apagarlo cuando termines. Solo pagas por el tiempo que usas.

### El problema del pantano: cuando el lago se descontroló

Aquí viene la parte que no cuentan en los whitepapers de marketing. El data lake sonaba perfecto en teoría: "guarda todo, ya lo usaremos". Pero en la práctica, muchas empresas descubrieron un problema grave: sin disciplina, el lake se convierte en un pantano (data swamp). Un pantano de datos es un lago donde nadie sabe qué hay, quién lo puso, si está actualizado, si es correcto, o cómo usarlo.

He visto lagos con 500 TB de datos donde el 80% era basura: copias duplicadas, experimentos abandonados, datos corruptos que nadie limpió, archivos sin documentación. El equipo de data science pedía un dataset y tardaba semanas en encontrarlo, validarlo y entender si podía confiar en él. El lago prometía democratizar los datos, pero en la práctica creó un caos peor que el que había antes.

### Data Lake vs Data Warehouse: no es uno u otro

Un error conceptual común es pensar que el data lake reemplaza al warehouse. No. Son complementarios. El lake es excelente para almacenar datos en crudo a bajo coste y para procesar datos semi-estructurados. El warehouse sigue siendo excelente para consultas analíticas rápidas sobre datos ya modelados. En la arquitectura moderna, los datos fluyen así: fuentes → data lake (almacenamiento barato, formato abierto) → procesamiento y modelado → data warehouse o capa gold del lake (consultas rápidas para BI).

De hecho, la evolución más reciente — el data lakehouse que veremos con Apache Iceberg — fusiona ambos mundos: almacenamiento barato de lake + capacidades ACID y de consulta del warehouse, todo en un solo sistema. Es el siguiente paso evolutivo.

### El ecosistema tecnológico del data lake

• ▹Almacenamiento: Amazon S3, Azure Data Lake Storage, Google Cloud Storage, o HDFS para on-premise
• ▹Formatos de archivo: Parquet (el rey para analítica), ORC, Avro, JSON, CSV
• ▹Motor de procesamiento: Apache Spark, Presto/Trino, DuckDB, Athena
• ▹Catálogo de metadatos: AWS Glue Catalog, Apache Hive Metastore, DataHub
• ▹Table formats (ACID): Apache Iceberg, Delta Lake, Apache Hudi
• ▹Gobernanza: políticas de acceso, linaje, calidad del dato

No te preocupes si algunos de estos nombres te suenan a ciencia ficción — los iremos cubriendo uno a uno en esta skill. Lo importante ahora es que entiendas el concepto: un data lake es una ARQUITECTURA, no un producto. Es un patrón de diseño que combina almacenamiento barato + formatos abiertos + compute elástico.