Solución de problemas de rendimiento habituales

  • 6 minutos

Las técnicas de optimización individuales son valiosas, pero los problemas de rendimiento del mundo real rara vez encajan perfectamente en una sola categoría. Un informe lento podría tener un problema de DAX, un problema de cardinalidad y un problema de diseño visual a la vez. Un enfoque de solución de problemas sistemático le ayuda a encontrar y corregir problemas de forma eficaz.

Seguimiento de un flujo de trabajo de diagnóstico sistemático

Cuando un informe sea lento, use este enfoque de tres pasos:

  1. ¿Es el gráfico, el DAX o los datos? Abra el analizador de rendimiento, borre la memoria caché y actualice todos los objetos visuales. Compare la consulta DAX, la visualización visual y otras métricas de tiempo para determinar dónde se dedica el tiempo.
  2. Aísle la causa principal. Copie la consulta DAX lenta y ejecútela en la vista de consulta DAX. Si la consulta es rápida allí pero lenta en la visualización, el problema es la representación. Si la consulta es lenta en todas partes, el problema es la medida o el modelo de datos.
  3. Corregir y comprobar. Aplique la corrección adecuada y vuelva a ejecutar el analizador de rendimiento para confirmar que el rendimiento ha mejorado. No suponga que la corrección funcionó: midala.

Este flujo de trabajo (síntoma → diagnóstico → corregir → comprobar) impide pasar tiempo en el problema incorrecto y confirma que los cambios realmente ayudan.

Ejecutar el Analizador de mejores prácticas para detectar problemas comunes

El Analizador de procedimientos recomendados (BPA) comprueba el modelo semántico con un conjunto de más de 60 reglas que abarcan el rendimiento, las expresiones DAX, la prevención de errores y el mantenimiento. En lugar de inspeccionar manualmente todas las columnas y medidas, BPA examina todo el modelo y marca problemas como columnas sin usar, claves de cardinalidad alta, descripciones que faltan y patrones DAX ineficaces.

En Microsoft Fabric, BPA está disponible a través de cuadernos de ejemplo que puede abrir directamente desde su modelo semántico en el servicio Power BI. Seleccione el modelo semántico y, a continuación, elija el cuaderno BPA en la cinta Inicio o en la lista desplegable Salud del modelo. El cuaderno se ejecuta con su modelo utilizando un enlace semántico y devuelve recomendaciones categorizadas. Un cuaderno complementario del Analizador de memoria muestra estadísticas de almacenamiento para tablas, columnas y relaciones.

BPA es más útil como una comprobación proactiva antes de que se muestren problemas de rendimiento. Ejecútelo después de compilar o cambiar significativamente un modelo y use los resultados para guiar las técnicas de optimización que se trataron anteriormente en este módulo.

Nota:

Si no tiene acceso a Fabric, Tabular Editor (una herramienta externa de terceros) incluye una característica BPA que ejecuta el mismo conjunto de reglas localmente en un modelo de escritorio de Power BI o un modelo publicado a través del punto de conexión XMLA.

Tratar elementos visuales complejos

Los objetos visuales que solicitan demasiados datos son un problema de rendimiento común. Cada objeto visual de una página de informe envía consultas DAX independientes al modelo semántico y los objetos visuales con muchas medidas, puntos de datos o dependencias de filtrado cruzado generan consultas complejas.

Problemas comunes de rendimiento visual:

  • Demasiadas medidas en un solo elemento visual. Un visual de tabla con 20 medidas genera una consulta grande y compleja. Reduzca el número de medidas o divida la información entre varios objetos visuales.
  • Demasiados puntos de datos. Un gráfico de dispersión con 100 000 puntos individuales o una tabla con 50 000 filas tarda mucho tiempo en representarse. Aplique los filtros N principales para limitar las filas devueltas.
  • Demasiados objetos visuales en una página. Cada elemento visual envía consultas independientemente. Una página con 30 objetos visuales consulta el modelo 30 veces al cargarse. Utilice páginas de desglose y consejos de herramientas para distribuir la información entre varias páginas en lugar de amontonarlo todo en una sola.

Sugerencia

Como guía general, no más de ocho elementos gráficos por página de informe. Más que eso aumenta los tiempos de carga y hace que el informe sea más difícil de usar.

Corrección de relaciones mal diseñadas

