Compartir por

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 las tablas Delta almacenadas en OneLake, el único almacén para todos los datos de análisis. Una vez cargado en memoria, el modelo semántico permite el análisis interactivo de alto rendimiento.

Diagrama muestra un modelo semántico de Direct Lake y cómo se conecta a tablas Delta en OneLake, como se describe en los párrafos anteriores.

Direct Lake es ideal para modelos semánticos que se conectan a grandes Lakehouses de Fabric, almacenes y otros orígenes con tablas Delta, especialmente cuando replicar todo el volumen de datos en un modelo de importación es difícil o imposible. Las consultas de Direct Lake son, como el modo de importación, procesadas por el motor de consultas VertiPaq, mientras que DirectQuery federa las consultas al origen de datos subyacente. Esto significa que las consultas de Direct Lake, como el modo de importación, normalmente superan el rendimiento de DirectQuery.

Sin embargo, un direct Lake difiere de un modo de importación de una manera importante: 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. El modo de importación replica los datos y crea una copia caché completa de los datos para el modelo semántico, mientras que una actualización de Direct Lake solo copia los metadatos (conocidos como marcos, descritos más adelante en este artículo), lo que puede tardar unos segundos en completarse. La actualización de Direct Lake es una operación de bajo costo que 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 de OneLake. Por el contrario, para una actualización de importación se 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). Direct Lake mueve la preparación de datos a OneLake y, al hacerlo, usa toda la amplitud de las tecnologías de Fabric para la preparación de datos, incluidos los trabajos de Spark, las instrucciones DML de T-SQL, los flujos de datos, las canalizaciones, etc.

El modo de almacenamiento de Direct Lake ofrece las siguientes ventajas clave:

  • De forma similar al modo de importación, el motor VertiPaq procesa consultas de Direct Lake y, por tanto, ofrece un rendimiento de consulta comparable al modo de importación sin la sobrecarga de administración de los ciclos de actualización de datos para cargar todo el volumen de datos.
  • Usa las inversiones existentes de Fabric integrándose de manera fluida con grandes lagos de datos, almacenes de datos y otros orígenes de Fabric con tablas Delta. Por ejemplo, Direct Lake es una opción ideal para la capa de análisis gold en la arquitectura del almacén de lago de datos medallion.
  • Maximiza la rentabilidad de la inversión (ROI) porque los volúmenes de datos analizados pueden superar los límites máximos de memoria de la capacidad, ya que solo los datos necesarios para responder a una consulta se cargan en la memoria.
  • Minimiza las latencias de datos mediante la sincronización rápida y automática de un modelo semántico con sus orígenes, lo que hace que los nuevos datos estén disponibles para los usuarios empresariales sin programaciones de actualización.

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

El caso de uso principal para el modo de almacenamiento de Direct Lake es típicamente para proyectos de análisis impulsados por TI que utilizan arquitecturas centradas en lagos. En estos escenarios, usted 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, lo que le permite 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 esta opción como una manera rápida de aprovechar las ventajas de Fabric sin necesidad de rediseñar el almacenamiento de datos o el sistema de análisis existentes.

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, lo que ayuda a garantizar que la lógica de preparación de datos se realice en sentido ascendente 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, si un analista de autoservicio no tiene permisos de escritura en una instancia de Lakehouse administrada por TI, aumentar el modelo con tablas del modo de almacenamiento de importación podría ser una buena opción, ya que el modo de importación 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 de (o prueba de concepto [POC]) para determinar si un modelo semántico de Direct Lake es la solución adecuada y mitigar el riesgo.

Conceptos clave y terminología

En este artículo, se asume que está familiarizado con estos conceptos:

  • Los usuarios interactúan con objetos visuales en informes de Power BI, que generan consultas DAX al modelo semántico.
  • Modo de almacenamiento: el modelo semántico procesa las consultas DAX de forma diferente en función del modo de almacenamiento empleado. Por ejemplo:
    • Los modos de importación y almacenamiento de Direct Lake usan el motor VertiPaq para procesar consultas DAX y devolver resultados al informe y al usuario de Power BI.
    • DirectQuery, por otro lado, traduce las consultas DAX a la sintaxis de consulta del origen de datos (normalmente una forma de SQL) y las federa a la base de datos subyacente. Los procesadores de consultas de base de datos de origen no suelen estar orientados a consultas agregadas de estilo BI y, por lo tanto, generan un rendimiento más lento y una menor interactividad del usuario en comparación con los modos Importar y Direct Lake.

