Introducción a Direct Lake

Direct Lake es una opción de modo de almacenamiento para las tablas de un modelo semántico de Power BI almacenado en un área de trabajo de Microsoft Fabric. Está optimizado para grandes volúmenes de datos que se pueden cargar rápidamente en la memoria de tablas Delta, que almacenan sus datos en archivos Parquet en OneLake, el único almacén para todos los datos de análisis. Una vez cargado en memoria, el modelo semántico permite consultas de alto rendimiento. Direct Lake elimina la necesidad lenta y costosa de importar datos en el modelo.

Puede usar el modo de almacenamiento de Direct Lake para conectarse a las tablas o vistas de un único almacén de Fabric LakeHouse o Fabric. Ambos elementos de Fabric y los modelos semánticos de Direct Lake requieren una licencia de capacidad de Fabric.

De alguna manera, un modelo semántico de Direct Lake es similar a un modelo semántico de importación. Esto se debe a que el motor de VertiPaq carga los datos del modelo en memoria para obtener un rendimiento rápido de las consultas (excepto en el caso de la reserva de DirectQuery, que se explica más adelante en este artículo).

Sin embargo, un modelo semántico de Direct Lake difiere de un modelo semántico de importación de una manera importante. Esto se debe a que una operación de actualización para un modelo semántico de Direct Lake es conceptualmente diferente a una operación de actualización para un modelo semántico de importación. Para un modelo semántico de Direct Lake, una actualización implica una operación de enmarcado (descrita más adelante en este artículo), que puede tardar unos segundos en completarse. Es una operación de bajo costo donde el modelo semántico analiza los metadatos de la versión más reciente de las tablas Delta y se actualiza para hacer referencia a los archivos más recientes en OneLake. En cambio, para un modelo semántico de importación, una actualización genera una copia de los datos, lo que puede tardar mucho tiempo y consumir recursos significativos de origen de datos y capacidad (memoria y CPU).

Nota:

La actualización incremental de un modelo semántico de importación puede ayudar a reducir el tiempo de actualización y el uso de los recursos de capacidad.

¿Cuándo debe usar el modo de almacenamiento de Direct Lake?

El caso de uso principal de un modo de almacenamiento de Direct Lake suele ser para proyectos de análisis controlados por TI que aprovechan las arquitecturas centradas en lago. En este escenario, tiene o espera acumular grandes volúmenes de datos en OneLake. La carga rápida de esos datos en la memoria, las operaciones de actualización frecuentes y rápidas, el uso eficaz de los recursos de capacidad y el rendimiento rápido de las consultas son importantes para este caso de uso.

Nota:

Los modelos semánticos de Importación y DirectQuery siguen siendo relevantes en Fabric y son la elección correcta del modelo semántico para algunos escenarios. Por ejemplo, el modo de almacenamiento de importación a menudo funciona bien para un analista de autoservicio que necesita la libertad y agilidad para actuar rápidamente y sin dependencia de TI para agregar nuevos elementos de datos.

Además, la integración de OneLake escribe automáticamente los datos de las tablas del modo de almacenamiento de importación en tablas delta de OneLake sin necesidad de realizar ningún esfuerzo de migración. Con esta opción, puede obtener muchas de las ventajas de Fabric que están disponibles para importar usuarios del modelo semántico, como la integración con lakehouses a través de accesos directos, consultas SQL, cuadernos, etc. Se recomienda considerar esta opción como una manera rápida de aprovechar las ventajas de Fabric sin necesidad de volver a diseñar de inmediato el almacenamiento de datos existente o el sistema de análisis.

El modo de almacenamiento de Direct Lake también es adecuado para minimizar la latencia de los datos para que los datos estén disponibles rápidamente para los usuarios empresariales. Si las tablas delta se modifican de forma intermitente (y suponiendo que ya ha realizado la preparación de datos en el lago de datos), puede depender de las actualizaciones automáticas para volver a crear el fotograma en respuesta a esas modificaciones. En este caso, las consultas enviadas al modelo semántico devolverán los datos más recientes. Esta funcionalidad funciona bien en colaboración con la característica de actualización automática de páginas de informes de Power BI.

