Compartir a través de

Desarrollo de modelos semánticos de Direct Lake

  • Artículo

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

Creación del modelo

Usará el portal de Fabric para crear un modelo semántico de Direct Lake en un área de trabajo. Se trata de un proceso sencillo que implica seleccionar las tablas de un solo almacén de lago de datos o almacenamiento de datos que se agregarán al modelo semántico.

Luego, puede usar la experiencia de modelado web para desarrollar aún más el modelo semántico. Esta experiencia le permite crear relaciones entre tablas, crear medidas y grupos de cálculo, marcar tablas de fecha y definir propiedades para el modelo y sus objetos (como formatos de columna). También puede configurar la seguridad de nivel de fila (RLS) del modelo definiendo roles y reglas y agregando miembros (cuentas de usuario o grupos de seguridad de Microsoft Entra) a esos roles.

Como alternativa, 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.

Sugerencia

Para aprender a crear un almacén de lago de datos, una tabla Delta y un modelo semántico básico de Direct Lake, complete este tutorial.

Tablas de modelo

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. El motivo es que las consultas a una tabla del modelo basadas en una vista siempre revertirán al modo DirectQuery, lo que podría dar lugar a un rendimiento más lento de las consultas.

Las tablas deben incluir columnas para filtrado, agrupación, ordenación y resumen, además de columnas que admitan las relaciones del modelo. Aunque las columnas innecesarias no afectan al rendimiento de las consultas del modelo semántico (porque no se cargarán en memoria), dan lugar a un tamaño de almacenamiento mayor en OneLake y, por tanto, necesitan más recursos de proceso para la carga y el mantenimiento.

Advertencia

No se admite el uso de columnas que apliquen enmascaramiento dinámico de datos (DDM) en modelos semánticos de Direct Lake.

Para saber 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 más información sobre las columnas que se incluirán en las tablas del modelo semántico, consulte Descripción del almacenamiento para los modelos semánticos de Direct Lake.

Aplicación de reglas de acceso a datos

Cuando tenga la necesidad de proporcionar 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 análisis SQL o en el modelo semántico.

Nota:

El tema de aplicar reglas de acceso a datos aunque es diferente, está relacionado con configurar permisos para consumidores de contenido, creadores y usuarios que administrarán el modelo semántico (y elementos de Fabric relacionados). Para más información sobre la configuración de permisos, consulte Administración de modelos semánticos de Direct Lake.

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 desde la tabla Employee.

En el caso de un punto de conexión de análisis SQL, puede configurar OLS para controlar el acceso a los objetos del 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 del punto 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 de nivel de fila (RLS)

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

Para un punto de conexión de análisis SQL, puede configurar RLS para controlar el acceso a las filas de una tabla del punto de conexión.

Importante

Cuando una consulta use cualquier tabla que tenga RLS en el punto de conexión de análisis SQL, revertirá al modo DirectQuery. El rendimiento de las consultas puede ser más lento.

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 usando una herramienta de terceros.

Cómo se evalúan las consultas

El motivo 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 son una aproximación a cómo se evalúan las consultas (y si darán error). 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 la seguridad OLS del modelo semántico, se devuelve un resultado de error (el objeto visual de informe no se representará).
  2. Si la consulta contiene alguna columna restringida por la seguridad CLS del punto de conexión de análisis SQL (o se deniega la tabla), se devuelve un resultado de error (el objeto visual de informe no se representará).
    1. Si la conexión de nube usa el inicio de sesión único (valor predeterminado), la seguridad CLS viene determinada por el nivel de acceso del consumidor del informe.
    2. Si la conexión de nube usa una identidad fija, la seguridad CLS viene determinada por el nivel de acceso de la identidad fija.
  3. Si la consulta contiene alguna tabla en el punto de conexión de análisis SQL que aplica la seguridad RLS o se usa una vista, la consulta vuelve al modo DirectQuery.
    1. Si la conexión de nube usa el inicio de sesión único (valor predeterminado), la seguridad RLS viene determinada por el nivel de acceso del consumidor del informe.
    2. Si la conexión de nube usa una identidad fija, la seguridad 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, revierte al modo DirectQuery.
  5. De lo contrario, la consulta se satisface desde la caché en memoria. Los datos de columna se cargar en la memoria como y cuando sea necesario.

Permisos de elementos de origen

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

  • Si la conexión de nube usa el inicio de sesión único (valor predeterminado), es el consumidor del informe.
  • Si la conexión de nube usa una identidad fija, es la identidad fija.

La cuenta debe tener al menos permisos Read y ReadData en el elemento de origen (almacén de lago de datos o almacenamiento de datos). Los permisos de elementos se pueden heredar de roles del área de trabajo o asignarse explícitamente para el elemento tal como se describe en este artículo.

Suponiendo que se cumpla 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.
  • El modelo semántico y el punto de conexión de análisis 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 la seguridad RLS aplicada por el modelo semántico se logra filtrando la caché en memoria de los datos 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 cualquiera de los casos, se recomienda encarecidamente que las conexiones de nube usen una identidad fija en lugar del inicio de sesión único. El inicio de sesión único implicaría que los usuarios finales pueden acceder directamente al punto de conexión de análisis SQL y, por lo tanto, pasar por alto las reglas de seguridad del modelo semántico.

Importante

Los permisos de elementos del modelo semántico se pueden configurar explícitamente a través de aplicaciones de Power BIo adquirirse implícitamente a través de roles de área de trabajo.

