OneLake: Arquitectura y estrategias de implementación en Microsoft Fabric

La fragmentación de datos ha sido, históricamente, el mayor lastre para la agilidad en los proyectos de Business Intelligence. En entornos corporativos complejos, es habitual encontrar la misma tabla de Ventas replicada en un Data Lake de Azure, un almacén de datos de SQL Server y múltiples extractos locales. Microsoft Fabric intenta erradicar este problema con OneLake, una capa de almacenamiento unificada que funciona bajo la premisa de «un solo inquilino, un solo lago».

Como consultor, mi enfoque con OneLake no es verlo como un simple repositorio de archivos, sino como un sistema operativo de datos. OneLake es a los datos lo que OneDrive es a los documentos de Office: un lugar donde la colaboración y el acceso centralizado eliminan la necesidad de mover o copiar información de un lado a otro. No se trata solo de ahorrar costes de almacenamiento, sino de garantizar la integridad de la verdad única en toda la organización.

El éxito de una implementación en Fabric depende de entender que OneLake no es opcional. Todo lo que ocurre en los distintos motores de Fabric —ya sea Spark, SQL o Power BI— termina persistiendo en OneLake en un formato abierto: Delta Parquet. Esta estandarización es la que permite que, por primera vez, el equipo de ingeniería de datos y el de analítica de negocio trabajen sobre el mismo archivo físico sin conflictos de concurrencia ni procesos de exportación tediosos.

La arquitectura de OneLake: Un lago lógico sobre ADLS Gen2

Aunque a nivel de usuario OneLake se presenta como una solución SaaS (Software as a Service), técnicamente está construido sobre Azure Data Lake Storage (ADLS) Gen2. Sin embargo, la diferencia fundamental radica en su estructura jerárquica. Mientras que en ADLS Gen2 gestionamos cuentas de almacenamiento independientes, OneLake organiza todo el contenido del tenant bajo un único espacio de nombres. Esta jerarquía se divide en Áreas de Trabajo (Workspaces) y Elementos (Items) como Lakehouses o Warehouses.

Un aspecto crítico que suelo enfatizar en mis auditorías es el uso de los dominios. OneLake permite agrupar áreas de trabajo en dominios (por ejemplo, Finanzas, Logística o RRHH), facilitando una gobernanza descentralizada pero bajo un control global. Esto es vital para cumplir con normativas de seguridad y para evitar que el lago se convierta en un pantano de datos sin dueño. Para profundizar en este aspecto, es recomendable revisar cómo la Gobernanza de datos en el flujo de trabajo: Impacto de Fabric Analytics 2026 influye en la estructuración de estos dominios.

Desde el punto de vista del rendimiento, OneLake utiliza una tecnología denominada V-Order. Se trata de un algoritmo de optimización de escritura para archivos Parquet que permite a los motores de Microsoft, especialmente a Power BI, leer los datos con una velocidad significativamente superior. Cuando escribimos una tabla de Clientes o Hechos_Ventas desde un Notebook de Fabric, el sistema aplica este ordenamiento de forma transparente, preparando el terreno para el modo de conexión Direct Lake.

Shortcuts: Virtualización de datos sin movimiento

La característica más disruptiva de OneLake son los shortcuts o atajos. Un shortcut es esencialmente un puntero simbólico que referencia datos ubicados en otro lugar (otra carpeta de OneLake, un ADLS Gen2 externo, Amazon S3 o Google Cloud Storage) y los hace aparecer como si estuvieran localmente en tu Lakehouse. El valor aquí es doble: cero latencia de copia y cero duplicidad de costes de almacenamiento.

En proyectos de retail donde la información de inventario reside en un bucket de AWS S3 y las ventas en OneLake, los shortcuts permiten realizar un JOIN entre ambas fuentes sin mover un solo byte de S3 a Azure. Esta capacidad de Shortcuts en OneLake: Virtualización de datos multicloud en Microsoft Fabric es lo que realmente habilita una arquitectura de Data Mesh funcional.

# Ejemplo de acceso a un Shortcut desde un Notebook de Spark en Fabric
# El shortcut 'S3_Ventas_Historicas' apunta a un bucket de Amazon S3

df_ventas = spark.read.format("delta").load("Files/Shortcuts/S3_Ventas_Historicas/ventas_2023")

# Realizamos una agregación simple sin haber movido los datos físicamente
df_resumen = df_ventas.groupBy("ID_Tienda").sum("Importe_Total")

display(df_resumen)

Es importante entender que los shortcuts no son solo para nubes externas. La práctica recomendada es usarlos internamente para compartir dimensiones maestras. Si el equipo de Finanzas tiene la tabla Calendario oficial, el resto de departamentos no debe crear la suya; simplemente crean un shortcut al Lakehouse de Finanzas. Esto asegura que todos los informes de la compañía utilicen la misma jerarquía temporal y festivos.

Eliminación de duplicidades y almacenamiento unificado

Antes de Fabric, si querías que un Data Warehouse SQL consumiera datos de un Data Lake, a menudo tenías que recurrir a procesos de carga (ETL) que duplicaban la información. OneLake elimina esta redundancia mediante el formato Delta Lake. Tanto el SQL Analytics Endpoint como los Notebooks de Spark leen y escriben en las mismas tablas Delta. Esta interoperabilidad es el núcleo de lo que explicamos al hablar de Delta Lake en OneLake: El motor de la interoperabilidad en Microsoft Fabric.

La siguiente tabla compara cómo ha cambiado el flujo de trabajo con la llegada de OneLake frente a las arquitecturas tradicionales de almacenamiento en la nube:

