Direct Lake en Microsoft Fabric: cuándo usarlo y cuándo seguir con Import

Cuando un equipo llega a Microsoft Fabric, la primera frase que escucha sobre Power BI es: «con Direct Lake ya no necesitas refrescar». Es verdad. Y es también la razón por la que he visto modelos migrados a Direct Lake que rinden peor que el modelo Import al que sustituyeron.

Direct Lake no es un Import más rápido ni un DirectQuery más barato. Es un modo de almacenamiento con su propia forma de cargar datos, sus propias condiciones para funcionar bien y una lista concreta de cosas que no puede hacer. Elegirlo bien exige entender ese funcionamiento interno, porque la mayoría de los problemas que aparecen después no están en el modelo semántico, sino en cómo se escriben las tablas Delta que lo alimentan.

Esta guía es lo que me habría gustado leer antes de trabajar con mis primeros modelos Direct Lake en retail: cómo funciona por dentro, cuándo cae a DirectQuery sin avisar, qué límites impone cada capacidad, qué pierdes al elegirlo, y una matriz de decisión para saber cuándo compensa y cuándo Import sigue siendo la respuesta correcta.

Los modos de almacenamiento, en dos minutos

Un modelo semántico de Power BI tiene tablas, y cada tabla tiene un modo de almacenamiento que determina dónde viven sus datos y qué motor responde las consultas.

	Import	DirectQuery	Direct Lake
Dónde están los datos	Copia comprimida en memoria del modelo	En el origen; no se copian	En tablas Delta de OneLake; se cargan a memoria bajo demanda
Quién responde la consulta	VertiPaq	El origen (SQL, etc.)	VertiPaq
Refresco	Copia completa o incremental, programada	No hay	Solo metadatos (framing), en segundos
Latencia del dato	La del último refresco	Tiempo real	La del último commit Delta
Transformaciones en Power Query	Sí	Limitadas	No
Licencia	Cualquiera, incluida Free	Cualquiera	Solo capacidad Fabric (SKU F)

La clave de la tabla está en la segunda fila: Direct Lake usa el mismo motor que Import. Cuando funciona en condiciones, la velocidad de consulta es equivalente. La diferencia está en cómo llegan los datos a ese motor.

Cómo funciona Direct Lake por dentro

Un modelo Import es como una mudanza: cada noche cargas toda la casa en un camión y la trasladas a memoria. Direct Lake es tener las cajas en un almacén ordenado y subir a casa solo las que abres. Para que la analogía se sostenga, el almacén tiene que estar bien organizado. Ahí está todo.

Tablas Delta en OneLake

El origen de un modelo Direct Lake son tablas Delta: ficheros Parquet más un registro de transacciones. Da igual quién las escriba: un notebook de Spark, un pipeline, un dataflow Gen2 que carga en un lakehouse, sentencias T-SQL en un warehouse o una base de datos reflejada. Si en OneLake hay una tabla Delta válida, Direct Lake puede leerla. Esto es lo que lo convierte en la opción natural para la capa gold de una arquitectura medallion: la preparación del dato ocurre aguas arriba, una sola vez, y el modelo semántico solo la consume.

Transcodificación: carga columna a columna

Cuando llega una consulta DAX, Direct Lake identifica qué columnas necesita y las carga desde Parquet a la estructura en memoria de VertiPaq. Esto se llama transcodificación. Solo se cargan las columnas que las consultas piden; una tabla de ventas con 60 columnas de las que los informes usan 12 ocupa en memoria lo que ocupan esas 12. Esta es la razón por la que un modelo Direct Lake puede analizar volúmenes mayores que la memoria disponible en la capacidad.

Framing: el refresco que dura segundos

Refrescar un modelo Direct Lake no copia datos. Lee el registro de transacciones Delta, identifica la versión actual de cada tabla y actualiza las referencias a los ficheros Parquet. Se llama framing y suele tardar segundos. Si activas las actualizaciones automáticas, el modelo detecta los cambios en las tablas Delta y se reencuadra solo. Un dato que se escribe en el lakehouse a las 10:03 puede estar en un informe a las 10:04 sin que nadie programe nada.