El diseño de relaciones afecta a la forma en que el motor resuelve la propagación de filtros entre tablas. Problemas a tener en cuenta:

  • Rutas de relación ambiguas. Varias rutas activas entre dos tablas obligan al motor a determinar qué ruta se debe usar, lo que puede llevar a resultados inesperados y a una sobrecarga de rendimiento. Utilice relaciones activas únicas y USERELATIONSHIP en las medidas cuando necesite una ruta alternativa.
  • Filtrado cruzado bidireccional. Las relaciones bidireccionales propagan filtros en ambas direcciones, lo que aumenta la complejidad de la evaluación de consultas. Utilice el filtrado bidireccional solo cuando sea necesario, por ejemplo, en relaciones muchos a muchos.
  • Columnas de relaciones de alta cardinalidad. Las relaciones en columnas con millones de valores únicos (como GUIDs) son más lentas de recorrer que aquellas en columnas con menor cardinalidad. Si es posible, use claves suplentes enteras en su lugar.

Resolución de problemas de contexto de filtro

La propagación de filtros costosa puede ralentizar las consultas incluso cuando la propia lógica de medida es sencilla. Observe estos patrones:

  • REMOVEFILTERS o ALL en tablas grandes. Estas funciones quitan el contexto de filtro, lo que significa que el motor debe evaluar toda la tabla sin restricciones. Úselas intencionadamente y solo en el ámbito necesario.
  • Relaciones muchos a muchos con tablas puente de gran tamaño. Cada consulta resuelve la correspondencia a través de la tabla puente. Con datos grandes, este proceso es costoso. Considere si un enfoque de modelado diferente (como las dimensiones de juego de roles o las tablas consolidadas) funciona mejor.

Solución de problemas de rendimiento de DirectQuery

Cuando el modelo semántico usa el modo de almacenamiento directQuery, el rendimiento lento puede provenir del origen de datos externo en lugar del motor DAX. Entre los problemas específicos de DirectQuery se incluyen:

  • Errores de plegado de consultas. Power Query intenta devolver las transformaciones a la fuente de datos (plegado de consultas). Cuando una transformación no se puede plegar, Power BI descarga los datos sin procesar y los procesa localmente. Este enfoque es mucho más lento. Revise la consulta nativa en Power Query para verificar el plegado.
  • Consultas de origen lentas. Incluso cuando funciona el plegado de consultas, la base de datos de origen podría ejecutar la consulta lentamente debido a la falta de índices, barridos de tablas grandes o contención de recursos. Trabaje con administradores de bases de datos para optimizar el rendimiento de origen.
  • Latencia de ida y vuelta. Cada interacción visual envía una consulta al origen de datos y espera una respuesta. La latencia de red y el tiempo de respuesta del origen se suman, especialmente en páginas con muchos elementos visuales. Considere la posibilidad de usar modos de almacenamiento mixtos con Importación de datos de resumen y DirectQuery para obtener datos detallados.

Uso de DAX Studio para un diagnóstico más profundo

El analizador de rendimiento y la vista de consultas DAX controlan la mayoría de los escenarios de solución de problemas. Cuando necesite detalles a nivel del motor (como si una consulta se ve ralentizada en el motor de fórmulas o en el motor de almacenamiento), DAX Studio cubre esa necesidad. Copie una consulta DAX lenta del analizador de rendimiento, péguela en DAX Studio y habilite El tiempo del servidor para ver exactamente dónde se dedica el tiempo. La vista Plan de Consulta también puede revelar operaciones ineficaces que no se hacen visibles solo mediante los datos temporales.

Nota:

SQL Server Profiler es otra opción para capturar un seguimiento completo de todas las consultas SQL de DAX y DirectQuery durante una sesión. Se conecta a la instancia local de Analysis Services que ejecuta Power BI Desktop. Profiler es útil para el análisis en toda la sesión, pero para la mayoría de la solución de problemas de nivel visual, el analizador de rendimiento y DAX Studio son más prácticos.

Creación de una lista de comprobación de solución de problemas

Al investigar un informe lento, realice estas comprobaciones en orden:

  1. Borre la memoria caché y ejecute el analizador de rendimiento. Identifique el elemento visual más lento y su categoría de cuello de botella.
  2. Si el tiempo de consulta de DAX es alto, copie y analice la consulta en la vista de consulta DAX o DAX Studio. Busque patrones costosos como FILTER en tablas grandes, iteradores o subexpresiones repetidas.
  3. Si el tiempo de visualización visual es alto, simplifique el objeto visual reduciendo el número de medidas, puntos de datos o aplicando filtros.
  4. Compruebe la cardinalidad de las columnas clave. Quite o reduzca las columnas de cardinalidad alta que no son necesarias.
  5. Para los modelos de DirectQuery, verifique el plegado de consultas y el rendimiento de la fuente de datos.
  6. Después de cada cambio, vuelva a medir para confirmar la mejora.

Este enfoque estructurado garantiza abordar primero los problemas más impactantes y no dedicar tiempo a los cambios que no mueven la aguja.