El modo de almacenamiento es una propiedad de una tabla en el modelo semántico. Cuando un modelo semántico incluye tablas con distintos modos de almacenamiento, se conoce como modelo compuesto. Para obtener más información sobre los modos de almacenamiento, consulte Modos de modelo semántico en el servicio Power BI.

  • El modo Direct Lake puede usar dos métodos de acceso diferentes:

    • Direct Lake en OneLake no depende de los puntos de conexión de SQL y puede usar datos de cualquier origen de datos de Fabric con tablas Delta. Direct Lake en OneLake no recurre al modo DirectQuery.

    Nota

    Direct Lake on OneLake está actualmente en versión preliminar pública.

    • Direct Lake en puntos de conexión de SQL usa el punto de conexión SQL de una instancia de Fabric Lakehouse o un almacén para la detección de tablas delta y las comprobaciones de permisos. Direct Lake en los puntos de conexión de SQL puede revertir al modo DirectQuery cuando no puede cargar los datos directamente desde una tabla Delta, como cuando el origen de datos es una vista SQL o cuando el almacenamiento usa seguridad de nivel de fila (RLS) basado en SQL. Direct Lake en puntos de conexión de SQL está disponible con carácter general y totalmente compatible en producción.

Comparación de los 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.

Capacidad Direct Lake en OneLake Direct Lake en puntos de conexión de SQL Importación Consulta Directa
Licenciamiento Suscripción de capacidad de Fabric (SKU) solo 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 Tablas de cualquier fuente de datos de Fabric respaldadas por tablas Delta Solo mesas de almacén o almacén de lago de datos (o vistas) Cualquier conector Cualquier conector que admita el modo DirectQuery
Conexión a vistas de punto de conexión de SQL Analytics No Sí: pero se revertirá automáticamente al modo DirectQuery. Sí Sí
Modelos compuestos No 1 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í Sí No aplicable Sí
Tablas calculadas Sí: pero los cálculos no pueden hacer referencia a columnas de tablas en modo Direct Lake. No – excepto grupos de cálculo, parámetros hipotéticosy 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 Sí: pero los cálculos no pueden hacer referencia a columnas de tablas en modo Direct Lake. No Sí Sí
Tablas híbridas No 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. 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 No Sí: se admite la importación de tablas de agregación en tablas de DirectQuery Sí
Seguridad de nivel de objeto o seguridad de nivel de columna del punto de conexión de SQL Analytics No Sí: pero puede producir errores cuando se deniega 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 No 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 identidad fija conexión en la nube Sí: pero se recomienda encarecidamente usar una identidad fija conexión en la nube Sí Sí
Seguridad de nivel de objeto del modelo semántico (OLS) Sí Sí Sí Sí
Volúmenes de datos grandes sin necesidad de actualización Sí Sí No Sí
Reducción de la latencia de datos Sí: cuando se habilitan las actualizaciones automáticas o la reencuadración mediante programación Sí: cuando se habilitan las actualizaciones automáticas o la reencuadración mediante programación No Sí
Power BI Integrado Sí 2 Sí 2 Sí Sí

1 Cuando se usa Direct Lake en puntos de conexión de SQL, 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 Creación de un modelo compuesto en un modelo semántico.

2 Requiere un token de inserción V2. Si utiliza una entidad de servicio, debe usar una conexión en la nube de identidad fija.

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 columnas en lugar de filas. 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á acoplado con el punto de conexión de SQL, lo que 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 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. 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 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

Marco proporciona a los propietarios de modelos un control temporal 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 encuadre, los segmentos de columnas de tabla y los diccionarios residentes pueden ser expulsados de la memoria si los datos subyacentes han cambiado y el momento 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ónde 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 generalmente no se eliminarán cuando tenga lugar el encuadre incremental, ya que se añadirán nuevos valores a los diccionarios existentes. Este enfoque de marco incremental ayuda a reducir la carga de recarga y beneficia al rendimiento de las consultas. En el caso ideal, cuando una tabla Delta no recibió actualizaciones, no es necesario volver a cargar las columnas que ya residen en la memoria y las consultas muestran un impacto mucho menor en el rendimiento después del marco porque el marco incremental básicamente permite que el modelo semántico actualice partes sustanciales de los datos en memoria existentes en su lugar.

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

Diagrama muestra cómo funcionan las operaciones de enmarcado 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.

La actualización de un modelo semántico de Direct Lake se puede realizar manualmente, automáticamente o mediante programación. Para obtener más información, consulte Actualizar 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. Está habilitado 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 obtener 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, siempre que el informe se conecte a un modelo semántico de Direct Lake u otro tipo de modelo semántico.

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 cuyo caso 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.

Cuando se produce la reserva de DirectQuery, una consulta ya no usa el modo Direct Lake. Una consulta no puede aprovechar el modo Direct Lake 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 no puede aprovechar el modo Direct Lake cuando una tabla Delta 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. Esta configuración solo se aplica a Direct Lake en puntos de conexión de SQL. Direct Lake en OneLake no admite la reserva de DirectQuery. Para obtener más información, consulte Establecimiento de la propiedadde comportamiento de Direct Lake.