Los cuatro estados de temperatura

Después de un framing, la memoria puede estar vacía o parcialmente cargada, y eso determina cuánto tarda la siguiente consulta:

• Frío: no hay nada en memoria. La primera consulta paga la transcodificación completa de las columnas que necesita.
• Semitemplado: tras un framing incremental, solo se descartan los segmentos de las filas que cambiaron. El resto sigue en memoria.
• Templado: las columnas necesarias ya están cargadas. Rendimiento equivalente a Import.
• Caliente: además, las cachés de consulta están pobladas. La respuesta es instantánea.

La primera consulta del día contra un modelo frío es el momento en el que los usuarios se quejan. Buena parte de la optimización de Direct Lake consiste en pasar de frío a templado lo más rápido posible y en no volver a frío sin necesidad.

V-Order: por qué importa cómo se escribió el Parquet

V-Order es una optimización de escritura de Fabric que ordena y comprime los ficheros Parquet con la misma lógica que usa VertiPaq. Un fichero con V-Order se transcodifica mucho más rápido y ocupa menos en memoria, porque el motor puede trabajar sobre los datos comprimidos sin descomprimirlos. Un fichero sin V-Order, escrito por ejemplo desde una herramienta externa, funciona, pero paga un coste en cada carga fría.

Direct Lake on OneLake y Direct Lake on SQL: dos sabores que no son iguales

Aquí está la primera decisión, y muchos equipos no saben que la están tomando. Existen dos variantes de Direct Lake:

	Direct Lake on OneLake	Direct Lake on SQL
Orígenes por modelo	Varios (varios lakehouses, warehouses, bases reflejadas)	Uno solo
Cae a DirectQuery	Nunca	Sí, cuando no puede leer la tabla Delta directamente
Mezcla con tablas Import	Sí, en el mismo modelo	No
Vistas SQL como origen	No	Sí, con fallback a DirectQuery
Seguridad de fila definida en SQL	Se ignora	Provoca fallback
Columnas y tablas calculadas	Sí, en vista previa	No
Reglas de deployment pipeline para cambiar origen	No	Sí

La variante sobre OneLake es la más reciente y la que Microsoft está desarrollando. Para un modelo nuevo es la que recomiendo, salvo que dependas de vistas SQL o de seguridad definida en el endpoint SQL. Y conviene tener claro que la variante SQL no falla cuando no puede leer directamente: cae a DirectQuery en silencio, que es de lo que trata la siguiente sección.

El fallback a DirectQuery: cuándo pasa y por qué duele

En Direct Lake on SQL, cuando el motor no puede cargar una tabla desde su fichero Delta, la consulta se envía al endpoint SQL como DirectQuery. El informe sigue funcionando, pero más lento, y nadie recibe un aviso. Las causas habituales:

• La tabla del modelo apunta a una vista SQL en lugar de a una tabla Delta.
• El endpoint SQL tiene seguridad a nivel de fila o de columna definida.
• Se han superado los límites de la capacidad (filas, ficheros o grupos de filas por tabla).
• Una tabla creada por XMLA está sin procesar porque nadie ejecutó el primer refresco.

En Direct Lake on OneLake no existe el fallback. Si se superan los límites, el refresco falla y el modelo no responde hasta que se optimizan las tablas. Es más duro, pero es mejor: un error visible se arregla; una degradación silenciosa se sufre durante meses.

El modelo tiene una propiedad, Direct Lake behavior, con tres valores: Automatic (cae a DirectQuery cuando hace falta), DirectLakeOnly (falla en lugar de caer) y DirectQueryOnly (para diagnóstico). Mi recomendación en producción es DirectLakeOnly. Además de evitar la degradación silenciosa, elimina los planes de consulta híbridos que el motor genera cuando el fallback está permitido, que penalizan el rendimiento incluso en consultas que nunca llegan a caer.

