Power BI でのクエリ診断の視覚化と解釈
はじめに
使用する診断を記録したら、次の手順では、診断の内容を理解できるようにします。
クエリ診断スキーマの各列が正確に何を意味するかを理解すると役立ちますが、この短いチュートリアルでは詳しく説明していません。 こちらにその完全な記事があります。
一般に、視覚化を構築するときは、完全な詳細テーブルを使用することをお勧めします。 行数に関係なく、おそらく見ているのは、さまざまなリソースで費やされた時間がどのように加算されるか、または出力されたネイティブ クエリが何であったかについての何らかの描写であるためです。
診断の記録に関する記事で説明したように、私は同じテーブル (またはほぼ同じ)、つまり Northwind の Customers テーブルの OData および SQL トレースを操作しています。 特に、お客様からよく寄せられる質問と、解釈しやすいトレース セットの 1 つであるデータ モデルの完全更新に焦点を当てます。
視覚化の構築
トレースを調べる場合、トレースを評価できる方法はたくさんあります。 この記事では、視覚化の 2 分割を中心に説明します。1 つは関心のある詳細情報を示し、もう 1 つはさまざまな要因による時間の影響を簡単に示すものです。 最初の視覚化では、テーブルが使用されます。 任意のフィールドを選択できますが、進行中の内容の概要を簡単に確認するために推奨されるフィールドは次のとおりです。
2 つ目の視覚化では、1 つの選択肢として積み上げ縦棒グラフを使用します。 'Axis' パラメーターでは、'Id' または 'Step 'を使用できます。 更新を確認する場合は、エディター自体の手順には関係ないので、おそらく単に 'Id'. を確認することになります。 'Legend' パラメーターには、(必要な細分性に応じて) 'Category' または 'Operation' を設定する必要があります。 'Value' には、'Exclusive Duration' を設定します (生の期間の値を取得するように、% でないことを確認します)。 最後に、ToolTip に、'Earliest Start Time' を設定します。
視覚化が作成されたら、発生した順序を確認できるように 'Earliest Start Time' で昇順に並べ替えます。
正確なニーズは異なる場合がありますが、このグラフの組み合わせは、多数の診断ファイルやさまざまな目的を確認するための開始点として適しています。
視覚化の解釈
上で述べたように、クエリ診断で答えられる質問はたくさんありますが、最もよく見られる 2 つは、時間の経過を尋ねる質問と、ソースに送信されたクエリが何であるかを尋ねることです。
時間がどのように費やされるかを尋ねるのは簡単で、ほとんどのコネクタで同様です。 他の場所で説明したように、クエリ診断で注意すべきなのは、コネクタによって大幅に異なる機能が表示されることです。 たとえば、多くの ODBC ベースのコネクタでは、実際のバックエンド システムに送信されるクエリの正確な記録がありません。これは、Power Query では ODBC ドライバーに送信される情報しか表示されないためです。
時間がどのように費やされたかを確認したい場合は、上記で作成した視覚化を調べることができます。
ここで使用しているサンプル クエリの時間値は非常に小さいため、Power BI で時間を報告する方法を処理する場合は、Power Query エディターでExclusive Duration列を 'Seconds' に変換することをお勧めします。 この変換を行うと、チャートを見て、どこに時間が費やされているかを適切に把握できるようになります。
OData の結果では、時間の大部分がソースからのデータの取得に費やされていることが画像でわかります。凡例で「データ ソース」項目を選択すると、データ ソースへのクエリ送信に関連するすべての操作が表示されます。
同じ操作をすべて実行し、同じような視覚化を構築するときに、ODATA トレースの代わりに SQL トレースを使用すると、2 つのデータ ソースの比較を確認できます。
ODATA 診断と同様にデータ ソース テーブルを選択すると、最初の評価 (この画像の 2.3) がメタデータ クエリを発行し、2 番目の評価で実際に対象のデータを取得していることがわかります。 この場合は少量のデータを取得しているため、データの取得には少し時間がかかります (2 番目の評価全体が発生するまでに 10 分の 1 秒未満、データの取得にかかる時間は 20 分の 1 秒未満です)。ただし、しかしそれはすべての場合に当てはまるわけではありません。
上記と同様に、凡例で「データ ソース」カテゴリを選択すると、発行されたクエリを確認できます。
データの掘り下げ
パスの確認
これを見るときに、(たとえば、OData クエリで) 費やされた時間が奇妙だと思われる場合、次の値を持つデータ ソース クエリがあることが分かる可能性があります。
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>
このデータ ソース クエリが関連付けられている操作が占めるのは、排他継続時間の約 1% のみです。 一方、同様のものがあります。
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
このデータ ソース クエリが関連付けられている操作が占めるのは、排他継続時間のほぼ 75% です。 パスをオンにした場合、後者は実際には前者の子であることが分かります。 これは、最初のクエリは基本的にそれ自体で少量の時間を追加し、実際のデータ取得は「内部」クエリによって追跡されることを意味します。
これらは極端な値ですが、表示できるものの範囲内にあります。