Desarrollo de modelos semánticos de Direct Lake

En este artículo se describen los temas de diseño relevantes para desarrollar modelos semánticos de Direct Lake.

Creación del modelo

Puede crear un modelo semántico de Direct Lake en Power BI Desktop o desde muchos elementos de Fabric en el explorador. Por ejemplo, desde una instancia de Open Lakehouse puede elegir Nuevo modelo semántico para crear un nuevo modelo semántico en el modo de almacenamiento de Direct Lake.

Puede usar Power BI Desktop o el modelado web en el explorador para editar el modelo semántico para agregar relaciones, cambiar el nombre de los campos, agregar medidas y otras tareas de modelado semántico.

Como alternativa, al igual que con cualquier modelo semántico de Power BI, puede continuar el desarrollo del modelo mediante una herramienta compatible con XMLA, como SQL Server Management Studio (SSMS) (versión 19.1 o posterior) o herramientas de la comunidad de código abierto. Para obtener más información, consulte Compatibilidad de escritura de modelos con el punto de conexión XMLA más adelante en este artículo. Los cuadernos de Fabric también pueden crear y editar modelos semánticos mediante programación con "Semantic Link" y laboratorios de "Semantic Link."

Model tables

Las tablas de modelo se basan en una tabla o una vista del punto de conexión de análisis SQL. Sin embargo, evite usar vistas siempre que sea posible. Las consultas a una tabla de modelos basadas en una vista se revierten al modo DirectQuery, lo que puede dar lugar a un rendimiento más lento de las consultas.

Las tablas deben incluir columnas para filtrar, agrupar, ordenar y resumir, además de columnas que admiten relaciones de modelo. Las columnas innecesarias no afectan al rendimiento de las consultas del modelo semántico porque no se cargan en memoria, pero dan como resultado un tamaño de almacenamiento mayor en OneLake y tienen más recursos de proceso para cargar y mantener.

Las tablas de importación se pueden agregar a modelos semánticos con Direct Lake en tablas de OneLake. Las tablas calculadas se pueden agregar siempre y cuando no hagan referencia a una tabla de Direct Lake. Se pueden agregar grupos de cálculo.

Para obtener información sobre cómo seleccionar qué tablas se van a incluir en el modelo semántico de Direct Lake, consulte Edición de tablas para modelos semánticos de Direct Lake.

Para obtener más información sobre las columnas que se van a incluir en las tablas del modelo semántico, consulte Descripción del rendimiento de las consultas de Direct Lake.

Aplicación de reglas de acceso a datos

Cuando tenga requisitos para entregar subconjuntos de datos del modelo a distintos usuarios, puede aplicar reglas de acceso a datos. Para aplicar reglas, configure la seguridad de nivel de objeto (OLS) o la seguridad de nivel de fila (RLS) en el punto de conexión de SQL Analytics o en el modelo semántico.

Seguridad de nivel de objeto (OLS)

OLS implica restringir el acceso para detectar y consultar objetos o columnas. Por ejemplo, puede usar OLS para limitar los usuarios que pueden acceder a la columna Salary de la tabla Employee.

En el caso de un punto de conexión de SQL Analytics, puede configurar OLS para controlar el acceso a los objetos de punto de conexión, como tablas o vistas, y la seguridad de nivel de columna (CLS) para controlar el acceso a las columnas de la tabla de puntos de conexión.

Para un modelo semántico, puede configurar OLS para controlar el acceso a las tablas o columnas del modelo. Debe usar herramientas de la comunidad de código abierto como Tabular Editor para configurar OLS.

Seguridad a nivel de fila (RLS)

RLS implica restringir el acceso a subconjuntos de datos en tablas. Por ejemplo, puede usar RLS para asegurarse de que los vendedores solo pueden acceder a los datos de ventas de los clientes de su región de ventas.

Para un punto de conexión de SQL Analytics, puede configurar RLS para controlar el acceso a las filas de una tabla de puntos de conexión.

Para un modelo semántico, puede configurar RLS para controlar el acceso a las filas de las tablas del modelo. RLS se puede configurar en la experiencia de modelado web o mediante una herramienta de terceros.

Cómo se evalúan las consultas

