Compartir por

Planificación de la implementación de Power BI: auditoría de nivel de datos

  • Artigo

Nota

Este artículo forma parte de la serie de artículos sobre el planeamiento de la implementación de Power BI. Esta serie se centra principalmente en la experiencia de Power BI en Microsoft Fabric. Para obtener una introducción a la serie, consulte el planeamiento de la implementación de Power BI.

Este artículo sobre la auditoría de nivel de datos está dirigido a varias audiencias:

  • Creadores de datos y administradores de áreas de trabajo: usuarios que necesitan comprender el uso, la adopción y el rendimiento de los modelos semánticos, los flujos de datos y los datos que crean, publican y comparten.
  • Administradores de Power BI: los administradores responsables de supervisar Power BI en la organización. Es posible que los administradores de Power BI tengan que colaborar con los departamentos de TI, seguridad, auditoría interna y otros equipos pertinentes. También es posible que los administradores de Power BI deban colaborar con los creadores de contenido a la hora de solucionar problemas de rendimiento.
  • Administradores de capacidad de Power BI: los administradores responsables de supervisar la capacidad Premium de la organización. Es posible que los administradores de capacidad de Power BI deban colaborar con los creadores de contenido a la hora de solucionar problemas de rendimiento.
  • Centro de excelencia, equipo de TI y BI: los equipos que también son responsables de supervisar Power BI. Puede que tengan que colaborar con los administradores de Power BI y otros equipos pertinentes.
  • Administradores del sistema: el equipo responsable de crear y proteger los recursos de Azure Log Analytics y los administradores de bases de datos que administran los orígenes de datos.

Importante

En ocasiones, este artículo hace referencia a Power BI Premium o a sus suscripciones de capacidad (SKU P). Tenga en cuenta que Microsoft está consolidando actualmente las opciones de compra y retirando las SKU de Power BI Premium por capacidad. Los clientes nuevos y existentes deben considerar la posibilidad de comprar suscripciones de capacidad de Fabric (SKU F) en su lugar.

Para obtener más información, consulte Actualización importante sobre las licencias de Power BI Premium y Preguntas más frecuentes sobre Power BI Premium.

Los conceptos descritos en este artículo se aplican principalmente a las soluciones creadas para tres ámbitos de entrega de contenido, específicamente BI para empresas, BI para departamentos y BI para equipos. Los creadores de soluciones de BI personales también pueden encontrar útil la información de este artículo; sin embargo, no son el público objetivo principal.

No es posible lograr un buen rendimiento en los informes y los objetos visuales cuando el modelo semántico subyacente o el origen de datos no funcionan bien. Este artículo se centra en la auditoría y la supervisión de modelos semánticos, flujos de datos y datamarts. Es el segundo artículo de la serie de auditoría y supervisión, puesto que las herramientas y técnicas son más complejas que las que se describen en el artículo sobre la auditoría de nivel de informe. Lo ideal es crear modelos semánticos compartidos (diseñados para reutilizarse entre muchos informes) antes de que los usuarios creen informes. Por lo tanto, se recomienda leer este artículo junto con el artículo sobre la auditoría de nivel de informe.

Dado que los modelos semánticos de Power BI se basan en el motor tabular de Analysis Services, puede conectarse a un modelo de datos local (en Power BI Desktop) o a un modelo semántico Premium (en el servicio Power BI) como si fueran bases de datos de Analysis Services. Por lo tanto, muchas de las funcionalidades de auditoría y supervisión de Analysis Services se admiten para los modelos semánticos de Power BI Premium.

Nota:

Para obtener más información sobre los modelos hospedados en Analysis Services, vea Información general sobre la supervisión.

El resto de este artículo se centra principalmente en los modelos publicados en el servicio Power BI.

Registros de eventos del modelo semántico

Con el tiempo, los creadores y propietarios de datos pueden encontrarse ante distintas situaciones con los modelos semánticos. Un modelo semántico puede:

Para garantizar la facilidad de uso, un buen rendimiento y la adopción del contenido que se crea, conviene auditar el uso y el rendimiento de los activos de datos que se han de administrar. Puede usar los registros de eventos del conjunto de datos, que capturan tanto las actividades generadas por el usuario como por el sistema que se producen para un modelo semántico. También se conocen como eventos de seguimiento, registros de conjuntos de datos o registros de actividad del conjunto de datos. Los administradores del sistema suelen llamarlos eventos de seguimiento de bajo nivel por lo detallados que son.

Nota:

El cambio de nombre del conjunto de datos se ha implementado en la servicio Power BI y en la documentación, aunque puede haber algunas instancias, como con nombres de operación del registro de eventos, donde aún no se ha producido el cambio.

Debe analizar los eventos de seguimiento del modelo semántico para:

  • Auditar todas las actividades que se ha producido en un modelo semántico.
  • Solucionar problemas y optimizar el rendimiento del modelo semántico, el uso de la memoria y la eficacia de las consultas.
  • Examinar los detalles y la duración de la actualización del modelo semántico.
  • Supervisar el lenguaje de fórmulas de Power Query (consultas M) enviado por Power Query.
  • Supervisar las fórmulas y expresiones DAX enviadas al modelo semántico (motor de Analysis Services).
  • Comprobar si se ha seleccionado el modo de almacenamiento correcto en función de las cargas de trabajo y la necesidad lograr un equilibrio entre la actualización de los datos y la optimización del rendimiento.
  • Auditar qué roles de seguridad de nivel de fila se invocan, para qué usuarios y en qué modelos semánticos.
  • Conocer la cantidad de usuarios simultáneos.
  • Validar un modelo semántico (por ejemplo, para comprobar la calidad y el rendimiento de los datos antes de aprobar un modelo semántico o antes de publicarlo en un área de trabajo de producción).

Los eventos generados por un modelo semántico de Power BI se obtienen a partir de los registros de diagnóstico existentes disponibles para Azure Analysis Services. Puede capturar y analizar muchos tipos de eventos de seguimiento, los cuales se describen en las secciones siguientes.

Azure Log Analytics

