Direct Lake: Análisis en tiempo de ejecución sobre Delta Lake sin importación

La evolución de las arquitecturas de datos en el ecosistema Microsoft ha alcanzado un punto de inflexión con la llegada de Microsoft Fabric y, específicamente, con el modo de almacenamiento Direct Lake. Durante años, los consultores de Business Intelligence hemos tenido que elegir entre la velocidad extrema del modo Import (pagando el precio de la latencia de refresco y la duplicación de datos) o la frescura de DirectQuery (sacrificando el rendimiento de las consultas y sobrecargando el origen). Direct Lake rompe esta dicotomía al permitir que el motor de análisis de Power BI, VertiPaq, acceda directamente a los archivos de datos en el almacenamiento distribuido sin necesidad de moverlos.

En proyectos de retail o industria, donde los volúmenes de ventas y telemetría crecen exponencialmente, la gestión de los tiempos de procesamiento se vuelve crítica. Tradicionalmente, un modelo de varios cientos de gigabytes requería ventanas de procesamiento nocturnas complejas. Direct Lake elimina esta barrera técnica: el motor lee los archivos Delta (Parquet) residentes en OneLake como si estuvieran en su propia memoria caché, aprovechando que el formato Parquet y el almacenamiento interno de VertiPaq comparten una estructura columnar muy similar.

Sin embargo, implementar Direct Lake no es simplemente pulsar un botón. Requiere entender cómo se produce el mapeo de memoria y qué condiciones deben cumplirse para que el motor no decida, de forma unilateral, volver al modo DirectQuery (lo que conocemos como fallback). En este artículo desglosamos la mecánica interna de esta tecnología y cómo configurarla para maximizar el retorno de inversión en capacidades de Fabric.

La arquitectura interna de Direct Lake: VertiPaq y OneLake

Para comprender Direct Lake, primero hay que entender qué hace VertiPaq con los datos en el modo Import tradicional. En Import, VertiPaq lee los datos del origen, los comprime, los codifica y los guarda en un formato propietario dentro del servicio de Power BI. En Direct Lake, este paso de «ingesta y transformación a formato propietario» se omite. El motor asume que los archivos Parquet en OneLake ya están optimizados.

El proceso técnico es fascinante: cuando un usuario interactúa con un informe, el motor de Power BI identifica qué columnas son necesarias para resolver la consulta DAX. Si esas columnas no están en la memoria del servidor de la capacidad, el motor realiza un paging (paginación) directamente desde los archivos Parquet de OneLake a la memoria RAM de la capacidad. No hay una copia persistente adicional; la memoria se llena bajo demanda.

Mapeo de archivos en memoria (Memory-mapped files)

Direct Lake utiliza una técnica de gestión de memoria similar a los archivos mapeados en memoria del sistema operativo. En lugar de leer todo el dataset, el motor carga solo los fragmentos (columnas y segmentos) necesarios. Esto es posible porque el formato Delta Lake almacena los datos en archivos Parquet, que son columnares por naturaleza. Si tu informe solo visualiza el Importe por Fecha, VertiPaq solo traerá esas dos columnas de OneLake, ignorando el resto de las 50 columnas de la tabla de ventas.

El papel crítico de V-Order y la codificación

No todos los archivos Parquet son iguales para VertiPaq. Para que el rendimiento sea comparable al modo Import, Microsoft introdujo una optimización llamada V-Order. Esta tecnología aplica algoritmos de ordenación y compresión específicos de VertiPaq a los archivos Parquet generados en Fabric (ya sea por Data Factory, Spark o SQL Analytics Endpoint).

Sin V-Order, el motor de Power BI puede leer los archivos, pero el rendimiento de descompresión en tiempo de ejecución sería sensiblemente inferior. Para profundizar en cómo configurar esta característica, es fundamental revisar la guía técnica sobre V-Order en Delta Lake. V-Order asegura que la disposición de los datos en el archivo Parquet coincida con la estructura que VertiPaq espera encontrar, reduciendo los ciclos de CPU necesarios para procesar cada fila.