Tenga en cuenta que Direct Lake depende de la preparación de datos que se realiza en el lago de datos. La preparación de datos se puede realizar mediante diversas herramientas, como trabajos de Spark para lakehouses de Fabric, instrucciones DML de T-SQL para almacenes de Fabric, flujos de datos, canalizaciones y otros. Este enfoque ayuda a garantizar que la lógica de preparación de datos se realice lo más bajo posible en la arquitectura para maximizar la reutilización. Sin embargo, si el autor del modelo semántico no tiene la capacidad de modificar el elemento de origen, por ejemplo, en el caso de un analista de autoservicio que podría no tener permisos de escritura en una instancia de Lakehouse administrada por TI, el modo de almacenamiento de importación podría ser una mejor opción. Esto se debe a que admite la preparación de datos mediante Power Query, que se define como parte del modelo semántico.

Asegúrese de tener en cuenta la licencia de capacidad de Fabric actual y los límites de protección de capacidad de Fabric cuando considere el modo de almacenamiento de Direct Lake. Además, tenga en cuenta las consideraciones y limitaciones, que se describen más adelante en este artículo.

Sugerencia

Se recomienda generar un prototipo (o prueba de concepto) para determinar si un modelo semántico de Direct Lake es la solución adecuada y mitigar el riesgo.

Funcionamiento de Direct Lake

Normalmente, las consultas enviadas a un modelo semántico de Direct Lake se controlan desde una caché en memoria de las columnas procedentes de tablas Delta. El almacenamiento subyacente de una tabla Delta es uno o varios archivos Parquet en OneLake. Los archivos Parquet organizan los datos por columnas en lugar de filas. Los modelos semánticos cargan columnas completas de tablas delta en memoria a medida que las consultas las requieren.

Un modelo semántico de Direct Lake también puede usar la reserva de DirectQuery, lo que implica cambiar sin problemas al modo DirectQuery. La reserva de DirectQuery recupera datos directamente desde el punto de conexión de SQL Analytics de lakehouse o el almacenamiento. Por ejemplo, la reserva puede producirse cuando una tabla Delta contiene más filas de datos de las que admite la capacidad de Fabric (que se describe más adelante en este artículo). En este caso, una operación directQuery envía una consulta al punto de conexión de SQL Analytics. Las operaciones de reserva pueden dar lugar a un rendimiento de consulta más lento.

En el diagrama siguiente se muestra cómo funciona Direct Lake mediante el escenario de un usuario que abre un informe de Power BI.

En el diagrama se muestran las siguientes acciones de usuario, procesos y características.

Elemento	Descripción
	OneLake es un lago de datos que almacena datos de análisis en formato Parquet. Este formato de archivo está optimizado para almacenar datos para modelos semánticos de Direct Lake.
	Un almacén de Fabric Lakehouse o Fabric existe en un área de trabajo que se encuentra en la capacidad de Fabric. Lakehouse tiene un punto de conexión de SQL Analytics, que proporciona una experiencia basada en SQL para realizar consultas. Las tablas (o vistas) proporcionan un medio para consultar las tablas Delta en OneLake mediante Transact-SQL (T-SQL).
	Existe un modelo semántico de Direct Lake en un área de trabajo de Fabric. Se conecta a tablas o vistas en el lago o en el almacén.
	Un usuario abre un informe de Power BI.
	El informe de Power BI envía consultas de expresiones de análisis de datos (DAX) al modelo semántico de Direct Lake.
	Cuando sea posible (y necesario), el modelo semántico carga columnas en memoria directamente desde los archivos Parquet almacenados en OneLake. Las consultas logran un rendimiento en memoria muy rápido.
	El modelo semántico devuelve los resultados de la consulta.
	El informe de Power BI representa los objetos visuales.
	En determinadas circunstancias, como cuando el modelo semántico supera los límites de protección de la capacidad, las consultas del modelo semántico vuelven automáticamente al modo DirectQuery. En este modo, las consultas se envían al punto de conexión de SQL Analytics de lakehouse o almacén.
	Las consultas directQuery enviadas al punto de conexión de SQL Analytics a su vez consultan las tablas Delta en OneLake. Por este motivo, el rendimiento de las consultas puede ser más lento que las consultas en memoria.

En las secciones siguientes se describen los conceptos y características de Direct Lake, incluida la carga de columnas, el marco, las actualizaciones automáticas y la reserva de DirectQuery.

Carga de columnas (transcodificación)

