Power BIでのクエリ診断の視覚化と解釈

使用する診断を 記録 した後、次の手順は、それらが何を言うかを理解することです。

クエリ診断スキーマの各列の意味を十分に理解しておくと役立ちます。 このチュートリアルでは、その情報については説明しません。 詳細については、「 クエリ診断」を参照してください。

一般に、視覚化を作成するときは、完全な詳細テーブルを使用します。 含まれる行の数に関係なく、さまざまなリソースで費やされた時間がどのように加算されるか、またはネイティブ クエリが出力された内容を何らかの種類で示している可能性があります。

診断の記録に関する記事で説明したように、この例は Northwind の Customers テーブルの OData トレースと SQL トレースで動作します。 特に、顧客からの一般的な質問と、解釈しやすいトレース セットの 1 つ (データ モデルの完全な更新) に焦点を当てています。

視覚化を構築する

トレースを確認するときは、さまざまな方法で評価できます。 この記事では、2 つの視覚化について説明します。 最初の視覚化には、関心のある詳細が表示され、もう 1 つの視覚化にはさまざまな要因の時間の寄与が示されます。 最初の視覚化では、テーブルを使用します。 任意のフィールドを選択できますが、簡単に概要を確認するには、次のフィールドを使用します。

2 番目の視覚化では、積み上げ縦棒グラフを使用します。 Axis パラメーターで、ID または Step使用します。 更新を見ている場合は、エディター自体の手順とは何の関係もないため、 ID だけを調べることをお望みでしょう。 [凡例 ] パラメーターで、[ カテゴリ] または [ 操作] を設定します (必要な粒度に応じて)。 Value パラメーターの場合は、排他期間を設定し、%でないことを確認して、生の期間の値を取得します。 最後に、 Tooltip パラメーターに対して、最も早い開始時刻を設定 します

視覚化を作成したら、イベントが発生する順序を確認できるように、 最も早い 開始時刻 で昇順で並べ替えるようにします。

トレース テーブルと、カテゴリと ID ごとの期間の積み上げ横棒グラフを含むクエリ診断のスクリーンショット。

正確なニーズが異なる場合はありますが、このグラフの組み合わせは、多数の診断ファイルや多くの目的を見るための良い場所です。

視覚化を解釈する

前述のように、クエリ診断は多くの質問に答えるのに役立ちます。 最も一般的な 2 つの質問は、時間の使い方とソースに送信されるクエリです。

時間の使い方を理解するのは簡単で、ほとんどのコネクタで似ています。 ただし、他の場所で説明したように、コネクタによって大幅に異なる機能が表示されます。 たとえば、ODBC ベースのコネクタの多くは、ODBC ドライバーに送信Power Queryクエリの正確なレコードを提供しません。

時間の使い方を確認するには、前に作成した視覚化を確認します。

ここで使用するサンプル クエリの時間値は非常に小さいため、時間をレポートする方法Power BI操作する場合は、Power Query エディターで排他期間列を秒に変換することをお勧めします。 この変換を行った後、グラフを見て、時間が費やされた場所を明確に把握できます。

OData の結果の場合、次の図は、ほとんどの時間がソースからデータの取得に費やされていることを示しています。 凡例で [データ ソース ] 項目を選択すると、データ ソースへのクエリの送信に関連するさまざまな操作がすべて表示されます。

データ ソース時間が強調表示されている詳細トレース テーブルと期間グラフを含む OData クエリ診断のスクリーンショット。

同じ操作をすべて実行し、同様の視覚化を作成するが、ODATA トレースの代わりに SQL トレースを使用する場合は、2 つのデータ ソースの比較を確認できます。

ID とカテゴリ別の排他的期間を比較した SQL 評価とグラフを示す詳細トレース テーブルのスクリーンショット。

ODATA 診断と同様にデータ ソース テーブルを選択すると、最初の評価 (この画像では 2.3) がメタデータ クエリを送信し、2 番目の評価では関心のあるデータが取得されます。 この例では少量のデータを取得するため、データの取得には少し時間がかかります (2 番目の評価全体では 10 分の 1 秒未満で、データ取得自体では 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% を占有する操作に関連付けられています。 パスをオンにした場合、後者は実際には前者の子であることが分かっています。 この知見は、最初のクエリ自体は基本的にわずかな時間しか追加せず、実際のデータ取得はinnerクエリによって追跡されることを意味します。

これらの値は極端ですが、実際に見られる範囲内です。