A data lake prioriza flexibilidad para almacenar datos diversos; un data warehouse optimiza información estructurada para BI y reporting; un lakehouse combina almacenamiento flexible con gobierno, transacciones y analítica avanzada. La elección correcta depende del tipo de datos, cargas de trabajo, latencia, gobierno y TCO; no de cuál arquitectura sea más nueva.
Data lake
Repositorio central diseñado para almacenar grandes volúmenes de datos estructurados, semiestructurados y no estructurados, frecuentemente en su formato original. Normalmente utiliza un enfoque de schema-on-read: la estructura se aplica cuando los datos se consumen, no necesariamente cuando se almacenan. AWS y Google Cloud describen este modelo como especialmente apropiado para exploración, ciencia de datos, machine learning y fuentes heterogéneas.
Data warehouse
Plataforma optimizada para almacenar y consultar información estructurada, depurada y modelada. Está orientada a SQL, inteligencia de negocio, dashboards, análisis histórico y consultas con alta concurrencia. El esquema y las reglas de calidad suelen definirse antes de que el dato llegue a la capa de consumo.
Lakehouse
Arquitectura que busca conservar la flexibilidad y escalabilidad de un data lake, pero incorporando funciones tradicionalmente asociadas con un warehouse: tablas administradas, control transaccional, esquemas, gobierno y rendimiento para SQL, sin separar necesariamente los datos usados por BI, ingeniería, ciencia de datos e IA.
Tabla comparativa: data lake vs data warehouse vs lakehouse
| Criterio | Data lake | Data warehouse | Lakehouse |
| Tipo de datos | Estructurados, semiestructurados y no estructurados | Principalmente estructurados y curados | Estructurados, semiestructurados y no estructurados |
| Modelo de esquema | Predomina schema-on-read | Predomina schema-on-write / esquema controlado | Combina flexibilidad con enforcement y evolución de esquema |
| Principal fortaleza | Ingesta flexible y almacenamiento a escala | SQL, reporting, BI y modelos corporativos | BI, ingeniería de datos, ML e IA sobre una base común |
| Usuarios principales | Data engineers, data scientists | Analistas, BI, finanzas, áreas de negocio | Data engineers, científicos de datos, analistas y equipos de IA |
| Datos sin procesar | Sí | Generalmente no es su propósito principal | Sí |
| SQL empresarial | Depende de las capas adicionales | Fortaleza central | Sí, mediante tablas y motores compatibles |
| Machine learning / IA | Muy adecuado | Posible, pero no siempre óptimo para acceso directo | Diseñado para coexistir con ML, IA y BI |
| Transacciones ACID | No son inherentes a un lake tradicional | Sí | Sí, cuando usa formatos/capas transaccionales como Delta |
| Government | Debe diseñarse explícitamente | Maduro en escenarios estructurados | Gobierno común para distintos tipos de workload |
| Costo de almacenamiento | Generalmente bajo con object storage | Puede aumentar con almacenamiento y cómputo especializados | Busca separar almacenamiento y cómputo y reducir copias |
| Riesgo típico | Convertirse en un “data swamp” | Silos y duplicación frente a ciencia de datos/IA | Complejidad si se implementa sin gobierno ni arquitectura |
| Mejor escenario | Ingesta, histórico, logs, archivos, imágenes, exploración | Estados financieros, reporting, KPIs, BI corporativo | Organizaciones donde BI, datos e IA usan información compartida |
Microsoft señala explícitamente que un lakehouse permite trabajar con datos estructurados y no estructurados, mientras que su warehouse está optimizado para analítica relacional y SQL de alto desempeño. También reconoce que ambos pueden convivir: por ejemplo, lakehouse para procesamiento e ingeniería y warehouse para información altamente curada destinada a reporting.
¿Qué problema de negocio resuelve realmente cada arquitectura?
La pregunta equivocada es: “¿Cuál tecnología es mejor?”
La pregunta correcta es: “¿Qué tiene que hacer la empresa con esos datos y cuánto cuesta conseguirlo?”
Una empresa no genera EBITDA por tener un lakehouse. Lo genera cuando esa arquitectura reduce tiempo de decisión, evita conciliaciones manuales, disminuye errores, mejora un forecast, identifica anomalías, habilita automatización o permite poner un modelo de IA en producción.
En el modelo de Data Intelligence de MAIA by Scanda, precisamente, el objetivo no es desplegar una tecnología aislada, sino habilitar decisiones confiables y rápidas mediante datos gobernados, integrando capacidades como MDM, Data Quality, ETL/ELT, data lakes, data warehouses, modelos predictivos y dashboards.
¿Cuándo elegir un data lake?
Un data lake tiene sentido cuando el primer problema es capturar y conservar datos diversos antes de saber todos los usos que tendrán.
Elige un data lake cuando:
- Recibes grandes volúmenes de JSON, logs, IoT, imágenes, documentos, video, telemetría o archivos además de información relacional.
- Necesitas conservar datos históricos o en formato original.
- Data science necesita experimentar con información que todavía no tiene un modelo empresarial definitivo.
- Existen múltiples fuentes y cambiar su estructura antes de almacenarlas generaría demasiada fricción.
- Necesitas desacoplar almacenamiento de cómputo.
- Quieres construir una capa de aterrizaje para posteriores procesos de ingeniería, ML o IA.
AWS define el data lake precisamente como un repositorio capaz de contener datos estructurados, semiestructurados y no estructurados sin tener que definir su esquema antes de almacenarlos.
El riesgo: almacenar no equivale a gobernar
El almacenamiento puede ser barato; el desorden no.
Un lake sin catálogo, ownership, clasificación, políticas de retención, controles de acceso, calidad y trazabilidad puede terminar acumulando múltiples archivos que nadie sabe si son actuales, confiables o autorizados.
El costo aparece después:
Costo del data lake mal gobernado = almacenamiento + cómputo desperdiciado + horas de preparación + duplicados + conciliaciones + riesgo de acceso indebido.
Por eso, “tenemos todos los datos en el lake” no es sinónimo de “tenemos los datos listos para IA”.
¿Cuándo elegir un data warehouse?
El data warehouse sigue siendo una arquitectura especialmente eficiente cuando el problema está claro y la mayoría de los usuarios necesita consultar información estructurada y consistente mediante SQL.
Elige un data warehouse cuando:
- El principal objetivo es reporting financiero o ejecutivo.
- Tus fuentes son predominantemente transaccionales y estructuradas.
- Existen definiciones corporativas estables para ventas, costos, clientes, inventario o rentabilidad.
- Necesitas modelos estrella o copo de nieve.
- BI requiere consultas predecibles, controladas y concurrentes.
- Finanzas necesita que una misma métrica tenga una definición inequívoca.
- El uso de imágenes, texto libre, ML o datos semiestructurados es secundario.
AWS describe el warehouse como un repositorio central para información proveniente de sistemas transaccionales y otras fuentes, diseñado específicamente para que BI, SQL y otras aplicaciones analíticas consulten grandes volúmenes con eficiencia.
Microsoft, por su parte, recomienda warehouse cuando el escenario demanda datos relacionales estructurados, analítica empresarial, SQL avanzado, transacciones ACID y alto desempeño para reporting.
Su principal riesgo financiero: mantener demasiadas copias
El problema aparece cuando el warehouse deja de ser la única plataforma analítica.
Por ejemplo:
ERP → ETL → Data Lake → ETL → Warehouse → exportación → plataforma ML.
Cada flecha supone:
- Pipelines.
- Monitoreo.
- Cómputo.
- Reintentos.
- Controles.
- Copias.
- Personal.
- Posible desactualización.
El paper original sobre arquitectura lakehouse identifica precisamente esta duplicación entre lake y warehouse como una fuente de mayor complejidad, inconsistencias y data staleness.
¿Cuándo elegir un lakehouse?
El lakehouse cobra sentido cuando los mismos datos deben servir a varias cargas de trabajo: BI, ingeniería, ciencia de datos, IA, streaming y analítica avanzada.
No significa “poner un data lake y llamarlo lakehouse”. Necesita capas de administración que conviertan los objetos almacenados en datos confiables y transaccionables.
Entre ellas:
- Catálogo y metadatos.
- Control de esquema.
- Transacciones ACID.
- Versionado.
- Lineage.
- Seguridad y políticas.
- Optimización de tablas.
- Separación entre almacenamiento y cómputo.
- Acceso desde motores SQL, Spark, ML e IA.
El concepto fue formalizado en 2021 por Armbrust, Ghodsi, Xin y Zaharia como una arquitectura basada en formatos de acceso abierto, con soporte de primera clase para machine learning y data science y prestaciones tradicionalmente asociadas con el warehouse.
En implementaciones basadas en Delta, por ejemplo, las tablas pueden incorporar propiedades ACID —atomicidad, consistencia, aislamiento y durabilidad— sobre almacenamiento de objetos.
¿Cómo decidir entre data lake, data warehouse y lakehouse?
Paso 1. Empieza por los casos de uso, no por la tecnología
Documenta las decisiones que la organización quiere mejorar durante los siguientes 12 a 24 meses.
Ejemplos:
| Necesidad | Arquitectura que normalmente tiene ventaja |
| Estado financiero consolidado mensual | Data warehouse |
| Dashboard corporativo de ventas | Data warehouse / lakehouse |
| Almacenar IoT y telemetría de planta | Data lake / lakehouse |
| Analizar imágenes de producción | Data lake / lakehouse |
| Forecast mediante machine learning | Lakehouse |
| IA generativa sobre información corporativa | Lakehouse + gobierno y capa semántica |
| Conservar históricos para usos todavía no definidos | Data lake |
| BI + ML sobre una versión común del dato | Lakehouse |
La palabra importante es “normalmente”. La arquitectura se valida contra el entorno real; no existe una tabla capaz de sustituir el discovery.
Paso 2. Clasifica los datos que realmente tienes
Calcula qué proporción corresponde a:
- Información relacional.
- JSON, XML u otros formatos semiestructurados.
- Documentos.
- Imágenes y video.
- Eventos o telemetría.
- Datos en streaming.
- Datos históricos.
- Información sensible o regulada.
Si el 95% de la demanda es SQL sobre información financiera estructurada, construir una plataforma compleja para visión computacional “por si acaso” es tecnología buscando un problema.
Pero si BI representa sólo una parte de un ecosistema que además necesita RAG, modelos predictivos, telemetría, documentos y agentes, separar cada carga en su propio silo puede incrementar el TCO.
Paso 3. Identifica cuántas veces estás copiando el mismo dato
Este es uno de los indicadores que más rápidamente revela deuda arquitectónica.
Pregunta:
¿Cuántas copias diferentes de ventas, inventarios, clientes o producción existen para BI, data science, IA y reporting?
Cada duplicación puede crear:
- Latencia.
- Diferencias de versión.
- Costos de almacenamiento.
- Costos de movimiento.
- Pipelines adicionales.
- Superficie de seguridad adicional.
Plataformas modernas buscan reducir ese problema. Microsoft Fabric, por ejemplo, usa OneLake como almacenamiento común y permite que diferentes workloads consuman datos compartidos; su documentación destaca incluso mecanismos de acceso zero-copy mediante shortcuts.
Eso no significa que “una sola copia” sea siempre posible, pero sí que cada copia adicional debe tener una razón económica o técnica.
Paso 4. Separa almacenamiento, procesamiento y consumo
No deben evaluarse como una sola partida.
Un TCO de datos real debería considerar:
TCO anual = almacenamiento + cómputo + ingesta + transformación + orquestación + gobierno + observabilidad + seguridad + licencias + personal + transferencias + respaldos/DR.
Una plataforma con almacenamiento barato puede resultar cara si cada consulta escanea enormes cantidades de información.
Una plataforma con SQL eficiente puede resultar cara si obliga a duplicar todos los datos para machine learning.
El CFO necesita el costo completo de la ruta fuente → dato confiable → decisión, no únicamente el precio por terabyte.
Paso 5. Mide el costo de la latencia
La arquitectura también afecta cuánto tarda el dato en convertirse en decisión.
Ejemplo:
Si ventas cierra el viernes, el pipeline termina el domingo y el reporte llega el martes, técnicamente existe BI. Operativamente existen cuatro días de latencia.
Para MAIA by Scanda, “tiempo de un dato a una decisión” es una métrica particularmente útil: cuando la información aparece después de que la decisión ya debía tomarse, el problema arquitectónico se convierte en costo de negocio. Recomienda revisar cuántas versiones existen de una misma cifra y qué porcentaje de fuentes está integrado al catálogo maestro.
Paso 6. Decide cuánto gobierno necesita el negocio
A mayor exposición regulatoria o sensibilidad del dato, mayor importancia adquieren:
- Data lineage.
- RBAC.
- Catálogo.
- Clasificación.
- Políticas de acceso.
- Versionado.
- Auditoría.
- Retención.
- Quality rules.
- Ownership.
- Evidencia de cambios.
La IA aumenta esta exigencia porque el dato deja de utilizarse únicamente para producir reportes: empieza a alimentar modelos, asistentes y agentes.
La arquitectura ya no debe responder únicamente “¿puedo consultar este dato?”, sino:
“¿Quién puede utilizarlo, para qué modelo, bajo qué versión, con qué autorización y con qué evidencia?”
La arquitectura híbrida que muchas empresas realmente necesitan
Elegir entre las tres alternativas no siempre implica eliminar las otras dos.
Microsoft documenta expresamente patrones en los que las capas bronze y silver se implementan como lakehouse y la capa gold como warehouse. El lakehouse conserva y transforma información diversa; el warehouse entrega una superficie altamente curada para SQL y BI.
Un patrón empresarial puede verse así:
Fuentes → Bronze → Silver → Gold → consumo
Bronze
Información tal como llega.
- Logs.
- CSV.
- JSON.
- ERP.
- CRM.
- IoT.
- Archivos.
- Datos históricos.
Silver
Información limpia y gobernada.
- Deduplicación.
- Normalización.
- Calidad.
- MDM.
- Integración.
- Reglas comunes.
- Identidades reconciliadas.
Gold
Información preparada para una decisión o producto.
- Finanzas.
- Ventas.
- Margen.
- Inventario.
- Forecast.
- Modelos de ML.
- Semantic layer.
- Features para IA.
Microsoft define precisamente las capas Bronze, Silver y Gold como una progresión de información cruda, enriquecida y finalmente curada para consumo.
El impacto financiero: dónde se gana o pierde el ROI
Una arquitectura de datos afecta al EBITDA de manera indirecta pero concreta.
| Problema arquitectónico | Impacto económico |
| Datos duplicados | Mayor almacenamiento, procesamiento, integración y soporte |
| Pipelines redundantes | Más horas de ingeniería y mayor riesgo de falla |
| Información inconsistente | Decisiones comerciales y financieras con cifras distintas |
| Reporting lento | Decisiones tomadas después de la ventana de oportunidad |
| Datos sin calidad | Reprocesos, conciliación y modelos poco confiables |
| Falta de gobierno | Mayor exposición operativa y de cumplimiento |
| Plataforma cerrada | Switching cost y dependencia tecnológica |
| Datos no preparados para IA | Pilotos que no escalan y presupuesto inmovilizado |
| Arquitectura sobredimensionada | CAPEX/OPEX tecnológico sin resultado proporcional |
Por ello, el business case no debería formularse como:
“Migrar a una arquitectura lakehouse costará X.”
Debería formularse como:
“Hoy gastamos X en integrar, copiar, conciliar y preparar información; tardamos Y horas/días desde que aparece un dato hasta que puede usarse y tenemos Z procesos de negocio que no pueden utilizarlo para IA. La arquitectura propuesta debe mejorar estas líneas base.”
Ese cambio de pregunta es importante: la arquitectura deja de ser una compra de infraestructura y se convierte en una inversión contra una línea base económica.
¿Un lakehouse reemplaza siempre al data warehouse?
No.
Es uno de los errores más frecuentes de modernización.
Si una compañía tiene datos predominantemente estructurados, reporting estable, un modelo semántico maduro y prácticamente ninguna demanda de ML, documentos o datos no estructurados, un warehouse puede continuar siendo la alternativa más simple.
Microsoft incluso diferencia explícitamente ambas opciones dentro de una misma plataforma: warehouse para analítica relacional estructurada y lakehouse para ingeniería, datos heterogéneos, Spark, data science y cargas más flexibles.
Arquitectura moderna no significa arquitectura máxima.
Significa la menor complejidad capaz de sostener los casos de uso actuales y previstos sin crear nueva deuda técnica.
¿Qué debe revisar un CIO antes de aprobar la arquitectura?
Antes de decidir, la organización debería ser capaz de responder:
- ¿Qué decisiones de negocio debe habilitar la plataforma?
- ¿Qué porcentaje de nuestros datos es estructurado, semiestructurado y no estructurado?
- ¿Cuántas copias diferentes tenemos de los datasets críticos?
- ¿Qué workloads necesitan SQL, BI, ML, IA generativa o procesamiento en tiempo real?
- ¿Cuánto tarda hoy un dato desde que se genera hasta que puede utilizarse?
- ¿Qué costo anual tienen integración, calidad, conciliación y operación de datos?
- ¿Podemos rastrear quién usó qué dato y bajo qué autorización?
- ¿Qué componentes son abiertos y cuáles crean dependencia con un fabricante?
- ¿Podemos separar almacenamiento y cómputo para escalar económicamente?
- ¿La arquitectura permitirá que los próximos casos de IA utilicen datos gobernados o tendremos que construir otra plataforma?
Las últimas preguntas suelen pesar más que “qué fabricante gana el benchmark”.
Conclusión predictiva
El debate empresarial dejará progresivamente de ser data lake vs data warehouse. La tendencia es hacia arquitecturas donde varios motores trabajan sobre datos compartidos y gobernados, con formatos abiertos y menor necesidad de mover información entre plataformas. Fabric ya combina lakehouse y warehouse sobre OneLake, mientras que plataformas lakehouse como Databricks ofrecen BI, ingeniería, ML e IA sobre una capa común.
Eso no elimina al data warehouse: cambia su papel.
El warehouse seguirá siendo valioso como capa de consumo altamente curada. El data lake seguirá siendo útil como espacio flexible para información diversa. Lo que pierde sentido económico es mantener múltiples repositorios, pipelines y copias cuando todos existen únicamente para compensar limitaciones de la arquitectura anterior.
Para los próximos proyectos de datos e IA, la ventaja no estará en tener más información almacenada, sino en reducir cuatro distancias:
dato → dato confiable → decisión → acción.
Ahí es donde la arquitectura empieza a producir ROI.
Tus datos no necesitan otra plataforma antes de necesitar un propósito
Elegir entre data lake, data warehouse o lakehouse debería comenzar por una pregunta de negocio: ¿qué decisión, proceso o caso de IA necesita habilitar la empresa y qué está impidiendo hacerlo hoy?
At MAIA by Scanda, Data Intelligence parte de esa línea base para identificar qué datos existen, cómo se integran, qué calidad tienen, qué arquitectura necesita cada caso y dónde existe valor suficiente para justificar la inversión. El enfoque de MAIA es explícito: construir el business case con información real del cliente y demostrar valor antes de escalar el presupuesto.
Agenda una sesión de diagnóstico con MAIA by Scanda y construyamos una ruta de datos e IA basada en tus casos de uso, tu arquitectura actual y tu retorno esperado.
Preguntas frecuentes
¿Qué es mejor: data lake, data warehouse o lakehouse?
No existe una arquitectura universalmente superior. Un data warehouse es eficiente para BI y datos estructurados; un data lake para almacenar y explorar información diversa; y un lakehouse cuando BI, data engineering, ML e IA necesitan trabajar sobre una base común. La elección debe considerar workloads, gobierno, latencia y TCO, no sólo almacenamiento.
¿Necesito un lakehouse para implementar inteligencia artificial?
No necesariamente, pero sí necesitas datos accesibles, confiables, gobernados y suficientemente actualizados. Un lakehouse puede facilitar que los mismos datasets sirvan para SQL, machine learning e IA sin mantener múltiples copias. Si los datos ya cumplen esos requisitos en otra arquitectura, migrar únicamente por adoptar la etiqueta lakehouse puede destruir ROI.
¿Un lakehouse reduce costos frente a un data warehouse?
Puede reducir duplicación de datos, movimiento entre plataformas y algunos pipelines, pero no garantiza menor TCO. El resultado depende de consumo de cómputo, gobierno, almacenamiento, licenciamiento, operación y talento. La comparación correcta debe calcular el costo completo desde la ingesta hasta el consumo, no únicamente el precio del storage.
Español 
English