Azure Log Analytics es un componente del servicio Azure Monitor. La integración de Azure Log Analytics con Power BI permite capturar eventos de modelo semántico de todos los modelos semánticos de un área de trabajo de Power BI. Solo se admite para áreas de trabajo Premium. Una vez que se configura la integración y se habilita la conexión (para un área de trabajo de Power BI Premium), los eventos de modelo semántico se capturan automáticamente y se envían de forma continua a un área de trabajo de Azure Log Analytics. Los registros del modelo semántico se almacenan en Azure Data Explorer, que es una base de datos de solo anexión optimizada para capturar grandes volúmenes de datos telemétricos prácticamente en tiempo real.

Asigne un área de trabajo de Power BI Premium a un área de trabajo de Log Analytics en Azure. Para habilitar este tipo de registro, debe crear un nuevo recurso de Log Analytics en la suscripción de Azure.

Los registros de una o varias áreas de trabajo de Power BI se enviarán a un área de trabajo de Log Analytics de destino. Estas son algunas maneras de organizar los datos.

  • Un área de trabajo de destino para todos los datos de auditoría: almacenar todos los datos en un área de trabajo de Log Analytics. Esto resulta útil cuando el mismo administrador o los usuarios tendrán acceso a todos los datos.
  • Áreas de trabajo de destino organizadas por área de asunto: organizar el contenido por área de asunto. Esta técnica es especialmente útil cuando distintos administradores o usuarios pueden acceder a los datos de auditoría desde Azure Log Analytics. Por ejemplo, cuando necesite separar los datos de ventas de los datos de operaciones.
  • Un área de trabajo de destino para cada área de trabajo de Power BI: configure una relación uno a uno entre un área de trabajo de Power BI y un área de trabajo de Azure Log Analytics. Esto resulta útil cuando tiene contenido especialmente confidencial o cuando los datos están sujetos a requisitos normativos o de cumplimiento específicos.

Sugerencia

Revise exhaustivamente la documentación y las preguntas más frecuentes sobre esta funcionalidad para tener claras las posibilidades y comprender los requisitos técnicos. Antes de poner esta funcionalidad a disposición de todos los administradores de áreas de trabajo de la organización, considere la posibilidad de realizar una prueba técnica de concepto (POC) con un área de trabajo de Power BI.

Importante

Aunque los nombres son similares, los datos capturados por Azure Log Analytics no son los mismos que los del registro de actividad de Power BI. Azure Log Analytics captura eventos de seguimiento de nivel de detalle del motor de Analysis Services. Su único propósito es facilitar el análisis y la solución de problemas de rendimiento del modelo semántico. El ámbito de aplicación es el nivel de área de trabajo. En cambio, el propósito del registro de actividad es facilitar información sobre la frecuencia con la que se producen determinadas actividades de usuario (como la edición de informes, la actualización de un modelo semántico o la creación de aplicaciones). El ámbito de aplicación es la totalidad del inquilino de Power BI.

Para obtener más información sobre las actividades de usuario que puede auditar para el inquilino de Power BI, vea Auditoría de nivel de inquilino.

La conexión de Azure Log Analytics para los administradores del área de trabajo controla qué grupos de usuarios (que también tienen el rol de administrador del área de trabajo necesario) pueden conectar un área de trabajo de Power BI a un área de trabajo de Azure Log Analytics existente.

Para poder configurar la integración, debe cumplir los requisitos previos de seguridad. Por lo tanto, considere la posibilidad de habilitar la configuración de inquilino de Power BI solo para los administradores del áreas de trabajo de Power BI que también tengan los permisos necesarios de Azure Log Analytics o que puedan obtener esos permisos a petición.

Sugerencia

Colabore con el administrador de Azure en las primeras fases del proceso de planificación, en particular cuando sea difícil obtener aprobación en la organización para crear un nuevo recurso de Azure. También deberá planificar los requisitos previos de seguridad. Determine si se concederá permiso al administrador de áreas de trabajo de Power BI en Azure, o si se concederá permiso al administrador de Azure en Power BI.

Los registros de modelos semánticos capturados por Azure Log Analytics incluyen las consultas del modelo semántico, las estadísticas de consulta, la actividad de actualización detallada, el tiempo de CPU consumido en las capacidades Premium, etc. Dado que se trata de registros de nivel de detalle del motor de Analysis Services, los datos pueden ser detallados. Los grandes volúmenes de datos son habituales en las áreas de trabajo de gran tamaño que experimentan una elevada actividad de los modelos semánticos.

Para optimizar el coste al usar Azure Log Analytics con Power BI:

  • Conecte las áreas de trabajo de Power BI a Azure Log Analytics solo cuando vaya a solucionar problemas, probar, optimizar o investigar activamente la actividad de los modelos semánticos. Cuando estén conectadas, se realizará un seguimiento de todos los modelos semánticos del área de trabajo.
  • Desconecte Azure Log Analytics del área de trabajo de Power BI cuando ya no necesite solucionar problemas, probar, optimizar o investigar activamente la actividad de los modelos semánticos. Con la desconexión, dejará de realizarse el seguimiento en todos los modelos semánticos del área de trabajo.
  • Asegúrese de comprender el modelo de costes según el cual Azure Log Analytics factura la ingesta de datos, el almacenamiento y las consultas.
  • No almacene los datos en Log Analytics durante más tiempo que el período de retención predeterminado de 30 días. El motivo es que el análisis de los modelos semánticos suele centrarse en actividades inmediatas de solución de problemas.

Hay varias maneras de acceder a los eventos que se envían a Azure Log Analytics. Puede usar:

  • La aplicación de plantilla predefinida de Log Analytics para modelos semánticos de Power BI.
  • El conector de Power BI Desktop para Azure Data Explorer (Kusto). Use el Lenguaje de consulta Kusto (KQL) para analizar los datos almacenados en Log Analytics. Si tiene experiencia con las consultas SQL, encontrará muchas similitudes con KQL.
  • La experiencia de consulta basada en web de Azure Data Explorer.
  • Cualquier herramienta de consulta que pueda ejecutar consultas KQL.

Sugerencia

Dado que hay un gran volumen de eventos de seguimiento del modelo semántico, se recomienda desarrollar un modelo de DirectQuery para analizar los datos. Los modelos de DirectQuery permiten consultar los datos prácticamente en tiempo real. Los eventos suelen llegar en cinco minutos.

Para más información, consulte Gobernanza de las conexiones de Azure.

