Comparar Fabric Lakehouse y Fabric Warehouse dentro del ecosistema de Microsoft Fabric nos lleva a analizar dos enfoques arquitectónicos que, aunque comparten una base tecnológica común, se diseñan para resolver problemas muy diferentes. Ambas soluciones surgen como respuesta a la necesidad de gestionar datos en un panorama empresarial cada vez más complejo, pero destacan por sus diferencias en flexibilidad, rendimiento y casos de uso.
Para empezar, debemos saber que Microsoft Fabric utiliza Delta Lake como formato de tabla unificado tanto para los componentes de Lakehouse como para los Warehouses. Las tablas Delta son esencialmente archivos Delta Parquet, un formato de código abierto compatible con la mayoría de las soluciones de otras nubes. Esto permite un acceso sin problemas a los datos en todos los motores de proceso de Microsoft Fabric y también entre diferentes nubes como Google, AWS, IBM, etc.
Por lo tanto, aunque los Warehouses en Microsoft Fabric pueden tener algunas similitudes con las bases de datos SQL tradicionales que tan bien conocemos, también tienen muchas características en común con los Lakehouses, incluyendo el uso de tablas Delta Parquet. Pero, entremos un poco más en detalle.
¿Qué es Fabric Lakehouse?
Fabric Lakehouse es una solución híbrida que combina lo mejor de los data lakes y los data warehouses. Este modelo permite gestionar datos estructurados, semiestructurados y no estructurados en un entorno único y flexible. Su arquitectura está basada en tecnologías de almacenamiento de objetos, como Delta Lake, optimizadas para trabajar con grandes volúmenes de datos en formatos diversos como Parquet, CSV y JSON.
Su enfoque permite a las empresas procesar datos en bruto, realizar análisis exploratorios y aplicar modelos avanzados como machine learning, sin necesidad de transformaciones estrictas previas. Por esta razón, Fabric Lakehouse es ideal para casos en los que se manejan datos históricos, flujos de datos en tiempo real o múltiples fuentes heterogéneas.
Fabric Warehouse: Optimización para consultas estructuradas
Fabric Warehouse, por su parte, representa el enfoque más tradicional de los almacenes de datos. Diseñado para cargas de trabajo analíticas OLAP, este modelo almacena los datos en un formato tabular estructurado que facilita consultas rápidas y eficientes. Su base tecnológica incluye índices columnstore que aceleran significativamente el tiempo de respuesta en análisis complejos.
Fabric Warehouse se destaca en escenarios de reporting empresarial, donde la precisión y la rapidez son fundamentales. Además, su integración nativa con herramientas como Power BI y Excel lo convierte en una elección prioritaria para la generación de informes y dashboards operativos.
Diferencias entre Fabric Lakehouse y Warehouse
Aunque ambos modelos comparten objetivos relacionados con la gestión de datos, presentan diferencias importantes en cuanto a flexibilidad, rendimiento y casos de uso.
Flexibilidad en el manejo de datos
Fabric Lakehouse ofrece un enfoque más versátil, permitiendo trabajar con datos en su estado original sin transformaciones previas. Esto es crucial en proyectos donde los datos cambian constantemente o provienen de múltiples fuentes con formatos variados. Por otro lado, Fabric Warehouse requiere un modelo de datos predefinido y procesos ETL claros para garantizar la eficiencia en el análisis.
Rendimiento en consultas y análisis
En términos de rendimiento, Fabric Warehouse sobresale en escenarios donde se necesitan consultas estructuradas y rápidas sobre datos optimizados. En cambio, Fabric Lakehouse es más adecuado para procesar grandes volúmenes de información y ejecutar análisis avanzados, aunque puede ser menos eficiente para consultas pequeñas.
Integración con herramientas de análisis
Fabric Lakehouse se integra de manera natural con entornos de Big Data y plataformas como Apache Spark, lo que lo hace ideal para análisis exploratorio y aprendizaje automático. Fabric Warehouse, por su parte, está optimizado para herramientas de BI tradicionales, siendo la opción preferida para usuarios de Power BI y Excel.
Endpoints de Fabric. La principal diferencia
Hasta ahora hemos estado viendo las definiciones más comerciales y las diferencias teóricas entre ambos sistemas. Vamos ahora con algo que va a marcar la diferencia entre ambas soluciones, los endpoints o puntos de conexión (me niego a llamarlos puntos finales como me niego a llamar tejido a fabric). Estos endpoints son los extremos finales de nuestros lakehouse y warehouse a los que nos vamos a conectar y vamos a ver que hay 3 tipos principales.
Lakehouse Endpoint para Spark Runtimes/Libraries
Para trabajar con archivos y tablas de Lakehouse, ya sea para análisis, transformaciones o procesamiento usando Spark, nos conectaremos al endpoint del Lakehouse que está separado del endpoint de SQL Analytics. Igual que con los métodos estándar fuera de Fabric para trabajar con archivos y tablas delta, para conectarnos, usaremos la URL, la ruta ABFS o montaremos el Lakehouse directamente en nuestro explorador. El uso de Spark nos permite realizar operaciones de escritura con Scala, PySpark, Spark SQL o R. Sin embargo, si deseamos utilizar T-SQL, deberemos utilizar SQL Analytics Endpoint, donde vamos a ver que solo podemos realizar operaciones de “solo lectura”.
SQL Analytics Endpoint (Lakehouse)
El endpoint SQL Analytics se crea automáticamente cuando creamos un Lakehouse. Cada Lakehouse tiene solo un endpoint SQL y, como cada Workspace o Área de Trabajo de Fabric puede tener más de un Lakehouse, la cantidad de endpoints SQL en un espacio de trabajo coincide con la cantidad de Lakehouses que tengamos.
Estos endpoint nos ofrecen una experiencia SQL para leer tablas Delta. Es importante destacar que este Endpoint es solo lectura y únicamente sirve para las tablas, como es lógico no podremos usar SQL para consultar archivos e información no estructurada. Por algo la S de SQL significa Structured, ¿no?
Esto no es todo, SQL Analytics Endpoint no solo nos permite analizar las tablas Delta utilizando T-SQL, también vamos a poder guardar funciones, generar vistas y aplicar seguridad a nivel de objetos SQL. Gracias a estas funcionalidades los ingenieros de datos podrán crear una capa relacional sobre los datos físicos en Lakehouse, y exponerlos para que los analistas usen sus a herramientas de informes utilizando una cadena de conexión SQL.
Ya que estos endpoint son solo lectura, la creación/modificación de tablas Delta (y los datos dentro de las tablas Delta) se debe hacer usando Apache Spark. Una vez creadas las tablas Delta con Spark dentro de Lakehouse se podrán ver y leer automáticamente a través del endpoint SQL. ¿Y qué pasa si hay tablas Delta externas creadas con código Spark? Estas tablas no serán visibles desde el endpoint SQL hasta que cree un acceso directo o Shortcut a la tabla Delta externa.
Seguridad en el SQL Endpoint de Fabric Lakehouse
Como hemos visto, podemos configurar la seguridad a nivel de objeto (OLS) para acceder a los datos mediante el punto final de análisis SQL. Sin embargo, es importante destacar que estos permisos solo se aplicarán cuando accedamos a los datos a través endpoint de análisis SQL. Si deseamos asegurar que no se pueda acceder a nuestros datos de otras maneras (a través de diferentes endpoints o directamente), debemos establecer roles y permisos en el Área de Trabajo.
Conexión al SQL Analytics Endpoint
Para esta parte del artículo me voy a basar en este del blog de Microsoft publicado por Marc Bushong y voy a tomar prestadas sus fotos.
Dejadme que antes de nada os enseñe su Área de Trabajo de Fabric. Como veis tiene un Lakehouse llamado “BronzeLakehouse” y, en la imagen, podemos ver el endpoint de SQL Analytics (rojo) y el endpoint de Lakehouse (verde)
Accediendo al endpoint de Lakehouse vemos Files (rojo) y Tables Delta (verde). Si queremos asegurarnos, en la esquina superior derecha veremos un menú desplegable con el endpoint estamos viendo seleccionado.
Si cambiamos la vista al Endpoint de SQL Analytics vais a ver que ya solo podemos ver las tablas:
Antes de pasar al siguiente endpoint tenemos que saber que también podemos conectar al endpoint SQL desde fuera de Fabric con las herramientas que conocemos como SSMS o Azure Data Studio. Simplemente tendremos que poner la autenticación y cadena de conexión del endpoint como si de cualquier otra conexión de servidor SQL se tratara.
Data Warehouse Endpoint
El Data Warehouse Endpoint opera como un DWH SQL en un entorno tradicional. Esto significa que proporciona compatibilidad casi total con T-SQL, de manera similar a una base de datos SQL Server implementada en nuestros servidores. Este endpoint ofrece múltiples ventajas funcionales.
T-SQL de lectura y escritura
Entre estas ventajas funcionales podemos destacar que cuenta con soporte para lectura y escritura en tablas Delta, lo que permite consultar los datos tanto con Spark como con T-SQL. Sin embargo, mientras que en el Lakehouse las operaciones de escritura solo se podían realizar con Spark, en el Warehouse es al revés y únicamente pueden realizarse mediante T-SQL. Además, incluye soporte casi completo para operaciones DML y DDL, lo que abarca la ingesta, el modelado y el desarrollo de datos a través de T-SQL o mediante interfaces gráficas. Esto nos permite un control absoluto sobre la creación de tablas, la carga de datos y las transformaciones, utilizando herramientas como COPY INTO, pipelines, dataflows o métodos de ingesta cruzada entre bases de datos como CREATE TABLE AS SELECT (CTAS), INSERT..SELECT o SELECT..INTO. Solo hay una pega, a día de hoy todavía no es compatible con la sintaxis MERGE.
Soporte ACID
Este endpoint también garantiza el cumplimiento de las propiedades ACID para transacciones aunque trabaje con tablas Delta. Cabe destacar que, aunque Lakehouse ofrece compatibilidad ACID, se limita a las tablas Delta, por lo que los ficheros de un Lakehouse podrían no cumplir con estas propiedades.
Transacciones Multitabla
Otra característica es el soporte para transacciones que abarcan múltiples tablas, lo que facilita flujos de trabajo complejos. Al combinar estas capacidades de lectura/escritura con las herramientas de ingesta entre bases de datos, es posible integrar datos sin complicaciones desde varios Warehouses o Lakehouses. Cuando se ingieren datos en el Warehouse, estos se almacenan automáticamente en formato Delta dentro de OneLake, garantizando una estructura optimizada y unificada.
En la siguiente imagen podemos ver todo lo que hemos comentado hasta ahora en acción, una consulta entre bases de datos para cargar datos en el Warehouse desde el Lakehouse, donde se crea y se carga la tabla de Warehouse «holiday.Warehouse_Holiday_Clean» con los datos de la tabla «Silverlakehouse.dbo.Holiday_Clean» del Lakehouse como origen, y luego se muestran los registros.
Conclusión
Para cerrar esta comparativa, queda claro que tanto Fabric Lakehouse como Fabric Warehouse son piezas fundamentales en el ecosistema de Microsoft Fabric, cada uno respondiendo a diferentes necesidades en el manejo y análisis de datos. A través de su integración en OneLake, ambas soluciones permiten un acceso uniforme y una gestión eficiente de los datos, aprovechando las ventajas de las tablas Delta como formato unificado.
La verdadera innovación radica en cómo Microsoft Fabric ofrece puntos de conexión (endpoints) especializados para cada solución. Estos endpoints no sólo habilitan el acceso a los datos según las necesidades específicas de cada modelo, sino que también permiten combinar diferentes entornos de datos en operaciones cruzadas, como lo demuestra la imagen adjunta. Aquí vemos cómo los endpoints para Lakehouse y Warehouse trabajan en conjunto, integrando datos de manera fluida y demostrando el poder de esta arquitectura unificada.
Este enfoque, que facilita tanto la conexión como el intercambio de datos entre sistemas, posiciona a Microsoft Fabric como una solución robusta y flexible para las necesidades actuales de la analítica empresarial.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