Transcoding: El coste oculto

Si los archivos Parquet no están optimizados o utilizan tipos de datos no nativos para VertiPaq, el motor debe realizar un proceso de transcoding sobre la marcha. Esto consume CPU y aumenta la latencia de la consulta. En escenarios de alta concurrencia, un exceso de transcoding puede agotar los recursos de la capacidad de Fabric, degradando la experiencia de todos los usuarios del tenant. Por ello, en el diseño de arquitecturas Medallion (Bronze/Silver/Gold), es imperativo que la capa Gold, que alimenta los modelos semánticos, tenga habilitado V-Order de forma consistente.

Cuándo ocurre el Fallback a DirectQuery

Uno de los mayores miedos del arquitecto de BI al usar Direct Lake es el fallback. Este mecanismo de seguridad ocurre cuando el motor no puede cumplir la consulta usando Direct Lake y recurre a DirectQuery para obtener los datos del SQL Analytics Endpoint del Lakehouse.

Las causas principales del fallback son:

• Límites de memoria de la capacidad: Cada SKU de Fabric (F64, F128, etc.) tiene un límite de memoria para objetos Direct Lake. Si el dataset supera ese límite, el motor pasa a DirectQuery.
• Seguridad a nivel de fila (RLS) en el origen: Si se define RLS en el Lakehouse (SQL level) en lugar de en el modelo semántico de Power BI, el motor se ve obligado a usar DirectQuery para respetar el contexto de seguridad.
• Vistas SQL complejas: Direct Lake funciona sobre tablas Delta. Si intentas apuntar el modelo a vistas SQL que no están materializadas, el sistema usará DirectQuery.

Es vital monitorizar este comportamiento. Un modelo que ayer funcionaba instantáneamente hoy puede ser lento porque ha cruzado el umbral de memoria y ha entrado en modo DirectQuery. Para evitar esto, es recomendable seguir las pautas de Power BI y Direct Lake: El fin de los procesos de carga, donde se detallan los límites por capacidad.

Comparativa: Import vs. DirectQuery vs. Direct Lake

Implementación técnica y optimización del modelo

Para implementar Direct Lake de forma efectiva, debemos trabajar desde el Lakehouse o el Warehouse de Fabric. El primer paso es asegurar que nuestras tablas sigan un esquema de estrella. Aunque Direct Lake es potente, no compensa un mal diseño de datos. Como mencionamos en nuestra reseña sobre modelado de datos, la base de cualquier informe eficiente es una correcta dimensión de fechas y tablas de hechos limpias.

A continuación, se muestra cómo podemos verificar el estado de las tablas en nuestro modelo Direct Lake mediante una consulta a las vistas de gestión dinámica (DMVs) desde herramientas como DAX Studio:

-- Consulta para verificar el modo de almacenamiento de las columnas
SELECT 
 [TableID], 
 [ColumnID], 
 [StorageType], 
 [IsResident], 
 [Temperature]
FROM $SYSTEM.DISCOVER_STORAGE_TABLE_COLUMNS
WHERE [StorageType] = 'DirectLake' -- Filtramos por columnas en este modo

En este código, la columna IsResident nos indica si la columna está actualmente cargada en la memoria RAM de la capacidad. La Temperature ayuda a entender qué columnas son las más accedidas, permitiéndonos tomar decisiones sobre particionamiento o limpieza de datos.

Gestión de versiones y metadatos

A diferencia del modo Import, donde el refresco vuelve a cargar todo el dataset, en Direct Lake el «refresco» es una operación de actualización de metadatos. El modelo simplemente toma nota del nuevo checkpoint de Delta Lake. No obstante, si el log de Delta crece demasiado, la lectura de metadatos puede ralentizarse. Es aquí donde la optimización de archivos se vuelve crucial, como explicamos en el artículo sobre Checkpoints de Delta en Fabric.

Errores comunes detectados en consultoría

