Direct Lake se implementa en Power BI dentro de Microsoft Fabric, donde el modelo semántico lee tablas Delta directamente desde OneLake sin importarlas ni duplicarlas. No es un botón mágico: requiere una capacidad de Fabric, tablas Delta bien diseñadas y una prueba de concepto con volumen, permisos y rendimiento antes de pasar a producción. La decisión se toma por caso, no por moda.
¿Qué es realmente Direct Lake y por qué es una decisión de arquitectura?
Direct Lake no es solo una mejora de rendimiento. Es una decisión de arquitectura. Microsoft Fabric permite que Power BI consuma datos Delta desde OneLake sin duplicarlos como haría un modelo Import tradicional. Eso cambia la forma en que piensas cuatro cosas al mismo tiempo: volumen, frescura de los datos, permisos y límites de capacidad.
En un modelo Import, los datos se copian dentro del modelo semántico y se refrescan por programación. En Direct Lake, el modelo apunta a las tablas Delta que ya viven en OneLake. Sirve especialmente cuando hay grandes volúmenes o actualizaciones frecuentes, porque reduce la duplicación. A cambio, exige diseñar bien las tablas, los permisos y la capacidad. Visto desde el negocio, el modelo semántico es el acuerdo compartido sobre cómo se calculan las métricas, algo que se ve con claridad al aplicar un modelo semántico en un sector como manufactura, y Direct Lake es una forma de servir ese acuerdo sin mantener dos copias de los mismos datos.
¿Cuándo conviene Direct Lake y cuándo no?
Antes de implementarlo, conviene decidir con criterio, no con entusiasmo. No prometemos Direct Lake como palabra mágica. Se evalúa por caso concreto según varios factores:
- Volumen: grandes cantidades de datos donde copiar todo a Import es costoso o lento.
- Latencia y frescura: cuando el negocio necesita ver datos recientes sin esperar refrescos largos.
- Licenciamiento y capacidad: Direct Lake requiere una capacidad de Fabric con un SKU adecuado.
- Tipo de consumo: reportes, Excel conectado, Scorecards u objetivos operativos.
- Seguridad: cómo se resuelven los permisos sobre los datos subyacentes.
- Mantenimiento: quién sostiene las tablas Delta y el modelo en el tiempo.
Si el caso no cumple estos criterios, un modelo Import o compuesto puede seguir siendo la opción correcta; por eso conviene tener claro cuándo usar Direct Lake o Import en Power BI antes de decidir. Direct Lake no corrige una arquitectura desordenada; sobre tablas mal diseñadas solo hace más visibles los problemas.
¿Cuáles son los pasos para implementar Direct Lake?
Una implementación ordenada sigue una secuencia clara. Estos son los pasos de alto nivel, siempre sobre una capacidad de Fabric activa:
- Preparar las tablas Delta: consolidar los datos en OneLake con tablas Delta optimizadas, idealmente siguiendo una arquitectura medallion (Bronze, Silver, Gold). El modelo se apoya en la capa Gold.
- Elegir el modo: definir si el modelo será Direct Lake on OneLake o Direct Lake on SQL, porque no se comportan igual ante fallas.
- Construir el modelo semántico: definir tablas, relaciones y medidas que reflejen de forma consistente las métricas del negocio.
- Configurar permisos y seguridad: validar quién puede leer qué, porque el acceso y la fuente cambian el comportamiento de la consulta.
- Hacer una prueba de concepto: probar con volumen real, permisos reales y tablas Delta optimizadas, midiendo rendimiento por SKU.
- Validar el consumo: revisar cómo se comporta en reportes, en Excel conectado y en Scorecards antes de liberar.
- Liberar a producción: solo después de pruebas de rendimiento y permisos que confirmen que el modelo se sostiene.
¿En qué se diferencian Direct Lake on OneLake y Direct Lake on SQL?
Esta distinción es crítica porque los dos modos no fallan de la misma forma. Elegir mal el modo es una de las causas más comunes de sorpresas en producción.
| Aspecto | Direct Lake on OneLake | Direct Lake on SQL |
|---|---|---|
| Fuente | Tablas Delta en OneLake | Endpoint SQL sobre los datos |
| Comportamiento ante límites | Puede devolver un error si la seguridad, las vistas o los límites no encajan | Puede cambiar a DirectQuery de forma automática |
| Riesgo principal | Consulta que falla en vez de degradarse | Rendimiento distinto tras el cambio a DirectQuery |
| Requisito común | Capacidad de Fabric y pruebas por SKU | Capacidad de Fabric y pruebas por SKU |
La lección práctica: Direct Lake on SQL puede cambiar a DirectQuery, mientras Direct Lake on OneLake puede devolver un error si la seguridad, las vistas o los límites no encajan. Por eso la prueba de concepto no es opcional.
¿Qué límites hay que respetar antes de prometerlo?
Direct Lake tiene límites concretos que conviene conocer antes de comprometerse con un cliente o con la dirección. Requiere una capacidad de Fabric y pruebas por SKU, porque el rendimiento depende del tamaño de la capacidad y del volumen de datos.
Hay un límite aprendido que vale oro: no hay que asumir que un modelo Import o compuesto puede recibir una tabla Direct Lake on SQL como parche. Si el cliente necesita objetivos o escritura operativa visibles al instante en Power BI, Excel o Scorecards, hay que elegir de forma consciente entre tres caminos:
- Rediseñar el modelo sobre OneLake y Direct Lake.
- Definir una actualización operativa que refresque el dato a tiempo.
- Actualizar al consumidor mediante una API.
Mezclar modos para tapar un hueco suele generar deuda técnica silenciosa. La documentación de Microsoft Learn describe los modos, los límites y el cambio a DirectQuery, y explica cuándo el acceso y la fuente cambian el comportamiento de la consulta.
¿Cómo se prueba antes de liberar a producción?
La regla es simple: nada llega a producción sin pruebas de rendimiento y permisos. Una prueba de concepto seria incluye tres cosas juntas.
- Volumen real: no un subconjunto pequeño, sino un tamaño representativo de lo que verá producción.
- Permisos reales: probar con los roles y accesos que tendrán los usuarios finales, no con una cuenta de administrador.
- Tablas Delta optimizadas: la capa Gold ordenada, porque un Delta mal mantenido degrada la experiencia.
Durante la prueba se mide el rendimiento por SKU y se observa el comportamiento del modo elegido: si Direct Lake on SQL cae a DirectQuery, o si Direct Lake on OneLake devuelve errores por seguridad o límites. Solo con esa evidencia se decide liberar. Así el modelo semántico llega a producción como una base confiable y no como una promesa frágil.
Siguiente paso
Direct Lake es una herramienta poderosa cuando se implementa con criterio: primero se ordenan las métricas y las decisiones, después se elige el modo y se prueba con volumen, permisos y capacidad reales. Tanto la formación del equipo como la consultoría sobre un caso concreto parten del mismo punto: entender cómo se ve este enfoque funcionando de principio a fin. Si quieres evaluar si Direct Lake conviene para tu escenario de volumen, seguridad y capacidad, mira la demo gratuita y decide con datos antes de invertir en la implementación.
Preguntas relacionadas
¿Qué se necesita para implementar Direct Lake en Power BI?
Se necesita Microsoft Fabric con una capacidad activa y un SKU adecuado, tablas Delta bien diseñadas en OneLake, un modelo semántico con permisos configurados y una prueba de concepto con volumen y rendimiento reales antes de pasar a producción.
¿Cuál es la diferencia entre Direct Lake on OneLake y Direct Lake on SQL?
No fallan igual. Direct Lake on SQL puede cambiar automáticamente 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 conviene elegir el modo según el caso y probarlo.
¿Cuándo conviene usar Direct Lake en lugar de un modelo Import?
Conviene sobre todo cuando hay grandes volúmenes o actualizaciones frecuentes, porque reduce la duplicación de datos. Se decide por caso según volumen, latencia, licenciamiento, tipo de consumo, seguridad y mantenimiento, no como opción por defecto.
¿Puedo agregar una tabla Direct Lake on SQL a un modelo Import como parche?
No conviene asumir eso. Si necesitas objetivos o escritura operativa visibles al instante en Power BI, Excel o Scorecards, la opción correcta es rediseñar el modelo sobre OneLake y Direct Lake, definir una actualización operativa o actualizar al consumidor mediante una API.
¿Por qué es obligatoria una prueba de concepto antes de producción?
Porque el rendimiento depende de la capacidad y del SKU, y el comportamiento cambia según el modo, la seguridad y los límites. La prueba con volumen real, permisos reales y tablas Delta optimizadas es la única forma de confirmar que el modelo se sostiene antes de liberarlo.