Los modelos semánticos de Direct Lake solo cargan datos de OneLake como y cuando las columnas se consultan por primera vez. El proceso de carga de datos a petición desde OneLake se conoce como transcodificación.

Cuando el modelo semántico recibe una consulta DAX (o expresiones multidimensionales, MDX), primero determina qué columnas son necesarias para generar un resultado de consulta. Las columnas necesarias incluyen las columnas que la consulta usa directamente y también las columnas necesarias para las relaciones y medidas. Normalmente, el número de columnas necesarias para generar un resultado de consulta es mucho menor que el número de columnas definidas en el modelo semántico.

Una vez que se comprenda qué columnas son necesarias, el modelo semántico determina qué columnas ya están en memoria. Si alguna columna necesaria para la consulta no está en memoria, el modelo semántico carga todos los datos de esas columnas de OneLake. La carga de datos de columna suele ser una operación muy rápida, pero puede depender de factores como la cardinalidad de los datos almacenados en las columnas.

Las columnas cargadas en la memoria se encuentran en la memoria. Las consultas futuras que implican solo columnas residentes no necesitan cargar más columnas en la memoria.

Una columna permanece residente hasta que haya motivo para que se quite (expulsar) de la memoria. Entre las razones por las que se pueden quitar las columnas se incluyen las siguientes:

• Se ha actualizado el modelo o la tabla (consulte El marco en la sección siguiente).
• Ninguna consulta ha usado la columna durante algún tiempo.
• Otras razones de administración de memoria, incluida la presión de memoria en la capacidad debido a otras operaciones simultáneas.

La elección de SKU de Fabric determina la memoria máxima disponible para cada modelo semántico de Direct Lake en la capacidad. Para obtener más información sobre los límites de protección de recursos y los límites máximos de memoria, consulte Límites y limitaciones de la capacidad de Fabric más adelante en este artículo.

Enmarcar

El marco proporciona a los propietarios de modelos un control a un momento dado sobre qué datos se cargan en el modelo semántico. El marco es una operación de Direct Lake desencadenada por una actualización de un modelo semántico y, en la mayoría de los casos, solo tarda unos segundos en completarse. Esto se debe a que es una operación de bajo costo donde el modelo semántico analiza los metadatos de la versión más reciente de las tablas de Delta Lake y se actualiza para hacer referencia a los archivos Parquet más recientes en OneLake.

Cuando se produce el marco, las columnas residentes se pueden expulsar de la memoria y el momento dado de la actualización se convierte en la nueva línea de base para todos los eventos de transcodificación futuros. Desde este punto, las consultas de Direct Lake solo consideran los datos de las tablas Delta a partir del momento de la operación de enmarcado más reciente. Por ese motivo, se consultan las tablas de Direct Lake para devolver datos en función del estado de la tabla Delta en el punto de la operación de enmarcado más reciente. Esa hora no es necesariamente el estado más reciente de las tablas Delta.

En el diagrama siguiente se muestra cómo funcionan las operaciones de marcos de Direct Lake.

En el diagrama se muestran los siguientes procesos y características.

Elemento	Descripción
	Existe un modelo semántico en un área de trabajo de Fabric.
	Las operaciones de enmarcado se realizan periódicamente y establecen la línea base para todos los eventos de transcodificación futuros. Las operaciones de enmarcado pueden producirse automáticamente, manualmente, según programación o mediante programación.
	OneLake almacena metadatos y archivos Parquet, que se representan como tablas Delta.
	La última operación de enmarcado incluye archivos Parquet relacionados con las tablas Delta, y específicamente los archivos Parquet que se agregaron antes de la última operación de enmarcado.
	Una operación de enmarcado posterior incluye archivos Parquet agregados después de la última operación de enmarcado.
	Las columnas residentes en el modelo semántico de Direct Lake podrían expulsarse de la memoria y el momento dado de la actualización se convierte en la nueva línea base para todos los eventos de transcodificación futuros.
	Las modificaciones de datos posteriores, representadas por nuevos archivos Parquet, no son visibles hasta que se produzca la siguiente operación de enmarcado.

No siempre es conveniente tener datos que representen el estado más reciente de cualquier tabla Delta cuando se produzca una operación de transcodificación. Tenga en cuenta que el marco puede ayudarle a proporcionar resultados de consulta coherentes en entornos en los que los datos de las tablas Delta son transitorios. Los datos pueden ser transitorios por varias razones, como cuando se producen procesos de extracción, transformación y carga (ETL) de ejecución prolongada.

