Funcionamiento de Direct Lake

Normalmente, las consultas enviadas a un modelo semántico de Direct Lake se gestionan desde una caché en la 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 columna en lugar de por fila. Los modelos semánticos cargan columnas completas de tablas delta en memoria a medida que las consultas las requieren.

Direct Lake en OneLake no está vinculado al punto de conexión SQL. Esta arquitectura ofrece una integración más estrecha con características de OneLake, como la seguridad de OneLake y planes de consulta DAX más eficaces, ya que, por ejemplo, no es necesario comprobar la seguridad basada en SQL. DirectQuery fallback no es compatible con Direct Lake en OneLake.

Con Direct Lake en puntos de conexión de SQL, una consulta DAX podría usar el fallback 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 se produce cuando se detecta la seguridad basada en SQL en el punto de conexión de SQL. 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 las secciones siguientes se describen los conceptos y características de Direct Lake, incluida la carga de columnas, la encapsulación, las actualizaciones automáticas y el retorno a DirectQuery.

Carga de columnas (transcodificación)

Los modelos semánticos de Direct Lake cargan datos de OneLake solo cuando una consulta solicita una columna por primera vez. Este proceso de carga de datos a petición 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. Se necesita cualquier columna usada directamente por la consulta y también las columnas requeridas por las relaciones y medidas. Normalmente, el número de columnas necesarias para generar un resultado de consulta es significativamente menor que el número de columnas definidas en el modelo semántico.

Una vez que 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 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:

