Résoudre les problèmes liés aux modèles DirectQuery dans Power BI Desktop

  • Article

Cet article vous aide à diagnostiquer les problèmes de performances liés aux modèles de données Power BI DirectQuery que vous développez dans Power BI Desktop ou le service Power BI. L’article explique également comment obtenir des informations détaillées pour vous aider à optimiser les rapports.

Vous devrez débuter un diagnostic des problèmes de performances dans Power BI Desktop au lieu de le faire dans Power BI (le service ou Power BI Report Server). Les problèmes de performances sont souvent liés au niveau de performance de la source sous-jacente. Vous pouvez identifier et diagnostiquer plus facilement ces problèmes dans l’environnement Power BI Desktop isolé, sans impliquer de composants tels qu’une passerelle locale.

Si vous ne trouvez pas de problème de performances dans Power BI Desktop, concentrez-vous sur les spécificités du rapport dans le service Power BI.

Vous devez également essayer d’isoler les problèmes d’un visuel individuel avant d’examiner de nombreux visuels sur une page.

Analyseur de performances

L’Analyseur de performances est un outil pratique pour identifier les problèmes de performances tout au long de ce processus de résolution des problèmes. Si vous pouvez identifier un seul visuel lent sur une page dans Power BI Desktop, vous pouvez utiliser Analyseur de performances pour déterminer les requêtes que Power BI Desktop envoie à la source sous-jacente.

Vous pouvez également afficher les traces et les informations de diagnostic émises par certaines sources de données sous-jacentes. Ces traces peuvent également contenir des informations utiles et détaillées sur la façon dont la requête a été exécutée et la manière de l’améliorer.

Même sans traces de la source, vous pouvez afficher les requêtes envoyées par Power BI, ainsi que leurs heures d’exécution.

Notes

Pour les sources SQL DirectQuery, Analyseur de performances affiche des requêtes uniquement pour les sources de données SQL Server, Oracle et Teradata.

Fichier de suivi

Par défaut, Power BI Desktop journalise les événements survenant au cours d’une session donnée dans un fichier de trace nommé FlightRecorderCurrent.trc. Vous pouvez rechercher un fichier de trace pour la session dans le dossier AppData de l’utilisateur actuel sur \<Utilisateur>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces.

Les sources de données DirectQuery suivantes écrivent toutes les requêtes que Power BI envoie au fichier de trace. Le journal peut prendre en charge d’autres sources DirectQuery à l’avenir.

  • SQL Server
  • Azure SQL Database
  • Azure Synapse Analytics (anciennement SQL Data Warehouse)
  • Oracle
  • Teradata
  • SAP HANA

Pour accéder facilement au dossier du fichier de trace dans Power BI Desktop, sélectionnez Fichier>Options et paramètres>Options, puis Diagnostics.

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

Sous Collection de vidages sur incident, sélectionnez le lien Ouvrir le dossier de vidages/traces sur incident pour ouvrir le dossier <Utilisateur>\AppData\Local\Microsoft\Power BI Desktop\Traces.

Accédez au dossier parent du dossier, puis ouvrez le dossier AnalysisServicesWorkspaces, qui contient un sous-dossier d’espace de travail pour chaque instance ouverte de Power BI Desktop. Les noms des sous-dossiers ont des suffixes entiers, tels que AnalysisServicesWorkspace2058279583.

Chaque dossier AnalysisServicesWorkspace inclut un sous-dossier Données qui contient le fichier de trace FlightRecorderCurrent.trc pour la session Power BI actuelle. Ce dossier disparaît à l’issue de la session Power BI Desktop associée.

Vous pouvez ouvrir les fichiers de trace à l’aide de l’outil SQL Server Profiler, que vous pouvez obtenir dans le cadre du téléchargement gratuit SQL Server Management Studio (SSMS). Une fois que vous avez téléchargé et installé SQL Server Management Studio, exécutez SQL Server Profiler.

Screenshot of SQL Server Profiler window with no highlighted traces.

Pour ouvrir un fichier de trace :

  1. Dans SQL Server Profiler, sélectionnez Fichier>Ouvrir>Fichier de trace.

  2. Naviguez ou entrez le chemin du fichier de trace de la session Power BI actuelle, par exemple : \<Utilisateur>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data et ouvrez FlightRecorderCurrent.trc.

