Data warehouse, data lake y lakehouse: diferencias y cuál necesita tu empresa

Qué es un data warehouse

Un data warehouse, o almacén de datos, es una base de datos pensada para analizar, no para operar. Recibe la información de los sistemas de la empresa (el ERP, el CRM, el sistema de facturación, las hojas de cálculo que todavía mandan en algunas áreas), la limpia, la ordena con criterios comunes y la deja lista para que Power BI, Excel o cualquier herramienta de reportes la consulte.

La diferencia con la base de datos del ERP es de propósito. El ERP está hecho para registrar una venta rápido y sin errores, una por una. El warehouse está hecho para responder preguntas sobre miles de ventas a la vez: cuánto vendimos por zona este trimestre contra el mismo trimestre del año pasado, qué clientes dejaron de comprar, qué producto deja margen. Si esas preguntas se le hacen directo al ERP, el sistema se pone lento para todos y cada área termina sacando su propia exportación a Excel. Si la idea de base de datos todavía no está clara en tu equipo, la explicación desde cero está en qué es una base de datos.

Tres rasgos lo definen:

• Datos estructurados y modelados. Tablas con columnas definidas, organizadas para el análisis: hechos (ventas, pedidos, cobranzas) y dimensiones (cliente, producto, fecha, vendedor).
• Historia. Guarda cómo estaban las cosas en cada momento, no solo la foto de hoy. Por eso puedes comparar periodos.
• Una sola versión de cada número. La venta se calcula una vez, con una regla escrita, y todos los reportes la leen de ahí.

Data warehouse corporativo y data marts

Cuando se habla de data warehouse corporativo se habla del almacén que cubre a toda la empresa, con las entidades compartidas (clientes, productos, sedes) definidas una sola vez. Un data mart es un pedazo de ese almacén pensado para un área: el de ventas, el de finanzas, el de operaciones. En una empresa mediana no hace falta construir el corporativo completo de golpe: se arma por áreas, empezando por la que más reportes discute, y cuidando que las dimensiones compartidas sean las mismas para todas.

Qué es un data lake

Un data lake, o lago de datos, es un almacenamiento donde caen los datos tal como vienen, en cualquier formato: tablas exportadas, archivos CSV, JSON de una API, registros de sensores, imágenes, audios, documentos. No se les da estructura al guardarlos; se les da cuando alguien los va a usar.

Esa flexibilidad es su ventaja y su riesgo. La ventaja: puedes guardar barato información que todavía no sabes cómo vas a usar, y el equipo de ciencia de datos puede explorar sin esperar a que alguien modele cada tabla. El riesgo: sin reglas, el lago se convierte en un depósito donde nadie sabe qué hay, de cuándo es ni si se puede confiar en ello. En el mundo de datos a eso se le llama, con razón, pantano de datos.

Un data lake tiene sentido cuando:

• Tienes datos que no son tablas: telemetría de equipos, logs de una app, documentos, imágenes.
• Hay un equipo que va a entrenar modelos de machine learning y necesita el dato crudo, no el resumen.
• El volumen es grande y guardar todo en un warehouse sale caro.

Qué es un lakehouse

El lakehouse es la arquitectura que junta las dos ideas: los datos viven en el almacenamiento barato y abierto del lago, pero guardados en formatos de tabla (Delta Lake, Apache Iceberg) que permiten consultarlos con SQL, controlar versiones y tener la confiabilidad de un warehouse. Así no hace falta mantener dos copias de todo, una cruda en el lago y otra ordenada en el almacén.

Casi siempre se organiza en capas, lo que se conoce como arquitectura medallón:

• Bronce: el dato crudo, tal como llegó de la fuente.
• Plata: el dato limpio, sin duplicados y con tipos correctos.
• Oro: las tablas listas para el negocio: ventas por día, margen por producto, cartera por vendedor. Es la capa que lee Power BI.

Plataformas como Databricks y Microsoft Fabric se construyeron sobre esta idea, y otras como Snowflake o BigQuery también leen formatos abiertos. Si tu empresa ya trabaja con Microsoft, el detalle de cómo lo resuelve Fabric está en Microsoft Fabric: qué es y cuándo conviene.

Data lake y data warehouse: la tabla comparativa

La lectura corta: el warehouse responde preguntas conocidas con números confiables; el lago guarda lo que todavía no sabes cómo vas a usar; el lakehouse intenta que no tengas que elegir.

Cuál conviene a una empresa mediana en Perú

La pregunta que más me hacen en reuniones es "¿necesitamos un data lake?". La respuesta casi siempre es "todavía no". Estos son los escenarios que veo más seguido y lo que recomiendo en cada uno:

• Los reportes salen de exportaciones del ERP pegadas en Excel. Necesitas un data warehouse, aunque sea chico. Es el paso que elimina las discusiones de "a mí me sale otro número".
• Ya tienes Power BI conectado a varias fuentes y los modelos se volvieron pesados. Necesitas un warehouse o una capa oro de lakehouse que haga el trabajo pesado antes de que llegue a Power BI.
• Tienes datos de sensores, telemetría de flota o documentos que quieres analizar con IA. Ahí sí entra el lago, o un lakehouse que lo incluya.
• Hay un equipo de ciencia de datos que entrena modelos. Un lakehouse les evita pedir extracciones cada semana.
• Eres una empresa con un solo sistema y pocos reportes. Quizás no necesitas ninguno de los tres todavía: con una base bien consultada con SQL y un buen modelo en Power BI alcanza.