Cómo saber si estás cayendo a DirectQuery

• Performance Analyzer en Power BI Desktop: si aparecen entradas de tipo «DirectQuery» al cargar un visual, ese visual está cayendo.
• DAX Studio con los tiempos de servidor activados: verás eventos SQL en lugar de consultas al motor de almacenamiento.
• La función INFO.STORAGETABLECOLUMNSEGMENTS() en una consulta DAX: muestra qué segmentos de columna están residentes en memoria y te dice si el modelo está frío, templado o si una tabla nunca se ha cargado.

Los límites de cada capacidad

Cada SKU de Fabric impone límites a lo que un modelo Direct Lake puede leer por consulta. No son recomendaciones: si los superas, en OneLake el refresco falla y en SQL caes a DirectQuery. Las tres primeras columnas se miden por tabla.

SKU	Ficheros Parquet	Grupos de filas	Filas (millones)	Tamaño máx.	Memoria máx.
F2 a F8	1.000	1.000	300	10 GB	3 GB
F16	1.000	1.000	300	20 GB	5 GB
F32	1.000	1.000	300	40 GB	10 GB
F64	5.000	5.000	1.500	Sin límite	25 GB
F128	5.000	5.000	3.000	Sin límite	50 GB
F256	5.000	5.000	6.000	Sin límite	100 GB
F512	10.000	10.000	12.000	Sin límite	200 GB

Dos matices para leer bien la tabla. El tamaño máximo del modelo se evalúa a nivel de modelo; el resto de límites se evalúan por consulta, sobre las tablas que esa consulta toca. Y la memoria máxima no es un límite estricto: es el techo de lo que puede estar paginado en memoria. Si tu modelo necesita más, el motor descarga y vuelve a cargar columnas, y el rendimiento se resiente, pero no falla.

Un ejemplo de retail para poner escala: una cadena de 300 tiendas que genera 400 millones de líneas de ticket al año cabe con holgura en F64 durante varios años. En F16, supera las 300 millones de filas antes de terminar el primer ejercicio. En ese caso, Import con refresco incremental o particionar la tabla por año son alternativas antes de escalar la capacidad.

Lo que pierdes al elegir Direct Lake

Esta es la sección que casi nadie lee antes de migrar y casi todos leen después.

• Power Query. No existe. Toda transformación tiene que hacerse aguas arriba: notebooks, pipelines, dataflows Gen2 que escriben en un lakehouse, o T-SQL en un warehouse. Si tu modelo tiene 40 pasos de Power Query que nadie documentó, la migración empieza por ahí.
• Columnas calculadas. Solo en Direct Lake on OneLake, en vista previa y con limitaciones. En la práctica, hoy la respuesta sigue siendo: hazlas en la tabla Delta.
• Tablas calculadas. Igual: vista previa en OneLake. Las excepciones que siempre han funcionado son las que Power BI crea implícitamente: grupos de cálculo, parámetros de campo y parámetros what-if.
• Refresco incremental y particiones del modelo. No aplican. El particionado se hace en la tabla Delta, no en el modelo.
• Agregaciones definidas por el usuario y tablas híbridas. No están disponibles.
• Excel y clientes MDX. Las jerarquías definidas por el usuario en tablas Direct Lake no funcionan en tablas dinámicas, y las sentencias MDX de sesión tampoco. Si tu organización vive en «Analizar en Excel», esto pesa.
• Gateway. No se admite ninguno, ni on-premises ni VNET. Solo conexiones en la nube.
• Región. El modelo y el origen deben estar en la misma región de Fabric. Si no, se resuelve con un lakehouse intermedio y atajos.
• Licencia. Exige capacidad Fabric. Con capacidades por debajo de F64, los usuarios que consumen el informe siguen necesitando licencia Pro.
• Área de trabajo personal. No se pueden crear modelos Direct Lake en «Mi área de trabajo».
• Tipos de datos. Sin binarios, sin GUID, sin tipos complejos, sin valores NaN. Cadenas de hasta 32.764 caracteres.
• Validación en el modelado web. No se comprueba la cardinalidad de las relaciones ni la unicidad de las claves. Si una dimensión tiene claves duplicadas, no te enteras al crear la relación; te enteras cuando la consulta falla.

