Data warehouse, data lake y lakehouse: qué son, las diferencias y cuál usar

Toda empresa que empieza a tomarse los datos en serio se topa con la misma pregunta práctica: ¿dónde van a vivir esos datos? Data warehouse, data lake y, más recientemente, el data lakehouse son las tres respuestas que el mercado da a esto. Los nombres parecen cosa de ingeniero, pero la decisión entre ellos influye directamente en si el informe cuadra o no cuadra, en si la IA decide bien o decide mal, y en si el proyecto entrega a tiempo o se convierte en retrabajo. Quien trabaja con gobernanza, alta y mantenimiento de registros maestros, compras o cualquier área que consuma información necesita entender esta diferencia, aunque no sea del área técnica.

Voy a explicar cada uno en lenguaje de negocio, mostrar cuándo tiene sentido usar cada enfoque, citar las herramientas que dominan el mercado y, sobre todo, mostrar el punto que casi nadie comenta: ninguna de estas arquitecturas arregla un dato malo. Solo cambian el lugar donde aparece el problema.

Qué es un data warehouse

Un data warehouse es un repositorio central que reúne datos ya organizados, tratados y listos para el análisis. Piensa en él como un almacén bien ordenado, donde cada caja tiene etiqueta, cada estante tiene un propósito y sabes exactamente dónde encontrar lo que buscas. El dato entra después de pasar por una cadena de limpieza y estandarización, así que cuando llega ahí ya está en el formato correcto.

Este modelo trabaja con lo que se llama schema on write, es decir, la estructura se define antes de que el dato se grabe. En la práctica, esto significa que alguien decidió de antemano que la tabla de ventas tiene estas columnas, con estos tipos, siguiendo estas reglas. La información cruda que viene del ERP, del CRM o de una hoja de cálculo pasa por un proceso de ETL, sigla de extraer, transformar y cargar, y solo entra al warehouse después de transformada.

El data warehouse fue hecho para responder preguntas de negocio con consistencia. Es la base de los informes gerenciales, los paneles de BI, el cierre financiero y los análisis históricos. Cuando el director pregunta cuánto vendió la empresa por región en el último trimestre, es el warehouse quien responde de forma confiable. El precio de esa confiabilidad es la rigidez: cambiar la estructura da trabajo, y no fue pensado para guardar cualquier tipo de dato, solo lo que ya está modelado.

Qué es un data lake

Un data lake es lo opuesto en la forma de pensar. En lugar de ordenar todo antes de guardar, recibe el dato tal como viene: estructurado, semiestructurado o totalmente crudo. Hoja de cálculo, log de sistema, imagen, audio, texto de correo, archivo de sensor de máquina, todo cabe. La imagen del lago ayuda: echas el agua de varias fuentes ahí dentro y queda disponible para quien quiera pescar después.

Aquí la lógica es schema on read. La estructura solo se aplica en el momento en que alguien va a usar el dato, no a la hora de guardarlo. Esto da una flexibilidad enorme y un costo de almacenamiento bajo, porque no existe la pesada cadena de transformación en la entrada. El proceso típico es el ELT, extraer, cargar y después transformar, invirtiendo el orden del warehouse. Primero metes todo adentro y tratas cuando lo necesites.

El data lake nació para dar cuenta del volumen y la variedad que el warehouse no soportaba, principalmente para ciencia de datos, machine learning y análisis exploratorios. El problema es que la flexibilidad sin disciplina cobra caro. Un data lake sin gobernanza se convierte en lo que el mercado apodó data swamp, el pantano de datos: todo entra, nadie sabe qué hay, y el dato deja de ser útil porque nadie confía en él ni puede encontrar lo que necesita. Esto ocurre mucho en las empresas que compraron la tecnología pensando que resolvería el desorden por sí sola.

Data warehouse y data lake: las diferencias en la práctica

La diferencia esencial está en cuándo se organiza el dato. En el warehouse, antes de entrar. En el lake, a la hora de usarlo. Esto se desdobla en casi todo lo demás. El warehouse guarda dato tratado, estructurado, caro por gigabyte, y sirve bien para informes y BI con respuestas consistentes. El lake guarda dato crudo de cualquier tipo, barato por gigabyte, y sirve bien para exploración, ciencia de datos y entrenamiento de modelos.

En la vida real de las empresas medianas y grandes, la pregunta rara vez es uno u otro. Es común ver a los dos conviviendo: el lake recibe el volumen crudo de varias fuentes, y una parte de ese dato, una vez tratada, se lleva al warehouse para alimentar los informes oficiales. Quien ya participó en un proyecto de datos sabe que esa arquitectura en dos capas funciona, pero genera duplicación, el costo de mantener dos entornos y el riesgo clásico de que el número del panel no coincida con el número de la exploración. Y ahí está el problema que el lakehouse vino a intentar resolver.