Lista de comprobación: al planificar el uso de Azure Log Analytics, estas son algunas de las decisiones y medidas más importantes.

  • Considerar la posibilidad de realizar una prueba técnica de concepto (POC): planifique un proyecto pequeño para asegurarse de comprender por completo los requisitos técnicos, los requisitos de seguridad, los eventos que se van a capturar y cómo analizar los registros.
  • Decidir qué áreas de trabajo se deben integrar con Log Analytics: determine qué áreas de trabajo Premium contienen los modelos semánticos que quiere analizar.
  • Decidir si Log Analytics debe habilitarse a tiempo completo para cualquier área de trabajo: para optimizar los costes, determine si hay alguna situación (o área de trabajo específica) para la que el registro deba habilitarse de manera permanente. Determine si las áreas de trabajo deben desconectarse cuando no se esté llevando a cabo la solución de problemas.
  • Decidir cuánto tiempo deben retenerse los datos de Log Analytics: determine si es necesario establecer un período de retención más largo que el predeterminado de 30 días.
  • Precisar el procedimiento para solicitar nuevas áreas de trabajo de Log Analytics: colabore con el administrador de Azure para concretar cómo deben presentar las solicitudes de nuevos recursos de Log Analytics los administradores de áreas de trabajo de Power BI.
  • Decidir cómo funcionará la seguridad: colabore con el administrador de Azure para determinar si es más viable conceder los derechos de las áreas de trabajo de Power BI al administrador de áreas de trabajo de Azure Log Analytics o bien conceder los derechos de las áreas de trabajo de Power BI al administrador de Azure. A la hora de tomar esta decisión relativa a la seguridad, tenga en cuenta el plan para conectar y desconectar las áreas de trabajo periódicamente (para optimizar los costes).
  • Decida cómo organizar las áreas de trabajo de Log Analytics de destino: tenga en cuenta cuántas áreas de trabajo de Azure Log Analytics serán adecuadas para organizar los datos de una o varias áreas de trabajo de Power BI. Alinee esta decisión con sus decisiones de seguridad para establecer quién puede acceder a los datos de registro.
  • Decidir qué administradores de áreas de trabajo podrán conectarse: determine qué grupos de administradores de áreas de trabajo podrán conectar un área de trabajo de Power BI a un área de trabajo de Log Analytics. Establezca en consecuencia la configuración de inquilino Conexiones de Azure Log Analytics para administradores del área de trabajo.
  • Crear el recurso de Azure Log Analytics: colabore con el administrador de Azure para crear cada área de trabajo de Log Analytics. Compruebe y actualice los permisos asignados en Azure para garantizar que la configuración de Power BI se realice sin problemas. Compruebe que los datos almacenados en Azure están en la región geográfica correcta.
  • Establecer la conexión de Log Analytics para cada área de trabajo de Power BI: colabore con los administradores de áreas de trabajo de Power BI para configurar la conexión a Log Analytics para cada área de trabajo de Power BI. Compruebe que los datos de registro fluyen correctamente al área de trabajo de Log Analytics.
  • Crear consultas para analizar los datos: establezca consultas de KQL para analizar los datos de Log Analytics en función del caso de uso y las necesidades actuales.
  • Incluir instrucciones para los administradores de áreas de trabajo de Power BI: proporcione información y requisitos previos a los administradores de áreas de trabajo de Power BI para obtener información sobre cómo solicitar una nueva área de trabajo de Log Analytics y cómo conectarse a un área de trabajo de Power BI. Además, explique cuándo es adecuado desconectar un área de trabajo de Power BI.
  • Proporcionar instrucciones y consultas de ejemplo para analizar los datos: cree consultas KQL para los administradores de áreas de trabajo para que les resulte más fácil empezar a analizar los datos capturados.
  • Supervisar los costes: colabore con el administrador de Azure para supervisar los costes de Log Analytics de forma continua.

SQL Server Profiler

Puede usar SQL Server Profiler (SQL Profiler) para capturar eventos de modelos semánticos de Power BI. Es un componente de SQL Server Management Studio (SSMS). La conectividad a un modelo semántico de Power BI es compatible con SSMS porque se basa en la arquitectura de Analysis Services originada en SQL Server.

Puede usar SQL Profiler en distintas fases del ciclo de vida de un modelo semántico.

  • Durante el desarrollo del modelo de datos: SQL Profiler puede conectarse a un modelo de datos en Power BI Desktop como herramienta externa. Este enfoque es útil para los modeladores de datos que quieren validar modelos de datos o ajustar el rendimiento.
  • Una vez que se publica el modelo semántico en el servicio Power BI: SQL Profiler puede conectarse a un modelo semántico de un área de trabajo Premium. SSMS es una de las muchas herramientas cliente compatibles que pueden usar el punto de conexión XMLA para la conectividad. Este enfoque es útil para auditar, supervisar, validar y ajustar un modelo semántico publicado en el servicio Power BI y solucionar los problemas.

También es posible usar SQL Profiler como herramienta externa en DAX Studio. Puede usar DAX Studio para iniciar un seguimiento del generador de perfiles, analizar los datos y dar formato a los resultados. Los modeladores de datos que usan DAX Studio suelen preferir este enfoque frente al uso directo de SQL Profiler.

Nota

El uso de SQL Profiler es un caso de uso distinto de la actividad de generación de perfiles de datos. Puede generar perfiles de datos en el Editor de Power Query para comprender mejor sus características. Aunque la generación de perfiles de datos es una actividad importante para los modeladores de datos, no entra en el ámbito de este artículo.

Considere la posibilidad de usar SQL Profiler en lugar de Azure Log Analytics en los casos siguientes:

  • La organización no permite usar ni crear recursos de Azure Log Analytics en Azure.
  • Para capturar eventos para un modelo de datos en Power BI Desktop (que no se ha publicado en un área de trabajo Premium en el servicio Power BI).
  • Para capturar eventos de un modelo semántico durante un breve período de tiempo (en lugar de todos los modelos semánticos de un área de trabajo Premium).
  • Para capturar determinados eventos solo durante un seguimiento (por ejemplo, solo el evento Fin de la consulta).
  • Para iniciar y detener seguimientos con frecuencia (por ejemplo, cuando necesite capturar eventos de modelo semántico que se estén produciendo en el momento).