Lo que ganas

• Sin ventana de refresco. Un modelo Import de 500 millones de filas necesita una hora de refresco nocturno y consume unidades de capacidad mientras tanto. El mismo modelo en Direct Lake se reencuadra en segundos cuando la tabla Delta cambia.
• Memoria proporcional al uso real. Solo residen las columnas que las consultas piden. Puedes analizar más datos de los que caben en la memoria de tu SKU.
• Una sola copia del dato. Spark, el endpoint SQL, los notebooks y Power BI leen la misma tabla Delta. Se acaba el «en Power BI sale distinto que en el lakehouse».
• Latencia mínima. Con actualizaciones automáticas, el dato está disponible en cuanto se confirma el commit Delta.
• La preparación del dato es reutilizable. Al obligarte a transformar aguas arriba, esa lógica sirve para cualquier consumidor, no solo para un modelo.

El modelo compuesto: hechos en Direct Lake, dimensiones en Import

Para la mayoría de equipos que migran desde Import, esta es la mejor respuesta y no la que suelen considerar primero. Direct Lake on OneLake permite mezclar en un mismo modelo tablas Direct Lake con tablas Import. El patrón que funciona:

• Tablas de hechos en Direct Lake: ventas, stock, tickets. Son las grandes, las que hacen inviable el refresco completo, y las que menos transformación necesitan una vez están en la capa gold.
• Dimensiones en Import: calendario, producto, tienda. Son pequeñas, se refrescan en segundos, y en ellas sí puedes usar columnas calculadas, jerarquías para Excel y Power Query si hace falta enriquecerlas con un fichero que mantiene negocio.

Las condiciones: los tipos de datos de las columnas relacionadas deben coincidir exactamente, las claves del lado uno deben ser únicas, y las tablas Import siguen necesitando su refresco programado, aunque sea trivial. Power BI Desktop permite editar en vivo un modelo mixto, y los grupos de cálculo y parámetros de campo siguen funcionando con normalidad.

La tabla de calendario merece mención aparte: la funcionalidad automática de fecha y hora de Power BI Desktop no se aplica a tablas Direct Lake. Construye tu propia tabla de calendario, márcala como tabla de fechas y relaciónala por una columna de tipo fecha. Es lo que deberías hacer en cualquier caso.

Preparar las tablas Delta: lo que de verdad decide el rendimiento

Si tuviera que resumir esta guía en una frase, sería esta: el rendimiento de Direct Lake se decide en cómo escribes las tablas Delta, no en el modelo semántico. Estos son los factores por orden de impacto.

Grupos de filas grandes y pocos ficheros

Cada grupo de filas de un fichero Parquet se convierte en un segmento de columna en VertiPaq. Una tabla con 2.000 grupos de filas pequeños genera 2.000 segmentos por columna, y el motor trabaja mucho peor con muchos segmentos pequeños que con pocos grandes. El objetivo es entre 1 y 16 millones de filas por grupo. Fabric gestiona esto bien por defecto si le dejas, pero conviene comprobarlo: la librería semantic-link-labs incluye Delta Analyzer, que desde un notebook te devuelve el número de ficheros, grupos de filas y su tamaño medio para cualquier tabla.

El patrón de carga: append sí, overwrite no

Este es el error que más veces he visto. Un pipeline nocturno que carga la tabla de ventas con sobrescritura completa borra el registro Delta y obliga a Direct Lake a descartar todo lo que tenía en memoria. El modelo amanece frío cada día y la primera consulta de cada mañana tarda lo que tarda la transcodificación de mil millones de filas. Cargar en modo append preserva los ficheros existentes y permite el framing incremental: solo se transcodifica lo nuevo.

