Power BI y Direct Lake: El fin de los procesos de carga en Microsoft Fabric

Durante años, los consultores de Business Intelligence nos hemos movido en un compromiso constante entre frescura de datos y rendimiento. Si necesitábamos velocidad de respuesta instantánea en los informes, optábamos por el modo Import, asumiendo la latencia de los procesos de refresco y los límites de memoria de la capacidad. Si la prioridad era el tiempo real o volúmenes masivos, DirectQuery era la solución, a costa de penalizar la experiencia de usuario y sobrecargar el origen de datos.

La llegada de Microsoft Fabric introduce Direct Lake, un modo de almacenamiento que rompe esta dicotomía. No es una mejora incremental de lo que conocíamos; es un cambio de paradigma en la forma en que el motor de Power BI (Analysis Services) interactúa con los datos. En lugar de copiar los datos a archivos propietarios .it o enviar consultas SQL al origen, Direct Lake lee directamente archivos Parquet en formato Delta desde OneLake. Es, en esencia, tener el rendimiento del motor VertiPaq sin el paso intermedio de la carga de datos.

En este artículo analizaremos por qué esta tecnología es la pieza angular de Microsoft Fabric: La convergencia analítica SaaS y el fin de la integración manual y cómo implementarla evitando los errores de configuración que degradan el rendimiento al modo DirectQuery tradicional.

¿Qué es Direct Lake y por qué cambia las reglas del juego?

Direct Lake es un modo de almacenamiento exclusivo de los modelos semánticos de Power BI en Microsoft Fabric. Su funcionamiento se basa en la capacidad del motor de Analysis Services para cargar columnas de archivos Parquet directamente en memoria bajo demanda. Cuando un usuario interactúa con un informe, el motor identifica qué columnas son necesarias y las «mapea» desde OneLake. Si la columna ya está en la memoria de la capacidad, la respuesta es instantánea.

La diferencia fundamental con el modo Import es que no hay una duplicidad de datos. En el modelo tradicional, si tenemos un Lakehouse y un modelo en Import, los datos residen en el almacenamiento del Lakehouse y otra copia reside en el modelo de Power BI. Con Direct Lake, el modelo semántico es simplemente una capa de metadatos que apunta a los archivos Delta Parquet. Esto impacta directamente en la frescura de datos en Microsoft Fabric, ya que en el momento en que un proceso de Spark o un Pipeline de datos actualiza una tabla en el Lakehouse, el modelo de Power BI refleja los cambios sin necesidad de un refresco programado.

El fin de la transcodificación manual

En el modo Import, durante el refresco, el motor debe leer los datos del origen, transformarlos y comprimirlos en el formato de columna propietario de Analysis Services. Direct Lake aprovecha que los archivos Delta en Fabric ya están organizados de forma columnar. Si además aplicamos el V-Order (una optimización de escritura propia de Microsoft), el motor de Power BI puede leer esos archivos casi sin transformación adicional, lo que reduce drásticamente el uso de CPU durante el acceso inicial a los datos.

Arquitectura y el concepto de Fallback

No todo es tan sencillo como activar un interruptor. El éxito de Direct Lake depende de que el motor pueda mantener los datos en el «carril rápido». Existe un mecanismo de seguridad llamado Fallback (retroceso). Si el motor encuentra una situación que no puede gestionar en modo Direct Lake, conmutará automáticamente a modo DirectQuery.

El Fallback ocurre principalmente por tres razones:

• Límites de memoria: Si el tamaño de las columnas necesarias excede la memoria disponible en tu capacidad de Fabric (SKU), el modelo pasará a DirectQuery para evitar un error de fuera de memoria.
• Seguridad de datos avanzada: Algunas configuraciones de RLS (seguridad a nivel de fila) complejas o vistas de SQL que no están materializadas pueden forzar este comportamiento.
• Tipos de datos no compatibles: Aunque es raro en modelos limpios, ciertos tipos de datos complejos en el Delta Lake pueden no ser legibles directamente por VertiPaq.

Para evitar esto, es fundamental monitorizar el estado del modelo. Como siempre digo en mis proyectos, no se puede optimizar lo que no se mide. Debemos usar Fabric Capacity Metrics para entender si estamos llegando al límite de nuestras Unidades de Capacidad (CUs) y si eso está provocando que nuestros usuarios sufran la lentitud de DirectQuery sin saberlo.

Optimización mediante V-Order y mantenimiento de tablas

Para que Direct Lake brille, las tablas deben estar optimizadas. Microsoft Fabric introduce una extensión del formato Parquet que aplica un ordenamiento específico a los datos durante la escritura. Esto permite que el motor de Power BI realice escaneos mucho más rápidos y que la compresión sea más eficiente.

Cuando trabajamos con grandes volúmenes en el Lakehouse, es vital realizar tareas de mantenimiento. No basta con insertar datos. El uso de comandos como OPTIMIZE y la limpieza de versiones antiguas con VACUUM en Delta Lake asegura que el motor de Power BI no tenga que navegar por cientos de archivos pequeños o versiones obsoletas de la misma tabla, lo que aumentaría la latencia de lectura inicial.