La actualización de un modelo semántico de Direct Lake se puede realizar manualmente, automáticamente o mediante programación. Para más información, consulte Actualización de modelos semánticos de Direct Lake.

Para obtener más información sobre el control de versiones y el marco de la tabla Delta, consulte Descripción del almacenamiento para los modelos semánticos de Direct Lake.

Actualizaciones automáticas

Hay una configuración semántica de nivel de modelo para actualizar automáticamente las tablas de Direct Lake. Esta casilla está habilitada de forma predeterminada. Garantiza que los cambios de datos en OneLake se reflejen automáticamente en el modelo semántico de Direct Lake. Debe deshabilitar las actualizaciones automáticas cuando desee controlar los cambios de datos mediante el marco, que se explicó en la sección anterior. Para más información, consulte Administración de modelos semánticos de Direct Lake.

Sugerencia

Puede configurar la actualización automática de páginas en los informes de Power BI. Es una característica que actualiza automáticamente una página de informe específica que proporciona que el informe se conecta a un modelo semántico de Direct Lake (u otros tipos de modelo semántico).

Reserva de DirectQuery

Una consulta enviada a un modelo semántico de Direct Lake puede revertir al modo DirectQuery. En este caso, recupera datos directamente desde el punto de conexión de SQL Analytics del almacén o lakehouse. Estas consultas siempre devuelven los datos más recientes porque no están restringidos al momento dado de la última operación de marco.

Una consulta siempre retrocede cuando el modelo semántico consulta una vista en el punto de conexión de SQL Analytics o una tabla del punto de conexión de SQL Analytics que aplica la seguridad de nivel de fila (RLS).

Además, una consulta podría revertirse cuando el modelo semántico supera los límites de protección de la capacidad.

Importante

Si es posible, siempre debe diseñar la solución (o ajustar el tamaño de la capacidad) para evitar la reserva de DirectQuery. Esto se debe a que podría dar lugar a un rendimiento de consultas más lento.

Puede controlar la reserva de los modelos semánticos de Direct Lake estableciendo su propiedad DirectLakeBehavior . Para obtener más información, consulte Establecimiento de la propiedad de comportamiento de Direct Lake.

Límites y limitaciones de la protección de la capacidad del tejido

Los modelos semánticos de Direct Lake requieren una licencia de capacidad de Fabric. Además, hay límites de protección de capacidad y limitaciones que se aplican a la suscripción de capacidad de Fabric (SKU), como se muestra en la tabla siguiente.

Importante

La primera columna de la tabla siguiente también incluye suscripciones de capacidad de Power BI Premium (SKU P). Tenga en cuenta que Microsoft está consolidando las opciones de compra y retirando las SKU de Power BI Premium por capacidad. Los clientes nuevos y existentes deben considerar la posibilidad de comprar suscripciones de capacidad de Fabric (SKU F) en su lugar.

Para más información, consulte Actualización importante que llega a las licencias de Power BI Premium y Power BI Premium.

Fabric SKU	Archivos Parquet por tabla	Grupos de filas por tabla	Filas por tabla (millones)	Tamaño máximo del modelo en disco/OneLake (GB)	Memoria máxima (GB) 1
F2	1,000	1,000	300	10	3
F4	1,000	1,000	300	10	3
F8	1,000	1,000	300	10	3
F16	1,000	1,000	300	20	5
F32	1,000	1,000	300	40	10
F64/FT1/P1	5\.000	5\.000	1500	Sin límite	25
F128/P2	5\.000	5\.000	3,000	Sin límite	50
F256/P3	5\.000	5\.000	6,000	Sin límite	100
F512/P4	10 000	10,000	12,000	Sin límite	200
F1024/P5	10 000	10 000	24,000	Sin límite	400
F2048	10 000	10 000	24,000	Sin límite	400

¹ Para los modelos semánticos de Direct Lake, Max Memory representa el límite superior de recursos de memoria para la cantidad de datos que se pueden paginar. Por esta razón, no es una barrera de protección porque superarlo no da lugar a una reserva al modo DirectQuery; sin embargo, puede tener un impacto en el rendimiento si la cantidad de datos es lo suficientemente grande como para provocar una paginación excesiva dentro y fuera de los datos del modelo de los datos de OneLake.