En particular, las reglas de acceso a datos del modelo semántico no se aplican a los usuarios que tienen el permiso Write en el modelo semántico. Por el contrario, las reglas de acceso a datos se aplican a los usuarios que tienen asignado el rol de área de trabajo Visor. Sin embargo, los usuarios que tienen asignado el rol de área de trabajo Administrador, Miembro o Colaborador tienen implícitamente el permiso Write en el modelo semántico, por lo que no se aplican las reglas de acceso a datos. Para obtener más información, consulte Roles de las áreas de trabajo.

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 análisis SQL, 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 consulten el punto de conexión de análisis SQL 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 del modelo semántico revertirá al modo DirectQuery cuando incluya alguna tabla que aplique la seguridad RLS en el punto de conexión de análisis SQL. Por lo tanto, el modelo semántico nunca podría almacenar en caché los datos en la memoria para lograr consultas de alto rendimiento.

Reglas de 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 encarecidamente que la conexión de nube use una identidad fija en lugar del inicio de sesión único.

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

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

Aplicar reglas de acceso a datos a Comentario
Solo el modelo semántico Use esta opción cuando a los usuarios no se les concedan permisos de elementos para consultar el almacén de lago de datos o el almacenamiento de datos. Configure la conexión de nube para usar una identidad fija. El alto rendimiento de las consultas se puede lograr desde la caché en memoria.
Solo el punto de conexión de análisis SQL Use esta opción cuando los usuarios necesiten acceder a los datos desde el almacenamiento de datos o el modelo semántico, y con reglas de acceso a datos coherentes. Asegúrese de que el inicio de sesión único esté habilitado para la conexión de nube. El rendimiento de las consultas puede ser lento.
Almacén de lago de datos o almacenamiento de datos y modelo semántico Esta opción implica una sobrecarga de administración adicional. Configure la conexión de nube para usar una identidad fija.

Procedimientos recomendados para aplicar reglas de acceso a datos:

  • Si los distintos usuarios deben estar restringidos a subconjunto de datos, y si es viable, aplique la seguridad RLS solo en la capa del modelo semántico. De este modo, los usuarios se beneficiarán de consultas de alto rendimiento en memoria. En este caso, se recomienda encarecidamente que la conexión de nube use una identidad fija en lugar del inicio de sesión único.
  • 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 crear 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.

Sugerencia

Para más información sobre el uso de herramientas de terceros para desarrollar, administrar o optimizar modelos semánticos, consulte el escenario de uso de administración avanzada de modelos de datos.

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

Compatibilidad de las operaciones de escritura de modelos con el punto de conexión XMLA:

  • Personalización, combinación, scripting, depuración y pruebas de metadatos de modelos de Direct Lake.
  • Control de código fuente y versiones, integración continua e implementación continua (CI/CD) con Azure DevOps y GitHub. Para más información, consulte Administración del ciclo de vida de 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 de REST.

Al cambiar un modelo semántico mediante XMLA, debe actualizar la colección ChangedProperties y PBI_RemovedChildren para el objeto modificado para incluir 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.

Los modelos admitidos para cambiar un modelo semántico mediante XMLA son los siguientes:

  • Cambio de nombre de tabla o columna (ChangeProperty = nombre)
  • Quitar tabla (agregar tabla a la anotación PBI_RemovedChildren en la expresión de consulta)

Importante

Las tablas de Direct Lake creadas con aplicaciones XMLA estarán inicialmente en un estado no procesado hasta que la aplicación emita un comando de actualización. Las consultas que implican tablas no procesadas siempre revertirán al modo DirectQuery. Por lo tanto, al crear un nuevo modelo semántico, asegúrese de actualizar el modelo para procesar sus tablas.

Para 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 se parecen a los de cualquier otro modelo. Sin embargo, los conjuntos de datos 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 análisis SQL para detectar información de esquema y seguridad, pero carga los datos directamente desde OneLake (a menos que revierta al modo DirectQuery por cualquier motivo).

Tareas posteriores a la publicación

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

Características no admitidas

Los modelos semánticos de Direct Lake no admiten las siguientes características del modelo:

  • Tablas calculadas que hagan referencia a tablas o columnas en modo de almacenamiento de Direct Lake
  • Columnas calculadas que hagan referencia a tablas o columnas en modo de almacenamiento de Direct Lake
  • Tablas híbridas
  • Agregaciones definidas por el usuario
  • Modelos compuestos, en los que no se pueden combinar tablas de modo de almacenamiento de Direct Lake con tablas de modo de almacenamiento de DirectQuery o doble en el mismo modelo. Sin embargo, puede usar Power BI Desktop para crear una conexión dinámica a un modelo semántico de Direct Lake y, a continuación, ampliarla con nuevas medidas y, a partir de ahí, puede hacer clic en la opción para realizar cambios en este modelo para agregar nuevas tablas (mediante el modo de almacenamiento de importación, DirectQuery o doble). Esta acción crea una conexión DirectQuery al modelo semántico en modo Direct Lake, por lo que las tablas se muestran como modo de almacenamiento DirectQuery, pero este modo de almacenamiento no indica la reversión a DirectQuery. Solo la conexión entre este nuevo modelo y el modelo de Direct Lake es DirectQuery y las consultas siguen usando Direct Lake para obtener datos de OneLake. Para obtener más información, consulte Compilación de un modelo compuesto en un modelo semántico.
  • Columnas basadas en columnas del punto de conexión de análisis SQL que aplican enmascaramiento dinámico de datos.

Contenido relacionado