Como ocurre con Azure Log Analytics (descrito anteriormente en este artículo), los eventos de modelo semántico capturados por SQL Profiler se obtienen a partir de los registros de diagnóstico existentes disponibles para Azure Analysis Services. Sin embargo, existen algunas diferencias en los eventos disponibles.

Sugerencia

El uso de SQL Profiler para supervisar Analysis Services se trata en muchos libros, artículos y entradas de blog. La mayoría de esa información es pertinente para supervisar un modelo semántico de Power BI.

Importante

También puede usar SQL Profiler para supervisar las consultas enviadas desde el servicio Power BI a los orígenes de datos subyacentes (por ejemplo, a una base de datos relacional de SQL Server). Sin embargo, la capacidad de realizar un seguimiento de una base de datos relacional está en desuso. La conexión con el motor de Analysis Services se admite y no está en desuso. Si ya conoce los eventos extendidos de Analysis Services y prefiere usarlos, también es posible la conectividad de SSMS para los modelos de datos de Power BI Desktop. Sin embargo, no se admite para Power BI Premium. Por lo tanto, esta sección solo se centra en la conectividad estándar de SQL Profiler.

La configuración de inquilino Permitir puntos de conexión XMLA y Analizar en Excel con modelos semánticos locales controla qué grupos de usuarios (que también tienen asignado el rol de colaborador, miembro o administrador de áreas de trabajo, o el permiso de compilación para el modelo semántico individual) pueden usar el punto de conexión XMLA para consultar o mantener modelos semánticos en el servicio Power BI. Para obtener más información sobre el uso de puntos de conexión XMLA, vea el escenario de uso de administración avanzada de modelos de datos.

Nota

También puede usar SQL Profiler para facilitar la depuración y la solución de problemas de expresiones DAX específicas. Puede conectar SQL Profiler a Power BI Desktop como herramienta externa. Busque la clase de evento registro de evaluación DAX para ver los resultados intermedios de una expresión DAX. Ese evento se genera cuando se usa la función DAX EVALUATEANDLOG en un cálculo del modelo.

Esta función solo está pensada para fines de desarrollo y pruebas. Debe eliminarla de los cálculos del modelo de datos antes de publicar el modelo de datos en un área de trabajo de producción.

Lista de comprobación: al planificar el uso de SQL Profiler, estas son algunas de las decisiones y medidas más importantes.

  • Decidir quién puede tener instalado SSMS o DAX Studio: determine si se permitirá que todos los creadores de contenido de Power BI de la organización instalen SSMS o DAX Studio para poder usar SQL Profiler. Determine si estas herramientas auxiliares se instalarán a petición o mediante un conjunto estándar de software instalado para los creadores de datos aprobados de la organización.
  • Agregar SQL Profiler al menú Herramientas externas de Power BI Desktop: si los creadores de datos van a usar SQL Profiler a menudo, pida al departamento de TI que lo agregue automáticamente al menú Herramientas externas en Power BI Desktop para estos usuarios.
  • Decidir quién podrá usar el punto de conexión XMLA: determine si todos los usuarios podrán conectarse a los modelos semánticos publicados mediante el punto de conexión XMLA o solo podrán hacerlo los creadores de datos aprobados. Establezca la configuración de inquilino Permitir puntos de conexión XMLA y Analizar en Excel con modelos semánticos locales para que se alinee con esta decisión.
  • Proporcionar instrucciones y consultas de ejemplo para analizar los datos: elabore documentación para los creadores de datos para que sepan de qué manera se recomienda auditar y supervisar los modelos semánticos. Proporcione instrucciones para casos de uso comunes para facilitar la recopilación y el análisis de los datos de seguimiento.

Metadatos del modelo de datos

Dado que los modelos semánticos de Power BI se basan en el motor de Analysis Services, tiene acceso a las herramientas que pueden consultar los metadatos de un modelo de datos. Los metadatos comprenden todo lo relacionado con el modelo de datos, incluidos los nombres de las tablas, los nombres de las columnas y las expresiones de medidas.

Vistas de administración dinámica

Las vistas de administración dinámica (DMV) de Analysis Services pueden consultar los metadatos del modelo de datos. Puede usar las DMV para auditar, documentar y optimizar los modelos de datos en un momento dado.

En concreto, puede:

  • Auditar los orígenes de datos usados por un modelo.
  • Determinar qué objetos consumen más memoria en un modelo.
  • Determinar cómo se pueden comprimir los datos de columna de forma eficaz.
  • Buscar las columnas que no se usen en un modelo.
  • Auditar las conexiones y sesiones de usuario activas.
  • Comprobar la estructura del modelo.
  • Revisar las expresiones DAX usadas por tablas calculadas, columnas calculadas, medidas y reglas de seguridad de nivel de fila (RLS).
  • Identificar las dependencias entre objetos y medidas.

Sugerencia

Las DMV recuperan información sobre el estado actual de un modelo semántico. Considere los datos devueltos por las DMV como una instantánea de lo que está ocurriendo en un momento dado. En cambio, los registros de eventos del modelo semántico (descritos anteriormente en este artículo) recuperan información sobre las actividades que se han producido para un modelo semántico mientras estaba activa una conexión de seguimiento.

SSMS es una herramienta que se usa normalmente para ejecutar consultas de DMV. También puede usar el cmdlet Invoke-ASCmd de PowerShell para crear y ejecutar scripts XMLA que consulten las DMV.

Las herramientas de terceros y las herramientas externas también son populares en la comunidad de Power BI. Estas herramientas usan las DMV documentadas públicamente para simplificar el acceso y trabajar con los datos devueltos por las DMV. Un ejemplo es DAX Studio, que incluye una funcionalidad explícita para acceder a las DMV. DAX Studio también incluye la característica integrada Ver métricas, que se conoce normalmente como Vertipaq Analyzer. Vertipaq Analyzer tiene una interfaz de usuario para analizar la estructura y el tamaño de las tablas, columnas, relaciones y particiones en un modelo de datos. También puede exportar (o importar) los metadatos del modelo de datos a un archivo .vpax. El archivo exportado solo contiene metadatos sobre la estructura y el tamaño del modelo de datos, no almacena ningún dato del modelo.

Sugerencia

Cuando necesite que alguien le ayude con un modelo de datos, considere la posibilidad de compartir un archivo .vpax. De este modo, no compartirá los datos del modelo con esa persona.

