Direct Lake o Import en Power BI: guía de decisión | Acadevor
·8 min de lectura
Direct Lake o Import en Power BI: cuándo usar cada modo
Direct Lake e Import resuelven problemas distintos en Power BI. Compara volumen, frescura, permisos y capacidad para elegir el modo correcto sin sorpresas.
Import conviene cuando el volumen es manejable, la frescura por refresco basta y quieres el máximo control del modelo. Direct Lake conviene con grandes volúmenes o actualizaciones frecuentes, porque Power BI lee datos Delta desde OneLake sin duplicarlos. No es un botón de rendimiento: exige capacidad de Fabric, tablas bien diseñadas y pruebas de permisos antes de liberar a producción.
¿Qué cambia realmente entre Direct Lake e Import?
En el modo Import, Power BI copia los datos dentro del modelo semántico y los guarda comprimidos en memoria. Cada actualización vuelve a traer los datos desde la fuente. Es rápido para consultar y muy predecible, pero duplica la información y depende de que el refresco corra a tiempo.
Direct Lake es otra idea. Fabric permite que Power BI consuma tablas Delta directamente desde OneLake, sin duplicarlas como hace Import. Eso cambia cómo pensamos cuatro cosas al mismo tiempo: volumen, frescura, permisos y límites de capacidad. No es solo una mejora de velocidad, es una decisión de arquitectura sobre dónde viven los datos y cómo se leen.
Por eso en Acadevor no lo tratamos como una palabra mágica. Primero se define qué significa cada métrica en el modelo semántico, y después se elige el modo de conexión que lo sostiene.
¿Cuándo conviene quedarse en Import?
Import sigue siendo una opción sólida y muchas veces la más simple. Tiene sentido cuando:
El volumen de datos es moderado y entra cómodo en la capacidad disponible.
La frescura por refresco programado es suficiente para el negocio (por ejemplo, una actualización cada noche o cada hora).
Demo gratuita
Mira cómo construir tu sistema de datos e IA
Un recorrido práctico de principio a fin para unificar fuentes dispersas en un modelo semántico que alimenta Excel, Power BI, Copilot y tus agentes.
Quieres el máximo control sobre el modelo, con transformaciones y cálculos ya resueltos antes de cargar.
No dependes de una capacidad de Fabric o prefieres no atarte a sus límites por SKU.
La contraparte es clara: duplicas los datos, dependes de que el refresco termine bien y, si el volumen crece mucho, el refresco se vuelve pesado y frágil.
¿Cuándo conviene Direct Lake?
Direct Lake sirve especialmente cuando hay grandes volúmenes o actualizaciones frecuentes, porque evita copiar los datos en cada refresco y reduce la duplicación. En vez de mover todo a memoria de forma anticipada, lee las tablas Delta desde OneLake cuando se necesitan.
Ese ahorro tiene un precio en disciplina. Direct Lake exige diseñar bien las tablas, los permisos y la capacidad; si vas a dar ese paso, ayuda seguir cómo implementar Direct Lake paso a paso para no saltarte requisitos. Requiere una capacidad de Fabric y pruebas por SKU antes de prometer que rinde. Y puede cambiar su comportamiento en tiempo de consulta según el modo, la seguridad y la capacidad, incluyendo el paso a DirectQuery en ciertos escenarios.
En resumen, Direct Lake brilla cuando el volumen o la frescura hacen que Import sea costoso o lento, y cuando ya tienes una arquitectura de lago ordenada sobre OneLake y tablas Delta optimizadas.
Tabla de decisión: Import frente a Direct Lake
Criterio
Import
Direct Lake
Volumen de datos
Moderado, entra en memoria
Grande, sin duplicar en el modelo
Frescura
Por refresco programado
Cercana a la fuente Delta
Duplicación de datos
Sí, copia en el modelo
Reduce duplicación (lee de OneLake)
Capacidad de Fabric
No obligatoria
Obligatoria, con pruebas por SKU
Comportamiento en consulta
Estable y predecible
Puede cambiar a DirectQuery según modo, seguridad y capacidad
Requisito previo
Modelo bien definido
Tablas Delta optimizadas, permisos y capacidad probados
Una tabla no reemplaza una prueba. Ayuda a ordenar la conversación, pero la decisión final se valida con datos reales.
¿Por qué Direct Lake exige una prueba de concepto?
Direct Lake tiene límites que conviene conocer antes de comprometerlo. No falla siempre de la misma forma: Direct Lake on OneLake y Direct Lake on SQL se comportan distinto. En el caso de SQL, la consulta puede cambiar a DirectQuery; en el caso de OneLake, puede devolver un error si la seguridad, las vistas o los límites no encajan.
Por eso, antes de prometerlo, hacemos una prueba de concepto con tres ingredientes:
Volumen real, no una muestra pequeña que oculte los cuellos de botella.
Permisos y seguridad aplicados como estarán en producción.
Tablas Delta optimizadas, para que la lectura desde OneLake sea eficiente.
Esa prueba responde la pregunta que importa: ¿este caso concreto rinde y respeta la seguridad con la capacidad que tenemos?
El límite que más sorprende: Direct Lake no es un parche
Hay un error frecuente que conviene evitar. No hay que asumir que un modelo Import o compuesto puede recibir una tabla Direct Lake on SQL como parche para ganar frescura. La arquitectura no se remienda así.
Si el negocio necesita objetivos o escritura operativa visibles al instante en Power BI, Excel o Scorecards, hay tres caminos honestos, y hay que elegir uno:
Rediseñar el modelo sobre OneLake y Direct Lake, de forma consistente.
Definir una actualización operativa que refresque a la cadencia que el negocio exige.
Actualizar el consumidor mediante una API, cuando la escritura al instante es el requisito real.
Elegir de forma explícita evita el peor resultado: un modelo mixto que parece funcionar en la demo y falla cuando el volumen, la seguridad o la capacidad aprietan.
¿Cómo decidimos en la práctica?
La decisión no depende de una moda ni de un solo criterio. Evaluamos caso por caso: volumen, latencia requerida, licenciamiento, tipo de consumo, seguridad, forma del modelo y costo de mantenimiento. Ese conjunto, no una sola variable, define el modo correcto.
El orden también importa. Primero se ordena el modelo semántico como contrato común de las métricas, para que todos vean los mismos números en Excel, Power BI o cualquier IA. Después se elige la conexión que sostiene ese contrato. La herramienta viene después del criterio, no antes.
Y toda decisión se valida con pruebas de rendimiento y permisos antes de liberar a producción. Un modelo que no se probó con volumen y seguridad reales no está listo, por más elegante que se vea en el diseño.
Siguiente paso
Elegir entre Import y Direct Lake es, en el fondo, una decisión de arquitectura y de negocio: volumen, frescura, permisos y capacidad. Si quieres ver cómo abordamos ese tipo de decisiones, con formación y consultoría según lo que tu equipo necesite, mira la demo gratuita y evalúa el camino con datos, no con supuestos.
Preguntas frecuentes
¿Direct Lake siempre es más rápido que Import?
No. Direct Lake reduce la duplicación y ayuda con grandes volúmenes o actualizaciones frecuentes, pero no es un botón de rendimiento. Su comportamiento puede cambiar en tiempo de consulta según el modo, la seguridad y la capacidad, e incluso pasar a DirectQuery. Sin pruebas por SKU no se puede prometer que rinda.
¿Necesito una capacidad de Fabric para usar Direct Lake?
Sí. Direct Lake requiere una capacidad de Fabric y pruebas por SKU. Import, en cambio, no obliga a tener esa capacidad. Ese es uno de los factores de licenciamiento que conviene evaluar antes de elegir el modo.
¿Puedo agregar una tabla Direct Lake on SQL a un modelo Import como parche?
No conviene asumirlo. En vez de remendar un modelo Import o compuesto, hay que elegir de forma explícita: rediseñar sobre OneLake y Direct Lake, definir una actualización operativa, o actualizar el consumidor mediante una API si necesitas escritura visible al instante.
¿Cuál es la diferencia entre Direct Lake on OneLake y Direct Lake on SQL?
No fallan de la misma forma. Direct Lake on SQL puede cambiar a DirectQuery, mientras que Direct Lake on OneLake puede devolver un error si la seguridad, las vistas o los límites no encajan. Por eso se prueban con volumen y permisos reales antes de producción.
¿Cuándo sigue siendo mejor quedarse en Import?
Cuando el volumen es moderado, la frescura por refresco programado alcanza y quieres el máximo control del modelo sin atarte a una capacidad de Fabric. Import es más simple y predecible, aunque duplica los datos y depende de que el refresco corra a tiempo.
