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

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.

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.

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:

• Volverse más complejo e incluir medidas complejas.
• Aumentar en cuanto a volumen de datos.
• Consumir más memoria (a veces innecesariamente si se han tomado decisiones de diseño deficientes).
• Usar orígenes de datos más diversos y relaciones más complejas entre tablas.
• Incluir más reglas de seguridad de nivel de fila (RLS). Para obtener más información, vea Aplicación de la seguridad de los datos en función de la identidad del consumidor.
• Tener más informes que dependen de él. Para obtener más información sobre el uso de conexiones dinámicas con un modelo semántico compartido, vea el escenario de uso de BI de autoservicio administrado.
• Tener más modelos de datos descendentes que dependen de él. Para obtener más información sobre el uso de DirectQuery para modelos semánticos de Power BI y Analysis Services con un modelo semántico compartido, vea el escenario de uso BI de autoservicio administrado personalizable.
• Experimentar tiempos más lentos de ejecución de consultas y de actualización de datos.
• Contribuir a una representación más lenta de los informes y objetos visuales.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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:

• La API de REST Get Refresh History in Group para recuperar la información de actualización de un área de trabajo.
• La API de REST Get Refreshables for Capacity para recuperar la información de actualización de una capacidad.

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.

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.

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.