La regla que sigo: la arquitectura se elige por las preguntas que el negocio necesita responder y por el equipo que la va a mantener, no por lo que está de moda. Un lakehouse que nadie en la empresa sabe operar es peor que un warehouse sencillo que todos entienden. El marco general de esa decisión está en arquitectura de datos para empresas.

Cómo se arma un data warehouse por dentro

Sin entrar en código, estas son las piezas que tiene cualquier warehouse que funciona:

1. Fuentes. Los sistemas donde nace el dato: ERP, CRM, facturación electrónica, planillas, hojas de cálculo.
2. Integración (ETL o ELT). Los procesos que extraen el dato, lo transforman y lo cargan. Es la tubería, y es lo que más se rompe. Quién la construye y la mantiene está explicado en qué hace ingeniería de datos.
3. Modelo. Tablas de hechos y dimensiones, normalmente en esquema estrella, con las reglas de negocio escritas: qué cuenta como venta, cómo se calcula el margen, qué cliente es activo.
4. Capa semántica. Las medidas con nombre de negocio que usa la gente: "venta neta", "ticket promedio". En Microsoft suele vivir en el modelo de Power BI, con DAX.
5. Consumo. Dashboards, reportes, alertas y, cada vez más, agentes de IA que leen esas mismas tablas.

Encima de todo eso va el gobierno: quién es dueño de cada dato, quién puede verlo y cómo se resuelve cuando dos áreas no están de acuerdo. Sin esa capa el warehouse se llena igual que el lago. Lo desarrollo en gobierno de datos y, para la parte de limpieza, en calidad de datos.

Qué mueve el costo de un data warehouse o un data lake

No te voy a dar una cifra, porque depende de la nube, la región, el volumen y el contrato, y cualquier número quedaría mal en unos meses. Lo que sí puedo darte son los rubros que mueven la factura, para que compares propuestas con criterio:

• Almacenamiento. Cuánto dato guardas y cuánto historial. Suele ser lo más barato, y por eso se subestima el resto.
• Cómputo. Cuánto procesas y consultas. Una consulta mal escrita que corre cada hora puede costar más que todo el almacenamiento. Se controla con buen modelado y con horarios de actualización razonables.
• Integración. Los conectores y las tuberías. Las fuentes estándar se conectan fácil; el sistema hecho a medida de hace años es el que se lleva las horas.
• Personas. Quién construye, quién mantiene y quién responde cuando un reporte no se actualizó. Es el rubro más grande y el que menos aparece en las propuestas.
• Licencias de la herramienta de reportes. Si usas Power BI, el detalle por usuario está en cuánto cuesta Power BI.
• Gobierno y seguridad. Permisos, auditoría y cumplimiento de la Ley de Protección de Datos Personales cuando hay datos de clientes o colaboradores.

Y el costo que no sale en ninguna factura: las horas que hoy se van cada mes en armar reportes a mano y en discutir qué número es el bueno. Ese es el punto de comparación justo.

Errores que veo al empezar

• Comprar la plataforma antes de definir las preguntas. Primero los diez reportes que el comité necesita y sus reglas de cálculo; después la tecnología.
• Mover el desorden a la nube. Si los clientes están duplicados en el ERP, van a estar duplicados en el warehouse. La limpieza es parte del proyecto, no un paso opcional.
• Un lago sin catálogo. Guardar todo "por si acaso" sin decir qué es, de dónde vino ni quién responde por ello.
• Un proyecto de dos años. El warehouse que funciona se entrega por áreas: primero ventas, que es donde más se discute, después finanzas, después operaciones.
• Depender de una sola persona. Si solo quien lo construyó sabe cómo se actualiza, el día que se va el warehouse se congela.

Consultoría de data lake o data warehouse: qué debería incluir

Si estás evaluando contratar una consultoría para tu data warehouse o tu data lake, estas son las cosas que tendrían que estar en la propuesta, y que reviso en cualquier proyecto que tomo:

1. Un inventario de fuentes con su dueño y su calidad actual, antes de diseñar nada.
2. La lista de preguntas de negocio y reportes que el warehouse tiene que responder, priorizada con gerencia.
3. Las reglas de cálculo escritas para los indicadores principales, firmadas por las áreas que los usan.
4. Una arquitectura propuesta con su razón de ser, no solo un diagrama con logos.
5. Una primera entrega acotada (un área, un tablero) que se use en un comité real.
6. Un plan de traspaso: quién del equipo interno mantiene qué y qué capacitación necesita.

Ese es el trabajo que hago en la consultoría en datos e IA: ordenar fuentes, reglas y arquitectura con el equipo de la empresa, y dejarlo funcionando. Si después quieres que los reportes se armen y se envíen solos, eso entra en agentes de IA y reportes automáticos. Y el marco de por qué todo esto importa para decidir está en business intelligence en la empresa.

Preguntas frecuentes

Escrito por

Gera Flores (Miss Yera)

Consultora y experta en IA

Agenda 30 min con Gera Ver bio completa