Qué es un data lakehouse y por qué se volvió el estándar

El data lakehouse es el intento de juntar lo mejor de los dos mundos en una sola arquitectura. Guarda el dato crudo y de cualquier formato, como el lake, pero agrega por encima una capa que aporta estructura, control y confiabilidad parecidos a los del warehouse. La idea es tener la flexibilidad y el bajo costo del lake con la consistencia y la capacidad de análisis del warehouse, sin mantener dos entornos separados.

Lo que lo hizo posible fueron los formatos de tabla abiertos, como Delta Lake, Apache Iceberg y Apache Hudi. Sin entrar en el detalle técnico, permiten que el dato guardado de forma barata en el almacenamiento se comporte como una tabla organizada, con control de versiones, transacciones confiables y reglas claras. Es esa capa la que transforma un depósito de archivos en algo que la empresa puede gobernar.

En los últimos años, el lakehouse dejó de ser tendencia y se volvió el modelo dominante de las grandes plataformas de datos. Es hoy la apuesta principal de Databricks, Snowflake y Microsoft Fabric, que se disputan este mercado. Para quien es de negocio, el mensaje es simple: la discusión de warehouse contra lake está siendo reemplazada por una arquitectura única que promete servir a los dos usos. Pero la promesa de la tecnología, como siempre, depende de la ejecución.

Dónde entran los datos maestros en esta historia

Aquí está el punto que rara vez aparece en las comparativas técnicas, y que hace toda la diferencia. Warehouse, lake y lakehouse son decisiones sobre dónde y cómo guardar el dato. Ninguno decide si el dato es bueno. Si el mismo proveedor está dado de alta tres veces con nombres distintos, estará duplicado en el warehouse, duplicado en el lake y duplicado en el lakehouse. La arquitectura más moderna del mundo no junta esos tres registros por sí sola.

Eso es lo que separa la infraestructura de datos de la gobernanza de datos. La plataforma organiza la estructura, pero los datos maestros, los maestros de clientes, proveedores, materiales y productos, necesitan definición, dueño, regla y calidad para valer algo. He visto empresas invertir fuerte en una plataforma nueva de datos y seguir con el informe que no cuadra, porque cada área todavía entiende cliente a su manera y el registro maestro que alimenta la plataforma sigue sucio. El dato malo solo cambió de dirección, ahora vive en un lugar más caro y más bonito.

Esto vale el doble para la inteligencia artificial. Todos quieren usar el lakehouse para entrenar modelos y aplicar IA. Solo que la IA no mejora un dato malo por arte de magia. Si los materiales están duplicados y los proveedores están mal clasificados, la IA solo va a acelerar decisiones equivocadas con más confianza. El Master Data Management es la capa que garantiza que el dato maestro que abastece a cualquiera de estas arquitecturas sea único, correcto y confiable. Sin eso, construyes un almacén impecable para guardar mercadería echada a perder.

Qué herramientas usa el mercado

Del lado de los data warehouses, los nombres más comunes son Snowflake, Amazon Redshift, Google BigQuery y Azure Synapse, además de Teradata en entornos más tradicionales. Son plataformas maduras, muy usadas para BI corporativo y análisis estructurado.

Para el data lake, la base suele ser el almacenamiento de objetos de las nubes, como Amazon S3, Azure Data Lake Storage y Google Cloud Storage, muchas veces con el legado del ecosistema Hadoop en empresas más antiguas. El dato queda ahí, barato, y las herramientas de procesamiento leen a partir de él.

En el territorio del lakehouse, la disputa hoy la dominan tres plataformas: Databricks, que popularizó el concepto y el formato Delta Lake, Snowflake, que evolucionó del warehouse para abrazar los datos abiertos, y Microsoft Fabric, la apuesta integrada de Microsoft que unifica ingesta, almacenamiento y análisis. La elección entre ellas depende del contexto de cada empresa, de lo que ya existe de nube y de equipo, y no de cuál es la mejor en el papel.

Vale recordar que estas plataformas resuelven almacenamiento y procesamiento. La capa de gobernanza, catálogo, calidad y datos maestros es complementaria, con herramientas específicas para cada función. Confundir una cosa con la otra es un error que cuesta caro en un proyecto.

Cómo aprender y construir carrera en esta área

