Nos adentramos en la nueva funcionalidad que ofrece Fabric, el modo Direct Lake, descubriendo sus ventajas frente a los antiguos modos de conexión y conociendo sus limitaciones para sacarle el máximo partido.
Fabric va creciendo y madurando poco a poco y cada vez nos va proporcionando soluciones más innovadoras para crear nuestros modelos semánticos y conectarnos a los datos. En este artículo, vamos a hablar sobre el modo Direct Lake, comparándolo con sus hermanos mayores, Import y DirectQuery, y mostrando tanto sus ventajas como sus limitaciones.
¡Comenzamos!
Hasta ahora, conocíamos en Power BI los modos de conectividad de datos Import, DirectQuery y para ciertos orígenes de datos el modo Live, pero con Fabric aparece una nueva funcionalidad conocida como Direct Lake que, a fecha de redacción de este artículo, se encuentra en versión preliminar.
El modo Direct Lake es una nueva capacidad que utilizan por defecto los modelos semánticos de Fabric y que permite tratar grandes volúmenes de datos sin tener que importar los datos en un modelo de Power BI. Esto lo consigue mediante la carga de datos directamente desde OneLake, consultando los archivos delta directamente sin necesidad de enviar consultas SQL al origen de datos. Solo sería necesario tener esos archivos delta almacenados en OneLake, bien sea en un Lakehouse o en un Warehouse según las necesidades del modelo y preferencias del usuario.
De esta forma, eliminamos la desventaja de rendimiento que podemos encontrar con DirectQuery y evitamos tener que duplicar datos como en el modo Import. Y, al mismo tiempo, conseguimos las ventajas de inmediatez de los datos y un buen rendimiento de estos. Por tanto, el modo Direct Lake sería ideal para un modelo de datos grande en el que el origen de los datos esté en constante cambio.
En el siguiente diagrama vemos cómo trabaja la capacidad Direct Lake frente a los modos previos de Import y DirectQuery.
Resumen de los diferentes modos de almacenamiento (Fuente: Microsoft)
Otra de las ventajas del modo Direct Lake es el refresco automático del modelo semántico al añadir datos o realizar cambios de metadatos en el mismo. Con esta nueva funcionalidad ahorraremos en tiempo de procesamiento del modelo evitando esos largos refrescos de los grandes modelos en modo Import.
Pero ¿qué pasa si no queremos que los cambios en los datos se vean reflejados inmediatamente en nuestro modelo semántico? Para eso existe una propiedad en el apartado de Refresco del modelo semántico, que viene habilitada por defecto pero que podemos deshabilitar para escenarios en los que estemos probando los datos o no queramos mostrarlos todavía al usuario final.
Además, como podemos ver en la imagen, es posible activar un refresco programado del modelo semántico para estos casos. Esta última funcionalidad de programar una frecuencia concreta de refresco solo está disponible para los modelos semánticos creados manualmente y no para los que se crean por defecto dentro del Lakehouse o Warehouse.
Limitaciones de Direct Lake
Además, como podemos ver en la imagen, es posible activar un refresco programado del modelo semántico para estos casos. Esta última funcionalidad de programar una frecuencia concreta de refresco solo está disponible para los modelos semánticos creados manualmente y no para los que se crean por defecto dentro del Lakehouse o Warehouse.
Si nuestro modelo supera alguna de estas limitaciones en la capacidad que tengamos contratada tendríamos que ir a una capacidad superior o desechar la idea de usar Direct Lake.
Por otro lado, encontramos otra serie de limitaciones propias del modo Direct Lake como son que el modelo no puede estar formado por vistas, no permite crear columnas ni tablas calculadas o que no se puede hacer uso de Power Query, entre otras.
A todo esto, se suman las limitaciones que encontramos en los modelos semánticos que se crean por defecto en cada Lakehouse y Warehouse:
- No nos permite programar los refrescos ni refrescar el modelo manualmente.
- No se pueden realizar cambios en los nombres de las tablas ni de las columnas.
- No está permitido modificar la propiedad del comportamiento de Direct Lake que viene por defecto en automático, como veremos más adelante.
Si el modelo se encuentra con alguna de estas limitaciones o excede los límites de capacidad provocará un fallback. Esto no significa que el informe deje de funcionar o provoque un fallo, si no que sus consultas cambiarán al modo DirectQuery perjudicando el rendimiento del informe.
Comportamientos del modo Direct Lake
Existen tres modos de comportamiento del Direct Lake para el modelo semántico. Estos modos se pueden cambiar modificando la propiedad DirectLakeBehavior a través de la herramienta Tabular Editor. Para ello, debemos conectarnos al modelo semántico a través de dicha herramienta y seleccionando a nivel del modelo encontramos la propiedad.
Dada la constante evolución que encontramos en este modo, desde hace unos días, también podemos modificar esta propiedad en el propio modelo semántico.
El comportamiento que viene seleccionado por defecto es el Automático, que hará uso de las consultas en Direct Lake mientras pueda y provocará un fallback de las mismas a DirectQuery si encuentra alguna limitación, garantizándonos que los informes creados a partir de un modelo Direct Lake muestren resultados a pesar de no cumplir con alguna condición. Es importante tener en cuenta que todavía no es posible tener modelos compuestos con Direct Lake, por lo que si alguna tabla no cumple con las limitaciones que hemos comentado anteriormente todas las tablas del modelo pasarán a modo DirectQuery.
Una de las formas de averiguar si con el comportamiento automático las consultas se están ejecutando en modo Direct Lake o si, por el contrario, se está produciendo un fallback a DirectQuery es a través de la propia herramienta de Power BI Performance Analyzer. Como podemos ver en el ejemplo de la izquierda, la consulta está provocando un fallback a DirectQuery mientras que en la imagen de la derecha se está ejecutando en Direct Lake.
También vemos la posibilidad del comportamiento Solo consulta directa (DirectQueryOnly) por si quisiéramos que las consultas no se ejecuten en modo Direct Lake. Esto sería interesante para probar el rendimiento del modo DirectQuery, bien para compararlo con el modo Direct Lake o bien para hacer uso del modo Automático y conocer las consecuencias de rendimiento de un posible fallback.
Y, por último, vemos el modo Solo Direct Lake (DirectLakeOnly), pero, podrías pensar, ¿cuál es la utilidad de tener este modo si el modo automático ya ejecuta las consultas en modo Direct Lake en primer lugar? Pues una gran utilidad es descubrir qué limitación de las antes comentadas está provocando que nuestra consulta se ejecute en modo DirectQuery en vez de en modo Direct Lake y así poder solventarlas.
De esta forma, forzando el modo Direct Lake, podemos descubrir que alguna de nuestras tablas supera el número máximo de filas:
O que el modelo semántico necesita un refresco manual porque el refresco automático anterior haya fallado o porque lo tengamos desactivado y hayamos añadido nuevas tablas o columnas al modelo.
Otra de las causas que podemos descubrir es que nuestras consultas se están pasando de memoria y debemos ir a una capacidad superior:
Si el comportamiento Solo Direct Lake no nos refleja ningún fallo y el informe carga correctamente, podremos estar seguros de que nuestro modelo funciona a la perfección en modo Direct Lake. Si bien, es recomendable monitorizar el uso de la capacidad para controlar que la concurrencia de usuarios a la hora de utilizar los recursos funciona correctamente y no provoca un consumo elevado de memoria lo que precisaría contratar una capacidad superior.
Recomendaciones en el Uso de Direct Lake
Se recomienda, inicialmente y sobre todo en la fase de desarrollo, usar el modo de comportamiento Solo Direct Lake para tener las limitaciones de nuestro modelo presentes y a partir de las advertencias que vayamos obteniendo adecuar nuestro modelo a las limitaciones que podamos tener según nuestra capacidad.
Como hemos comentado, uno de los principales beneficios del modo Direct Lake en los modelos semánticos es un mejor rendimiento a la hora de visualizar los datos en los informes, sin embargo, es posible experimentar tiempos de respuesta elevados al abrir un informe por primera vez. Esto es debido a que los datos no están cargados en memoria encontrándonos en una situación que conocemos como caché fría en la que todos los datos deben recuperarse por completo desde el origen OneLake.
Por el contrario, nos referimos a caché caliente cuando los datos del informe ya están cargados en memoria caché por lo que, al no tener que ser cargados nuevamente, el rendimiento de las consultas mejora significativamente. En estas ocasiones vamos a encontrar unos tiempos de respuesta más rápidos.
Para evitar experimentar esa primera situación de respuesta del informe recomendamos precalentar el modelo. Esto podría llevarse a cabo mediante una API que lanzaría una query de las columnas del modelo más usadas en los informes provocando que se cargaran en la caché. Esta llamada a la API podría estar incluida, por ejemplo, como paso final en el pipeline que cargase los datos al modelo desde un origen externo.
Además, se recomienda no hacer uso del modelo semántico que se crea por defecto al construir un Lakehouse o Warehouse debido a las limitaciones extra con las que cuenta frente a un modelo creado manualmente.
Conclusión
El modo Direct Lake es una innovadora solución que presenta Fabric para hacer frente a las desventajas de los modos Import y Direct Lake. Su uso es recomendable para grandes volúmenes de datos que sufren constantes cambios en origen, siempre y cuando cumplan con las limitaciones expuestas anteriormente según la capacidad en la que nos encontremos.
Por último, recuerda que Fabric está ofreciendo, por el momento, poder activar una capacidad de prueba gratuita FT1 (correspondiente a una F64) durante 60 días, lo que es una oportunidad inmejorable para experimentar de primera mano las capacidades de Fabric y en concreto del modo Direct Lake.
Beatriz Nomdedeu Cabrera
Data & IA Architect