Las actualizaciones y borrados están en un punto intermedio: reescriben los ficheros afectados. Borrar un día de datos en una tabla no particionada puede tocar el 95% de los ficheros, porque las filas de ese día están repartidas por todos. Si tu proceso hace ventanas deslizantes o correcciones de datos, particiona.

Particionar por una columna de baja cardinalidad

La tentación es particionar por fecha. Con cinco años de datos son 1.800 particiones, cada una con ficheros pequeños, y vuelves al problema de los segmentos diminutos. La regla práctica es una columna de partición con menos de 200 valores distintos: año y mes, región, canal. Con particiones por mes, un borrado del día de ayer toca un solo fichero, y el mantenimiento semanal se limita a las particiones recientes.

Mantenimiento: OPTIMIZE y VACUUM

OPTIMIZE compacta ficheros pequeños en grandes. Es imprescindible en cargas frecuentes o streaming, donde se acumulan cientos de ficheros diminutos al día, y conviene ejecutarlo en fines de semana o cierres de mes porque reescribe ficheros y provoca una carga fría de lo compactado. VACUUM elimina las versiones antiguas de los ficheros. Con un detalle crítico: un modelo Direct Lake apunta a una versión concreta del registro Delta hasta su siguiente framing. Si VACUUM borra esa versión antes, los usuarios ven errores de consulta. Mantén la retención por defecto de siete días y no la reduzcas sin coordinarlo con la frecuencia de refresco del modelo.

Tipos de datos y cardinalidad

Lo mismo que en Import, pero con más consecuencias: enteros antes que texto, claves numéricas, sin columnas de alta cardinalidad que nadie usa. Una columna de identificador de transacción con mil millones de valores únicos que ningún informe muestra no cuesta nada en la tabla Delta, pero si una consulta la toca, su transcodificación es la más cara del modelo.

Seguridad: RLS, OLS y la identidad fija

La seguridad a nivel de fila y de objeto definida en el modelo semántico funciona con normalidad en Direct Lake. La recomendación fuerte de Microsoft, que comparto, es usar una conexión en la nube con identidad fija: el modelo accede a OneLake con una identidad concreta y los usuarios no necesitan permisos sobre los ficheros. Sin identidad fija, cada usuario debe tener acceso de lectura a los ficheros del lakehouse, lo que complica la gestión y puede exponer datos por otras vías.

La seguridad definida en el endpoint SQL es otra historia. Direct Lake on OneLake la ignora por completo: lee los ficheros directamente y no pasa por el endpoint. Direct Lake on SQL la respeta, pero a costa de caer a DirectQuery. Si tu seguridad vive en SQL, o la trasladas al modelo semántico o asumes el fallback.

Matriz de decisión

Con todo lo anterior, estas son las situaciones que me encuentro y la recomendación para cada una:

Situación	Recomendación
Las fuentes están fuera de Fabric (SQL on-premises, Excel, APIs) y no hay lakehouse	Import. Direct Lake necesita tablas Delta en OneLake; sin ellas no hay conversación
Modelo por debajo de 50 o 100 millones de filas y un refresco nocturno es suficiente	Import. Es más simple, más barato y no tiene las limitaciones. No migres por moda
Lakehouse gold con cientos de millones de filas y capacidad F64 o superior	Direct Lake on OneLake. El caso para el que se diseñó
El dato cambia durante el día y el negocio necesita verlo sin esperar al refresco	Direct Lake con actualizaciones automáticas. Si la fuente no está en OneLake, DirectQuery
Necesitas columnas calculadas, jerarquías o Power Query en las dimensiones	Modelo compuesto: hechos en Direct Lake, dimensiones en Import
La seguridad de fila está definida en el endpoint SQL del warehouse	Trasládala al modelo y usa Direct Lake on OneLake. Si no es posible, Import
Capacidad F2 a F32 con tablas que superan los 300 millones de filas	Import con refresco incremental o particionar en Delta por año y modelos separados
Los usuarios trabajan sobre todo con Analizar en Excel	Import, o dimensiones Import en un modelo compuesto para mantener las jerarquías
Analista de autoservicio sin permisos de escritura en el lakehouse	Import. Direct Lake presupone que puedes preparar el dato aguas arriba
El pipeline carga con sobrescritura completa y nadie lo va a cambiar	Import. Un Direct Lake que amanece frío cada día rinde peor que un Import bien refrescado

