Solución de problemas de los modelos de DirectQuery en Power BI Desktop

  • Artículo

Este artículo le ayuda a diagnosticar problemas de rendimiento con los modelos de datos DirectQuery de Power BI que se desarrollan en Power BI Desktop o en el servicio Power BI. En el artículo también se describe cómo obtener información detallada para ayudarle a optimizar los informes.

Sería conveniente iniciar el diagnóstico de problemas de rendimiento en Power BI Desktop, en lugar de hacerlo en el servicio Power BI o en Power BI Report Server. Los problemas de rendimiento suelen basarse en el nivel de rendimiento del origen de datos subyacente. Puede identificar y diagnosticar estos problemas más fácilmente en el entorno de Power BI Desktop aislado, sin que intervengan componentes como puertas de enlace locales.

Si no se producen problemas de rendimiento en Power BI Desktop, puede centrar su investigación en los detalles del informe en el servicio Power BI.

También debe intentar aislar los problemas en un objeto visual en concreto antes de examinar muchos objetos visuales de una página.

Analizador de rendimiento

El Analizador de rendimiento es una herramienta útil para identificar problemas de rendimiento a lo largo del proceso de solución de problemas. Si puede identificar un solo objeto visual lento en una página de Power BI Desktop, puede usar el Analizador de rendimiento para determinar qué consultas envía Power BI Desktop al origen subyacente.

También puede ver seguimientos e información de diagnóstico que emiten los orígenes de datos subyacentes. Tales seguimientos pueden contener también información útil sobre los detalles de cómo se ejecutó la consulta y cómo mejorarla.

Incluso sin seguimientos del origen, puede ver las consultas enviadas por Power BI, junto con sus tiempos de ejecución.

Nota

En el caso de los orígenes basados en SQL de DirectQuery, el Analizador de rendimiento muestra solo consultas de orígenes de datos de SQL Server, Oracle y Teradata.

Archivo de seguimiento

De manera predeterminada, Power BI Desktop registra los eventos que se producen durante una sesión determinada en un archivo de seguimiento llamado FlightRecorderCurrent.trc. Puede encontrar el archivo de seguimiento de la sesión actual en la carpeta AppData del usuario actual, en <User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces.

Los siguientes orígenes de datos de DirectQuery escriben todas las consultas que Power BI les envía en el archivo de seguimiento. Es posible que el registro admita otros orígenes de DirectQuery en el futuro.

  • SQL Server
  • Azure SQL Database
  • Azure Synapse Analytics (anteriormente SQL Data Warehouse)
  • Oracle
  • Teradatos
  • SAP HANA

Para llegar fácilmente a la carpeta del archivo de seguimiento de Power BI Desktop, seleccione Archivo>Opciones y configuración>Opciones, y luego elija Diagnóstico.

Screenshot of the Diagnostics section of the Power BI Desktop Options screen with the link to open the crash dump/traces folder.

En Recopilación del volcado de memoria, seleccione el vínculo Abrir la carpeta de volcado de memoria y seguimiento para abrir la carpeta <User>\AppData\Local\Microsoft\Power BI Desktop\Traces.

Vaya a la carpeta principal y, luego, a la carpeta AnalysisServicesWorkspaces, que contiene una carpeta de área de trabajo para cada instancia abierta de Power BI Desktop. Los nombres de subcarpeta tienen sufijos enteros, como AnalysisServicesWorkspace2058279583.

Cada carpeta AnalysisServicesWorkspace incluye una subcarpeta Datos que contiene el archivo de seguimiento FlightRecorderCurrent.trc de la sesión de Power BI actual. La carpeta desaparece cuando finaliza la sesión de Power BI Desktop asociada.

Puede abrir los archivos de seguimiento mediante la herramienta SQL Server Profiler, que puede conseguir como parte de la descarga gratuita de SQL Server Management Studio (SSMS). Después de descargar e instalar SQL Server Management Studio, ejecute SQL Server Profiler.

Screenshot of SQL Server Profiler window with no highlighted traces.

Para abrir un archivo de seguimiento:

  1. En SQL Server Profiler, seleccione Archivo>Abrir>Archivo de seguimiento.

  2. Vaya a la ruta de acceso del archivo de seguimiento de la sesión de Power BI actual, o escríbala, por ejemplo, <Usuario>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data y abra FlightRecorderCurrent.trc.