La razón para desarrollar modelos semánticos de Direct Lake es lograr consultas de alto rendimiento en grandes volúmenes de datos en OneLake. Por lo tanto, debe esforzarse por diseñar una solución que maximice las posibilidades de realizar consultas en memoria.

Los pasos siguientes describen cómo se evalúan las consultas (y si fallan). Las ventajas del modo de almacenamiento de Direct Lake solo son posibles cuando se logra el quinto paso.

1. Si la consulta contiene cualquier tabla o columna restringida por olS del modelo semántico, se devuelve un resultado de error (los objetos visuales de informe no se pueden representar).
2. Si la consulta contiene cualquier columna restringida por CLS del punto de conexión de SQL Analytics (o se deniega la tabla), se devuelve un resultado de error (los objetos visuales de informe no se pueden representar).
   1. Si la conexión en la nube usa SSO (valor predeterminado), CLS viene determinado por el nivel de acceso del consumidor del informe.
   2. Si la conexión en la nube usa una identidad fija, CLS viene determinada por el nivel de acceso de la identidad fija.
3. Si la consulta contiene cualquier tabla en el punto de conexión de SQL Analytics que aplica RLS o se usa una vista, la consulta vuelve al modo DirectQuery.
   1. Si la conexión en la nube usa SSO (valor predeterminado), RLS viene determinado por el nivel de acceso del consumidor del informe.
   2. Si la conexión en la nube usa una identidad fija, RLS viene determinada por el nivel de acceso de la identidad fija.
4. Si la consulta supera los límites de protección de la capacidad, vuelve al modo DirectQuery.
5. De lo contrario, la consulta se satisface desde la memoria caché. Los datos de columna se cargan en la memoria como y cuando es necesario.

Permisos del elemento origen

La cuenta usada para acceder a los datos es una de las siguientes.

• Si la conexión en la nube usa SSO (valor predeterminado), es el consumidor del informe.
• Si la conexión en la nube usa una identidad fija, es la identidad fija.

La cuenta debe tener al menos permisos Read y ReadData en el elemento de origen (lakehouse o warehouse). Los permisos de elemento se pueden heredar de roles de área de trabajo o asignarse explícitamente para el elemento, tal como se describe en este artículo.

Suponiendo que se cumple este requisito, Fabric concede el acceso necesario al modelo semántico para leer las tablas Delta y los archivos Parquet asociados (para cargar datos de columna en memoria) y se pueden aplicar reglas de acceso a datos.

Opciones de reglas de acceso a datos

Puede configurar reglas de acceso a datos en:

• Solo el modelo semántico.
• Solo el punto de conexión de análisis SQL.
• Tanto en el modelo semántico como en el endpoint de análisis de SQL.

Reglas del modelo semántico

Si debe aplicar reglas de acceso a datos, debe hacerlo en el modelo semántico siempre que sea viable. Esto se debe a que RLS aplicado por el modelo semántico se consigue filtrando la caché de datos en memoria para lograr consultas de alto rendimiento.

También es un enfoque adecuado cuando no se concede permiso a los consumidores de informes para consultar el almacén de lago de datos o el almacenamiento de datos.

En cualquier caso, se recomienda encarecidamente que la conexión en la nube use una identidad fija en lugar de SSO. SSO implicaría que los usuarios finales puedan acceder directamente al punto de conexión de SQL Analytics y, por lo tanto, omitir las reglas de seguridad en el modelo semántico.

Reglas del punto de conexión de análisis SQL

Resulta conveniente aplicar reglas de acceso a datos en el punto de conexión de análisis SQL cuando la conexión de nube del modelo semántico usa el inicio de sesión único (SSO). Esto se debe a que la identidad del usuario se delega para consultar el punto de conexión de SQL Analytics, lo que garantiza que las consultas devuelvan solo los datos a los que puede acceder el usuario. También es adecuado aplicar reglas de acceso a datos en este nivel cuando los usuarios consultan el punto de conexión de SQL Analytics directamente para otras cargas de trabajo (por ejemplo, para crear un informe paginado de Power BI o exportar datos).

Sin embargo, en particular, una consulta de modelo semántico vuelve al modo DirectQuery cuando incluye cualquier tabla que aplique RLS en el punto de conexión de SQL Analytics. Por lo tanto, el modelo semántico nunca podría almacenar en caché los datos en memoria para lograr consultas de alto rendimiento.

