Data warehouse vs data lake vs lakehouse: diferencias y un ejemplo para marketing y ventas

Un data warehouse guarda datos ya ordenados para responder preguntas de negocio: tablas con columnas fijas, definiciones acordadas y consultas en SQL. Un data lake guarda datos en bruto, en el formato en que llegan (tablas, JSON, CSV, registros de eventos, documentos), en un almacenamiento barato, y se les da forma después, cuando alguien los necesita. El lakehouse es la mezcla de los dos: los ficheros siguen en el lago, pero encima hay tablas con las garantías de un warehouse.

Si todavía no tienes claro qué es un data warehouse ni si lo necesitas, empieza por qué es un data warehouse y cuándo lo necesitas. Aquí lo damos por sabido y vamos a las diferencias, a un ejemplo para marketing y ventas y a qué producto es cada cosa.

Durante años, muchas empresas tuvieron las dos cosas: un lago para guardarlo todo y, al lado, un warehouse con una copia de lo que se usaba en los informes. Dos sitios, dos copias y dos facturas.

El lakehouse quita esa copia. Los datos se quedan en ficheros Parquet en el almacenamiento de tu nube, y un formato de tabla abierto, como Delta Lake o Apache Iceberg, añade lo que les faltaba para comportarse como tablas de verdad: transacciones, esquema y versiones anteriores consultables. Un catálogo por encima gestiona los permisos. Así el mismo dato sirve para el informe de Power BI y para el modelo de Python.

Un data mart es una parte del data warehouse preparada para un área concreta. El de marketing tiene campañas, inversión, leads y atribución; el de ventas, oportunidades, pedidos y cuotas por comercial. Es más pequeño, más fácil de entender y suele ser lo que de verdad abre la gente.

Hoy no tiene por qué ser una base de datos aparte: lo normal es un esquema dentro del mismo warehouse, construido sobre las mismas tablas comunes. Lo que conviene evitar es que marketing y ventas monten cada uno su data mart con su propia copia de los clientes, porque vuelven las cifras que no cuadran.

Pongamos que quieres saber el coste de adquisición por canal. En bronce tienes la inversión diaria de Google Ads y de Meta Ads, las sesiones de GA4 con su origen y las oportunidades del CRM con su fuente original. En plata, las campañas de cada plataforma se agrupan en los mismos canales, las fechas pasan a la misma zona horaria y cada cliente ganado queda unido a su primer contacto. En oro hay una tabla por mes y canal con la inversión, los clientes nuevos y el coste por cliente, que es lo que lee el cuadro de mando.

Si mañana decidís contar un canal de otra forma, se cambia la regla en plata y se recalcula todo desde bronce, histórico incluido. La fórmula y sus trampas están en cómo calcular el CAC.

En un proyecto de business intelligence, el data warehouse es la parte que no se ve. El cuadro de mando es lo que la dirección abre el lunes, pero las cifras salen de la capa oro, y si esa capa está bien hecha el cuadro de mando es casi lo fácil. Sin warehouse, cada informe hace su propia limpieza y dos informes con la misma métrica acaban dando dos números. Más en business intelligence.

Para la mayoría de equipos de marketing y ventas, un data warehouse basta: sus fuentes son tablas (CRM, anuncios, analítica web, facturación) y se consultan con SQL o con una herramienta de BI.

Merece la pena pensar en un lakehouse cuando:

• Tienes mucho dato de eventos o semiestructurado: navegación detallada, uso de producto, registros de una aplicación.
• Vas a entrenar modelos en Python y quieres que trabajen sobre la misma copia que los informes.
• Quieres guardar documentos, transcripciones de llamadas o correos para analizarlos con IA.
• Tu empresa ya usa Databricks o Fabric en otras áreas y lo razonable es sumarse.

La frontera se ha difuminado, así que la pregunta útil no es qué etiqueta elegir, sino qué fuentes tienes, qué quieres responder y quién lo va a mantener. Es lo que trabajamos en la estrategia de datos.