Puede usar consultas DMV en distintas fases del ciclo de vida de un modelo semántico.

  • Durante el desarrollo del modelo de datos: la herramienta elegida puede conectarse a un modelo de datos en Power BI Desktop como herramienta externa. Este enfoque es útil para los modeladores de datos que quieren validar modelos de datos o ajustar el rendimiento.
  • Una vez que se publica el modelo semántico en el servicio Power BI: la herramienta que elija puede conectarse a un modelo semántico de un área de trabajo Premium. SSMS es una de las muchas herramientas cliente compatibles que usan el punto de conexión XMLA para la conectividad. Este enfoque es útil para auditar o validar un modelo semántico publicado en el servicio Power BI.

Sugerencia

Si decide escribir sus propias consultas DMV (por ejemplo, en SSMS), tenga en cuenta que las DMV no admiten todas las operaciones SQL. Además, algunas DMV no se admiten en Power BI (porque requieren permisos de administrador del servidor de Analysis Services que no son compatibles con Power BI).

La configuración de inquilino Permitir puntos de conexión XMLA y Analizar en Excel con modelos semánticos locales controla qué grupos de usuarios (que también tienen asignado el rol de colaborador, miembro o administrador de áreas de trabajo, o el permiso de compilación para el modelo semántico individual) pueden usar el punto de conexión XMLA para consultar o mantener modelos semánticos en el servicio Power BI.

Para obtener más información sobre el uso del punto de conexión XMLA, las herramientas de terceros y las herramientas externas, vea el escenario de uso de administración avanzada de modelos de datos.

Analizador de procedimientos recomendados

El analizador de procedimientos recomendados (BPA) es una característica del Editor tabular, que es una herramienta de terceros que ha logrado una adopción generalizada por parte de la comunidad de Power BI. El BPA incluye un conjunto de reglas personalizables que permiten auditar la calidad, la coherencia y el rendimiento del modelo de datos.

Sugerencia

Para configurar el BPA, descargue el conjunto de reglas de procedimientos recomendados que proporciona Microsoft en GitHub.

Principalmente, el BPA permite mejorar la coherencia de los modelos mediante la detección de las decisiones de diseño no óptimas que pueden reducir los problemas de rendimiento. Resulta útil cuando tiene modeladores de datos de autoservicio distribuidos en diferentes áreas de la organización.

El BPA también puede facilitar la auditoría y el control de los modelos de datos. Por ejemplo, puede comprobar si un modelo de datos incluye algún rol de seguridad de nivel de fila (RLS). O bien puede validar si todos los objetos del modelo tienen una descripción. Esto resulta útil cuando, por ejemplo, haya que asegurarse de que el modelo de datos incluya un diccionario de datos.

El BPA puede exponer problemas de diseño para que el Centro de excelencia determine si se necesita más formación o documentación. Permite tomar medidas para informar a los creadores de datos sobre los procedimientos recomendados y las directrices de la organización.

Sugerencia

Tenga en cuenta que el BPA detecta la existencia de la característica (como la seguridad de nivel de fila). Sin embargo, puede ser difícil determinar si está configurada correctamente. Por ese motivo, puede ser necesario que un experto en la materia lleve a cabo una revisión. Por otro lado, la no existencia de una característica determinada no significa necesariamente un mal diseño; el modelador de datos puede tener una buena razón para producir un diseño determinado.

Lista de comprobación: al planificar el acceso a los metadatos de los modelos de datos, estas son algunas de las decisiones y medidas más importantes.

  • Decidir quién puede tener instalado SSMS: determine si se permitirá que todos los creadores de contenido de Power BI de la organización instalen SSMS para poder conectarse a los modelos semánticos publicados. Determine si se instalará a petición o mediante un conjunto estándar de software instalado para los creadores de datos aprobados de la organización.
  • Decidir quién puede tener instaladas herramientas de terceros: determine si se permitirá que todos los creadores de contenido de Power BI de la organización instalen herramientas de terceros (como DAX Studio y Editor tabular) para poder supervisar modelos de datos locales o modelos semánticos publicados. Determine si se instalará a petición o mediante un conjunto estándar de software instalado para los creadores de datos aprobados de la organización.
  • Establecer reglas de procedimientos recomendados: decida qué reglas del analizador de procedimientos recomendados podrán examinar los modelos de datos de la organización.
  • Decidir quién podrá usar el punto de conexión XMLA: determine si todos los usuarios podrán conectarse a los modelos semánticos mediante el punto de conexión XMLA o solo podrán hacerlo los creadores de datos aprobados. Establezca la configuración de inquilino Permitir puntos de conexión XMLA y Analizar en Excel con modelos semánticos locales para que se alinee con esta decisión.
  • Proporcionar instrucciones para los creadores de contenido: elabore documentación para los creadores de datos para que sepan de qué maneras se recomienda analizar los modelos semánticos. Proporcione instrucciones para casos de uso comunes para facilitar la recopilación y el análisis de resultados de DMV o el uso del analizador de procedimientos recomendados.

Modelo de datos y rendimiento de consultas

Power BI Desktop incluye varias herramientas que ayudan a los creadores de datos a solucionar problemas e investigar sus modelos de datos. Estas funcionalidades están destinadas a los modeladores de datos que quieren validar sus modelos de datos y ajustar el rendimiento antes de publicarlos en el servicio Power BI.

Analizador de rendimiento

Use el Analizador de rendimiento, que está disponible en Power BI Desktop, para auditar e investigar el rendimiento de los modelos de datos. El Analizador de rendimiento permite a los creadores de informes evaluar el rendimiento de los elementos individuales de los informes. Sin embargo, la causa principal de los problemas de rendimiento suele estar relacionada con el diseño del modelo de datos. Por este motivo, un creador de modelos semánticos también puede beneficiarse del uso del Analizador de rendimiento. Si existen distintos creadores de contenido responsables de la creación de informes y de la creación de modelos semánticos, es probable que necesiten colaborar para solucionar los problemas de rendimiento.

Sugerencia

Puede usar DAX Studio para importar y analizar los archivos de registro generados por el Analizador de rendimiento.

Para obtener más información sobre el Analizador de rendimiento, vea Auditoría de nivel de informe.

