Lakehouse vs Data Warehouse en Microsoft Fabric: Guía de Arquitectura y Selección

En Microsoft Fabric, la distinción entre un Lakehouse y un Data Warehouse no reside en el almacenamiento. Ambos guardan la información en OneLake utilizando el formato abierto Delta Parquet. La diferencia crítica, y la que determinará el éxito de tu proyecto, se encuentra en el motor de computación que procesa esos datos, el nivel de control sobre el esquema y las competencias técnicas de tu equipo. Como consultor, veo a menudo arquitecturas que fracasan no por falta de potencia, sino por elegir el artefacto equivocado para el perfil de los ingenieros encargados de mantenerlo.

Muchos usuarios de Power BI asumen que el Data Warehouse es la evolución natural del SQL Server tradicional en la nube, mientras que el Lakehouse es un terreno exclusivo para científicos de datos. Esta es una simplificación peligrosa. El Lakehouse en Fabric ofrece un SQL Analytics Endpoint de solo lectura que permite a los analistas de SQL consultar tablas sin tocar una sola línea de Python. Sin embargo, cuando hablamos de escritura, transaccionalidad y gobierno, los caminos se bifurcan claramente. No se trata de qué herramienta es mejor, sino de cuál minimiza la fricción entre la ingesta de datos y la entrega de valor en el informe final.

Antes de profundizar, es fundamental entender que en Microsoft Fabric: La convergencia analítica SaaS y el fin de la integración manual, la plataforma busca eliminar los silos. No obstante, elegir mal el punto de partida obligará a realizar migraciones costosas o a mantener procesos de copia innecesarios entre artefactos.

El motor de computación: Spark frente a Polaris

La decisión técnica primaria es el motor de ejecución. El Lakehouse utiliza principalmente Apache Spark para las operaciones de escritura. Spark es un motor de procesamiento distribuido masivo, ideal para transformaciones complejas de datos no estructurados o semiestructurados (JSON, Parquet, imágenes, logs). Si tu origen de datos es una API de retail con JSONs anidados o telemetría de sensores industriales, el Lakehouse es el entorno natural.

Por otro lado, el Data Warehouse utiliza el motor Polaris, una evolución nativa de la nube del motor de SQL Server. Es un motor de procesamiento de consultas distribuidas que se especializa en T-SQL. Para un equipo que lleva décadas optimizando procedimientos almacenados y modelos en estrella en entornos on-premise, la curva de aprendizaje es casi nula. El Warehouse ofrece soporte completo para DDL (Data Definition Language) y DML (Data Manipulation Language) a través de T-SQL, incluyendo transacciones ACID multi-tabla, algo que en el Lakehouse requiere un manejo más cuidadoso a través de sesiones de Spark.

Latencia y frescura de los datos

En proyectos de energía o industria, donde la toma de decisiones depende de la última hora de datos, la latencia es innegociable. El Lakehouse tiende a ser más rápido en la ingesta masiva de archivos raw gracias a su naturaleza de sistema de archivos. No obstante, para medir esto con rigor, recomiendo revisar el artículo sobre frescura de datos en Microsoft Fabric: Cómo medir la latencia en el Lakehouse. El Warehouse, aunque ha mejorado drásticamente, aplica una capa de metadatos más estricta durante la escritura que puede penalizar la velocidad de ingesta si no se optimizan las cargas por lotes.

Esquema rígido vs. Esquema flexible

El Data Warehouse impone un esquema en la escritura (Schema-on-write). Esto significa que la estructura de las tablas (tipos de datos, restricciones de nulidad) debe definirse antes de cargar los datos. Es la opción ideal para el «Gold Layer» o la capa de presentación de un modelo Kimball. Asegura que los informes de Power BI no rompan por cambios inesperados en los tipos de datos de origen.

El Lakehouse permite un enfoque de esquema en la lectura (Schema-on-read). Puedes volcar archivos en carpetas y decidir cómo interpretarlos después. Esto es vital en las fases iniciales de descubrimiento o en proyectos de investigación donde el origen de datos cambia con frecuencia. Si quieres aprender a configurar uno desde cero, consulta la Guía Práctica: Creando un Lakehouse en Microsoft Fabric.

Competencias del equipo: El factor decisivo

No subestimes el coste de reentrenar a un equipo. Si tienes una plantilla de desarrolladores BI que dominan SSMS y procedimientos almacenados, forzarlos a usar Notebooks de Python para limpiar una tabla de Ventas es una ineficiencia operativa. Para ellos, el Warehouse ofrece una experiencia familiar con la ventaja de poder conectar SSMS, Azure Data Studio y sqlcmd a Microsoft Fabric Warehouse de forma nativa.

Si, por el contrario, tu equipo viene del ecosistema de Databricks o Big Data, el Lakehouse les resultará mucho más potente. El uso de Notebooks permite una documentación viva y la integración de librerías de Machine Learning que no existen en el entorno SQL puro. Aquí un ejemplo de cómo se realizaría una limpieza básica en un Lakehouse utilizando PySpark:

# Transformación de ventas en Lakehouse usando Spark
from pyspark.sql.functions import col, when

# Leer datos de la zona Bronze
df_ventas = spark.read.format("delta").load("Tables/ventas_raw")

