Compartir a través de

Administración de modelos semánticos de Direct Lake

  • Artículo

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

Tareas posteriores a la publicación

Después de publicar primero un modelo semántico de Direct Lake listo para los informes, debe completar inmediatamente algunas tareas posteriores a la publicación. Estas tareas también se pueden ajustar en cualquier momento durante el ciclo de vida del modelo semántico.

Opcionalmente, también puede configurar la detección de datos para permitir que los creadores de informes lean metadatos, lo que les ayuda a detectar datos en el centro de datos de OneLake y solicitar acceso a ellos. También puede aprobar (certificado o promocionado) el modelo semántico para comunicar que representa los datos de calidad adecuados para su uso.

Configuración de la conexión en la nube

Un modelo semántico de Direct Lake usa una conexión en la nube para conectarse al punto de conexión de análisis SQL. Permite el acceso a los datos de origen, que es los archivos Parquet en OneLake (modo de almacenamiento de Direct Lake, lo que implica cargar datos de columna en memoria) o el punto de conexión de análisis SQL (cuando las consultas revierten al modo DirectQuery).

Conexión en la nube predeterminada

Al crear un modelo semántico de Direct Lake, se usa la conexión en la nube predeterminada. Aprovecha 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) se usa para consultar los datos del punto de conexión de análisis SQL.

Conexión en la nube que se puede compartir

Opcionalmente, puede crear una conexión en la nube (SCC) que se pueda compartir para que las conexiones al origen de datos se puedan realizar con una identidad fija. Puede ayudar a los clientes empresariales a proteger sus almacenes de datos de la organización. El departamento de TI puede administrar credenciales, crear SCC y compartirlas con los creadores destinados a la administración de acceso centralizado.

Para configurar una identidad fija, consulte Especificar una identidad fija para un modelo semántico de Direct Lake.

Autenticación

La identidad fija se puede autenticar mediante OAuth 2.0 o una entidad de servicio.

Nota:

Sólo se admite la autenticación Microsoft Entra. Por lo tanto, autenticación básica no se admite para los modelos semánticos de Direct Lake.

OAuth 2.0

Al usar OAuth 2.0, puede autenticarse con una cuenta de usuario de Microsoft Entra. La cuenta de usuario debe tener permiso para consultar las vistas y tablas del punto de conexión de análisis SQL y los metadatos del esquema.

El uso de una cuenta de usuario específica no es una práctica recomendada. Esto se debe a que se producirá un error en las consultas del modelo semántico si se cambia la contraseña o se elimina la cuenta de usuario (por ejemplo, cuando un empleado abandona la organización).

Entidad de servicio

La autenticación con una entidad de servicio es la práctica recomendada porque no depende de una cuenta de usuario específica. La entidad de seguridad debe tener permiso para consultar las vistas y tablas del punto de conexión de análisis SQL y los metadatos del esquema.

Por continuidad, las credenciales de la entidad de servicio se pueden administrar mediante la rotación de secretos o certificados.

Nota:

La configuración del inquilino de Fabric debe permitir las entidades de servicio y la entidad de servicio debe pertenecer a un grupo de seguridad declarado.

Inicio de sesión único

Cuando se crea una conexión en la nube que se puede compartir, la casilla inicio de sesión único está desactivada de forma predeterminada. Es la configuración correcta cuando se usa una identidad fija.

Puede habilitar el inicio de sesión único cuando desee que la identidad que consulta el modelo semántico también consulte el punto de conexión de análisis SQL. En esta configuración, el modelo semántico de Direct Lake usará la identidad fija para actualizar el modelo y la identidad de usuario para consultar los datos.

Al usar una identidad fija, es habitual deshabilitar el inicio de sesión único para que la identidad fija se use tanto para las actualizaciones como para las consultas, pero no hay ningún requisito técnico para hacerlo.

Estos son los procedimientos recomendados relacionados con las conexiones en la nube:

  • Cuando todos los usuarios pueden acceder a los datos (y tener permiso para hacerlo), no es necesario crear una conexión en la nube compartida. En su lugar, se puede usar la configuración de conexión en la nube predeterminada. En este caso, la identidad del usuario que consulta el modelo se usará si las consultas se revierten al modo DirectQuery.
  • Cree una conexión en la nube compartida cuando desee usar una identidad fija para consultar los datos de origen. Esto podría deberse a que los usuarios que consultan el modelo semántico no tienen permiso para leer el almacén de lago de datos o almacén. Este enfoque es especialmente relevante cuando el modelo semántico aplica RLS.
  • Si usa una identidad fija, use la opción de entidad de servicio porque es más segura y confiable. Esto se debe a que no depende de una sola cuenta de usuario o sus permisos, y no requerirá mantenimiento (e interrupción) si cambian su contraseña o abandonan la organización.
  • Si los distintos usuarios deben estar restringidos para acceder solo a subconjuntos de datos, si es 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.
  • Si es posible, evite OLS y CLS porque genera errores en los objetos visuales de 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).