SQL Server Profiler affiche tous les événements de la session active. La capture d’écran suivante met en évidence un groupe d’événements pour une requête. Chaque groupe de requête inclut les événements suivants :

  • Événements Query Begin et Query End, qui représentent le début et la fin d’une requête DAX générée en modifiant un visuel ou un filtre dans l’interface utilisateur Power BI, ou en filtrant ou transformant des données dans le Éditeur Power Query.

  • Une ou plusieurs paires d’événements DirectQuery Begin et DirectQuery End, qui représentent une requête envoyée à la source de données sous-jacente dans le cadre de l’évaluation de la requête DAX.

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

Dans la mesure où plusieurs requêtes DAX peuvent être exécutées en parallèle, les événements de différents groupes peuvent être entrelacés. Vous pouvez utiliser la valeur de ActivityID pour déterminer quels événements appartiennent au même groupe.

Les colonnes suivantes sont également intéressantes :

  • TextData : détail textuel de l’événement. Pour les événements Query Begin et Query End, il s’agit de la requête DAX. Pour les événements DirectQuery Begin et DirectQuery End, il s’agit de la requête SQL envoyée à la source sous-jacente. La valeur TextData de l’événement actuellement sélectionné apparaît également dans le volet en bas de l’écran.
  • EndTime : heure de fin de l’événement.
  • Durée : durée d’exécution de la requête DAX ou SQL, exprimée en millisecondes.
  • Erreur : indique si une erreur s’est produite, auquel cas l’événement s’affiche également en rouge.

L’image précédente réduit certaines des colonnes les moins intéressantes, ce qui vous permet de voir plus facilement les colonnes les plus intéressantes.

Suivez cette approche pour capturer une trace afin de faciliter le diagnostic d’un problème potentiel de performances :

  1. Ouvrez une session Power BI Desktop pour éviter les confusions possibles entre plusieurs dossiers de l’espace de travail.

  2. Effectuez l’ensemble des actions qui vous intéressent dans Power BI Desktop. Incluez quelques actions supplémentaires pour vous assurer que les événements intéressants sont vidés dans le fichier de trace.

  3. Ouvrez SQL Server Profiler, puis examinez la trace. N’oubliez pas que le fichier de trace est supprimé à la fermeture de Power BI Desktop. Par ailleurs, les actions supplémentaires effectuées dans Power BI Desktop n’apparaissent pas immédiatement. Vous devez fermer et rouvrir le fichier de trace pour voir les nouveaux événements.

Conservez des sessions individuelles relativement petites (10 secondes d’actions éventuellement, mais pas des centaines). Cette approche simplifie l’interprétation du fichier de trace. Il existe également une limite sur la taille du fichier de trace. Par conséquent, pour les sessions longues, il est possible que les événements précoces diminuent.

Format de requête et de sous-requête

Le format général des requêtes Power BI Desktop consiste à utiliser des sous-requêtes pour chaque table de modèle référencée par les requêtes. La requête de l’Éditeur Power Query définit les requêtes de sous-sélection. Par exemple, supposons les tables TPC-DS suivantes dans une base de données relationnelle 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.

Dans le visuel Power BI, l’expression suivante définit la mesure 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.

L’actualisation de ce visuel produit la requête T-SQL dans l’image suivante. Il existe trois sous-requêtes pour les tables Web_Sales, Item et Date_dim du modèle. Chaque requête retourne toutes les colonnes de table de modèle, même si le visuel ne fait référence qu’à quatre colonnes.

Ces sous-requêtes grisées sont exactement la définition des requêtes de Power Query. Cette utilisation de sous-requêtes ne semble pas affecter le niveau de performance des sources de données prises en charge par DirectQuery. Des sources de données telles que SQL Server optimisent les références aux autres colonnes.

L’une des raisons pour lesquelles Power BI utilise ce modèle est que vous pouvez définir une requête Power Query pour utiliser une instruction de requête spécifique. Power BI utilise la requête telle qu’elle est fournie, sans aucune tentative de réécriture. Notez que ces modèles restreignent l’utilisation des instructions de requête qui utilisent des expressions de table communes et des procédures stockées. Vous ne pouvez pas utiliser ces instructions dans les sous-requêtes.

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

Performances de la passerelle

Pour plus d’informations sur la résolution des problèmes de performances de la passerelle, consultez Résoudre les problèmes liés aux passerelles - Power BI.

Contenu connexe

Pour plus d’informations sur DirectQuery, consultez les ressources suivantes :

Vous avez des questions ? Essayez d’interroger la communauté Power BI