Compartir vía

Desarrollo de modelos semánticos de Direct Lake

  • Artículo

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

Creación del modelo

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

A continuación, 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 fechas y establecer propiedades para el modelo y sus objetos (como formatos de columna). También puede configurar el modelo seguridad de nivel de fila (RLS) 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. Esto se debe a que las consultas a una tabla de modelo basadas en una vista siempre revertirán al modo DirectQuery, lo que podría dar lugar a un rendimiento de consultas más lento.

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

Advertencia

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

Para obtener información sobre cómo seleccionar las tablas que se van a incluir en el modelo semántico de Direct Lake, consulte Editar 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 almacenamiento de los modelos semánticos 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 análisis SQL o en el modelo semántico.

Nota

El tema de aplicar reglas de acceso a datos es diferente, pero relacionado, con establecer permisos para consumidores de contenido, creadores y usuarios que administrarán el modelo semántico (y elementos de Fabric relacionados). Para obtener más información sobre cómo establecer 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 de 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 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 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 usa cualquier tabla que tenga RLS en el punto de conexión de SQL Analytics, se 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 mediante 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 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 alguna tabla o columna restringida por el OLS del modelo semántico, se devuelve un resultado de error (el visual del informe no se mostrará).
  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 (el objeto visual de informe no se 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 cargar en la memoria como y cuando sea 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 (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 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.

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 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 consultarán 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 volverá al modo DirectQuery cuando incluya 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 la 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 encarecidamente 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.

Aplicación de reglas de acceso a datos Comentario
Modelo semántico solo 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 en la nube para usar una identidad fija. Un alto rendimiento de las consultas se puede obtener de la memoria caché.
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 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 en la nube para usar una identidad fija.

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 beneficiarán de consultas de alto rendimiento en memoria. 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.

Sugerencia

Para obtener 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.

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 las colecciones ChangedProperties y PBI_RemovedChildren del objeto modificado para incluir cualquier propiedad modificada o eliminada. 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.

Importante

Las tablas de Direct Lake creadas mediante aplicaciones XMLA estarán inicialmente en un estado no procesado hasta que la aplicación envíe un comando de actualización. Las consultas que implican tablas no procesadas siempre volverá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 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 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 obtener más información, consulte administración de modelos semá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 hacen referencia a tablas o columnas en modo de almacenamiento de Direct Lake
  • Columnas calculadas que hacen 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, desde allí, puede hacer clic en la opción para realizar cambios en este modelo para agregar nuevas tablas (mediante el modo de almacenamiento Import, DirectQuery o Dual). 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 Creació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