Power BI の最適化ガイド

  • [アーティクル]

この記事では、開発者と管理者が、最適化された Power BI ソリューションを作成および維持できるようにするためのガイダンスを提供します。 ソリューションは、さまざまなアーキテクチャ レイヤーで最適化することができます。 次のようなレイヤーがあります。

  • データ ソース
  • データ モデル
  • 視覚化 (ダッシュボード、Power BI レポート、Power BI のページ分割されたレポートなど)
  • 環境 (容量、データ ゲートウェイ、ネットワークなど)

データ モデルの最適化

データ モデルでは、視覚化エクスペリエンス全体がサポートされています。 データ モデルは、Power BI エコシステムまたは外部 (DirectQuery またはライブ接続を使用) でホストされ、Power BI では "セマンティック モデル" (以前はデータセットと呼ばれていました) と呼ばれます。 選択肢を理解し、ご自分のソリューションに適したセマンティック モデルの種類を選択することが重要です。 インポート、DirectQuery、複合の 3 つのセマンティック モデル モードがあります。 詳細については、「Power BI サービスのセマンティック モデル」および「Power BI サービスのセマンティック モデル モード」を参照してください。

特定のセマンティック モデル モードのガイダンスについては、次を参照してください。

視覚化の最適化

Power BI の視覚化には、ダッシュボード、Power BI レポート、または Power BI のページ分割されたレポートがあります。 それぞれアーキテクチャが異なるため、それぞれに対して個別のガイダンスを示します。

ダッシュボード

Power BI では、ダッシュボードのタイルのキャッシュが保持されることを理解しておくことが重要です。ただし、ライブ レポート タイルとストリーミング タイルは除きます。 お使いのセマンティック モデルで動的な行レベルのセキュリティ (RLS) が適用される場合は、タイルがユーザー単位でキャッシュされるため、パフォーマンスへの影響があることを理解しておく必要があります。

ライブ レポート タイルをダッシュボードにピン留めしても、それらがクエリ キャッシュから提供されることはありません。 代わりに、それらはレポートのように動作し、仮想コアに対してすぐにクエリを実行します。

名前からわかるように、キャッシュからデータを取得することで、データ ソースに依存するよりも優れた、より一貫性のあるパフォーマンスが実現できます。 この機能を活用するための 1 つの方法は、ダッシュボードをユーザーのための最初のランディング ページにすることです。 よく使用され、頻繁に要求されるビジュアルをダッシュボードにピン留めします。 こうすることで、ダッシュボードが貴重な "防御の最前線" となり、容量の負荷を抑え、一貫したパフォーマンスを実現することができます。 ユーザーは引き続き、レポートをクリックして詳細情報を分析することができます。

DirectQuery とライブ接続のセマンティック モデルの場合、キャッシュはデータ ソースにクエリを実行することで定期的に更新されます。 既定では、これは 1 時間ごとに実行されますが、セマンティック モデルの設定で異なる頻度を構成することもできます。 キャッシュの各更新では、キャッシュを更新するために基になるデータ ソースに対してクエリが送信されます。 生成されるクエリの数は、データ ソースに依存するダッシュボードにピン留めされたビジュアルの数によって異なります。 行レベルのセキュリティが有効になっている場合は、異なるセキュリティ コンテキストごとにクエリが生成されることに注意してください。 たとえば、ユーザーを分類する 2 つの異なるロールがあり、それらには 2 つの異なるデータのビューがあるとします。 クエリ キャッシュの更新中に、Power BI によって 2 つのセットのクエリが生成されます。

Power BI レポート

Power BI レポートのデザインを最適化するには、いくつかの推奨事項があります。

Note

レポートが DirectQuery セマンティック モデルに基づいている場合、さらなるレポート デザインの最適化については、Power BI Desktop の DirectQuery モデルのガイダンス (レポートのデザインを最適化する) に関する記事を参照してください。

最も制限の厳しいフィルターを適用する

ビジュアルで表示しなければならないデータが増えると、ビジュアルの読み込みがそれだけ遅くなります。 これは当然の原則であるように思われますが、忘れがちなことです。 たとえば、大規模なセマンティック モデルがあるとします。 そのセマンティック モデルに基づいて、テーブルを使用してレポートを作成します。 エンド ユーザーは、ページ上のスライサーを使用して目的の行に到達します。通常、関心があるのは数十の行だけです。

よくある間違いは、テーブルの既定のビューをフィルター処理しないことです。つまり、1 億を超えるすべての行が表示されます。 これらの行のデータはメモリに読み込まれ、更新のたびに圧縮解除されます。 この処理により、メモリの需要が大量に発生します。 解決策: "上位 N" のフィルターを使用して、テーブルに表示される項目の最大数を減らします。 項目の最大数は、ユーザーが必要とする数より大きくする (10,000 など) ことができます。 その結果、エンドユーザー エクスペリエンスが変わることはありませんが、メモリ使用量が大幅に低下します。 そして、最も重要なこととして、パフォーマンスが向上します。