• El modelo o la tabla se ha actualizado después de una actualización de la tabla Delta en el origen (vea Encuadre 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 del SKU de Fabric determina la memoria máxima disponible para cada modelo semántico de Direct Lake dentro de la capacidad asignada. Para más información sobre los límites de protección de recursos y los límites máximos de memoria, consulte Requisitos de capacidad de Fabric.

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 framing es una operación de Direct Lake que se desencadena al actualizar un modelo semántico. En la mayoría de los casos, solo tarda unos segundos en completarse. Esto se debe a que es una operación de bajo coste en la que el modelo semántico analiza los metadatos de la versión más reciente de las tablas de Delta Lake y actualiza las referencias para que apunten a los archivos Parquet más recientes de OneLake.

Cuando se realiza el encuadre, el proceso podría desalojar de la memoria los segmentos de columnas de tabla y los diccionarios residentes si los datos subyacentes han cambiado. El momento dado de la actualización se convierte en la nueva línea 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. Ese momento no es necesariamente el estado más reciente de las tablas Delta.

El modelo semántico analiza el registro Delta de cada tabla Delta durante el proceso de enmarcado para eliminar solo los segmentos de columna afectados y recargar los datos recién agregados durante la transcodificación. Una optimización importante es que los diccionarios normalmente no se descartan cuando se aplica el enmarcado incremental, y se añaden nuevos valores a los diccionarios existentes. Este enfoque de marco incremental ayuda a reducir la carga de recarga y beneficia el rendimiento de las consultas. En el caso ideal, cuando una tabla Delta no recibe actualizaciones, no es necesario volver a cargar las columnas que ya residen en la memoria. Las consultas muestran un impacto mucho menor en el rendimiento después del marco porque el marco incremental básicamente permite al modelo semántico actualizar partes sustanciales de los datos en memoria existentes.

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 ser eliminadas de la memoria, y el momento dado de la actualización se convierte en el nuevo punto de referencia 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.

Puede actualizar un modelo semántico de Direct Lake manualmente, automáticamente o mediante programación. Para obtener más información, consulte Actualizar modelos semánticos de Direct Lake.

Actualizaciones automáticas

El modelo semántico incluye una configuración que actualiza automáticamente las tablas de Direct Lake. Está habilitado de manera predeterminada. Esta configuración garantiza que los cambios de datos en OneLake aparezcan automáticamente en el modelo semántico de Direct Lake. Deshabilite las actualizaciones automáticas cuando desee controlar los cambios de datos mediante el marco, que explica la sección anterior. Para obtener más información, consulte administración de modelos semánticos de Direct Lake .

Alternativa de DirectQuery

Cuando se usa Direct Lake en puntos de conexión de SQL, una consulta enviada a un modelo semántico de Direct Lake puede revertir al modo DirectQuery. En este modo, la tabla ya no funciona en modo Direct Lake. Recupera datos directamente desde el punto de conexión de SQL Analytics del almacén o almacén de lago de datos. Estas consultas siempre devuelven los datos más recientes porque no están restringidos al momento dado de la última operación de marco. Sin embargo, las operaciones de respaldo pueden provocar un rendimiento más lento de las consultas.

Direct Lake en OneLake se ejecuta exclusivamente en modo DirectLakeOnly y no admite la reserva de DirectQuery. Para los nuevos modelos semánticos, es la opción recomendada de Direct Lake.

Cuando se usa el modo Direct Lake

Las consultas se mantienen en modo Direct Lake (evitando el recurso a DirectQuery) solo cuando todas las condiciones siguientes se cumplen:

• El modelo semántico no hace referencia a ninguna tabla que tenga la seguridad de nivel de fila (RLS) de SQL definida en el punto de conexión de SQL Analytics.
• El modelo semántico no hace referencia a tablas que tengan definido el enmascaramiento dinámico de datos (DDM) de SQL en el extremo de análisis de SQL.
• El modelo semántico no hace referencia a ninguna tabla que tenga la seguridad de nivel de objeto (OLS) de SQL definida en el punto de conexión de SQL Analytics.
• El modelo semántico no hace referencia a ninguna tabla basada en vistas SQL no materializadas.
• Ninguna tabla del modelo semántico supera los límites de protección, tal como se definen en Requisitos de capacidad de Fabric:
  • El número de archivos Parquet se encuentra dentro del límite.
  • El número de grupos de filas está dentro del límite.
  • El número de filas está dentro del límite.
• Ha actualizado (enmarcado) el modelo semántico después de crear o modificar las tablas Delta subyacentes.

Una sola tabla que supere cualquier límite de barrera de protección impide el modo Direct Lake para todo el modelo.

Controlar la alternativa con DirectLakeBehavior

Cuando no se cumplen las condiciones de Direct Lake, el comportamiento de los modelos semánticos depende de la configuración de DirectLakeBehavior . Esta configuración solo se aplica a Direct Lake en puntos de conexión de SQL.

Establezca la propiedad DirectLakeBehavior en uno de los tres valores siguientes:

Establecer DirectLakeBehavior

En la vista Modelo , abra el panel Propiedades del modelo semántico y cambie la configuración de comportamiento de Direct Lake .

Establecimiento de DirectLakeBehavior mediante programación

También puede configurar la propiedad DirectLakeBehavior mediante el modelo de objetos tabulares (TOM) o el lenguaje de scripting de modelos tabulares (TMSL).

En el ejemplo siguiente se especifican todas las consultas que solo usan el modo Direct Lake:

// Disable fallback to DirectQuery mode.
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly;
database.Model.SaveChanges();

Para obtener más información, vea Model.DirectLakeBehavior (propiedad).

Diagnosticar el mecanismo de respaldo

Para identificar qué tablas se revierten y por qué, ejecute la siguiente consulta DAX:

EVALUATE TABLETRAITS()

La columna [DirectLakeFallbackInfo] muestra el motivo de respaldo de cada tabla. Un valor de None significa que la tabla usa el modo Direct Lake.

Solucionar las causas habituales de los mecanismos alternativos

Utilice esta tabla para identificar la corrección correspondiente a cada escenario de respaldo:

Para obtener un análisis detallado de nivel de consulta mediante Analizador de rendimiento o SQL Server Profiler, consulte Análisis del procesamiento de consultas para modelos semánticos de Direct Lake.

Contenido relacionado

• Introducción a Direct Lake
• Desarrollar modelos semánticos de Direct Lake
• Administración de modelos semánticos de Direct Lake
• Descripción del rendimiento de las consultas de Direct Lake