Diagnóstico de consultas

Use el Diagnóstico de consulta, disponible en Power BI Desktop, para investigar el rendimiento de Power Query. Es útil para solucionar problemas y cuando se necesita saber qué está haciendo el motor de Power Query.

Entre la información que puede obtener del Diagnóstico de consulta se incluye la siguiente:

  • Detalles adicionales relacionados con los mensajes de error (cuando se produce una excepción).
  • Las consultas que se envían a un origen de datos.
  • Si se está produciendo o no el plegado de consultas.
  • Cantidad de filas devueltas por una consulta.
  • Posibles ralentizaciones durante una operación de actualización de datos.
  • Eventos en segundo plano y consultas generadas por el sistema.

En función de lo que busque, puede habilitar uno o todos los registros: agregados, detallados, contadores de rendimiento y particiones de privacidad de datos.

Puede iniciar diagnósticos de sesión en el Editor de Power Query. Una vez que se habilita, se recopilan las operaciones de consulta y actualización hasta que se detiene el seguimiento de diagnóstico. Los datos se rellenan directamente en el editor de consultas en cuanto se detiene el diagnóstico. Power Query crea el grupo Diagnóstico (carpeta) y agrega varias consultas en él. A continuación, puede usar la funcionalidad estándar de Power Query para ver y analizar los datos de diagnóstico.

También puede habilitar un seguimiento en Power BI Desktop en la sección Diagnóstico de la ventana Opciones. Los archivos de registro se guardan en una carpeta de la máquina local. Estos archivos de registro se rellenan con los datos una vez que se cierra Power BI Desktop, momento en el que se detiene el seguimiento. Una vez que se cierra Power BI Desktop, puede abrir los archivos de registro con el programa que prefiera (por ejemplo, un editor de texto) para verlos.

Evaluación y plegado de consultas

Power Query admite varias funcionalidades para facilitar la comprensión de la evaluación de consultas, incluido el plan de consulta. También puede ayudar a determinar si se produce el plegado de consultas para una consulta completa o para un subconjunto de pasos de una consulta. El plegado de consultas es uno de los aspectos más importantes del ajuste del rendimiento. También resulta útil revisar las consultas nativas enviadas por Power Query al supervisar un origen de datos, lo que se describe más adelante en este artículo.

Aplicación de métricas de Premium

A la hora de solucionar problemas, puede resultar útil colaborar con el administrador de capacidad de Power BI Premium. El administrador de capacidad tiene acceso a la aplicación de métricas y uso de Power BI Premium. Esta aplicación puede facilitar una gran cantidad de información sobre las actividades que se producen en la capacidad. Esa información puede servir de ayuda para solucionar problemas del modelo semántico.

Sugerencia

El administrador de capacidad Premium puede conceder acceso a usuarios adicionales (administradores que no son de capacidad) para permitirles acceder a la aplicación de métricas Premium.

La aplicación de métricas Premium consta de un modelo semántico interno y un conjunto inicial de informes. Permite realizar una supervisión prácticamente en tiempo real de una capacidad de Power BI Premium (SKU P) o Power BI Embedded (SKU A). Incluye datos de las últimas dos a cuatro semanas (en función de la métrica).

Use la aplicación de métricas Premium para solucionar problemas y optimizar los modelos semánticos. Por ejemplo, puede identificar los modelos semánticos que ocupan una gran superficie de memoria o que habitualmente hacen un uso elevado de la CPU. También es una herramienta útil para buscar los modelos semánticos que se aproximan al límite del tamaño de la capacidad.

Lista de comprobación: al considerar los enfoques que se usarán para supervisar el modelo de datos y el rendimiento de las consultas, estas son algunas de las decisiones y medidas más importantes.

  • Identificar los objetivos de rendimiento de consulta del modelo semántico: asegúrese de comprender bien lo que significa un buen rendimiento del modelo semántico. Determine cuándo se necesitarán objetivos específicos de rendimiento de consulta (por ejemplo, las consultas para la generación de informes deben representarse en un tiempo máximo de cinco segundos). En ese caso, asegúrese de que se comuniquen los objetivos a los creadores de datos de la organización.
  • Identificar los objetivos de rendimiento de actualización del modelo semántico: determine cuándo se necesitarán objetivos específicos para la actualización de los datos (por ejemplo, la finalización de una operación de actualización de datos en un tiempo máximo de 15 minutos y antes de las 5 de la mañana). En ese caso, asegúrese de que se comuniquen los objetivos a los creadores de datos de la organización.
  • Informar al equipo de soporte técnico: asegúrese de que el equipo de soporte técnico interno para usuarios conozca las funcionalidades de diagnóstico para poder dar soporte a los usuarios de Power BI cuando estos necesiten ayuda.
  • Poner al equipo de soporte técnico en contacto con los administradores de bases de datos: asegúrese de que el equipo de soporte técnico sepa cómo ponerse en contacto con los administradores correspondientes para cada origen de datos (por ejemplo, para solucionar problemas de plegado de consultas).
  • Colaborar con el administrador de capacidad Premium: trabaje con el administrador de capacidad para solucionar problemas con los modelos semánticos existentes en las áreas de trabajo asignadas a la capacidad Premium o a la capacidad Power BI Embedded. Cuando sea necesario, solicite acceso a la aplicación de métricas Premium.
  • Proporcionar instrucciones para los creadores de contenido: elabore documentación para los creadores de datos para que sepan qué medidas deben tomar para la solución de problemas.
  • Incluir materiales de formación: proporcione instrucciones a los creadores de datos para crear modelos de datos de buen rendimiento. Ayúdelos a adoptar buenos hábitos de diseño desde el principio. Céntrese en enseñar a los creadores de datos cómo tomar buenas decisiones de diseño.

Supervisión del origen de datos

A veces es necesario supervisar directamente un origen de datos específico al que se conecta Power BI. Por ejemplo, es posible que tenga un almacenamiento de datos que experimente una mayor carga de trabajo y que los usuarios informen de una degradación del rendimiento. Normalmente, los orígenes de datos los supervisa un administrador de bases de datos o un administrador del sistema.