El impacto en el rendimiento es tangible. Al eliminar las capas de traducción entre el almacenamiento y el motor de visualización, reducimos los tiempos de refresco. Con Direct Lake, el motor de Power BI (Analysis Services) carga las columnas de los archivos Parquet de OneLake directamente en memoria cuando se solicitan, lo que supone el fin de los procesos de carga en Microsoft Fabric para muchos escenarios de gran volumen.

Implementación técnica: SQL y Spark conviviendo en OneLake

Una duda frecuente es cómo interactúan los diferentes lenguajes sobre OneLake. Imagina un escenario donde el equipo de ingeniería limpia datos de Sensores industriales usando Python y el equipo de BI necesita esos datos para un modelo en estrella. En el Warehouse de Fabric, podemos consultar directamente las tablas creadas por Spark sin realizar ninguna importación.

-- Consulta desde el SQL Analytics Endpoint de un Lakehouse
-- Accediendo a una tabla creada originalmente mediante un proceso de Spark

SELECT 
 p.NombreProducto,
 SUM(v.Cantidad) AS TotalUnidades,
 SUM(v.Importe) AS IngresoTotal
FROM 
 [MiLakehouse].[dbo].[Ventas_Procesadas] v
JOIN 
 [MiLakehouse].[dbo].[Productos] p ON v.ID_Producto = p.ID_Producto
WHERE 
 v.Fecha >= '2024-01-01'
GROUP BY 
 p.NombreProducto
ORDER BY 
 IngresoTotal DESC;

Para garantizar que este rendimiento se mantenga, es fundamental monitorizar el estado de los archivos. OneLake permite que otros servicios consuman estos datos mediante el protocolo de Azure Storage. Por ejemplo, podemos integrar datos de Eventhouse a OneLake para análisis en tiempo real, manteniendo la coherencia del esquema Delta en todo momento.

Otro punto clave es la optimización manual. Aunque Fabric gestiona mucho por debajo, en tablas de gran volumen (cientos de millones de filas), forzar el mantenimiento de los archivos Delta es una buena práctica para evitar el problema de los «archivos pequeños» que degrada el rendimiento de lectura.

# Mantenimiento de tablas Delta para optimizar OneLake
# Se recomienda ejecutar periódicamente en tablas de alta rotación

from delta.tables import *

deltaTable = DeltaTable.forPath(spark, "Tables/Fact_Ventas")

# Compactación de archivos y eliminación de versiones antiguas (Vacuum)
deltaTable.optimize().executeCompaction()
deltaTable.vacuum(retentionHours=168) # 7 días de retención

Errores comunes en la adopción de OneLake

En mis años de consultoría, he visto patrones que se repiten y que pueden arruinar una implementación de Fabric desde el inicio:

• Tratar OneLake como una carpeta de red: Subir archivos CSV o Excel desordenados sin una estructura de capas (Bronze, Silver, Gold). OneLake es un motor analítico, no un vertedero.
• Abuso de Shortcuts encadenados: Crear un shortcut que apunta a otro shortcut que apunta a un tercer Lakehouse. Esto dificulta enormemente el seguimiento del linaje de datos y puede impactar levemente en la latencia de metadatos.
• Ignorar la seguridad a nivel de objeto: Confiar ciegamente en que todos los usuarios del Workspace pueden verlo todo. Es necesario definir correctamente los roles y, cuando sea posible, usar OneSecurity para heredar permisos.
• No considerar la región: Aunque OneLake es global, los datos residen físicamente en la región de la capacidad de Fabric. Crear shortcuts entre regiones muy distantes puede generar costes de salida de datos (egress) imprevistos.

Resumen y próximos pasos

OneLake no es solo una evolución tecnológica; es un cambio de mentalidad en la arquitectura de datos. Al desacoplar el almacenamiento del cómputo y estandarizar en Delta Parquet, Microsoft ha resuelto el problema de la fragmentación que obligaba a las empresas a gastar el 80% de su tiempo en mover datos y solo el 20% en analizarlos.

Para aprovechar al máximo este ecosistema, te sugiero seguir este checklist de implementación:

1. Define una estructura de Dominios clara que refleje la organización de tu empresa.
2. Establece el formato Delta Parquet como el estándar obligatorio para todas las tablas de producción.
3. Prioriza el uso de Shortcuts antes que cualquier proceso de copia de datos (Data Factory o Pipelines).
4. Activa la optimización V-Order en tus Notebooks de Spark para maximizar la velocidad en Power BI.
5. Implementa una política de mantenimiento (VACUUM/OPTIMIZE) para evitar la degradación del rendimiento en tablas grandes.

Preguntas frecuentes

¿OneLake tiene un coste independiente del de la capacidad de Fabric?

Sí, OneLake se factura por el almacenamiento utilizado (GB/mes), de forma similar a como funciona ADLS Gen2. Los costes de computación para leer o escribir en él se cargan a tu capacidad de Fabric (F-SKU o P-SKU).

¿Puedo acceder a OneLake desde herramientas que no sean de Microsoft?

Absolutamente. Al ser compatible con las APIs de ADLS Gen2, puedes usar herramientas como Azure Storage Explorer, Databricks o incluso scripts de Python locales utilizando las librerías estándar de Azure Blob Storage para interactuar con los datos.

¿Qué sucede si borro un shortcut? ¿Se borran los datos de origen?

No. Un shortcut es solo un enlace. Si borras el shortcut en tu Lakehouse, los datos originales en S3, ADLS o el otro Lakehouse permanecen intactos. Solo se elimina el acceso virtual desde ese punto específico.

¿Es OneLake adecuado para datos no estructurados como imágenes o PDFs?

Sí, OneLake permite almacenar cualquier tipo de archivo en la sección «Files» de un Lakehouse. Aunque su potencia brilla con datos tabulares en formato Delta para analítica, puede servir como repositorio central para archivos de entrada en procesos de Inteligencia Artificial.