# Limpieza y tipado de datos
df_clean = df_ventas.withColumn(
 "ImporteTotal", 
 col("Cantidad") * col("PrecioUnitario")
).filter(col("ImporteTotal") > 0)

# Guardar en la zona Silver
df_clean.write.format("delta").mode("overwrite").saveAsTable("ventas_procesadas")

Comparemos esto con el enfoque equivalente en el Data Warehouse mediante T-SQL. La ventaja aquí es el soporte para transacciones complejas y la facilidad de mantenimiento para perfiles SQL:

-- Transformación de ventas en Warehouse usando T-SQL
CREATE OR ALTER PROCEDURE stp_ProcesarVentas
AS
BEGIN
 BEGIN TRANSACTION;
 -- Limpieza de datos existentes para el periodo
 DELETE FROM [dbo].[Fact_Ventas] 
 WHERE [FechaKey] >= CAST(GETDATE() AS DATE);

 -- Inserción de nuevos datos calculados
 INSERT INTO [dbo].[Fact_Ventas] (
 [VentaID], [ProductoID], [FechaKey], [ImporteTotal], [Unidades]
 )
 SELECT 
 v.ID, 
 v.ProductID, 
 v.DateKey, 
 v.Qty * v.UnitPrice, 
 v.Qty
 FROM [stg].[Ventas] v
 WHERE v.Qty > 0;
 COMMIT TRANSACTION;
END

Mantenimiento y rendimiento a largo plazo

Un error común es pensar que al ser SaaS, Fabric se encarga de todo. En el Warehouse, la fragmentación de archivos Delta puede degradar el rendimiento de las consultas en tablas con millones de registros de Ventas y Clientes. Es vital comprender la fragmentación en Microsoft Fabric Warehouse y su compactación automática para evitar latencias inesperadas en Power BI.

En el Lakehouse, aunque la gestión de archivos es más manual, tienes control total sobre el comando OPTIMIZE y VACUUM de Delta Lake, lo que permite afinar el rendimiento para cargas de trabajo específicas de Data Science. Si buscas una metodología de medición real para tus entornos, te sugiero revisar las pruebas de rendimiento en Fabric Warehouse, aplicables también para comparar el SQL Endpoint del Lakehouse.

Errores frecuentes al elegir arquitectura

• Elegir Warehouse para datos no estructurados: El Warehouse solo acepta tablas. Intentar forzar la ingesta de JSONs complejos mediante T-SQL es ineficiente comparado con la capacidad nativa de Spark.
• Ignorar el SQL Endpoint del Lakehouse: Muchos creen que si eligen Lakehouse no pueden usar SQL. Falso. Puedes crear vistas SQL sobre tablas de Lakehouse para que Power BI las consuma en modo Direct Lake.
• No considerar la concurrencia: El Data Warehouse de Fabric tiene límites de concurrencia diferentes a los de un Dedicated SQL Pool de Synapse. En escenarios de cientos de usuarios simultáneos, el escalado automático de Fabric debe ser monitorizado de cerca.
• Subestimar el coste de Spark: Los tiempos de arranque de los clusters de Spark (Cold Start) pueden penalizar procesos pequeños y frecuentes. El Warehouse es instantáneo.

Checklist para tu decisión final

1. ¿Tus fuentes de datos son principalmente archivos JSON, XML o logs sin estructura fija? Elige Lakehouse.
2. ¿Tu equipo de desarrollo prefiere T-SQL y procedimientos almacenados sobre Python/Notebooks? Elige Data Warehouse.
3. ¿Necesitas transacciones ACID que afecten a múltiples tablas de forma atómica? Elige Data Warehouse.
4. ¿Vas a realizar tareas intensivas de Machine Learning o procesamiento de datos masivos con librerías externas? Elige Lakehouse.
5. ¿Tu prioridad absoluta es la compatibilidad con herramientas heredadas como SSMS o dbt (SQL adapter)? Elige Data Warehouse.

Preguntas frecuentes

¿Puedo mover datos de un Lakehouse a un Warehouse fácilmente?

Sí, gracias a OneLake. Puedes usar «Shortcuts» para ver las tablas del Lakehouse dentro del Warehouse sin mover los datos físicamente. Esto permite una arquitectura híbrida donde la ingesta es en el Lakehouse y la presentación en el Warehouse.

¿Cuál es más barato en términos de capacidad de Fabric?

Ambos consumen Unidades de Capacidad (CU). Sin embargo, Spark consume capacidad mientras el cluster está activo (mínimo 1 minuto), mientras que el Warehouse factura por el uso real del motor de consulta. Para cargas pequeñas, el Warehouse suele ser más eficiente en costes.

¿Qué opción es mejor para Power BI?

Ambos soportan el modo Direct Lake, que ofrece rendimiento de Import sin necesidad de refrescos. El Warehouse ofrece una experiencia más similar a una base de datos tradicional para el modelado de datos, facilitando la creación de relaciones y medidas DAX.

¿Soporta el Warehouse claves primarias y foráneas?

El Warehouse permite definir la sintaxis de Primary Keys y Foreign Keys, pero actualmente son informativas (non-enforced). Sirven para que el optimizador de consultas genere mejores planes de ejecución, pero la integridad debe controlarse en el proceso de carga.