Puede supervisar un origen de datos para hacer lo siguiente:

  • Auditar qué usuarios envían consultas al origen de datos.
  • Auditar qué aplicaciones (como Power BI) envían consultas al origen de datos.
  • Revisar qué instrucciones de consulta se envían al origen de datos, cuándo y por parte de qué usuarios.
  • Determinar cuánto tiempo tarda una consulta en ejecutarse.
  • Auditar cómo el sistema de origen invoca la seguridad de nivel de fila cuando usa el inicio de sesión único (SSO).

El creador de contenidos de Power BI puede tomar muchas medidas una vez que analiza los resultados del seguimiento. Por ejemplo:

  • Ajustar y restringir las consultas que se envían al origen de datos para que sean lo más eficaces posible.
  • Validar y ajustar las consultas nativas que se envían al origen de datos.
  • Reducir la cantidad de columnas que se importan en un modelo de datos.
  • Quitar las columnas de alta precisión y alta cardinalidad que se importan en un modelo de datos.
  • Reducir la cantidad de datos históricos que se importan en un modelo de datos.
  • Ajustar los tiempos de actualización de datos de Power BI para ayudar a distribuir la demanda del origen de datos.
  • Usar la actualización incremental de datos para reducir la carga en el origen de datos.
  • Reducir la cantidad de actualizaciones de datos de Power BI mediante la consolidación de varios modelos semánticos en un modelo semántico compartido.
  • Ajustar la configuración de actualización automática de páginas para aumentar la frecuencia de actualización y, en consecuencia, reducir la carga en el origen de datos.
  • Simplificar los cálculos para reducir la complejidad de las consultas que se envían al origen de datos.
  • Cambiar el modo de almacenamiento de datos (por ejemplo, al modo de importación en lugar de DirectQuery) para reducir la carga de consultas constante en el origen de datos.
  • Usar técnicas de reducción de consultas para reducir la cantidad de consultas que se envían al origen de datos.

Los administradores del sistema pueden tomar otras medidas. Por ejemplo:

  • Introducir una capa de datos intermedia, como flujos de datos de Power BI (cuando el almacenamiento de datos no es una opción viable). Los creadores de contenido de Power BI pueden usar los flujos de datos como su propio origen de datos en lugar de conectarse directamente a orígenes de datos. Una capa de datos intermedia puede reducir la carga en un sistema de origen. También tiene la ventaja adicional de centralizar la lógica de preparación de datos. Para obtener más información, vea el escenario de uso de preparación de datos de autoservicio.
  • Cambiar la ubicación del origen de datos para reducir el efecto de la latencia de red (por ejemplo, usar la misma región de datos para el servicio Power BI, los orígenes de datos y las puertas de enlace).
  • Optimizar el origen de datos para que recupere datos de forma más eficaz para Power BI. Entre las técnicas más comunes se encuentran la creación de índices de tablas, la creación de vistas indexadas, la creación de columnas calculadas persistentes, el mantenimiento de estadísticas, el uso de tablas de almacén de columnas o en memoria y la creación de vistas materializadas.
  • Dar instrucciones a los usuarios para que usen una réplica de solo lectura del origen de datos, en lugar de una base de datos de producción original. Puede haber una réplica disponible como parte de una estrategia de base de datos de alta disponibilidad (HA). Una de las ventajas de las réplicas de solo lectura es la reducción de la contención en el sistema de origen.

Las herramientas y las técnicas que se pueden usar para supervisar los orígenes de datos dependerán de la plataforma tecnológica. Por ejemplo, los administradores de bases de datos pueden usar los eventos extendidos o el almacén de consultas para supervisar las bases de datos Azure SQL y SQL Server.

A veces, Power BI accede al origen de datos a través de una puerta de enlace de datos. Las puertas de enlace controlan la conectividad del servicio Power BI a determinados tipos de orígenes de datos. Sin embargo, hacen algo más que conectarse a los datos. Una puerta de enlace incluye un motor de mashup que lleva a cabo el procesamiento y las transformaciones de datos en la máquina. También comprime y cifra los datos para que puedan transmitirse de forma eficaz y segura al servicio Power BI. Por lo tanto, una puerta de enlace no administrada o no optimizada puede contribuir a que se produzcan cuellos de botella de rendimiento. Se recomienda hablar con el administrador de las puertas de enlace para obtener ayuda con las puertas de enlace de supervisión.

Sugerencia

El administrador de Power BI puede recopilar un inventario completo de los inquilinos (incluido el linaje) y acceder a las actividades de usuario en el registro de actividad. Al correlacionar el linaje y las actividades de usuario, los administradores pueden identificar los orígenes de datos y las puertas de enlace que se usan con más frecuencia.

Para obtener más información sobre el inventario de inquilinos, vea Auditoría de nivel de inquilino.

Lista de comprobación: al planificar la supervisión del origen de datos, estas son algunas de las decisiones y medidas más importantes.

  • Determinar objetivos específicos: a la hora de supervisar una fuente de datos, tenga claro qué necesita conseguir exactamente y los objetivos de solución de problemas.
  • Colaborar con los administradores de bases de datos: trabaje con los administradores de bases de datos o del sistema para contar con su ayuda a la hora de supervisar un origen de datos específico.
  • Colaborar con los administradores de puertas de enlace: en el caso de los orígenes de datos que se conectan a través de una puerta de enlace de datos, colabore con el administrador de puertas de enlace para solucionar los problemas.
  • Poner al equipo de soporte técnico en contacto con los administradores de bases de datos: asegúrese de que el equipo de soporte técnico sepa cómo ponerse en contacto con los administradores correspondientes para cada origen de datos (por ejemplo, para solucionar problemas de plegado de consultas).
  • Actualizar los materiales de formación y las instrucciones: incluya información clave y sugerencias para los creadores de datos sobre cómo trabajar con los orígenes de datos de la organización. Incluya información sobre lo que debe hacer cuando algo vaya mal.

Supervisión de la actualización de datos

Una operación de actualización de datos implica importar datos de orígenes de datos subyacentes a un modelo semántico, flujo de datos o datamart de Power BI. Las operaciones de actualización de datos se pueden programar o ejecutar a petición.

Contrato de nivel de servicio