Cómo migrar un modelo Import a Direct Lake sin sustos

1. Empieza por un prototipo con una sola tabla de hechos. Mide tiempos en frío y en templado con Performance Analyzer antes de decidir nada.
2. Mueve Power Query aguas arriba. Cada paso de transformación pasa a un dataflow Gen2 con destino en el lakehouse, a un notebook o a T-SQL. Documenta la equivalencia paso a paso.
3. Valida tipos y claves. Columnas de relación con el mismo tipo en ambos lados y claves únicas en el lado uno. Hazlo con una consulta antes de crear el modelo, porque el modelado web no lo va a comprobar por ti.
4. Configura DirectLakeOnly desde el primer día en el entorno de pruebas. Si algo cae, quieres saberlo ahora.
5. Configura la identidad fija y traslada la seguridad de fila al modelo.
6. Revisa el patrón de carga de cada tabla Delta. Append donde sea posible, particionado por mes donde haya borrados, OPTIMIZE programado si hay cargas frecuentes.
7. Usa la integración con OneLake como paso intermedio. Un modelo Import puede escribir automáticamente sus tablas en OneLake como Delta. Permite que otros consumidores empiecen a usar el dato desde el lago mientras el modelo sigue en Import, y te da un origen listo para cuando cambies.
8. Monitoriza la capacidad con la app de métricas de Fabric durante las primeras semanas. Compara el consumo en consultas con lo que costaban los refrescos que has eliminado.

Errores que veo repetirse

• Sobrescritura nocturna. El modelo amanece frío y la primera consulta del día tarda minutos. Se arregla en el pipeline, no en el modelo.
• Tablas sobre vistas SQL. En la variante SQL caen a DirectQuery sin avisar; en OneLake directamente no se pueden crear. Materializa la vista como tabla Delta.
• Claves duplicadas en una dimensión. Las consultas fallan y el mensaje no es evidente. Comprueba la unicidad antes de relacionar.
• Esperar Power Query o columnas calculadas. Hoy no están en condiciones de producción. Planifica la transformación aguas arriba desde el principio.
• Ignorar los límites del SKU. Con F16 y una tabla de 400 millones de filas, el refresco falla y el modelo se queda inaccesible.
• Desplegar con fallback automático y no mirar nunca. Meses de informes lentos sin que nadie sepa por qué.
• Lakehouse en otra región. No se puede crear el modelo. Se resuelve con atajos desde un lakehouse en la región correcta.
• Streaming sin OPTIMIZE. Miles de ficheros pequeños, límite de ficheros superado, refresco fallido.

En resumen

Direct Lake es la opción correcta cuando el dato ya vive en OneLake, el volumen hace inviable el refresco completo y tienes capacidad para sostenerlo. En ese escenario ofrece lo mejor de Import sin sus ventanas de refresco. Fuera de ese escenario, Import sigue siendo la respuesta más simple y más robusta, y no hay ningún motivo para migrar un modelo de 30 millones de filas que refresca en cuatro minutos.

Y cuando Direct Lake sea la elección, recuerda dónde se gana o se pierde: en los grupos de filas, en el patrón de carga, en el particionado y en el mantenimiento de las tablas Delta. El modelo semántico solo consume lo que el lago le da.

¿Has migrado ya algún modelo a Direct Lake? ¿Qué te encontraste que no esperabas? Me interesa especialmente saber qué patrón de carga usáis en vuestras tablas de hechos. Cuéntamelo en los comentarios.

Comentarios

Deja tu comentario

Nombre *

Email * (no se publica)

Comentario *

Publicar comentario

Los comentarios son revisados antes de publicarse.