SQL Server Profiler muestra todos los eventos de la sesión actual. En la captura de pantalla siguiente se resalta un grupo de eventos para una consulta. Cada grupo de consulta tiene los siguientes eventos:

  • Un evento Query Begin y Query End, que representan el inicio y el final de una consulta DAX generada al cambiar un objeto visual o un filtro en la interfaz de usuario de Power BI, o a partir del filtrado o la transformación de datos en el Power Query Editor.

  • Uno o más pares de eventos DirectQuery Begin y DirectQuery End, que representan consultas enviadas al origen de datos subyacente como parte de la evaluación de la consulta DAX.

Screenshot of SQL Server Profiler with highlighted Query Begin and Query End events.

Se pueden ejecutar varias consultas DAX en paralelo, por lo que se pueden intercalar eventos de distintos grupos. Puede usar el valor de ActivityID para determinar qué eventos pertenecen al mismo grupo.

Las columnas siguientes también son de interés:

  • TextData: el detalle textual del evento. Para los eventos Query Begin y Query End, el detalle es la consulta DAX. En el caso de los eventos DirectQuery Begin y DirectQuery End, el detalle es la consulta SQL enviada al origen subyacente. El valor de TextData del evento seleccionado actualmente también aparece en el panel de la parte inferior de la pantalla.
  • EndTime: cuándo se completó el evento.
  • Duration: la duración, en milisegundos, que tardó en ejecutarse la consulta DAX o SQL.
  • Error: si se ha producido un error, en cuyo caso el evento también se muestra en rojo.

La imagen anterior reduce algunas de las columnas menos interesantes, para que pueda ver las columnas más interesantes con mayor facilidad.

Para capturar un seguimiento que le ayude a diagnosticar un posible problema de rendimiento, siga esta estrategia:

  1. Abra una sesión única de Power BI Desktop, para evitar la confusión de tener varias carpetas de área de trabajo.

  2. Realice el conjunto de acciones de interés en Power BI Desktop. Incluya algunas acciones más, para asegurarse de que los eventos de interés se vacían en el archivo de seguimiento.

  3. Abra SQL Server Profiler y examine el seguimiento. Recuerde que al cerrar Power BI Desktop, se elimina el archivo de seguimiento. Además, las acciones adicionales en Power BI Desktop no aparecen inmediatamente. Debe cerrar y volver a abrir el archivo de seguimiento para ver nuevos eventos.

Mantenga sesiones individuales razonablemente pequeñas, quizás 10 segundos de acciones, no cientos. Este enfoque facilita la interpretación del archivo de seguimiento. También hay un límite en el tamaño del archivo de seguimiento, por lo que durante sesiones largas, existe la posibilidad de que se anulen eventos tempranos.

Formato de consulta y subconsulta

El formato general de las consultas de Power BI Desktop consiste en usar subconsultas para cada tabla de modelo a la que hacen referencia las consultas. La consulta del Power Query Editor define las consultas de la subselección. Por ejemplo, supongamos que tiene las siguientes tablas TPC-DS en una base de datos relacional de SQL Server:

Screenshot of a Power BI Desktop model view diagram that shows the related Item, Web_Sales, Customer and Date-dim TPC-DS tables.

En el objeto visual de Power BI, la expresión siguiente define la medida SalesAmount:


SalesAmount = SUMX(Web_Sales, [ws_sales_price] * [ws_quantity])

Screenshot of a Power BI Desktop stacked column chart that displays sales amount by category.

Al actualizar el objeto visual, se genera la consulta T-SQL en la imagen siguiente. Como puede ver, hay tres subconsultas para las tablas de modelo Web_Sales, Item y Date_dim. Cada consulta devuelve todas las columnas de la tabla de modelo, aunque el objeto visual solo haga referencia a cuatro.

Estas subconsultas sombreadas son la definición exacta de las consultas de Power Query. Este uso de consultas no afecta al rendimiento de los orígenes de datos compatibles con DirectQuery. Los orígenes de datos como SQL Server optimizan las referencias a las otras columnas.

Una razón por la que Power BI emplea este patrón es porque se puede definir una consulta de Power Query para que use una instrucción de consulta concreta. Power BI usa la consulta como se proporciona, sin ningún intento de reescribirla. Este patrón restringe el uso de instrucciones de consulta que usan expresiones de tabla comunes (CTE) y procedimientos almacenados. Estas instrucciones no se pueden usar en subconsultas.

Screenshot of a T-SQL query that shows embedded subqueries, one for each model table.

Rendimiento de las puertas de enlace

Para más información sobre la solución de problemas de rendimiento de la puerta de enlace, consulte Solución de problemas de puertas de enlace: Power BI.

Contenido relacionado

Para más información acerca de DirectQuery, revise los siguientes recursos:

¿Tiene alguna pregunta? Pruebe a preguntar a la comunidad de Power BI