El departamento de TI suele usar acuerdos de nivel de servicio para documentar las expectativas sobre los recursos de datos. En el caso de Power BI, considere la posibilidad de usar un Acuerdo de Nivel de Servicio para contenido crítico o contenido de nivel empresarial. En él suele incluirse cuándo los usuarios pueden esperar que los datos actualizados de un modelo semántico estén disponibles. Por ejemplo, el Acuerdo de Nivel de Servicio puede establecer que todas las actualizaciones de datos deben estar realizadas todos los días antes de las 7 de la mañana.

Registros de modelos semánticos

Los registros de eventos del modelo semántico de Azure Log Analytics o SQL Profiler (descritos anteriormente en este artículo) incluyen información detallada sobre lo que sucede en un modelo semántico. Los eventos capturados incluyen la actividad de actualización del modelo semántico. Los registros de eventos son especialmente útiles cuando es necesario solucionar problemas e investigar las actualizaciones del modelo semántico.

Modelos semánticos de capacidad Premium

Cuando se dispone de contenido hospedado en Power BI Premium, se cuenta con más capacidades para supervisar las operaciones de actualización de datos.

  • En la página resúmenes de actualización de Power BI del portal de administración se incluye un resumen del historial de actualizaciones. En ese resumen se proporciona información sobre la duración de las actualizaciones y los mensajes de error.
  • En la aplicación de métricas y uso de Power BI Premium también se incluye información de actualización práctica. Resulta útil cuando es necesario investigar la actividad de actualización de una capacidad de Power BI Premium (SKU P) o Power BI Embedded (SKU A).

Actualizaciones mejoradas del modelo semántico

Los creadores de contenido pueden iniciar actualizaciones de modelos semánticos mediante programación usando la actualización mejorada con la API de REST de Power BI Refresh Dataset in Group. Al usar la actualización mejorada, se pueden supervisar las operaciones históricas, actuales y pendientes de actualización.

Supervisión de la programación de actualización de datos

Los administradores de Power BI pueden supervisar los programas de actualización de datos en el inquilino para determinar si hay muchas operaciones de actualización programadas simultáneamente para una franja horaria concreta (por ejemplo, entre las 5 y las 7 de la mañana, que podría ser una franja particularmente intensa de actualización de datos). Los administradores tienen permiso para acceder a los metadatos de programación de actualización del modelo semántico desde las API de análisis de metadatos, que se conocen como las API de escáner.

API de REST de Power BI

En el caso de los modelos semánticos críticos, no se base únicamente en las notificaciones por correo electrónico para supervisar problemas de actualización de datos. Considere la posibilidad de recopilar el historial de actualización de datos en un almacén centralizado donde pueda supervisarlo, analizarlo y actuar en consecuencia.

Puede recuperar el historial de actualización de datos mediante las siguientes API:

Sugerencia

Se recomienda encarecidamente supervisar el historial de actualización de los modelos semánticos para asegurarse de que los datos actuales están disponibles para los informes y paneles. También sirve para saber si se cumple el Acuerdo de Nivel de Servicio.

Lista de comprobación: al planificar la supervisión de la actualización de los datos, estas son algunas de las decisiones y medidas más importantes.

  • Determinar objetivos específicos: a la hora de supervisar las actualizaciones de los datos, tenga claro qué necesita conseguir exactamente y cuál debe ser el ámbito de la supervisión (por ejemplo, modelos semánticos de producción, modelos semánticos certificados u otros).
  • Considerar la posibilidad de configurar un Acuerdo de Nivel de Servicio: determine si sería útil un Acuerdo de Nivel de Servicio para establecer las expectativas de disponibilidad de los datos y cuándo se deben ejecutar las programaciones de actualización de datos.
  • Colaborar con administradores de bases de datos y puertas de enlace: trabaje con los administradores de bases de datos o del sistema y los administradores de puertas de enlace para supervisar o solucionar problemas de actualización de datos.
  • Transferir de conocimientos para el equipo de soporte técnico: asegúrese de que el equipo de soporte técnico sepa cómo ayudar a los creadores de contenido cuando surjan problemas de actualización de datos.
  • Actualizar los materiales de formación y las instrucciones: incluya información clave y sugerencias para los creadores de datos sobre cómo actualizar los datos de los orígenes de datos de la organización y los orígenes de datos comunes. Incluya los procedimientos recomendados y las preferencias de la organización para la administración de la actualización de datos.
  • Usar una dirección de correo electrónico de soporte técnico para las notificaciones: para el contenido crítico, establezca el uso de una dirección de correo electrónico de soporte técnico para las notificaciones de actualización.
  • Configurar una supervisión centralizada de la actualización: use las API de REST de Power BI para recopilar el historial de actualización de datos.

Supervisión de flujos de datos

Cree un flujo de datos de Power BI con Power Query Online. Son aplicables muchas de las características de rendimiento de las consultas y el diagnóstico de Power Query, que se han descrito antes.

Opcionalmente, puede establecer áreas de trabajo para usar Azure Data Lake Storage Gen2 para el almacenamiento de flujos de datos (conocido como Traiga su propio almacenamiento) en lugar del almacenamiento interno. Al usar Traiga su propio almacenamiento, considere la posibilidad de habilitar la telemetría para poder supervisar las métricas de la cuenta de almacenamiento. Para obtener más información, vea los escenarios de uso de preparación de datos de autoservicio y preparación de datos avanzada.

Puede usar las API de REST de Power BI para supervisar las transacciones de flujo de datos. Por ejemplo, use la API Get Dataflow Transactions para comprobar el estado de las actualizaciones del flujo de datos.

Puede realizar un seguimiento de las actividades de usuario de los flujos de datos de Power BI con el registro de actividad de Power BI. Para más información, vea Auditoría de nivel de inquilino.

Sugerencia

Existen muchos procedimientos recomendados que se pueden adoptar para optimizar los diseños de flujos de datos. Para obtener más información, consulte Procedimientos recomendados para flujos de datos.

Supervisión de datamarts

Un datamart de Power BI dispone de varios componentes integrados, como un flujo de datos, una base de datos administrada y un modelo semántico. Consulte las secciones anteriores de este artículo para obtener información sobre la auditoría y la supervisión de cada componente.

Puede realizar un seguimiento de las actividades de usuario de los datamarts de Power BI con el registro de actividad de Power BI. Para más información, vea Auditoría de nivel de inquilino.

Contenido relacionado

En el siguiente artículo de esta serie, obtendrá información sobre la auditoría de nivel de inquilino.