Visualisation et interprétation des diagnostics de requête dans Power BI

Introduction

Une fois que vous avez enregistré les diagnostics que vous souhaitez utiliser, l’étape suivante sera d’être en mesure de comprendre ce qu’ils disent.

Il est utile d’avoir une bonne compréhension de ce que chaque colonne du schéma de diagnostic de requête signifie. Nous n’allons pas le rappeler dans ce court tutoriel. Il y a un article à ce sujet ici.

En général, lors de la création de visualisations, il est préférable d’utiliser la table détaillée complète. Étant donné que, indépendamment du nombre de lignes, ce que vous examinez probablement est une sorte de représentation de la façon dont le temps passé dans différentes ressources s’ajoute, ou de ce que la requête native a émis.

Comme mentionné dans notre article sur l’enregistrement des diagnostics, je travaille avec les suivis OData et SQL pour la même table (ou presque) : la table Customers de Northwind. En particulier, je vais me concentrer sur la demande commune de nos clients, et l’un des ensembles de suivis les plus faciles à interpréter : l’actualisation complète du modèle de données.

Génération des visualisations

Lorsque vous passez par des suivis, il existe de nombreuses façons de les évaluer. Dans cet article, nous allons nous concentrer sur le fractionnement de deux visualisations pour afficher les détails qui vous intéressent et l’autre pour examiner facilement les contributions de temps de différents facteurs. Pour la première visualisation, une table est utilisée. Vous pouvez choisir les champs que vous aimez, mais ceux recommandés pour un aperçu facile et de haut niveau de ce qui se passe sont :

• Id
• Heure de début
• Requête
• Étape
• Requête de source de données
• Durée exclusive (%)
• Nombre de lignes
• Catégorie
• Requête utilisateur
• Chemin d’accès

Pour la deuxième visualisation, un choix consiste à utiliser un graphique en colonnes empilé. Dans le paramètre « Axe », vous pouvez utiliser « ID » ou «Étape». Si nous examinons l’actualisation, car elle n’a rien à voir avec les étapes de l’éditeur lui-même, nous voulons probablement regarder «ID». Pour le paramètre « Légende », vous devez définir «Catégorie« ou »Opération» (selon la granularité souhaitée). Pour la valeur « Valeur », définissez «Durée exclusive» (et assurez-vous qu’il ne s’agit pas du pourcentage, afin que vous obteniez la valeur de durée brute). Enfin, pour l’info-bulle, définissez « Heure de début la plus ancienne ».

Une fois que votre visualisation est générée, veillez à trier par « Heure de début la plus ancienne »pour que vous puissiez voir les choses de l’ordre se produire.

Bien que vos besoins exacts puissent différer, cette combinaison de graphiques est un bon endroit où commencer pour examiner de nombreux fichiers de diagnostic et à plusieurs fins.

Interprétation des visualisations

Comme mentionné ci-dessus, il existe de nombreuses questions auxquelles vous pouvez essayer de répondre avec les diagnostics de requête, mais les deux que nous voyons le plus souvent concerne la façon dont le temps est passé et demande ce qu’est la requête envoyée à la source.

Demander comment le temps est passé est facile et sera similaire pour la plupart des connecteurs. Un avertissement avec les diagnostics de requête, comme mentionné ailleurs, est que vous verrez des fonctionnalités radicalement différentes en fonction du connecteur. Par exemple, de nombreux connecteurs basés sur ODBC n’ont pas d’enregistrement précis de la requête envoyée au système principal réel, car Power Query voit uniquement ce qu’il envoie au pilote ODBC.

Si nous voulons voir comment le temps est passé, nous pouvons simplement examiner les visualisations que nous avons générées ci-dessus.

Maintenant, étant donné que les valeurs de temps pour les exemples de requêtes que nous utilisons ici sont si petites, si nous voulons travailler avec la façon dont Power BI rapporte le temps, il est préférable de convertir la colonne Durée exclusive en « Secondes » dans l’éditeur Power Query. Une fois cette conversion terminée, nous pouvons examiner notre graphique et obtenir une idée acceptable de l’endroit où le temps est passé.

Pour mes résultats OData, je vois dans l’image que la grande majorité du temps a été passé à récupérer les données à partir de la source , si je sélectionne l’élément « Source de données » sur la légende, il me montre toutes les différentes opérations liées à l’envoi d’une requête à la source de données.

Si nous effectuons toutes les mêmes opérations et générons des visualisations similaires, avec les traces SQL au lieu des données ODATA, nous pouvons comparer les deux sources de données !

Si nous sélectionnons la table source de données, comme avec les diagnostics ODATA, nous pouvons voir que la première évaluation (2.3 dans cette image) émet des requêtes de métadonnées et que la deuxième évaluation récupère réellement les données qui nous intéressent. Étant donné que nous récupérons de petites quantités de données dans ce cas, les données extraites prennent peu de temps (moins d’un dixième d’une seconde pour l’ensemble de la deuxième évaluation qui doit avoir lieu, avec moins d’un 20ème de seconde pour l’extraction de données elle-même). Cependant, cela ne sera pas vrai dans tous les cas.

Comme ci-dessus, nous pouvons sélectionner la catégorie « Source de données » sur la légende pour afficher les requêtes émises.

Exploration des données

Les chemins d’accès

Lorsque vous examinez ce problème, s’il semble que le temps passé soit anormal, par exemple, sur la requête OData, vous pouvez voir qu’il existe une requête de source de données avec la valeur suivante :

Request:
https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle%20eq%20%27Sales%20Representative%27&$select=CustomerID%2CCountry HTTP/1.1
Content-Type: application/json;odata.metadata=minimal;q=1.0,application/json;odata=minimalmetadata;q=0.9,application/atomsvc+xml;q=0.8,application/atom+xml;q=0.8,application/xml;q=0.7,text/plain;q=0.7

<Content placeholder>

Response:
Content-Type: application/json;odata.metadata=minimal;q=1.0,application/json;odata=minimalmetadata;q=0.9,application/atomsvc+xml;q=0.8,application/atom+xml;q=0.8,application/xml;q=0.7,text/plain;q=0.7
Content-Length: 435

<Content placeholder>

Cette requête de source de données est associée à une opération qui prend uniquement en charge, disons, 1 % de la durée exclusive. En attendant, il y en a un similaire :

Request:
GET https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle eq 'Sales Representative'&$select=CustomerID%2CCountry HTTP/1.1

Response:
https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle eq 'Sales Representative'&$select=CustomerID%2CCountry
HTTP/1.1 200 OK

Cette requête de source de données est associée à une opération qui prend en charge presque 75 % de la durée exclusive. Si vous activez le chemin d’accès, vous découvrez que ce dernier est en fait un élément enfant du précédent. Cela signifie que la première requête a essentiellement ajouté une petite quantité de temps en soi, avec l’extraction de données réelle suivie par la requête « interne ».

Il s’agit de valeurs extrêmes, mais elles se trouvent dans les limites de ce qui peut être vu.