Power Query のクエリ プラン (プレビュー)

Power Query のクエリ プランは、クエリの評価をわかりやすく表示できる機能です。 特定のクエリが特定のステップでフォールディングされない場合がある理由を判断するのに役立ちます。

この記事では、実際の例を通じて主な使用用途と、クエリ プラン機能を使ってクエリのステップを確認することの潜在的な利点を示します。 この記事で使用する例は、Azure SQL Server 用の AdventureWorksLT サンプル データベースを使って作成されています。これは AdventureWorks サンプル データベースからダウンロードできます。

Note

Power Query のクエリ プラン機能は、Power Query Online でのみ使用できます。

この記事は、クエリ プランを解釈するために推奨される一連の手順に分割されています。 手順は次のとおりです。

1. クエリ フォールディング インジケーターを確認します。
2. クエリのステップを選択してそのクエリ プランを確認する。
3. クエリの変更を実施する。

次の手順に従って、ご自身の Power Query Online 環境でクエリを作成します。

1. [Power Query - データ ソースの選択] から、[空のクエリ] を選択します。

2. 空のクエリのスクリプトを次のクエリに置き換えます。

   let
     Source = Sql.Database("servername", "database"),
     Navigation = Source{[Schema = "Sales", Item = "SalesOrderHeader"]}[Data],
     #"Removed other columns" = Table.SelectColumns(Navigation, {"SalesOrderID", "OrderDate", "SalesOrderNumber", "PurchaseOrderNumber", "AccountNumber", "CustomerID", "TotalDue"}),
     #"Filtered rows" = Table.SelectRows(#"Removed other columns", each [TotalDue] > 1000),
     #"Kept bottom rows" = Table.LastN(#"Filtered rows", 5)
   in
     #"Kept bottom rows"
   

3. servername と database を、ご自身の環境に適した名前に置き換えます。

4. (省略可能) オンプレミス環境のサーバーとデータベースに接続しようとしている場合は、必ずその環境用のゲートウェイを構成してください。

5. [次へ] を選択します。

6. Power Query エディターで、[接続の構成] を選択し、データ ソースに対する資格情報を指定します。

Note

SQL Server に接続する方法の詳細については、SQL Server データベースに関する記事を参照してください。

これらの手順を実行すると、クエリは次の画像にあるもののようになります。

このクエリは SalesOrderHeader テーブルに接続し、最新の 5 件の注文から TotalDue の値が 1000 を超えているいくつかの列を選択します。

Note

この記事では、簡略化された例を使ってこの機能を紹介していますが、この記事で説明する概念はすべてのクエリに当てはまります。 クエリ プランを読む前に、クエリ フォールディングに関する知識を深めておくことをお勧めします。 クエリ フォールディングの詳細については、クエリ フォールディングの基本に関する記事を参照してください。

1. クエリ フォールディング インジケーターを確認します

Note

このセクションを読む前に、クエリ フォールディング インジケーターに関する記事を確認することをお勧めします。

このプロセスの最初のステップは、クエリを確認し、クエリ フォールディング インジケーターに細心の注意を払うことです。 目標は、フォールディングされないとマークされているステップを確認することです。 その後、クエリ全体に変更を加えてそれらの変換を完全にフォールディングできるかどうかを確認できます。

この例では、フォールディングできない唯一のステップは [保持された下位の行] です。これは フォールディングされない ステップ インジケーターによって簡単に識別できます。 このステップは、クエリの最後のステップでもあります。

ここでの目標は、このステップを確認し、データ ソースにフォールディングされるものと、フォールディングできないものを把握することです。

2. クエリのステップを選択してそのクエリ プランを確認する

[保持された下位の行] ステップが、データ ソースにフォールディングされないため、関心のあるステップであることがわかりました。 ステップを右クリックし、[クエリ プランの表示] オプションを選択します。 この操作により、選択したステップのクエリ プランの図を含む新しいダイアログが表示されます。

Power Query では、クエリ フォールディングの基本に関する記事で説明されているように、遅延評価とクエリ フォールディングを利用してクエリの最適化を試みます。 このクエリ プランは、M クエリの、データ ソースに送信されるネイティブ クエリへの最適化された変換を表します。 また、Power Query エンジンによって実行される変換も含まれています。 各ノードが表示される順序は、クエリの最後のステップまたは出力から始まるクエリの順序に従います。これは図の一番左に表示されます。この例では、[保持された下位の行] ステップを表す [Table.LastN] ノードが該当します。

ダイアログの下部にはバーがあり、クエリ プラン ビューの拡大または縮小に役立つアイコンと、ビューの管理に役立つその他のボタンがあります。 前の図では、このバーの [表示に合わせる] オプションを使って、ノードを見やすくしています。

Note