Reglas en ambas capas

Las reglas de acceso a datos se pueden aplicar en ambas capas. Sin embargo, este enfoque implica una sobrecarga adicional de complejidad y administración. En este caso, se recomienda que la conexión en la nube use una identidad fija en lugar de SSO.

Comparación de las opciones de reglas de acceso a datos

En la tabla siguiente se comparan las opciones de configuración de acceso a datos.

Procedimientos recomendados para aplicar reglas de acceso a datos

Estos son los procedimientos recomendados relacionados con la aplicación de reglas de acceso a datos:

• Si los distintos usuarios deben estar restringidos a subconjuntos de datos, siempre que sea viable, aplique RLS solo en la capa de modelo semántico. De este modo, los usuarios se benefician de consultas en memoria de alto rendimiento. En este caso, se recomienda encarecidamente que la conexión en la nube use una identidad fija en lugar de SSO.
• Si es posible, evite la seguridad OLS y CLS en cualquiera de las capas, dado que genera errores en los objetos visuales del informe. Los errores pueden provocar confusión o preocupación para los usuarios. Para las columnas que se pueden resumir, considere la posibilidad de crear medidas que devuelvan BLANK en determinadas condiciones en lugar de CLS (si es posible).

Compatibilidad de escritura de modelos con el punto de conexión XMLA

Los modelos semánticos de Direct Lake admiten operaciones de escritura con el punto de conexión XMLA mediante herramientas como SSMS (19.1 o posterior) y herramientas de comunidad de código abierto.

Para poder realizar operaciones de escritura, la opción de lectura y escritura XMLA debe estar habilitada para la capacidad. Para obtener más información, consulte Habilitación de lectura y escritura xmlA.

Operaciones de escritura de modelos con compatibilidad con el punto de conexión XMLA:

• Personalización, combinación, creación de scripts, depuración y pruebas de metadatos del modelo de Direct Lake.
• Control de código fuente y de versiones, integración continua e implementación continua (CI/CD) con Azure DevOps y GitHub. Para obtener más información, consulte Administración del ciclo de vida del contenido.
• Tareas de automatización como la actualización del modelo semántico y la aplicación de cambios en los modelos semánticos de Direct Lake mediante PowerShell y las API REST.

Al cambiar un modelo semántico mediante XMLA, debe actualizar la colección ChangedProperties y PBI_RemovedChildren para que el objeto modificado incluya las propiedades modificadas o eliminadas. Si no realiza esa actualización, las herramientas de modelado de Power BI podrían sobrescribir los cambios la próxima vez que se sincronice el esquema con Lakehouse.

Obtenga más información sobre las etiquetas de linaje de objetos de modelo semántico en el artículo Etiquetas de linaje para modelos semánticos de Power BI .

Para obtener más información, consulte Conectividad del modelo semántico con el punto de conexión XMLA.

Metadatos del modelo de Direct Lake

Cuando se conecta a un modelo semántico de Direct Lake con el punto de conexión XMLA, los metadatos tienen el aspecto de cualquier otro modelo. Sin embargo, los modelos de Direct Lake muestran las siguientes diferencias:

• La propiedad compatibilityLevel del objeto de base de datos es 1604 (o superior).
• La propiedad mode de las particiones de Direct Lake se establece en directLake.
• Las particiones de Direct Lake usan expresiones compartidas para definir orígenes de datos. Los puntos de expresión para el punto de conexión de análisis SQL del almacén de lago de datos o del almacenamiento de datos. Direct Lake usa el punto de conexión de SQL Analytics para detectar información de esquema y seguridad, pero carga los datos directamente desde OneLake (a menos que vuelva al modo DirectQuery por cualquier motivo).

Post-publication tasks

Después de publicar un modelo semántico de Direct Lake, debe completar algunas tareas de configuración. Para obtener más información, consulte administración de modelos semánticos de Direct Lake .

Related content

• Introducción a Direct Lake
• Administración de modelos semánticos de Direct Lake
• Descripción del rendimiento de las consultas de Direct Lake
• Creación de un almacén de lago de datos para Direct Lake
• Edición de tablas para modelos semánticos de Direct Lake
• Integración de OneLake para modelos semánticos