Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Direct Lake es una opción de modo de almacenamiento de tablas del modelo semántico de Power BI disponible en Microsoft Fabric. Está optimizado para que grandes volúmenes de datos se carguen rápidamente en la memoria de las tablas Delta disponibles 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.
Direct Lake es ideal para modelos semánticos que se conectan a grandes Fabric lakehouses, almacenes y otros orígenes de datos Fabric con tablas Delta. Direct Lake es especialmente útil cuando replicar el volumen de datos completo en una tabla de importación es poco práctico o imposible. El motor de consultas VertiPaq procesa las consultas de Direct Lake e Importación, mientras que DirectQuery federa las consultas al origen de datos subyacente. Las consultas de Direct Lake y Import suelen superar a las consultas de DirectQuery al cargar e interactuar con objetos visuales en los informes.
Sin embargo, Direct Lake difiere del 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 de 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 actualiza las referencias a los archivos más recientes de OneLake. Por el contrario, una actualización de importació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). 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 las consultas de Direct Lake y, por tanto, proporciona 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 ya realizadas en Fabric mediante la integración fluida con grandes repositorios de datos, almacenes 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.
Sugerencia
El rendimiento de Direct Lake depende de tablas Delta bien optimizadas. Para obtener instrucciones completas sobre la optimización de tablas para el uso en Direct Lake, incluidas las recomendaciones para V-Order y grupos de filas, consulte Mantenimiento y optimización de tablas en contextos de múltiples cargas de trabajo.
¿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
Las tablas import y DirectQuery de los modelos semánticos 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.
Un modelo semántico con Tablas de importación y tablas de Direct Lake ofrece la escala y flexibilidad necesaria para muchos escenarios de BI.
Además, OneLake integration escribe automáticamente datos para tablas en el modo de almacenamiento de importación en tablas Delta en OneLake sin implicar ningún esfuerzo de migración, lo que le permite aprovechar muchas de las ventajas de Fabric disponibles para usuarios del modelo semántico de Importación, como la integración con lakehouses a través de accesos directos, consultas SQL, cuadernos y mucho más. Se recomienda esta opción como una manera rápida de aprovechar las ventajas de Fabric sin necesidad o rediseñando inmediatamente el almacenamiento de datos existente o el sistema de análisis.
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 Fabric lakehouses, instrucciones DML de T-SQL para almacenes 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 su 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 cargan e 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 de tablas usado. 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 traduce las consultas DAX a la sintaxis de consulta del origen de datos, como una consulta SQL, y las ejecuta en la base de datos de origen subyacente. Estas bases de datos fuente no suelen estar optimizadas para una carga intensiva de consultas que provienen de informes y las consultas agregadas necesarias por las visualizaciones, lo que puede ocasionar un rendimiento más lento en comparación con los modos de Importación 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 Semantic model modes in the servicio Power BI.
El modo de almacenamiento de tablas de Direct Lake tiene dos opciones:
Direct Lake en OneLake puede usar datos de uno o varios orígenes de datos Fabric con tablas Delta. Direct Lake en OneLake no regresa al modo DirectQuery a través del punto final de SQL Analytics del origen de datos. Los modelos semánticos con Direct Lake en tablas oneLake también pueden tener tablas de importación agregadas desde otros orígenes de datos.
Direct Lake en SQL puede usar los datos de un único origen de datos Fabric con tablas Delta. El punto de conexión de SQL Analytics se utiliza para el descubrimiento de tablas Delta y vistas SQL y para las comprobaciones de permisos. Direct Lake en los puntos de conexión de SQL recurre al modo de almacenamiento de tablas de 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 el control de acceso granular basado en SQL. La propiedad del modelo semántico, el comportamiento de Direct Lake, controla el comportamiento alternativo.
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 | Solo suscripción de capacidad de Fabric (SKU) | solo suscripción de capacidad de Fabric (SKU) | Cualquier licencia Fabric o Power BI (incluidas las licencias gratuitas de Microsoft Fabric) | Cualquier licencia Fabric o Power BI (incluidas las licencias gratuitas de Microsoft Fabric) |
| Origen de datos | Tablas de cualquier fuente de datos de Fabric sustentadas 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 | Sí, se puede combinar con tablas en modo de importación en el modelado web de Power BI y con tablas de DirectQuery utilizando herramientas XMLA. | No 1 | Sí: puede combinarse con las tablas del modo de almacenamiento directQuery, Dual y Direct Lake. | Sí – puede combinarse con tablas de modo de almacenamiento de importación, Dual y Direct Lake |
| 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 | No | 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 Embedded | 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.
Para obtener más información sobre cómo funciona Direct Lake, incluida la carga de columnas (transcodificación), la estructuración, las actualizaciones automáticas y la reserva de consulta DirectQuery, consulte Funcionamiento de Direct Lake.
Para más información sobre los permisos, la autenticación, OLS/RLS y las opciones de reglas de acceso a datos, consulte Integración de la seguridad de Direct Lake.
requisitos de capacidad de Fabric
Los modelos semánticos de Direct Lake requieren una licencia de capacidad Fabric. Además, existen barreras de capacidad y limitaciones que se aplican a la suscripción de capacidad (SKU) de Fabric, como se muestra en la siguiente tabla.
Importante
Las suscripciones de capacidad Premium de Power BI (P SKUs) también están incluidas en la primera columna de la tabla siguiente. Microsoft está consolidando las opciones de compra y retirando las SKU Power BI Premium por capacidad. En su lugar, los clientes nuevos y existentes deben considerar la posibilidad de comprar suscripciones de capacidad Fabric (SKU F).
Para obtener más información, consulte la importante actualización 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; 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 superan los guardrails, el comportamiento depende del modo de almacenamiento de tablas:
- Direct Lake en OneLake: Similar al modo de importación, se produce un error en la actualización y no se puede consultar el modelo hasta que las tablas Delta están optimizadas para que se encuentren dentro de los límites de los guardarraíles.
- Direct Lake en SQL: vuelve al modo DirectQuery si el retorno está habilitado. La actualización se completa con advertencia y las consultas siguen devolviendo resultados, pero con un rendimiento reducido.
El tamaño máximo del modelo en disk/OneLake guardrail se evalúa en el nivel de modelo y afecta a todas las consultas. 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 de forma innecesaria a una 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 tienen 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 volverá 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 Direct Lake 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, lo que significa que las tablas del modelo semántico de Direct Lake se pueden mezclar con tablas en otros modos de almacenamiento, como Importar, DirectQuery o Dual (excepto en casos especiales, incluidos los grupos de cálculo, los parámetros what-if y los parámetros de campo). | Compatible | No está soportado |
| Columnas calculadas y tablas calculadas que hacen referencia a columnas o tablas en el modo de almacenamiento Direct Lake. Los grupos de cálculo, los parámetros hipotéticos y los parámetros de campo, que crean implícitamente tablas calculadas y tablas calculadas que no hacen referencia a columnas o tablas de Direct Lake se admiten en todos los escenarios. | 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 de fecha y hora automática 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 usando un principal de servicio solo se admite cuando se utiliza 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, la pestaña Direct Lake del historial de actualizaciones enumera 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. Para encontrar cuál es su región, consulte encontrar su región principal de Fabric. | Sí | Sí Una solución alternativa consiste en crear una instancia de lakehouse en el área de trabajo de la otra región y crear un acceso directo a las tablas antes de crear el modelo semántico. |
| Para la inserción de informes se necesita un token de inserción V2. | Sí | Sí |
| Perfiles de entidad de servicio para la autenticación. | No está soportado | No está soportado |
| Power BI permite que los modelos semánticos de Direct Lake sean creados y consultados por entidades de servicio, y es compatible con la pertenencia al rol de Visor con entidades de servicio, pero los modelos semánticos predeterminados de Direct Lake en lakehouse/warehouse no soportan 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. | Compatible | 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 se admite directamente: puede crear una expresión de parámetro para usarla en el cadena de conexión. | Compatible |
| Agregar varias tablas desde la misma tabla de origen de datos. | No se admite en Power BI Desktop o modelado web. Es posible agregar varias tablas de la misma tabla de origen de datos mediante herramientas externas basadas en XMLA. Usar Edit tables en las herramientas de Power BI y actualizar resulta en un error que involucra múltiples tablas provenientes de la misma tabla de origen de datos en el modelo semántico. | No se admite en Power BI Desktop o en modelado web. Es posible agregar varias tablas de la misma tabla de origen de datos mediante herramientas externas basadas en XMLA. Con Edit tables en las herramientas de Power BI y refresh, provoca un error al haber varias tablas de la misma tabla de origen de datos en el modelo semántico. |
| Las tablas de Direct Lake creadas mediante aplicaciones XMLA se encuentran inicialmente en un estado no procesado hasta que la aplicación envía un comando refresh. Asegúrese de actualizar el modelo para procesar sus tablas al crear un nuevo modelo semántico. | Las consultas que implican tablas no procesadas devuelven un error. | Las consultas que implican tablas no procesadas vuelven al modo DirectQuery, a menos que la reversión esté deshabilitada, en cuyo caso las consultas fallan. |
Las herramientas compatibles con XMLA deben admitir compatibilityLevel 1604 o superior para trabajar con modelos semánticos de Direct Lake y exponer metadatos específicos de Direct Lake. |
Sí | Sí |
Analizar en Excel tablas dinámicas (y otros clientes MDX) tiene las mismas limitaciones que DirectQuery con tablas de Direct Lake en el modelo semántico. No se admiten instrucciones MDX con ámbito de sesión, como conjuntos con nombre, miembros calculados, miembros predeterminados, etc. Se admiten instrucciones MDX con ámbito de consulta, como la cláusula 'WITH'. No se admiten jerarquías definidas por el usuario de la tabla de Direct Lake. Las jerarquías definidas por el usuario de importación de tablas se admiten incluso con tablas de Direct Lake en el modelo semántico.
Power BI Desktop puede editar dinámicamente un modelo semántico con tablas de Direct Lake e Importar tablas. También se pueden incluir grupos de cálculo, parámetros hipotéticos y parámetros de campo, que crean tablas calculadas implícitamente y tablas calculadas que no hacen referencia a columnas o tablas de Direct Lake.
El modelado web de Power BI puede abrirse a cualquier modelo semántico, incluidas las tablas de Direct Lake con otras tablas de modo de almacenamiento.
La vista de consulta DAX, al editar o estar conectado en tiempo real, así como al escribir consultas DAX en la web, es compatible con Direct Lake en SQL, Direct Lake en OneLake, y modelos semánticos verdaderamente compuestos (Direct Lake en OneLake + Importación desde cualquier fuente de datos).
La vista TMDL es compatible con la edición en vivo en Power BI Escritorio.
La creación de informes con una conexión dinámica se admite para todos los modelos semánticos, cuando el autor del informe tiene al menos acceso de compilación.
Direct Lake en la expresión de conexión SQL del modelo semántico debe hacer referencia al punto de conexión de SQL Analytics por GUID, no por nombre descriptivo, para usar Edit tables y actualizar en Power BI Desktop y en el modelado web de Power BI. La expresión de conexión se puede actualizar en la vista TMDL o en herramientas externas basadas en XMLA. El GUID está disponible en la dirección URL al ver el endpoint de SQL Analytics en el navegador.