-- Optimización de una tabla de ventas para Direct Lake
OPTIMIZE FactVentas
WHERE Fecha >= '2023-01-01'
ZORDER BY (ProductoKey, ClienteKey);

-- Limpieza de archivos no referenciados después de 7 días
VACUUM FactVentas RETAIN 168 HOURS;

Comparativa: Import vs. DirectQuery vs. Direct Lake

Para decidir cuándo usar Direct Lake, debemos entender su posición frente a los métodos tradicionales. En mis consultorías, suelo usar esta tabla para explicar la transición a los equipos de arquitectura:

Modelado en estrella: Sigue siendo el estándar

Un error común que veo en la era de Fabric es pensar que, como la tecnología es más potente, podemos descuidar el modelado. Direct Lake no compensa un mal diseño de datos. De hecho, un modelo de «tabla ancha» con cientos de columnas puede penalizar Direct Lake al forzar la carga de demasiados archivos Parquet pesados en memoria.

El diseño en estrella (Kimball) sigue siendo el rey. Al separar nuestras tablas de hechos (Ventas, Unidades, Importes) de nuestras dimensiones (Producto, Calendario, Cliente), permitimos que el motor de Direct Lake cargue solo las columnas necesarias para una consulta específica. Si un informe solo muestra ventas por año, el motor solo cargará la columna de Importe de la tabla de hechos y la columna de Año de la dimensión calendario, dejando el resto de los datos en OneLake sin consumir memoria de la capacidad.

Además, al evitar transformaciones complejas en el modelo semántico y delegarlas a la capa de transformación previa, facilitamos el plegado de consultas o query folding en las etapas de preparación, asegurando que los datos lleguen al Lakehouse ya optimizados para su consumo directo.

-- Ejemplo de medida DAX eficiente para Direct Lake
-- El motor solo cargará las columnas Importe y FechaKey
Ventas Acumuladas = 
VAR FechaMax = MAX('Calendario'[Fecha])
RETURN
 CALCULATE(
 SUM('FactVentas'[Importe]),
 'Calendario'[Fecha] <= FechaMax,
 ALL('Calendario')
 )

Errores frecuentes en la implementación de Direct Lake

1. No usar el V-Order: Escribir datos en OneLake desde herramientas externas a Fabric sin aplicar la optimización V-Order puede degradar el rendimiento de lectura inicial hasta un 40%.
2. Configurar incorrectamente el Fallback: Dejar el fallback en «automático» sin monitorización puede ocultar problemas de rendimiento que solo se detectan cuando los usuarios se quejan de la lentitud del informe.
3. Uso excesivo de columnas calculadas: Las columnas calculadas en DAX no se almacenan en los archivos Parquet. Se calculan en tiempo de ejecución y pueden forzar que el modelo pase a DirectQuery si el volumen es muy alto.
4. Ignorar la jerarquía de carpetas Delta: Una tabla con demasiados archivos pequeños (small files problem) obligará al motor a realizar miles de peticiones de red a OneLake para resolver una sola visualización.

Checklist para tu primer modelo Direct Lake

• [ ] Confirma que tus datos están en formato Delta y almacenados en un Lakehouse o Warehouse de Fabric.
• [ ] Asegúrate de que los procesos de carga (Notebooks o Pipelines) tienen activada la opción de V-Order.
• [ ] Crea el Modelo Semántico desde la vista de Modelado de Fabric, seleccionando solo las tablas necesarias.
• [ ] Verifica en las propiedades del modelo que el modo de almacenamiento sea «Direct Lake» y no haya conmutado a DirectQuery.
• [ ] Realiza una prueba de carga inicial y monitoriza con la App de Capacity Metrics para validar el consumo de memoria.

Preguntas frecuentes

¿Puedo usar Direct Lake con orígenes de datos externos?

Direct Lake solo funciona con datos que residen físicamente en OneLake en formato Delta. Sin embargo, puedes usar Shortcuts (Atajos) para apuntar a datos en ADLS Gen2 o AWS S3, y mientras estén en formato Delta, Power BI podrá consumirlos en modo Direct Lake sin moverlos.

¿Qué ocurre si mi capacidad de Fabric se pausa?

Al igual que con cualquier recurso de Fabric, si la capacidad está pausada, el modelo semántico no estará disponible para los usuarios. Direct Lake requiere que la capacidad esté activa para que el motor VertiPaq pueda orquestar la lectura de los archivos desde OneLake.

¿Sustituye Direct Lake al modo Import por completo?

No necesariamente. Para modelos pequeños que requieren una lógica de transformación muy compleja dentro de Power Query o que no residen en Fabric, el modo Import sigue siendo muy eficiente. Direct Lake es la solución de elección cuando hablamos de grandes volúmenes y necesidad de eliminar la latencia de los refrescos.

¿Es compatible con la seguridad a nivel de fila (RLS)?

Sí, Direct Lake soporta RLS definido en el modelo semántico. No obstante, si se define RLS a nivel de SQL en un Warehouse de Fabric, el modelo podría conmutar a DirectQuery para respetar las reglas de seguridad del motor de base de datos.