Administrar la pertenencia a roles de seguridad

Si el modelo semántico de Direct Lake aplica seguridad de nivel de fila (RLS), es posible que tenga que administrar los miembros asignados a los roles de seguridad. Para obtener más información, consulte administración de seguridad en el modelo.

Establecer permisos de elemento de Fabric

Los modelos semánticos de Direct Lake se adhieren a un modelo de seguridad en capas. Realizan comprobaciones de permisos a través del punto de conexión de análisis SQL para determinar si la identidad que intenta acceder a los datos tiene los permisos de acceso a datos necesarios.

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 permisos de compilación. Los permisos de modelo semántico se pueden asignar directamente o adquirir implícitamente a través de 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.

Según la configuración de la conexión en la nube y si los usuarios necesitan consultar el almacén de lago de datos o el punto de conexión de análisis SQL de almacenamiento, es posible que tenga que conceder otros permisos (descritos en la tabla de esta sección).

Nota:

En particular, los usuarios no necesitan permiso para leer datos 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 análisis SQL para realizar comprobaciones de permisos para determinar a qué datos puede tener acceso el usuario (o identidad fija) que realiza la consulta.

Tenga en cuenta los siguientes escenarios y requisitos de permisos.

Escenario Permisos necesarios Comentarios
Los usuarios pueden ver informes • Conceda permisos de lectura para los informes y permisos de lectura para el modelo semántico.
• Si la conexión en la nube usa SSO, conceda al menos permiso de lectura para el almacén de lago de datos o almacén.		 Los informes no necesitan pertenecer a la misma área de trabajo que el modelo semántico. Para obtener más información, consulte la estrategia para consumidores de solo lectura.
Los usuarios pueden crear informes • Conceda permisos de compilación para el modelo semántico.
• Si la conexión en la nube usa SSO, conceda al menos permiso de lectura para el almacén de lago de datos o almacén.		 Para obtener más información, consulte la estrategia para creadores de contenido.
Los usuarios pueden consultar el modelo semántico, pero se les deniega la consulta al punto de conexión de almacén de lago de datos o análisis SQL • No conceda ningún permiso al almacén de lago de datos o el almacén. Solo es adecuado cuando la conexión en la nube usa una identidad fija.
Los usuarios pueden consultar el modelo semántico y el punto de conexión de análisis SQL, pero se les deniega la consulta al almacén de lago de datos • Conceda permisos de lectura y de ReadData para el almacén o el almacén de lago de datos. Importante: las consultas enviadas al punto de conexión de análisis SQL omitirán los permisos de acceso a datos que aplica el modelo semántico.
Administrar el modelo semántico, incluida la configuración de actualización • Requiere la propiedad del modelo semántico. Para obtener más información, vea Propiedad del modelo semántico.

Importante

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

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

Actualizar modelos semánticos de Direct Lake

Una actualización de un modelo semántico de Direct Lake da como resultado una operación de enmarcado. Se puede desencadenar una operación de actualización:

  • Manualmente, mediante una actualización a petición en el portal de Fabric, o ejecutando el comando Actualizar del lenguaje de scripting de modelos tabulares (TMSL) desde un script de SQL Server Management Studio (SSMS), o mediante una herramienta de terceros que se conecta a través del punto de conexión XMLA.
  • De forma automática, configurando una programación de actualización en el portal de Fabric.
  • Automáticamente, cuando se detectan cambios en las tablas delta subyacentes, para obtener más información, consulte actualizaciones automáticas (se describe a continuación).
  • Mediante programación, desencadenando una actualización utilizando la API de REST de Power BI o TOM. Es posible que desencadene una actualización mediante programación como paso final de un proceso de extracción, transformación y carga (ETL).

Actualizaciones automáticas

Hay una configuración semántica de nivel de modelo denominada Mantener actualizados los datos de Direct Lake que realiza actualizaciones automáticas de tablas de Direct Lake. Esta casilla está habilitada de forma predeterminada. Garantiza que los cambios de datos en OneLake se reflejen automáticamente en el modelo semántico de Direct Lake. La configuración está disponible en el portal de Fabric, en la sección Actualizar de la configuración del modelo semántico.

Cuando se habilita la configuración, el modelo semántico realiza una operación de enmarcado cada vez que se detectan modificaciones de datos en tablas Delta subyacentes. La operación de enmarcado siempre es específica de solo las tablas en las que se detectan modificados de datos.

Le recomendamos que deje activada la configuración, especialmente cuando tenga un modelo semántico de tamaño pequeño o mediano. Es especialmente útil cuando tiene requisitos de informes de baja latencia y las tablas Delta se modifican periódicamente.

En algunas situaciones, es posible que desee deshabilitar las actualizaciones automáticas. Por ejemplo, es posible que tenga que permitir la finalización de trabajos de preparación de datos o el proceso de ETL antes de exponer los nuevos datos a los consumidores del modelo semántico. Cuando está deshabilitado, puede desencadenar una actualización con un método mediante programación (descrito anteriormente).