Si se supera, el tamaño máximo del modelo en disco o OneLake hará que todas las consultas al modelo semántico vuelvan al modo DirectQuery. Todas las demás barreras de protección presentadas en la tabla se evalúan por consulta. Por lo tanto, es importante optimizar las tablas delta y el modelo semántico de Direct Lake para evitar tener que escalar verticalmente innecesariamente a una SKU de Fabric superior (lo que da lugar a un mayor costo).

Además, los límites de memoria máxima y unidad de capacidad por consulta se aplican a los modelos semánticos de Direct Lake. Para obtener más información, consulte Capacidades y SKU.

Consideraciones y limitaciones

Los modelos semánticos de Direct Lake presentan algunas consideraciones y limitaciones.

Nota:

Las funcionalidades y características de los modelos semánticos de Direct Lake evolucionan. Asegúrese de volver a comprobar periódicamente para revisar la lista más reciente de consideraciones y limitaciones.

• Cuando una tabla de modelo semántico de Direct Lake se conecta a una tabla en el punto de conexión de SQL Analytics que aplica la seguridad de nivel de fila (RLS), las consultas que implican esa tabla de modelos siempre volverán al modo DirectQuery. El rendimiento de las consultas puede ser más lento.
• Cuando una tabla de modelo semántico de Direct Lake se conecta a una vista en el punto de conexión de SQL Analytics, las consultas que implican esa tabla de modelos siempre volverán al modo DirectQuery. El rendimiento de las consultas puede ser más lento.
• No se admite el modelado compuesto. Esto significa que las tablas del modelo semántico de Direct Lake no se pueden mezclar con tablas en otros modos de almacenamiento, como Import, DirectQuery o Dual (excepto en casos especiales, incluidos los grupos de cálculo, los parámetros what-if y los parámetros de campo).
• Las columnas calculadas y las tablas calculadas que hacen referencia a columnas o tablas en el modo de almacenamiento de Direct Lake no se admiten. Se admiten grupos de cálculo, parámetros hipotéticos y parámetros de campo, que crean implícitamente tablas calculadas y tablas calculadas que no hacen referencia a las columnas o tablas de Direct Lake.
• Las tablas en modo de almacenamiento de Direct Lake no admiten tipos complejos de columnas de tabla Delta. Los tipos semánticos binarios y GUID también no son compatibles. Debe convertir estos tipos de datos en cadenas u otros tipos de datos admitidos.
• Las relaciones de tabla requieren que coincidan los tipos de datos de las columnas relacionadas.
• Las columnas de relaciones de un lado deben contener valores únicos. Se producirá un error en las consultas si se detectan valores duplicados en una columna de un lado.
• No se admite la inteligencia automática de datos y tiempo en Power BI Desktop . Se admite la marca de su propia tabla de fechas como tabla de fechas.
• La longitud de los valores de columna de cadena está limitada a 32 764 caracteres Unicode.
• No se admite el valor de punto flotante NaN (no un número).
• No se admiten los escenarios de inserción que usan para el escenario de uso del cliente .
• La publicación en web desde Power BI solo se admite cuando se usa una identidad fija para el modelo semántico de Direct Lake.
• En la experiencia de modelado web, la validación se limita a los modelos semánticos de Direct Lake. Se supone que las selecciones de usuario son correctas y no se emite ninguna consulta para validar la cardinalidad o las selecciones de filtro cruzado para las relaciones, o para la columna de fecha seleccionada en una tabla de fechas marcada.
• En el portal de Fabric, la pestaña Direct Lake del historial de actualizaciones muestra solo los errores de actualización relacionados con Direct Lake. Las operaciones de actualización correcta (enmarcado) no aparecen en la lista.
• La SKU de Fabric determina la memoria máxima disponible por modelo semántico de Direct Lake para la capacidad. Cuando se supera el límite, las consultas al modelo semántico pueden ser más lentas debido a la paginación excesiva dentro y fuera de los datos del modelo.
• No se admite la creación de un modelo semántico de Direct Lake en un área de trabajo que se encuentra en otra región del área de trabajo del origen de datos. Por ejemplo, si Lakehouse se encuentra en centro-oeste de EE. UU., solo puede crear modelos semánticos desde esta instancia de Lakehouse en la misma región. Una solución alternativa consiste en crear una instancia de Lakehouse en el área de trabajo de la otra región y acceder al acceso directo a las tablas antes de crear el modelo semántico. Para encontrar la región en la que se encuentra, consulte búsqueda de la región principal de Fabric.