1. No ejecutar OPTIMIZE y VACUUM: El rendimiento de Direct Lake depende de la salud de los archivos Parquet. Si tienes miles de archivos pequeños de 10KB, el motor sufrirá para leerlos. Mantener los archivos en tamaños de ~128MB a 1GB es el estándar.
2. Uso excesivo de columnas calculadas en DAX: En Direct Lake, las columnas calculadas no se almacenan en OneLake. Se calculan en tiempo de ejecución o pueden forzar un refresco que no esperas. Siempre que sea posible, mueve la lógica de columnas a la capa de transformación (Spark o SQL) antes de que lleguen a la tabla Delta.
3. Ignorar el límite de la capacidad: Muchos clientes empiezan con una F2 o F4 y se sorprenden cuando el modelo entra en fallback. Direct Lake está diseñado para brillar en capacidades mayores, aunque es funcional en pequeñas si el volumen de datos activos es moderado.

Monitorización avanzada con Capacity Metrics

Para un consultor senior, no basta con que el informe funcione; debe ser eficiente. La aplicación Microsoft Fabric Capacity Metrics es nuestra principal herramienta. Debemos vigilar el consumo de «Background Operations». Aunque Direct Lake reduce la carga de procesamiento (CPU), el acceso a OneLake y el paging computan en el uso de la capacidad. Si vemos picos de Throttling (estrangulamiento), es probable que necesitemos revisar el particionamiento de las tablas de hechos grandes.

-- Ejemplo de cómo optimizar una tabla de ventas en Spark para Direct Lake
OPTIMIZE Fact_Ventas
WHERE Fecha >= '2023-01-01'
ZORDER BY (ProductoKey, ClienteKey); -- Mejoramos la localidad de datos para VertiPaq

El uso de ZORDER es fundamental en tablas con millones de filas, ya que agrupa físicamente los datos relacionados, permitiendo que VertiPaq lea menos archivos para satisfacer una consulta filtrada por producto o cliente.

Checklist para una implementación exitosa de Direct Lake

• Confirmar que todas las tablas del modelo semántico residen en el mismo Workspace de Fabric que el Lakehouse.
• Asegurar que la configuración de la capacidad tiene habilitado el acceso a archivos de OneLake.
• Verificar mediante DAX Studio que el StorageMode de las tablas es efectivamente DirectLake.
• Implementar una política de mantenimiento (OPTIMIZE/VACUUM) semanal para evitar la fragmentación de archivos.
• Configurar alertas de memoria en la capacidad de Fabric para detectar situaciones de fallback antes de que los usuarios reporten lentitud.

Preguntas frecuentes

¿Puedo combinar tablas en Direct Lake con tablas en modo Import en el mismo modelo?

Sí, es posible crear modelos compuestos. Sin embargo, esto suele ser una solución temporal. La potencia de Direct Lake reside en mantener la homogeneidad para evitar el movimiento de datos entre diferentes motores, lo que podría anular las ventajas de rendimiento.

¿Es Direct Lake compatible con modelos semánticos de gran tamaño (Large Format)?

Direct Lake está diseñado intrínsecamente para grandes volúmenes de datos. No tiene las restricciones de tamaño de archivo .pbix tradicional, ya que los datos residen en OneLake. El único límite real es la memoria máxima que tu SKU de Fabric puede asignar a un único dataset.

¿Qué ocurre si borro archivos del Lakehouse mientras un informe está abierto?

Power BI mantiene una versión de los metadatos (el log de Delta). Si los archivos físicos desaparecen sin actualizar los metadatos del modelo, las consultas fallarán. Es fundamental coordinar las tareas de limpieza como VACUUM en Delta Lake con la actualización del modelo semántico.

¿Direct Lake requiere una licencia Power BI Premium?

Direct Lake requiere una capacidad de Microsoft Fabric (SKU F) o Power BI Premium (SKU P). No está disponible en licencias Pro o por usuario (PPU) sin una capacidad compartida que soporte las cargas de trabajo de Fabric.