Lakehouse vs Data Warehouse en Microsoft Fabric: Matriz de Decisión

En el despliegue de soluciones en Microsoft Fabric, la pregunta recurrente no es cuál herramienta es mejor en términos absolutos, sino cuál se adapta mejor a la topología de tu equipo y a la naturaleza de tus datos. Como consultores, a menudo nos enfrentamos a la parálisis por análisis al elegir entre el Lakehouse y el Data Warehouse. Ambos residen sobre OneLake y utilizan el formato Delta Parquet, pero sus motores y la forma en que interactuamos con ellos definen el éxito o el fracaso de una implementación de Business Intelligence.

La elección impacta directamente en la latencia, la capacidad de aplicar lógica de negocio compleja y, sobre todo, en quién puede mantener la solución a largo plazo. No es solo una cuestión de volumen de datos; es una cuestión de gobierno y de cómo se consumen esos datos. En este artículo, desglosaremos los criterios de decisión que aplicamos en proyectos reales, desde el sector retail hasta la industria pesada, donde un error en la capa de persistencia puede degradar el rendimiento de los informes de Power BI de forma irreversible.

Para entender las diferencias fundamentales, es imprescindible revisar la Lakehouse vs Data Warehouse en Microsoft Fabric: Guía de Arquitectura y Selección, donde se sientan las bases de estos dos artefactos. Aquí daremos un paso más hacia la implementación práctica y la estrategia de consultoría.

El motor de computación: Spark frente a T-SQL

La diferencia más notable radica en el lenguaje y el motor que procesa la información. El Lakehouse está intrínsecamente ligado a Apache Spark. Esto nos permite manejar datos no estructurados o semiestructurados (como JSON de telemetría de contadores inteligentes en el sector energético) con una flexibilidad que el SQL tradicional no ofrece. Spark es ideal para transformaciones complejas, limpieza de cadenas de texto masivas y preparación de datos para modelos de ciencia de datos.

Por otro lado, el Data Warehouse de Fabric es el hogar del motor T-SQL escalonado. Si tu equipo viene de un entorno de SQL Server o Azure SQL Database, la curva de aprendizaje es prácticamente nula. El Warehouse ofrece soporte completo para DDL (Data Definition Language) y DML (Data Manipulation Language) mediante T-SQL. Esto significa que puedes realizar operaciones de INSERT, UPDATE y DELETE con la sintaxis de toda la vida, algo que en el Lakehouse requiere el uso de Spark o el SQL Analytics Endpoint (que es de solo lectura).

¿Cuándo priorizar el Warehouse?

Si tu proyecto se centra en un modelo en estrella clásico (Kimball), con tablas de Ventas, Producto y Calendario bien definidas, el Warehouse suele ser la opción ganadora. La razón es la simplicidad en la gestión de la integridad referencial (aunque sea lógica) y la facilidad para que los analistas de BI realicen consultas ad-hoc sin preocuparse por el arranque de un clúster de Spark.

Matriz de decisión técnica

Para facilitar la elección, he diseñado esta tabla comparativa basada en los factores que realmente determinan el rendimiento y la mantenibilidad en un entorno de producción.

Un punto crítico que solemos ver en auditorías es la gestión de la seguridad. Si necesitas aplicar reglas de visibilidad granulares, te recomiendo leer sobre RLS y CLS en Microsoft Fabric: Implementación de Seguridad Granular con T-SQL para entender cómo el Warehouse facilita esta tarea frente al enfoque del Lakehouse.

Flexibilidad de esquema vs. Rigidez necesaria

En el Lakehouse, operamos bajo el paradigma de schema-on-read, aunque Delta Lake nos permite forzar cierta validación. Esto es vital cuando los orígenes de datos son volátiles. Por ejemplo, en una cadena de retail donde los sistemas de TPV (Terminal Punto de Venta) cambian sus esquemas de JSON sin previo aviso, el Lakehouse permite ingestar primero y estructurar después en una capa Silver o Gold.

En el Warehouse, el esquema es estricto. Esto, que puede parecer una limitación, es en realidad una ventaja en proyectos donde la consistencia financiera es primordial. No quieres que una columna de Importe cambie de tipo de datos silenciosamente. El Warehouse garantiza que lo que entra cumple con el contrato definido.

-- Ejemplo de transformación en Warehouse para consolidar ventas
CREATE OR ALTER PROCEDURE dbo.TransformarVentasDiarias
AS
BEGIN
 INSERT INTO dbo.FactVentas (FechaKey, ProductoKey, ClienteKey, Importe, Unidades)
 SELECT 
 CAST(FORMAT(v.Fecha, 'yyyyMMdd') AS INT),
 p.ProductoKey,
 c.ClienteKey,
 SUM(v.Total),
 COUNT(v.Id)
 FROM Staging.Ventas v
 INNER JOIN dbo.DimProducto p ON v.CodigoEAN = p.CodigoEAN
 INNER JOIN dbo.DimCliente c ON v.IdCliente = c.IdExterno
 GROUP BY v.Fecha, p.ProductoKey, c.ClienteKey;
END;

En cambio, si optamos por un Lakehouse para una tarea similar, el enfoque sería mediante un Notebook de PySpark, lo cual es mucho más potente para manejar, por ejemplo, archivos con nombres inconsistentes o limpiezas basadas en expresiones regulares complejas.

# Limpieza de datos en Lakehouse usando PySpark
from pyspark.sql.functions import col, when

