次の方法で共有

Power BI の最適化ガイド

  • [アーティクル]

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

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

データ モデルの最適化

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

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

レポート作成者とモデル コンシューマー向けの最適化

セマンティック モデルは、Power BI のすべてのレポートの基盤です。 セマンティック モデルのコンシューマーは、パブリッシュされたセマンティック モデルに接続するか、データに接続してローカル セマンティック モデルを作成することで、Power BI Desktop で Power BI レポートを作成できます。 セマンティック モデルを使用して、ブラウザーで Power BI レポートを作成することもできます。 Power BI 探索の作成、の作成、DAX クエリの作成、Excel での Analyze を使用した Excel でのレポートの作成、Excel の Power BI への接続 レポート ビジュアルからのデータのエクスポートその他の多くのレポート ツールの作成を行います。 セマンティック モデルの作成者は、セマンティック モデルのコンシューマーが、モデルを構築する方法と共にセマンティック モデルを理解し、利用するのに役立ちます。

  • 名前: セマンティック モデル内のテーブル、列、メジャーとわかりやすい名前。 たとえば、テーブル名としての "Store Sales" は 、'Table1' よりも直感的です。
  • 説明: モデル内のテーブル、列、メジャーに説明を追加して、名前に収まらない詳細を提供できます。 含まれる内容だけでなく、その使用方法について説明します。
  • 非表示: モデル内のテーブル、列、メジャーを非表示にして、レポートで使用する予定のテーブル、列、メジャーのみを表示できます。 たとえば、リレーションシップ列はレポートに必要なく、レポートで使用されることが想定されていないため非表示にできる ID である場合や、列を集計するメジャーがあるデータ列を非表示にして、代わりにメジャーの使用を促すことができます。 非表示のオブジェクトは、モデル コンシューマーによって後でいつでも非表示にできるため、引き続き使用できますが、非表示にするとフォーカスが得られる場合があります。
  • 階層: 階層を作成して、複数の列にわたって階層を伝達できます。 たとえば、カレンダー階層には年、月、日の列を含め、製品階層にはカテゴリ、サブカテゴリ、製品の列を含める場合があります。 列を右クリックして階層を作成します。
  • メジャー: 測定 を使用してセマンティック モデルのデータ列を集計し、レポート間の一貫性を提供できます。 メジャーの範囲は、列の SUM から、特定の方法で複数の集計を組み合わせた正常性インデックス、または今月の 1 日の平均など、期間全体の集計を比較する正常性インデックスまで、前年の同じ月の日次平均と比較できます。 メジャーは、Power BI 検索やその他の機能 ( Metrics やスコアカードなどでも表示できます。
  • 形式: 列またはメジャーをビジュアルに表示する方法を既定で指定できます。 ビジュアル内の値は、ビジュアル内でさらにカスタマイズできます。 書式オプションには、コンマが 1,000 個ある場合、小数点以下の桁数、日付の表示方法などが含まれます。 custom または dynamic 形式を適用することもできます。
  • データ カテゴリ: 列 データ カテゴリ (国または Web URL など) を指定できます。

これらは Power BI セマンティック モデルの一般的な機能であり、レポート作成者とモデル コンシューマーを支援するために利用できます。 他にも、 計算グループ、 フィールド パラメーター、 if パラメーター、 グループ化列とビン分割列などがあります。これらは、特定のレポートのニーズを適用するかどうかを評価する必要があります。

視覚化の最適化

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 でのレポートのパフォーマンスの監視に関する記事をご覧ください。

関連するコンテンツ

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