Permisos de acceso y seguridad de datos

De forma predeterminada, Direct Lake usa el inicio de sesión único (SSO), lo que significa que la identidad que consulta el modelo semántico (a menudo un usuario de informe) debe estar autorizado para acceder a los datos. Como alternativa, puede enlazar un modelo de Direct Lake a una conexión en la nube (SCC) que se pueda compartir para proporcionar una identidad fija y deshabilitar el inicio de sesión único. En este caso, solo la identidad fija requiere acceso de lectura a los datos del origen.

Permisos de elementos de Fabric

Los modelos semánticos de Direct Lake se adhieren a un modelo de seguridad en capas. Realizan comprobaciones de permisos para determinar si la identidad que intenta acceder a los datos tiene los permisos de acceso a datos necesarios en el elemento de datos de origen y el modelo semántico. Los permisos se pueden asignar directamente o adquirir implícitamente mediante roles de área de trabajo en Microsoft Fabric.

Es importante saber que Direct Lake en OneLake y Direct Lake en los puntos de conexión de SQL realizan comprobaciones de permisos de forma diferente.

  • Direct Lake en OneLake requiere permisos Read y ReadAll en lakehouse/warehouse para acceder a las tablas delta.
  • Direct Lake en puntos de conexión de SQL requiere permisos Read y ReadData en lakehouse/warehouse para acceder a los datos desde el punto de conexión de SQL Analytics.

Nota

Direct Lake en OneLake requiere que los usuarios tengan permiso para leer tablas Delta en OneLake y no necesariamente el punto de conexión de SQL. Esto aplica un diseño de seguridad centralizado en el que OneLake es el único origen del control de acceso.

Direct Lake en puntos de conexión de SQL, por otro lado, requiere que los usuarios tengan acceso de lectura al punto de conexión de SQL y no necesariamente a tablas Delta en OneLake. Esto se debe a que Fabric concede los permisos necesarios al modelo semántico para leer las tablas Delta y los archivos Parquet asociados (para cargar datos de columna en memoria). El modelo semántico también tiene los permisos necesarios para leer periódicamente el punto de conexión de SQL Analytics para realizar comprobaciones de permisos para determinar a qué datos puede tener acceso el usuario que realiza la consulta (o identidad fija).

Permisos de modelo semántico

Además de los permisos de elementos de Fabric, también debe conceder permisos a los usuarios para que puedan usar o administrar el modelo semántico de Direct Lake. En resumen, los consumidores de informes necesitan permiso de lectura y los creadores de informes necesitan permiso de compilación adicional. Los permisos de modelo semántico se pueden asignar directamente o adquirir implícitamente mediante roles de área de trabajo. Para administrar la configuración del modelo semántico (para actualizar y otras configuraciones), debe ser el propietario del modelo semántico .

Requisitos de permisos de

Tenga en cuenta los siguientes escenarios y requisitos de permisos.

Escenario Permisos necesarios Comentarios
Los usuarios pueden ver informes Conceda permiso de lectura para los informes y permiso de lectura para el modelo semántico.

Si el modelo semántico usa Direct Lake en puntos de conexión de SQL y la conexión en la nube usa SSO, conceda al menos permisos ReadyReadDatapara lakehouse o warehouse.

Si el modelo semántico usa Direct Lake en OneLake y la conexión en la nube usa SSO, conceda al menos el permiso Read y ReadAll para las tablas Delta de OneLake.		 Los informes no necesitan pertenecer al mismo área de trabajo que el modelo semántico. Para más información, vea Estrategia para consumidores de solo lectura.
Los usuarios pueden crear informes Conceda permiso de compilación para el modelo semántico.

Si el modelo semántico usa Direct Lake en puntos de conexión de SQL y la conexión en la nube usa SSO, conceda al menos permisos Read y ReadData para lakehouse o warehouse.

Si el modelo semántico usa Direct Lake en OneLake y la conexión en la nube usa SSO, conceda al menos el permiso Read y ReadAll para las tablas Delta de OneLake.		 Para obtener más información, consulte Estrategia para creadores de contenido .
Los usuarios pueden ver informes, pero se les deniega la consulta a las tablas lakehouse, SQL Analytics o Delta en OneLake. Conceda permiso de lectura para los informes y permiso de lectura para el modelo semántico.

No conceda a los usuarios ningún permiso para las tablas lakehouse, warehouse o Delta.		 Solo es adecuado cuando el modelo de Direct Lake usa una identidad fija a través de una conexión en la nube con SSO deshabilitado.
Administrar el modelo semántico, incluida la configuración de actualización Requiere la propiedad del modelo semántico. Para más información, vea Propiedad del modelo semántico.