df_ventas = spark.read.format("delta").table("stg_ventas")

# Corregir importes negativos y nulos en un solo paso
df_limpio = df_ventas.withColumn(
 "Importe", 
 when(col("Importe") < 0, 0).otherwise(col("Importe")).cast("decimal(18,2)")
).filter(col("Fecha").isNotNull())

df_limpio.write.format("delta").mode("append").saveAsTable("fact_ventas")

Latencia y Frescura de los datos

Un error común es pensar que el Warehouse es inherentemente más lento por ser «más pesado». En Fabric, ambos comparten OneLake, por lo que la velocidad de lectura en Power BI mediante Direct Lake es prácticamente idéntica. La diferencia de latencia real ocurre en la ingesta y el procesado.

Para escenarios de casi tiempo real, el Lakehouse suele tener ventaja gracias a la integración nativa con procesos de streaming y la rapidez de Spark para procesar micro-batches. Sin embargo, para medir esto con precisión, es fundamental implementar métricas de observabilidad. Sobre esto, detallamos más en Frescura de datos en Microsoft Fabric: Cómo medir la latencia en el Lakehouse.

Concurrencia y carga de trabajo

El Data Warehouse de Fabric utiliza un motor de consultas distribuido que gestiona de forma excelente la concurrencia de múltiples usuarios lanzando consultas pesadas simultáneamente. Es el escenario típico de una empresa con 50 analistas de Power BI cruzando datos de Ventas con Presupuestos.

En el Lakehouse, aunque el SQL Analytics Endpoint permite consultas T-SQL, su propósito principal es el reporte y no la carga de trabajo transaccional intensiva. Si intentas usar el SQL Endpoint del Lakehouse como si fuera un SQL Server de producción para realizar joins masivos de tablas de miles de millones de filas con muchos usuarios concurrentes, podrías encontrar cuellos de botella que no verías en el Warehouse.

Además, el mantenimiento es distinto. En el Warehouse, Fabric se encarga de muchas tareas de optimización de archivos de forma transparente, pero no debemos ignorar la fragmentación. Puedes ampliar información en Fragmentación en Microsoft Fabric Warehouse: Guía de Compactación Automática y Optimización de Consultas.

Errores frecuentes que veo en proyectos de Fabric

• Usar el Lakehouse solo por moda: Equipos expertos en SQL perdiendo semanas aprendiendo Spark para tareas que un MERGE de T-SQL resolvería en minutos.
• Ignorar el SQL Analytics Endpoint: No saber que el Lakehouse tiene un endpoint de SQL de solo lectura y crear un Warehouse redundante solo para conectar Power BI.
• No controlar el tamaño de los archivos: Generar miles de archivos pequeños en el Lakehouse mediante Spark, lo que arruina el rendimiento del Direct Lake. Es vital ejecutar OPTIMIZE y VACUUM periódicamente.
• Subestimar el tiempo de arranque de Spark: En procesos ETL muy cortos y frecuentes, el tiempo que tarda el clúster de Spark en estar disponible puede ser mayor que el tiempo de ejecución del proceso en sí. En esos casos, el Warehouse o Data Factory con flujos de datos son más eficientes.

Checklist para tu próxima arquitectura en Fabric

• ¿El equipo sabe Python/Scala o prefiere SQL? Si es SQL, ve a Warehouse. Si es Python, Lakehouse.
• ¿Necesitas soporte para archivos no estructurados (imágenes, PDFs, JSON complejo)? Si la respuesta es sí, Lakehouse es obligatorio.
• ¿Cuál es el volumen de concurrencia de consultas SQL? Para alta concurrencia de analistas, el Warehouse ofrece un aislamiento de carga de trabajo superior.
• ¿Es necesaria la seguridad a nivel de columna (CLS) en la capa de escritura? El Warehouse es la opción más madura aquí.
• ¿Vas a realizar Data Science avanzado? El Lakehouse es el entorno natural para trabajar con modelos de ML y cuadernos de notas.

Preguntas frecuentes

¿Puedo combinar ambos en la misma arquitectura?

Absolutamente. Es una práctica común usar un Lakehouse para la capa de bronce/plata (ingesta y limpieza con Spark) y un Warehouse para la capa de oro (modelo dimensional para negocio), comunicándolos mediante Shortcuts de OneLake para evitar duplicar datos.

¿El Data Warehouse de Fabric es lo mismo que Synapse Dedicated SQL Pool?

No. Aunque comparten herencia, el Warehouse de Fabric es una evolución SaaS que no requiere gestionar índices, estadísticas de la misma forma ni distribuciones (hash/replicated). Se autogestiona mucho más, permitiendo que te centres en el modelo de datos.

¿Cuál es más barato?

Ambos consumen unidades de capacidad (CU) de Fabric. El coste dependerá del tiempo de computación. Spark (Lakehouse) consume según el tamaño del nodo y el tiempo activo, mientras que el Warehouse consume según la complejidad de las queries SQL ejecutadas. En general, para transformaciones masivas, Spark suele ser más eficiente en costes si se parametriza correctamente.

¿Qué motor es mejor para el modo Direct Lake de Power BI?

Ambos funcionan perfectamente con Direct Lake ya que ambos guardan los datos en formato Delta Parquet. Power BI lee directamente de OneLake, saltándose el motor de computación (Spark o SQL) en la mayoría de los casos, lo que proporciona un rendimiento de motor VertiPaq sobre datos en el lago.

»