Direct Lake, Import o DirectQuery: cuál elegir en Microsoft Fabric
Elegir entre Direct Lake o Import es la primera decisión de arquitectura de cualquier modelo en Fabric. También es la que más veces se toma por el motivo equivocado, que suele ser «porque Direct Lake es lo nuevo».
En bastantes proyectos Import sigue siendo la respuesta correcta. Y elegir mal no se nota el primer día: se nota tres meses después, cuando el informe va lento a ratos y nadie sabe por qué.
Los tres modos, sin adornos
Import copia los datos en memoria durante la actualización. Es el más rápido consultando y los datos son los de la última carga.
DirectQuery lanza una consulta al origen en cada interacción. Datos siempre al día, y un rendimiento que es el de la base que hay detrás.
Direct Lake lee los ficheros Delta del lago sin copiarlos ni consultar el origen en cada clic. Sobre el papel, lo bueno de los dos anteriores.
Un modelo puede mezclarlos, tabla a tabla. Eso se llama modelo compuesto, es útil de verdad, y también multiplica las formas de meter la pata.
Direct Lake o Import: cuándo elegir cada uno
Import sigue siendo la opción sensata por defecto en más casos de los que la gente cree. Si el modelo cabe cómodamente en memoria, si los datos de ayer bastan para decidir, o si necesitas transformaciones complejas dentro del propio modelo semántico, no lo compliques. Tiene una ventaja que casi nadie menciona: es el modo con menos cosas que se pueden romper.
DirectQuery tiene un territorio estrecho: cuando el negocio necesita el dato al segundo y aceptas pagarlo en rendimiento. Un aviso que sale en casi todas las auditorías que hacemos: no lo apuntes contra la base de datos operacional. El informe funcionará, y de paso saturará el sistema que sostiene la operación cada lunes a las nueve.
Direct Lake gana con claridad cuando el volumen hace inviable Import, los datos ya viven en el lago en Delta y la lógica pesada está resuelta antes, en la capa de datos. Si esas condiciones se cumplen, no hay discusión. Si no se cumplen, se comporta peor de lo que esperabas, y aquí viene el porqué.
Ya no hace falta elegir para todo el modelo
Hasta hace poco, elegir modo era elegirlo para el modelo entero. Ahora Direct Lake sobre OneLake permite mezclar en el mismo modelo tablas en Direct Lake y tablas en Import, con relaciones normales entre ellas.
En la práctica, esto resuelve el caso más habitual: una tabla de hechos enorme que ya vive en el lago y unas cuantas dimensiones que vienen de otros sistemas. Los hechos, en Direct Lake, sin cargas pesadas. Las dimensiones, en Import, desde donde estén. Bien planteado, es lo mejor de los dos mundos. Mal planteado, es un modelo difícil de mantener, así que conviene decidirlo con criterio y no por comodidad.
Direct Lake son dos cosas distintas
Casi todo lo que se publica habla de Direct Lake como si fuera uno solo. No lo es, y la diferencia cambia el diseño.
Sobre el endpoint SQL hay repliegue. Si una consulta no se puede resolver leyendo el lago, cae a DirectQuery sin avisar. El informe sigue funcionando, el rendimiento se desploma y el usuario solo sabe decirte que «a veces va lento». Eso es lo peor que le puede pasar a un diagnóstico.
Sobre OneLake no hay repliegue. O resuelve en Direct Lake o la consulta falla. Microsoft la recomienda para modelos nuevos justo por eso: el fallo es ruidoso en lugar de silencioso, y un fallo ruidoso se arregla.
Existe además un ajuste con tres valores que controla ese comportamiento. En desarrollo conviene ponerlo estricto para que los problemas salgan a la cara. En producción se suele dejar automático, para que el usuario no se quede sin informe un martes por la mañana. El detalle está en la guía oficial de funcionamiento de Direct Lake.
Qué provoca el repliegue
No es misterioso: las causas están documentadas y se auditan en una tarde. Las que más vemos:
- Seguridad a nivel de fila definida en el endpoint SQL en lugar de en el modelo semántico. Con eso replegarás siempre.
- Tablas construidas sobre vistas que no están materializadas.
- Una sola tabla que supere los límites de la capacidad. Basta con una para tumbar el modo en todo el modelo.
- Haber cambiado las tablas de origen sin refrescar el modelo después.
Se puede saber, tabla a tabla, cuál está replegando y por qué. Es lo primero que revisamos cuando alguien nos dice que su modelo va lento y no sabe explicar cuándo.
Lo que de verdad marca el rendimiento
Una vez elegido el modo, lo que decide si va rápido es bastante prosaico. Los tipos de datos, empezando por el clásico de guardar números como texto. Las columnas con muchísimos valores distintos, que comprimen mal y ralentizan todo. El tamaño de los segmentos, porque muchos ficheros pequeños penalizan. Y el estado de memoria del modelo, que hace que uno recién despertado responda peor que uno en uso, cosa que despista al medir.
Por eso una tarea tan poco lucida como optimizar las tablas Delta suele dar más mejora que cambiar de modo. No queda bien en una presentación, pero funciona.
La capacidad también decide
Direct Lake necesita una capacidad de Fabric, y lo que admite depende de su tamaño. Hasta F32, una tabla puede tener unos 300 millones de filas; en F64 el límite sube a 1.500 millones. Si una sola tabla lo supera, el modo deja de funcionar para todo el modelo.
Por eso la elección del modo y la de la capacidad van juntas. Subir de capacidad para que quepa una tabla mal mantenida es la forma más cara de arreglarlo. Lo habitual es que el problema se resuelva antes, en cómo se guardan los datos.
A cambio, Direct Lake tiene una ventaja que se nota en la factura: actualizar el modelo no copia los datos, solo apunta a la última versión del lago. Lo que en Import es una carga de minutos u horas, aquí es cuestión de segundos.
Direct Lake o Import: el árbol de decisión
- ¿Cabe en memoria y vale el dato de ayer? Import, y a otra cosa.
- ¿Hace falta el dato al segundo y el origen aguanta? DirectQuery, nunca contra la base operacional.
- ¿Volumen grande, datos en Delta y lógica pesada resuelta antes? Direct Lake, y sobre OneLake si el modelo es nuevo.
- ¿Hechos enormes en el lago y dimensiones que vienen de otros sistemas? Modelo mixto: hechos en Direct Lake, dimensiones en Import.
- ¿Hay seguridad a nivel de fila o vistas de por medio? Resuélvelo en el modelo semántico antes de decidir, o acabarás en DirectQuery sin enterarte.
Si tienes esta decisión encima de la mesa, escríbenos. Revisamos tu modelo y tu capacidad y te decimos qué modo le conviene a cada parte, antes de que se note en producción. Cuesta poco acertar al principio y bastante corregirlo después.