Importante

Siempre debe probar los permisos exhaustivamente antes de liberar el modelo semántico y los informes en producción.

Para obtener más información, consulte Permisos de modelo semántico.

Requisitos de capacidad de Fabric

Los modelos semánticos de Direct Lake requieren una licenciade 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.

SKU de Fabric 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 1,500 Ilimitado 25
F128/P2 5.000 5.000 3,000 Ilimitado 50
F256/P3 5.000 5.000 6 000 Ilimitado 100
F512/P4 10.000 10.000 12,000 Ilimitado 200
F1024/P5 10.000 10.000 24,000 Ilimitado 400
F2048 10.000 10.000 24,000 Ilimitado 400

1 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 del modelo máximo de en disco o OneLake hace 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 innecesariamente a un SKU de Fabric superior.

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 SKUs.

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 rápidamente. Asegúrese de volver a comprobar periódicamente para revisar la lista más reciente de consideraciones y limitaciones.

Consideración y limitación Direct Lake en OneLake Direct Lake en SQL (punto de análisis)
Cuando el punto de conexión de SQL Analytics aplica la seguridad de nivel de fila, las consultas DAX se procesan de forma diferente en función del tipo de modo de Direct Lake empleado.

Cuando se emplea Direct Lake en OneLake, las consultas se realizarán correctamente y no se aplicará RLS basado en SQL. Direct Lake en OneLake requiere que el usuario tenga acceso a los archivos de OneLake, lo que no observa RLS basado en SQL.		 Las consultas se realizarán correctamente. Sí, a menos que la función de respaldo esté deshabilitada, en ese caso, las consultas fallarán.
Si una tabla del modelo semántico se basa en una vista SQL (no materializada), las consultas DAX se procesan de forma diferente según el tipo de modo direct Lake empleado.

Direct Lake en los puntos de conexión de SQL se revertirá a DirectQuery en este caso.

No se admite la creación de una tabla de Direct Lake en OneLake basada en una vista SQL no materializada. En su lugar, puede usar una vista materializada de lakehouse porque se crean tablas Delta. Como alternativa, use otro modo de almacenamiento, como Importar o DirectLake para tablas basadas en vistas SQL no materializadas.		 No aplicable Sí, a menos que la función de respaldo esté deshabilitada, en ese caso, las consultas fallarán.
El modelado compuesto no se admite en este momento, lo que 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). No está soportado No está soportado
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 columnas o tablas de Direct Lake. No está soportado No está soportado
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. No está soportado No está soportado
Las relaciones de tabla requieren que coincidan los tipos de datos de las columnas relacionadas. Sí Sí
Las columnas de relaciones de un lado deben contener valores únicos. Las consultas producen un error si se detectan valores duplicados en una columna de un lado. Sí Sí
Inteligencia automática de fecha y hora en Power BI Desktop para crear relaciones con solo la parte de fecha de una columna datetime. Nota: Se admite designar su propia tabla como una tabla de fechas y crear relaciones usando columnas de fecha. Compatible No está soportado
La longitud de los valores de columna de cadena está limitada a 32 764 caracteres Unicode. Sí Sí
No se admiten valores de punto flotante no numéricos, como NaN (no un número). Sí Sí
Publicar en la web desde Power BI mediante una entidad de servicio solo se admite cuando se usa una identidad fija para el modelo semántico de Direct Lake. Sí Sí
En la experiencia de modelado web , la validación está limitada para 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. Sí Sí
En el portal de Fabric, en la pestaña Direct Lake del historial de actualizaciones se enumeran los errores de actualización relacionados con Direct Lake. Las operaciones de actualización correcta (enmarcado) no suelen aparecer a menos que cambie el estado de actualización, como "desde ninguna ejecución anterior" o "error de actualización" a "actualizado correctamente" o "actualizado correctamente con advertencias". Sí Sí
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. Sí Sí
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 buscar la región principal de Fabric. Sí Sí
Para la inserción de informes se necesita un token de inserción V2. Sí No está soportado
Perfiles de entidad de servicio para la autenticación. No está soportado No está soportado
Los modelos semánticos de Power BI Direct Lake se pueden crear y consultar mediante entidades de servicio y pertenencia a roles de visor con entidades de servicio, pero los modelos semánticos predeterminados de Direct Lake en lakehouse/warehouse no admiten este escenario. Sí Sí
Los accesos directos de una instancia de Lakehouse se pueden usar como orígenes de datos para tablas de modelos semánticos. No se admite durante la versión preliminar pública Compatible
Cree modelos de Direct Lake en áreas de trabajo personales (Mi área de trabajo). No está soportado No está soportado
Reglas de canalización de implementación para volver a enlazar el origen de datos. No está soportado Compatible

Contenido relacionado