レポート内のすべてのビジュアルに対して、上記と似たようなデザインのアプローチを使用することをお勧めします。 このビジュアルのデータはすべて必要かどうか、 エンドユーザー エクスペリエンスへの影響を最小限に抑えながら、ビジュアルに表示されるデータの量をフィルター処理する方法はありますか。 テーブルには特にコストがかかる場合があることを忘れないでください。

レポート ページのビジュアルを制限する

上記の原則は、レポート ページに追加するビジュアルの数にも同様に当てはまります。 特定のレポート ページ上のビジュアルの数を、必要な分だけに制限することを強くお勧めします。 ドリルスルー ページとレポート ページのヒントは、ページにさらに多くのビジュアルを詰め込むことなく、追加の詳細情報を表示するための優れた方法です。

カスタム ビジュアルのパフォーマンスを評価する

高パフォーマンスを得るため、必ず各カスタム ビジュアルの性能を試します。 適切に最適化されていない Power BI ビジュアルは、レポート全体のパフォーマンスに悪影響を及ぼす場合があります。

Power BI のページ分割されたレポート

Power BI のページ分割されたレポートのデザインを最適化するには、レポートのデータ取得に対してベスト プラクティスのデザインを適用します。 詳細については、「ページ分割されたレポートでのデータ取得のガイダンス」をご覧ください。

また、ご使用の容量で、ページ分割されたレポート ワークロードに十分なメモリが割り当てられていることを確認してください。

環境の最適化

容量設定の構成、データ ゲートウェイのサイズ変更、およびネットワーク待機時間の短縮により、Power BI 環境を最適化することができます。

容量の設定

容量 (Power BI Premium (P SKU)、Premium Per User (PPU) ライセンス、または Power BI Embedded (A SKU、A4-A6) で利用可能) を使用する場合は、容量の設定を管理できます。 詳細については、「Microsoft Fabric 容量ライセンス」と「Premium 容量の管理」を参照してください。

重要

この記事では、Power BI Premium またはその容量サブスクリプション (P SKU) に言及することがあります。 現在、Microsoft は購入オプションを統合し、容量あたりの Power BI Premium SKU を廃止していることに注意してください。 新規および既存のお客様は、代わりに Fabric 容量サブスクリプション (F SKU) の購入をご検討ください。

詳細については、「Power BI Premium ライセンスに関する重要な更新」と「Power BI Premium のよく寄せられる質問」を参照してください。

ゲートウェイのサイズ設定

インターネット経由で直接アクセスできないデータに Power BI がアクセスする必要がある場合は、常にゲートウェイが必要です。 オンプレミスのサーバー、または VM でホストされるサービスとしてのインフラストラクチャ (IaaS) に、オンプレミス データ ゲートウェイをインストールすることができます。

ゲートウェイのワークロードとサイズ設定の推奨事項について理解するには、「オンプレミス データ ゲートウェイのサイズ設定」をご覧ください。

ネットワーク待機時間

ネットワーク待機時間は、要求が Power BI サービスに到達するまでに要する時間と、応答の配信に要する時間が増えることで、レポートのパフォーマンスに影響を及ぼす可能性があります。 Power BI のテナントは、特定のリージョンに割り当てられています。

ヒント

ご自身のテナントが配置されている場所を特定するには、「Power BI テナントの場所」をご覧ください。

テナントのユーザーが Power BI サービスにアクセスすると、要求は常にこのリージョンにルーティングされます。 要求が Power BI サービスに到達すると、サービスからさらに要求が送信されることがあります (たとえば、基になるデータ ソースやデータ ゲートウェイに対して)。これもネットワーク待機時間の影響を受けます。

Azure Speed Test などのツールによって、クライアントと Azure リージョン間のネットワーク待機時間の表示が提供されます。 一般に、ネットワーク待機時間の影響を最小限に抑えるには、データ ソース、ゲートウェイ、および Power BI 容量をできるだけ近くに配置するようにします。 可能であれば、それらを同じリージョン内に配置します。 ネットワーク待機時間が問題になっている場合は、ゲートウェイとデータ ソースをクラウドでホストされる仮想マシン内に配置することで、Power BI 容量により近い位置に配置してみてください。

パフォーマンス監視

パフォーマンスを監視して、ボトルネックを特定することができます。 低速なクエリ (またはレポート ビジュアル) は、継続的な最適化の中心点にする必要があります。 監視は、デザイン時に Power BI Desktop で、または Power BI Premium 容量の運用ワークロードで行うことができます。 詳細については、Power BI でのレポートのパフォーマンスの監視に関する記事をご覧ください。

関連するコンテンツ

この記事に関する詳細については、次のリソースを参照してください。