クエリ プランは、最適化されたプランを表します。 エンジンによってクエリが評価されるときに、すべての演算子をデータ ソースにフォールディングしようとします。 場合によっては、フォールディングを最大化するために、ステップの内部的な並べ替えが実行される場合もあります。 この点を念頭に置くと、この最適化されたクエリ プランに残されているノードや演算子には、通常、"フォールディングされた" データ ソース クエリと、フォールディングできなかった、ローカルで評価されるすべての演算子が含まれています。

フォールディングされたノードとその他のノードを識別する

この図のノードは、次の 2 つのグループに識別できます。

• フォールディングされたノード: このノードは、Value.NativeQuery か、Sql.Database などの "データ ソース" ノードのいずれかになります。 これらは、その関数名の下にある [リモート] というラベルで識別できます。
• フォールディングされていないノード: Table.SelectRows、Table.SelectColumns などのその他のテーブル演算子と、フォールディングできなかったその他の関数です。 これらは、[フル スキャン] や [ストリーミング] というラベルで識別することもできます。

次の図では、赤い四角形の中にフォールディングされたノードが示されています。 残りのノードは、データ ソースにフォールディングできませんでした。 これらのノードをデータ ソースにフォールディングすることが目標であるため、残りのノードを確認する必要があります。

一部のノードの下部にある [詳細の表示] を選択すると、拡張情報を表示できます。 たとえば、Value.NativeQuery ノードの詳細には、データ ソースに送信されるネイティブ クエリ (SQL) が表示されます。

ここに表示されているクエリは、データ ソースに送信されるクエリとまったく同じではない場合がありますが、かなり近いものになります。 このケースでは、SalesOrderHeader テーブルからクエリが実行される正確な列と、その後 TotalDue フィールドを使ってそのテーブルをフィルター処理し、そのフィールドの値が 1000 より大きい行のみを取得する方法が示されています。 その横にあるノード Table.LastN は、フォールディングできないため、Power Query エンジンによってローカルで計算されます。

Note

各演算子は、クエリのスクリプトで使用される関数と正確に一致しない場合があります。

フォールディングされていないノードを確認し、変換をフォールディングするためのアクションを検討する

これで、フォールディングできなかった、ローカルで評価されるノードがどれかわかりました。 今回は Table.LastN ノードしかありませんが、他のシナリオではさらに多くなる可能性があります。

目標は、ステップをフォールディングできるようにクエリに対して変更を適用することです。 実施できる変更は、各ステップの並び替えから、データ ソースに対してより明示的な代替ロジックをクエリに適用する場合まで、さまざまです。 これは、すべてのクエリとすべての操作が変更を適用することによってフォールディング可能になるという意味ではありません。 しかし、クエリをフォールディングできるかどうか、試行錯誤によって判断することをお勧めします。

データ ソースは SQL Server データベースであるため、目標がテーブルから最新の 5 件の注文を取得することである場合は、SQL の TOP 句と ORDER BY 句を利用するのが適切な代替手段です。 SQL には BOTTOM 句が存在しないため、PowerQuery の Table.LastN 変換は SQL に変換できません。 Table.LastN ステップを削除し、次に置き換えることができます。

• テーブルの SalesOrderID 列による降順の並べ替えステップ。この列によって、どの注文が最初で、どの注文が最後に入力されたかが決定されるためです。
• 上位 5 行の選択。テーブルは並べ替えられているため、この変換は [保持された下位の行] (Table.LastN) の場合と同じ処理を実行します。

この代替手段は、元のクエリと等価です。 この代替手段は理論的には適切に見えますが、変更を行って、この代替手段によってこのノードがデータ ソースに完全にフォールディングされるかどうかを確認する必要があります。

3. クエリの変更を実施する

前のセクションで説明した代替手段を実装します。

1. [クエリ プラン] ダイアログを閉じて、Power Query エディターに戻ります。

2. [保持された下位の行] ステップを削除します。

3. SalesOrderID 列を降順に並べ替えます。

   

4. データ プレビュー ビューの左上隅にあるテーブル アイコンを選択し、[上位の行の保持] と表示されたオプションを選択します。 ダイアログで、引数として数値 5 を渡し、[OK] を選択します。

   

変更を実装した後、クエリ フォールディング インジケーターをもう一度確認し、フォールディング インジケーターが表示されるかどうかを確認します。

次に、最後のステップのクエリ プランを確認します。これは [上位の行の保持] になっています。 現在は、フォールディングされたノードしかありません。 Value.NativeQuery の下にある [詳細の表示] を選択して、データベースに送信されるクエリを確認します。

この記事では適用すべき代替手段を提案していますが、主な目標は、お客様がクエリ プランを使ってクエリのフォールディングを調査する方法を学習することです。 また、この記事では、データ ソースに送信される内容と、ローカルで実行される変換も示しています。

お客様は、ご自分のコードを調整し、それがクエリに与える影響を確認できます。 クエリ フォールディング インジケーターを使用すると、どのステップがクエリのフォールディングを妨げているかをよりよく理解できます。