OneLake y el ecosistema de Microsoft Fabric: Novedades y su impacto técnico real
Tras el despliegue masivo de Microsoft Fabric en los últimos años, las novedades presentadas en Barcelona para 2026 confirman que OneLake ya no es solo un repositorio de ficheros Delta Parquet. Se ha convertido en la capa lógica donde reside la verdad del dato, eliminando la necesidad de mover información entre servicios. Como consultores, nuestra prioridad es entender qué de todo esto es ruido de marketing y qué afecta realmente al rendimiento de nuestros modelos en producción.
El enfoque actual de Microsoft se centra en la democratización del acceso mediante Copilot y agentes de IA, pero para que esto funcione, la base de datos debe ser sólida. Si el linaje del dato es confuso o si las particiones en el Lakehouse no están optimizadas, cualquier capa de IA generará alucinaciones o latencias inaceptables. En este artículo desgranamos los cambios técnicos en OneLake y cómo debes ajustar tu estrategia de arquitectura para aprovecharlos sin comprometer la estabilidad del sistema.
Para quienes ya trabajan con esta tecnología, es fundamental entender 1. ¿Qué es exactamente Microsoft Fabric? antes de profundizar en las nuevas capacidades de federación de datos y seguridad a nivel de objeto que se están desplegando este año.
La evolución de OneLake: De almacenamiento a capa lógica
OneLake nació con la promesa del «OneDrive para los datos». La realidad técnica es que es una capa de abstracción sobre Azure Data Lake Storage (ADLS) Gen2 que utiliza el formato abierto Delta Lake. Las novedades se centran en los Shortcuts (accesos directos) y el Mirroring. Lo que antes requería complejos pipelines de ETL en Data Factory para copiar datos de una base de datos SQL o de un bucket de S3, ahora se resuelve con punteros lógicos.
En nuestros proyectos de retail, por ejemplo, esto significa que podemos atacar los datos de inventario en SAP o los datos de ventas en una instancia de SQL Server sin duplicar los terabytes de información. Sin embargo, el error más común es pensar que el Shortcut es gratis a nivel de rendimiento. Aunque no haya coste de almacenamiento duplicado, la computación para leer esos datos sigue existiendo y la latencia de red entre nubes puede penalizar tus informes de Power BI.
Shortcuts vs. Mirroring: Cuándo usar cada uno
El Mirroring es la respuesta de Microsoft para escenarios de baja latencia donde el origen de datos (como Cosmos DB, Snowflake o Azure SQL) sincroniza sus cambios casi en tiempo real con OneLake. A diferencia del Shortcut, el Mirroring sí crea una copia física en formato Delta, pero lo hace de forma gestionada y automática. Si buscas rendimiento puro en Power BI mediante Direct Lake, el Mirroring suele ser la opción ganadora frente a los Shortcuts externos.
Optimización de tablas Delta y el fin del particionamiento manual
Una de las mejoras más críticas en el ecosistema OneLake es el refinamiento del motor de V-Order. Cuando escribimos datos en un Lakehouse, Fabric aplica un algoritmo de ordenación propietario que optimiza la compresión y la velocidad de lectura para el motor VertiPaq. Esto es vital para entender la optimización de modelos semánticos en Power BI.
En entornos industriales con millones de filas por sensor, hemos comprobado que un fichero Delta mal compactado puede triplicar el tiempo de respuesta de una medida DAX sencilla. El mantenimiento de las tablas (VACUUM y OPTIMIZE) ahora se integra mejor en OneLake, permitiendo que el sistema se autogestione en gran medida. A continuación, un ejemplo de cómo forzar la optimización de una tabla de ventas mediante Spark para asegurar que el V-Order se aplica correctamente:
# Optimización de tabla de ventas en Fabric Lakehouse
# El comando OPTIMIZE compacta ficheros pequeños y mejora el rendimiento
from delta.tables import DeltaTable
tabla_ventas = "Ventas_Retail_2026"
path = f"abfss://WorkspaceID@onelake.dfs.fabric.microsoft.com/LakehouseID/Tables/{tabla_ventas}"
deltaTable = DeltaTable.forPath(spark, path)
# Ejecutar compactación y limpieza de logs antiguos
deltaTable.optimize().executeCompaction()
deltaTable.vacuum(168) # Mantener 7 días de historial para Time TravelSeguridad unificada: El reto del acceso granular
Hasta ahora, gestionar la seguridad en Fabric era un rompecabezas entre permisos de Workspace, roles de SQL Endpoint y RLS en Power BI. Las novedades de Barcelona apuntan a una OneLake Security centralizada. Esto permite definir reglas de acceso a nivel de carpeta y fichero que se heredan en todos los motores (Spark, SQL y Power BI).
Para un consultor, esto simplifica el gobierno de datos, pero exige una revisión profunda de los modelos en producción. Si aplicas seguridad en el Lakehouse, debes testear cómo afecta a Direct Lake. Si el motor no puede hacer un «fallback» correcto a DirectQuery, el informe fallará. Es un escenario similar al que vemos cuando se analizan patrones DAX que destruyen el rendimiento en DirectQuery.
| Característica | Shortcuts | Mirroring | ETL Tradicional |
|---|---|---|---|
| Copia de datos | No (Puntero lógico) | Sí (Automática en Delta) | Sí (Manual/Programada) |
| Latencia | Depende del origen | Casi tiempo real | Alta (Batch) |
| Coste Storage | Cero en Fabric | Incluido en capacidad | Duplicado |
| Uso recomendado | Datos externos (AWS/GCP) | Bases de datos operacionales | Transformaciones complejas |
Direct Lake y la conexión con el modelo semántico
El mayor cambio para quien ya tiene modelos en producción es la estabilidad de Direct Lake. En las sesiones de Barcelona se ha enfatizado la capacidad de OneLake para servir datos directamente a la memoria de Power BI sin pasar por el proceso de refresco (import). Esto cambia las reglas del juego en sectores como el público o el energético, donde los volúmenes de datos superan a menudo los límites de la capacidad Pro o Premium tradicional.
Sin embargo, hay que tener cuidado con el uso de columnas calculadas en DAX dentro de modelos Direct Lake. Al ser calculadas en tiempo de carga (si se hacen en el modelo), pueden forzar al motor a salir de Direct Lake y entrar en el lento modo DirectQuery. La recomendación técnica es clara: cualquier columna necesaria para el negocio debe persistirse en el Lakehouse mediante una transformación previa en el flujo de datos.
-- Consulta para verificar el estado de las tablas en el SQL Endpoint
-- Ayuda a identificar si las tablas están listas para Direct Lake
SELECT
t.name AS NombreTabla,
p.rows AS NumeroFilas,
s.last_user_update AS UltimaActualizacion
FROM sys.tables t
JOIN sys.partitions p ON t.object_id = p.object_id
LEFT JOIN sys.dm_db_index_usage_stats s ON t.object_id = s.object_id
WHERE t.is_ms_shipped = 0
ORDER BY p.rows DESC;Errores frecuentes al implementar las nuevas capacidades de OneLake
- Abusar de los Shortcuts: Crear una red de shortcuts anidados que genera una latencia inasumible para el usuario final.
- Ignorar el esquema: No definir tipos de datos correctos en el Lakehouse, lo que obliga a Power Query a realizar conversiones pesadas en cada lectura.
- Configuración de Capacidad: No monitorizar el consumo de CU (Capacity Units) al activar Mirroring masivo, lo que puede pausar la capacidad por exceso de uso.
- Seguridad duplicada: Mantener reglas de RLS en el modelo de Power BI y, simultáneamente, en el SQL Endpoint, generando conflictos de acceso difíciles de depurar.
Si estás empezando con estas arquitecturas, te recomiendo seguir nuestra guía práctica para crear un Lakehouse en Microsoft Fabric, donde detallamos los pasos iniciales para evitar estos problemas de base.
Conclusiones y Checklist de adopción
OneLake en 2026 no es solo una pieza tecnológica; es un cambio de mentalidad. Pasamos de mover datos a conectar con ellos. Para los que gestionamos entornos críticos, la clave está en la prudencia: medir el rendimiento antes y después de pasar una tabla de Import a Direct Lake y asegurarse de que la gobernanza no se diluye en la facilidad de crear Shortcuts.
Checklist para revisar tus modelos actuales:
- Verifica si tus orígenes de datos actuales (SQL, Snowflake) son candidatos para Mirroring para reducir latencia ETL.
- Revisa las particiones de tus tablas Delta en OneLake; asegúrate de que no tienes miles de ficheros pequeños (usa OPTIMIZE).
- Comprueba si tus medidas DAX más complejas siguen funcionando en Direct Lake sin caer en DirectQuery.
- Documenta el linaje de los Shortcuts: saber de dónde viene el dato es más difícil cuando no hay una copia física.
- Evalúa el impacto de la seguridad unificada de OneLake en tus roles actuales de Power BI.
Preguntas frecuentes
¿Sustituye OneLake completamente a un Data Warehouse tradicional?
No necesariamente. Aunque OneLake ofrece el SQL Analytics Endpoint, para transformaciones muy complejas con transaccionalidad pesada, el motor de Warehouse de Fabric sigue siendo preferible por su capacidad de DML (Data Manipulation Language) completo.
¿Qué ocurre con mis informes existentes en modo Import?
Seguirán funcionando perfectamente. La transición a OneLake y Direct Lake es opcional, aunque recomendada para grandes volúmenes de datos donde el tiempo de refresco es un cuello de botella.
¿Es más caro usar Mirroring que un ETL con Data Factory?
El Mirroring consume unidades de capacidad (CU) de Fabric de forma continua para la sincronización, mientras que Data Factory suele facturarse por ejecución o actividad. En volúmenes altos, el Mirroring suele ser más rentable y mucho más sencillo de mantener.
