テーブル レベルのストレージで DirectQuery モデルを最適化する
DirectQuery は、Power BI Desktop にデータを取り組む方法の 1 つです。 DirectQuery メソッドでは、Power BI Desktop データベース内からソース リポジトリのデータに直接接続します。 これは、データを Power BI Desktop にインポートする代替手段です。
DirectQuery のメソッドを使用する場合、全体的なユーザー エクスペリエンスは、基になるデータ ソースのパフォーマンスによって大きく異なります。 クエリの応答時間が遅いとユーザー エクスペリエンスが低下し、最悪のシナリオではクエリがタイム アウトする場合があります。また、どの時点においても、レポートを開いているユーザー数はデータ ソースに与える負荷に影響します。 たとえば、レポート内のビジュアル数が 20 で、そのレポートを使用しているユーザー数が 10 人である場合、各ビジュアルは 1 つ以上のクエリを発行するため、データ ソース上には 200 を超えるクエリが存在します。
残念ながら、Power BI モデルのパフォーマンスは、基になるデータ ソースのパフォーマンスだけでなく、次のような他の制御できない要因によっても影響されます。
ネットワーク待機時間: ネットワークの速度が速いほど、データは早く返されます。
データ ソースのサーバーのパフォーマンスとそのサーバー上にある他のワークロードの数: たとえば、数百人ものユーザーがさまざまな理由で同じサーバーを使用しているときにサーバーの更新が行われた場合の影響について考えてみてください。
このため、DirectQuery を使用すると、モデルのパフォーマンス品質にリスクをもたらします。 このような状況でパフォーマンスを最適化するには、ソース データベースを制御するか、またはこれにアクセスする必要があります。
詳細については、Power BI Desktop の DirectQuery モデルのガイダンスを参照してください。
DirectQuery を使用する意義
ベスト プラクティスは、データを Power BI Desktop にインポートすることですが、次のいずれかの理由 (DirectQuery のメリット) により、組織で DirectQuery データ接続モードを使用する必要がある場合があります。
これは、データが頻繁に変更され、ほぼリアルタイムのレポートが必要な場合に適しています。
これは、事前に集計する必要なく、大きなデータを処理できます。
これは、データ主権制限を適用して法的要件に準拠します。
これは、多次元データ ソース SAP Business Warehouse (BW) などのメジャーを含む多次元データ ソースで使用できます。
組織で DirectQuery を使用する必要がある場合は、Power BI Desktop 内でのその動作を明確に理解し、その制限を認識する必要があります。 そうすれば、DirectQuery モデルを可能な限り最適化するための措置を講じることができます。
DirectQuery 接続の動作
DirectQuery を使用して Power BI Desktop のデータに接続した場合、その接続は次のように動作します。
最初に Power BI Desktop のデータを取得機能を使用する場合、ソースを選択します。 リレーショナル ソースに接続する場合は、テーブルのセットを選択でき、各テーブルには、データのセットを論理的に返すクエリが定義されます。 SAP BW などの多次元ソースを選択する場合は、ソースのみを選択できます。
データを読み込むと、Power BI Desktop にデータはインポートされず、スキーマのみ読み込まれます。 Power BI Desktop 内でビジュアルを構築すると、クエリが基になるソースに送信され、必要なデータが取得されます。 ビジュアルの更新にかかる時間は、基になるデータ ソースのパフォーマンスによって異なります。
基になるデータに変更が加えた場合、キャッシュにより、Power BI の既存のビジュアルには即座に反映されません。 これらの変更を確認するには、更新を実行する必要があります。 必要なクエリが各ビジュアルに表示され、それに応じてビジュアルが更新されます。
レポートを Power BI サービスに公開すると、インポートの場合と同様に、Power BI サービスにセマンティック モデルが生成されます。 ただし、そのセマンティック モデルにデータは含まれません。
既存のレポートを Power BI サービスで開く、または新しいレポートを作成すると、基になるソースが再度クエリされ、必要なデータが取得されます。 元のソースの場所によっては、オンプレミス データ ゲートウェイの構成が必要になる場合があります。
ビジュアルまたはレポート ページ全体をダッシュボード タイルとしてピン留めすることができます。 タイルは、1 時間ごとなどのスケジュールに基づいて自動的に更新されます。 この更新の頻度を制御して、要件を満たすことができます。 ダッシュボードを開くと、前回の更新時のデータがタイルに反映されますが、基になるデータ ソースに対して加えられた最新の変更が反映されていないことがあります。 開いているダッシュボードを常に最新の状態に更新できます。
DirectQuery 接続の制限
DirectQuery を使用すると、悪影響が生じる可能性があります。 制限は、使用されている特定のデータ ソースによって異なります。 次の点を考慮する必要があります。
パフォーマンス - 既に説明したように、全体的なユーザー エクスペリエンスは、基になるデータ ソースのパフォーマンスに大きく依存します。
セキュリティ - DirectQuery モデルで複数のデータ ソースを使用する場合は、基になるデータ ソース間でデータがどのように移動するか、また、関連するセキュリティへの影響を把握することが重要です。 また、Power BI ではすべてのユーザーがデータを表示できるため、セキュリティ ルールを基になるソースのデータに適用できるか識別する必要があります。
データ変換 - インポート データと比較した場合、Power Query エディター内のデータ変換手法の適用に関して言えば、DirectQuery から取得されたデータには制限があります。 たとえば、SAP BW などの OLAP ソースに接続する場合、変換は一切できません。外部モデル全体がデータ ソースから取得されます。 データを変換する場合は、基になるデータ ソースでこれを行う必要があります。
モデリング - DirectQuery を使用する場合、インポートしたデータで使用できるモデリング機能の一部が使用できないか、制限されます。
レポート - 基になるソースによって適切なレベルのパフォーマンスが提供されている場合は、インポートしたデータで使用できるほとんどすべてのレポート機能が DirectQuery モデルでもサポートされます。 ただし、レポートを Power BI サービスに公開する場合、クイック分析情報および Q&A 機能はサポートされません。 また、Excel のエクスプローラー機能を使用すると、パフォーマンスが低下する可能性があります。
DirectQuery の使用に関する制限事項の詳細については、DirectQuery を使用する意義を参照してください。
DirectQuery の動作とそれによって生じる制限事項について簡単に理解できたので、パフォーマンスを向上させるための対策を講じることができます。
パフォーマンスを最適化する
引き続き Tailwind Traders のシナリオで、セマンティック モデルのレビューの際に、クエリで DirectQuery を使用して Power BI Desktop をソース データに接続したことがわかります。 この DirectQuery の使用が、レポートのパフォーマンスが低下している原因です。 レポート内のページの読み込みに時間がかかりすぎるため、特定の選択が行われたときにテーブルがすばやく更新されません。 DirectQuery モデルのパフォーマンスを最適化するには、措置を講じる必要があります。
基になるソースに送信されているクエリを確認し、クエリのパフォーマンスが低下している理由を特定することができます。 その後で、Power BI Desktop と基になるデータ ソースに変更を加え、全体的なパフォーマンスを最適化できます。
Power BI Desktop でデータを最適化する
データ ソースをできる限り最適化すると、パフォーマンス アナライザーを使用して Power BI Desktop 内でさらにアクションを実行することができます。その際、クエリを分離してクエリ プランを検証することができます。
基になるソースに送信されているクエリの継続時間を分析して、読み込みに長時間かかっているクエリを特定できます。 つまり、どこにボトルネックが存在するかを特定できます。
DirectQuery モデルを最適化するときに、特別なアプローチを使用する必要はありません。インポートしたデータで使用したのと同じ最適化手法を適用して、DirectQuery ソースのデータを調整できます。 たとえば、レポート ページ上のビジュアルの数を減らしたり、ビジュアルで使用されるフィールドの数を減らしたりすることができます。 不要な列と行を削除することもできます。
DirectQuery クエリを最適化する方法の詳細なガイダンスについては、Power BI Desktop の DirectQuery モデルのガイダンスと DirectQuery を正常に使用するためのガイダンスを参照してください。
基になるデータソースを最適化する (接続されたデータベース)
最初の対象はデータ ソースです。 ソース データベースのパフォーマンスを向上させるために実行することにより Power BI DirectQuery のパフォーマンスが向上するため、そのソース データベースをできる限り調整する必要があります。 データベースで講じる措置は、最も効果的に働きます。
ほとんどの状況に適用される次の標準的なデータベース プラクティスを使用することを検討してください。
計算式はソース クエリに埋め込まれるため、複雑な計算列を使用しないようにしてください。 プッシュ ダウンが回避されるため、式をソースに戻す方が効率的です。 また、代理キー列を分析コード タイプ テーブルに追加することもできます。
インデックスを確認し、現在のインデックスが正しいことを検証します。 新しいインデックスを作成する必要がある場合は、それらが適切であることを保証します。
データ ソースのガイダンス ドキュメントを参照し、パフォーマンスに関するレコメンデーションを実装します。
クエリを減らすオプションをカスタマイズする
Power BI Desktop には、結果として生じるクエリの実行時間が長い場合に、クエリの送信数を少なくし、エクスペリエンスの低下につながる特定の対話を無効にするオプションが用意されています。 これらのオプションを適用すると、データ ソースがクエリから絶え間なくヒットされることがなくなり、パフォーマンスが向上します。
この例では、既定の設定を編集して、使用可能なデータ削減オプションをモデルに適用します。 この設定にアクセスするには、ファイル > オプションと設定 > オプション を選択し、ページをしたにスクロールして、クエリを減らす オプションを選択します。
クエリを減らす次のオプションを利用できます:
次によって送信されるクエリの数を減らす - 既定で、すべてのビジュアルが他のすべてのビジュアルと相互作用します。 このチェック ボックスをオンにすると、既定の相互作用が無効になります。 必要に応じて、相互作用を編集 機能を使用して、相互作用するビジュアルを選択できます。
スライサー - 既定で、スライサーの変更をすぐに適用する オプションが選択されています。 レポート ユーザーがスライサーの変更を手動で適用するように強制するには、各スライサーに [適用] ボタンを追加して、準備ができたら変更を適用する オプションを選択します。
フィルター - 既定で、基本フィルターの変更をすぐに適用する オプションが選択されています。 レポート ユーザーに手動でのフィルターの変更を適用させるには、次のいずれかの代替オプションを選択します。
すべての基本フィルターに [適用] ボタンを追加して、準備ができたら変更を適用する
一度に変更を適用するための 1 つの [適用] ボタンをフィルター ウィンドウに追加する (プレビュー)
