No hay nada peor que un jefe llegado de un rimbombante congreso de tecnología. Hoy en día, vienne infectados por la última palabra de moda del sector: Data Lake (Lago de Datos). Nuestro meticuloso y estructurado Data Warehouse está anticuado y que tenemos que empezar a volcar todo (bases de datos, logs, imágenes, audios) en un gran "lago" centralizado.

Cuando te vienen con estas tienes que respirar hondo. Aunque el concepto de Data Lake tiene mucho sentido técnico, la forma en la que lo venden a los directivos es puro humo que esconde un peligro gigantesco.

Schema-on-Write vs Schema-on-Read

El núcleo técnico de esta discusión es dónde y cuándo imponemos las reglas de los datos.

En un modelo tradicional (Data Warehouse), usamos Schema-on-Write. Yo diseño una tabla Ventas con un INT para el ID y un DECIMAL para el precio. Si intentas insertar una fila donde el precio es la palabra "Veinte", la base de datos rechaza la transacción y lanza un error. El dato siempre está limpio porque el peaje está a la entrada.

En un Data Lake, el modelo es Schema-on-Read. Volcamos ficheros JSON, CSVs mal formados y logs crudos en crudo en un clúster HDFS o un cubo de S3, sin validar nada. La estructura no se impone al guardar, sino al leer. Cuando un analista quiere ver las ventas, lanza un motor de consultas distribuidas como Presto, Apache Hive o Spark SQL que intenta interpretar esos ficheros al vuelo.

-- Usando Apache Hive para consultar datos crudos como si fueran una tabla
CREATE EXTERNAL TABLE ventas_lago (
    id_venta STRING,
    importe STRING -- Todo entra como texto porque no sabemos qué hay realmente
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ','
LOCATION '/datos_crudos/lago/ventas/';

-- Y ahora rezamos para que los CSVs no tengan comas dentro del importe
SELECT id_venta, CAST(importe AS DOUBLE) FROM ventas_lago;

Reflexión: Bienvenidos al Pantano de Datos (Data Swamp)

La promesa de los proveedores de software es que puedes almacenar petabytes a coste de risa y preocuparte de la estructura "después". El problema es que ese "después" rara vez llega.

Si permites que cualquier departamento tire ficheros sueltos a una carpeta compartida en Hadoop sin metadatos, sin un catálogo de datos y sin reglas de gobierno corporativo, no estás construyendo un Lago de Datos. Estás construyendo un vertedero. Un Data Swamp (Pantano de Datos).

De nada sirve tener 10 Terabytes de logs de usuarios si el analista que los tiene que procesar no sabe si las fechas están en formato americano o europeo, o si la zona horaria es UTC. El "Data Lake" es una arquitectura fantástica para los científicos de datos que necesitan materia prima sin manipular, pero requiere más disciplina, más catalogación y mejor ingeniería de flujos de datos que el modelo relacional clásico. Si no, terminaremos ahogados en nuestro propio lago.