Para quien quiere entrar a este mundo, el camino no empieza por la herramienta, empieza por el concepto. Antes de aprender a operar Databricks o Snowflake, vale la pena entender modelado de datos, qué es un dato estructurado, cómo funciona un proceso de carga y por qué existen la calidad y la gobernanza. La herramienta cambia cada año, el fundamento no.

Una buena hoja de ruta pasa por tres frentes: los fundamentos de gestión de datos, donde referencias como el DAMA-DMBOK y la certificación CDMP ayudan a organizar el pensamiento; la parte técnica de arquitectura, con SQL bien dominado y práctica en las plataformas de nube; y, lo que más falta en el mercado, la visión de negocio, la capacidad de conectar el dato con el impacto en compras, ventas, finanzas y operación. El profesional que domina los tres se vuelve raro y valioso.

Las oportunidades

La demanda de quien entiende de arquitectura y gobernanza de datos viene creciendo de forma consistente, empujada por la presión de usar IA con responsabilidad. Toda empresa quiere aplicar inteligencia artificial, y todas están descubriendo que no se puede hacer sobre una base desorganizada. Esto abre espacio para roles como ingeniero de datos, arquitecto de datos, especialista en calidad, data steward y gestor de datos maestros.

Lo interesante para quien está empezando es que sobra gente que sabe apretar botones en una herramienta y falta gente que entiende por qué el dato necesita ser confiable y cómo hacerlo realidad en la práctica. Es exactamente en ese espacio, entre la tecnología y el negocio, donde están hoy las mejores oportunidades de carrera en datos.

Principales dudas

¿Cuál es la diferencia entre data warehouse y data lake? El data warehouse guarda datos ya tratados y estructurados, organizados antes de entrar, y sirve para informes y BI. El data lake guarda datos crudos de cualquier formato, organizados solo a la hora de usarlos, y sirve para exploración y ciencia de datos. La diferencia central es el momento en que se estructura el dato.

¿El data lakehouse sustituye al data warehouse? En muchos casos unifica los dos usos en una sola arquitectura, reduciendo la necesidad de mantener entornos separados. Pero no es un reemplazo automático. Las empresas con un warehouse maduro y estable siguen usando lo que funciona, y la migración es una decisión de contexto, no de moda.

¿Necesito tener los dos, warehouse y lake? Depende del volumen y la variedad de datos de la empresa. Muchas organizaciones operan los dos en capas, con el lake recibiendo lo crudo y el warehouse sirviendo el dato tratado. El lakehouse surgió justamente para reducir esa duplicación.

¿Data lake y data lakehouse son lo mismo? No. El lake es el depósito de datos crudos. El lakehouse agrega sobre ese depósito una capa de estructura y control que aporta confiabilidad de warehouse. El lakehouse es una evolución del lake, no un sinónimo.

¿Estas plataformas resuelven la calidad de los datos? No por sí solas. Resuelven dónde guardar y cómo procesar. La calidad, la estandarización y la unicidad de los datos maestros dependen de la gobernanza y de la disciplina, y siguen siendo responsabilidad de la empresa, no de la herramienta.

MDM Academy

La MDM Academy es la escuela de gobernanza y datos maestros de 4MDG, creada para formar profesionales que entiendan el dato de verdad, no solo la herramienta de turno. La propuesta es unir fundamento, práctica y visión de negocio, enseñando desde los conceptos de gobernanza y calidad hasta cómo los datos maestros sostienen cualquier arquitectura, sea warehouse, lake o lakehouse. Es el tipo de formación que prepara para lo que el mercado realmente pide: gente que conecta el dato con el resultado de la empresa.

Si quieres construir una carrera en un área en alza y aprender con quienes viven proyectos reales de datos en el día a día, vale la pena conocer la MDM Academy y entrar al Club de los Datos, donde compartimos contenido, intercambio y práctica sobre gobernanza y datos maestros.

Conclusión

Elegir entre data warehouse, data lake y lakehouse es una decisión importante de arquitectura, y el lakehouse tiene buenas razones para ser hoy la apuesta principal del mercado. Pero la lección que queda de casi treinta años de proyectos es siempre la misma: la tecnología decide dónde vive el dato, nunca si es bueno. Puedes tener la plataforma más moderna del mundo y seguir con el informe que no cuadra, la compra equivocada y la IA que decide mal, si los datos maestros que alimentan todo eso están sucios.

El punto es ese. Antes de discutir qué arquitectura adoptar, vale la pena preguntar si la empresa confía en sus propios datos. Porque, al final, no es el almacén lo que hace la diferencia. Es la calidad de lo que guardas dentro de él.