Nota:

Power BI suspende las actualizaciones automáticas cuando se encuentra un error no recuperable durante la actualización. Se puede producir un error no recuperable, por ejemplo, cuando se produce un error en una actualización después de varios intentos. Por lo tanto, asegúrese de que el modelo semántico se puede actualizar correctamente. Power BI reanuda automáticamente las actualizaciones automáticas cuando se completa una actualización a petición posterior sin errores.

Preparación de la memoria caché

Una operación de actualización del modelo semántico de Direct Lake podría desalojar todas las columnas residentes de la memoria. Esto significa que las primeras consultas después de una actualización de un modelo semántico de Direct Lake podrían experimentar algún retraso, ya que las columnas se cargan en la memoria. Los retrasos solo pueden ser perceptibles cuando tiene volúmenes de datos extremadamente grandes.

Para evitar estos retrasos, considere la posibilidad de preparar la memoria caché mediante programación del envío de una consulta al modelo semántico. Una manera cómoda de enviar una consulta es usar un vínculo semántico. Esta operación debe realizarse inmediatamente después de que finalice la operación de actualización.

Importante

La preparación de la memoria caché solo puede tener sentido cuando los retrasos son inaceptables. Tenga cuidado de no cargar datos innecesariamente en la memoria que podrían presionar en otras cargas de trabajo de capacidad, lo que los limita o les quita prioridad.

Establecer la propiedad de comportamiento de Direct Lake

Puede controlar la reserva de los modelos semánticos de Direct Lake estableciendo su propiedad DirectLakeBehavior. Se puede establecer en:

  • Automática: (valor predeterminado) las consultas se revierten al modo DirectQuery si los datos necesarios no se pueden cargar eficazmente en la memoria.
  • DirectLakeOnly: todas las consultas usan solo el modo de almacenamiento de Direct Lake. Revertir al modo DirectQuery está deshabilitado. Si los datos no se pueden cargar en la memoria, se devolverá un error.
  • DirectQueryOnly: todas las consultas solo usan el modo DirectQuery. Use esta configuración para probar el rendimiento de reserva, donde, por ejemplo, puede observar el rendimiento de las consultas en informes conectados.

Puede establecer la propiedad en la experiencia de modelado web o mediante modelo de objetos tabulares (TOM) o lenguaje de scripting de modelos tabulares (TMSL).

Sugerencia

Considere la posibilidad de deshabilitar la reserva de DirectQuery cuando quiera procesar consultas solo en modo de almacenamiento de Direct Lake. Se recomienda deshabilitar la reserva cuando no quiera revertir a DirectQuery. También puede resultar útil cuando desea analizar el procesamiento de consultas de un modelo semántico de Direct Lake para identificar si se produce y con qué frecuencia se produce la reserva.

Supervisar modelos semánticos de Direct Lake

Puede supervisar un modelo semántico de Direct Lake para determinar el rendimiento de las consultas DAX visuales de informe o determinar cuándo se revierte al modo DirectQuery.

Puede usar el Analizador de rendimiento, SQL Server Profiler, Azure Log Analytics o una herramienta de comunidad de código abierto, como DAX Studio.

Analizador de rendimiento

Puede usar el Analizador de rendimiento en Power BI Desktop para registrar el tiempo de procesamiento necesario para actualizar los elementos de informe iniciados como resultado de cualquier interacción del usuario que produzca la ejecución de una consulta. Si los resultados de la supervisión muestran una métrica de Consulta directa, significa que las consultas DAX se procesaron en modo DirectQuery. En ausencia de esa métrica, las consultas DAX se procesaron en modo Direct Lake.

Para obtener más información, consulte Analizar mediante el Analizador de rendimiento.

SQL Server Profiler

Puede usar SQL Server Profiler para recuperar detalles sobre el rendimiento de las consultas mediante el seguimiento de eventos de consulta. Se instala con SQL Server Management Studio (SSMS). Antes de empezar, asegúrese de que tiene instalada la versión más reciente de SSMS.

Para obtener más información, vea Analizar mediante SQL Server Profiler.

Importante

En general, el modo de almacenamiento de Direct Lake proporciona un rendimiento rápido de las consultas a menos que sea necesaria una reserva al modo DirectQuery. Dado que la reserva al modo DirectQuery puede afectar al rendimiento de las consultas, es importante analizar el procesamiento de consultas de un modelo semántico de Direct Lake para identificar si, con qué frecuencia y por qué se producen las reservaciones.

Azure Log Analytics

Puede usar Azure Log Analytics para recopilar, analizar y actuar sobre los datos de telemetría asociados a un modelo semántico de Direct Lake. Es un servicio dentro de Azure Monitor, que Power BI usa para guardar los registros de actividad.

Para más información, vea Usar Azure Log Analytics en Power BI.

Contenido relacionado