Comparación con otros modos de almacenamiento

En la tabla siguiente se compara el modo de almacenamiento de Direct Lake con los modos de importación y almacenamiento de DirectQuery.

Funcionalidad	Direct Lake	Importar	DirectQuery
Licencias	Suscripción de capacidad de Fabric (SKU) solo	Cualquier licencia de Fabric o Power BI (incluidas las licencias gratuitas de Microsoft Fabric)	Cualquier licencia de Fabric o Power BI (incluidas las licencias gratuitas de Microsoft Fabric)
Origen de datos	Solo mesas de lago o almacén (o vistas)	Cualquier conector	Cualquier conector que admita el modo DirectQuery
Conexión a vistas de punto de conexión de SQL Analytics	Sí: pero se revertirá automáticamente al modo DirectQuery.	Sí	Sí
Modelos compuestos	No 1	Sí: puede combinarse con tablas de modo de almacenamiento Dual o DirectQuery.	Sí: se puede combinar con las tablas del modo de almacenamiento dual o de importación
Inicio de sesión único (SSO)	Sí	No aplicable	Sí
Tablas calculadas	No: excepto los grupos de cálculo, los parámetros hipotéticos y los parámetros de campo, que crean implícitamente tablas calculadas.	Sí	No: las tablas calculadas usan el modo importar almacenamiento incluso cuando hacen referencia a otras tablas en modo DirectQuery.
Columnas calculadas	No	Sí	Sí
Tablas híbridas	No	Sí	Sí
Particiones de tabla de modelos	No: sin embargo , la creación de particiones se puede realizar en el nivel de tabla Delta.	Sí: se crea automáticamente mediante la actualización incremental o se crea manualmente mediante el punto de conexión XMLA.	No
Agregaciones definidas por el usuario	No	Sí	Sí
Seguridad de nivel de objeto o seguridad de nivel de columna del punto de conexión de SQL Analytics	Sí: pero las consultas se revertirán al modo DirectQuery y podrían producir errores cuando se deniegue el permiso.	Sí: pero debe duplicar los permisos con la seguridad de nivel de objeto del modelo semántico	Sí: pero las consultas pueden producir errores cuando se deniega el permiso
Seguridad de nivel de fila (RLS) del punto de conexión de SQL Analytics	Sí: pero las consultas se revertirán al modo DirectQuery.	Sí: pero debe duplicar los permisos con el modelo semántico RLS.	Sí
Seguridad de nivel de fila del modelo semántico (RLS)	Sí: pero se recomienda encarecidamente usar una conexión fija en la nube de identidades .	Sí	Sí
Seguridad de nivel de objeto del modelo semántico (OLS)	Sí	Sí	Sí
Volúmenes de datos grandes sin necesidad de actualización	Sí	Menos adecuado: es posible que se requiera un tamaño de capacidad mayor para consultar y actualizar.	Sí
Reducción de la latencia de datos	Sí: cuando se habilitan las actualizaciones automáticas o la reencuadración mediante programación; sin embargo, la preparación de datos debe realizarse primero en la cadena ascendente.	No	Sí

¹ No se pueden combinar tablas en modo de almacenamiento de Direct Lake con tablas de modo de almacenamiento DirectQuery o Dual en el mismo modelo semántico. Sin embargo, puede usar Power BI Desktop para crear un modelo compuesto en un modelo semántico de Direct Lake y, a continuación, ampliarlo con nuevas tablas (mediante el modo de importación, DirectQuery o almacenamiento dual) o cálculos. Para obtener más información, consulte Compilación de un modelo compuesto en un modelo semántico.

Contenido relacionado

• Desarrollo de modelos semánticos de Direct Lake
• Administración de modelos semánticos de Direct Lake
• Descripción del almacenamiento para los modelos semánticos de Direct Lake
• Creación de un almacén de lago para Direct Lake
• Análisis del procesamiento de consultas para modelos semánticos de Direct Lake