Power BI パフォーマンスの最適化: DAX、モデル、クエリ

読み込みに 15 秒かかる Power BI レポートは、ユーザーが使用しなくなるレポートです。パフォーマンスは技術的な美しさではなく、BI の導入と BI の放棄の違いです。レポートの読み込み時間が 1 秒ごとに発生すると、ユーザーのエンゲージメントが大幅に減少します。調査によると、インタラクティブなダッシュボード (読み込み時間 3 秒未満) は遅いダッシュボード (10 秒以上) よりも 4 ～ 5 倍多くのビューを受け取り、一貫した遅さを経験したユーザーは 30 日以内に手動プロセスに戻ることが一貫して示されています。

幸いなことに、Power BI のパフォーマンスの問題はほとんどの場合解決可能です。何百もの Power BI 環境を最適化した経験から、パフォーマンスの問題の 90% は、非効率な DAX 対策、過大なデータ モデル、不十分なリレーションシップ設計、DirectQuery の不適切な使用、またはワークロードの容量不足という 5 つの根本原因のいずれかに起因します。このガイドでは、これらの各問題を診断して解決するための体系的なアプローチを提供します。

Power BI 環境で、チームが内部で解決できないパフォーマンスの問題が発生している場合は、Power BI パフォーマンス最適化サービス が実践的な分析と修復を提供します。

重要なポイント

• Power BI Desktop のパフォーマンス アナライザーは、どのビジュアルとクエリが遅いかを特定します --- 最適化する前に、常にここから開始してください
• DAX Studio は、遅いクエリがストレージ エンジン (データ スキャン) またはフォーミュラ エンジン (計算) でボトルネックになっているかどうかを明らかにします --- 修正方法は大幅に異なります
• 最も一般的な DAX パフォーマンスの間違いは、不必要な CALCULATE ネスト、アグリゲータで十分な場合のイテレータの使用、および大きな中間テーブルの具体化です。
• モデル サイズはパフォーマンスに直接影響します。未使用の列を削除し、カーディナリティを削減し、データ型を最適化すると、モデルを 40 ～ 70% 縮小できる可能性があります。
• 集計テーブルは、概要データを事前に計算することにより、大規模なデータセットのクエリ パフォーマンスを 10 ～ 100 倍向上させます。
• DirectQuery は対話型レポートのインポート モードより 10 ～ 100 倍遅い --- データの鮮度要件が本当に必要な場合にのみ使用してください
• 文書化されたメトリクスを使用したベンチマークの前後は、最適化の影響を証明し、回帰を防ぐために不可欠です

---

診断ツールと方法論

パフォーマンスアナライザー

パフォーマンス アナライザーは、Power BI Desktop の組み込み診断ツールです。レポート ページ上のすべてのビジュアルによって生成されたすべてのクエリの実行時間を記録し、時間を次の 3 つの要素に分類します。

パフォーマンス アナライザーの使用方法:

1. Power BI Desktop でレポートを開きます。
2. [表示] > [パフォーマンス アナライザー] に移動します。
3. 「録音開始」をクリックします。
4. レポートを操作します (フィルターの変更、ページの移動、スライサーの適用)。 5.「停止」をクリックします。
5. 合計期間でソートされた結果を確認します。

結果の解釈:

• DAX クエリ時間が支配的である場合、問題はメジャーまたはモデルにあります。より詳細な分析には DAX Studio を使用します。
• ビジュアル表示時間が支配的である場合、問題はビジュアル構成にあります (データ ポイントが多すぎる、複雑な条件付き書式設定、またはパフォーマンスの低いカスタム ビジュアル)。
• 「その他」の時間が大半を占めている場合、問題はインフラストラクチャ (DirectQuery のネットワーク遅延、ゲートウェイのボトルネック、または容量調整) にあります。

ほとんどの人がスキップする重要な手順: パフォーマンス アナライザーから DAX クエリをコピーし (右クリック > [クエリのコピー])、DAX Studio に貼り付けます。パフォーマンス アナライザーは、どのビジュアルが遅いかを示します。 DAX Studio がその理由を説明します。

DAX スタジオ

DAX Studio は、Power BI の基盤となる Analysis Services エンジンに詳細な診断機能を提供する無料のオープンソース ツールです。これは、Power BI パフォーマンス エンジニアのツールキットの中で最も重要なツールです。

DAX Studio の主要な機能:

サーバー タイミング: ストレージ エンジン (SE) とフォーミュラ エンジン (FE) のクエリ時間の内訳を示します。

• ストレージ エンジン (SE) クエリ は、カラム型ストレージ (VertiPaq エンジン) に対して実行されるデータ スキャンです。これらは高度に並列化されており、高速です。 SE クエリは、トレース内では xmSQL ステートメントとして表示されます。
• Formula Engine (FE) 操作は、SE クエリの結果に対して実行されるシングルスレッド計算です。 FE 操作は、ほとんどの低速 DAX 対策における主なボトルネックです。

最適化の目標は、できる限り多くの作業をストレージ エンジンにプッシュし、フォーミュラ エンジンの操作を最小限に抑えることです。

クエリ プラン: DAX Studio では、エンジンがメジャーをどのように処理するかを正確に示す論理クエリ プランと物理クエリ プランを表示できます。上級ユーザーにとって、クエリ プランは、タイミング データだけでは見えない最適化の機会を明らかにします。

VertiPaq Analyzer: データ モデル全体をスキャンし、すべてのテーブルのすべての列の列サイズ、カーディナリティ、エンコード タイプ、辞書サイズをレポートします。これは、モデルを膨張させている大きすぎる列やテーブルを特定する方法です。

体系的な最適化手法

1. ベースライン: パフォーマンス アナライザーを使用して、すべてのページの読み込み時間を記録します。ドキュメント モデルのサイズ ([ファイル] > [情報] > [ファイル サイズの削減] > [分析])。プレミアム/ファブリック上の場合は、容量メトリックを記録します。

2. 識別: パフォーマンス アナライザーの結果を合計期間で並べ替えます。最も遅い上位 5 つのビジュアルに注目します。これらは、最適化すると最も大きな影響を与えます。

3. 診断: 遅いクエリをそれぞれ DAX Studio にコピーします。 SE と FE の時間を分析します。 FE ボトルネックの原因となっている特定の DAX パターンを特定します。

4. 最適化: 対象を絞った修正を適用します (詳細は以下で説明します)。各変更を個別にテストして、その影響を測定します。

5. 検証: パフォーマンス アナライザーを再実行し、ベースラインと比較します。最適化ごとに改善点を文書化します。

6. 監視: 継続的なパフォーマンス監視 (容量メトリクス、ユーザーから報告された問題、定期的なパフォーマンス アナライザー チェック) を設定して、回帰を防止します。

---

遅い DAX パターンと修正

パターン 1: 不要な CALCULATE のネスト

問題:

Bad Measure =
CALCULATE(
    CALCULATE(
        SUM(Sales[Amount]),
        FILTER(ALL(Products), Products[Category] = "Electronics")
    ),
    Date[Year] = 2025
)

ネストされた CALCULATE ステートメントは処理能力を追加しません。混乱を招き、場合によってはパフォーマンスのオーバーヘッドを追加します。 CALCULATE ごとに新しいフィルター コンテキストが作成され、それらをネストすると予期しない結果が生成され、フォーミュラ エンジンに冗長なコンテキスト遷移の実行が強制される可能性があります。

修正:

Good Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics",
    Date[Year] = 2025
)

フィルター引数を単一の CALCULATE に結合します。複数のフィルター引数が同時に適用されます (交差)。これにより、よりクリーンな実行でも同じ結果が得られます。

パターン 2: 直接列フィルターの代わりに ALL を使用した FILTER

問題:

Slow Measure =
CALCULATE(
    SUM(Sales[Amount]),
    FILTER(ALL(Products), Products[Category] = "Electronics")
)

FILTER(ALL(Products), ...) エンジンは数式エンジン内の Products テーブル全体を強制的に実体化し、すべての行を反復処理してフィルターを適用します。数百万行のテーブルの場合、これは非常に遅くなります。

修正:

Fast Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics"
)

CALCULATE の直接列フィルターはストレージ エンジンで解決されるため、桁違いに高速になります。 FILTER は、単純な列比較として表現できない複雑な条件を適用する必要がある場合にのみ使用します (メジャー値でのフィルター処理や、複数の列を含む条件など)。

経験則: FILTER 条件が単純な比較で単一の列を参照している場合は、それを直接 CALCULATE フィルター引数に置き換えます。本当に複雑な条件のために FILTER を予約してください。

パターン 3: アグリゲータで十分なイテレータ

問題:

Slow Total = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])

SUMX は Sales テーブルのすべての行を反復処理し、数式エンジンの各行の式を評価します。 1,000 万行の Sales テーブルの場合、これは 1,000 万回の FE 操作を意味します。

修正:

計算が 2 つの列の単純な乗算である場合は、計算列として事前に計算します。

-- Add calculated column: Sales[LineTotal] = Sales[Quantity] * Sales[UnitPrice]
-- Then use aggregator:
Fast Total = SUM(Sales[LineTotal])

SUM はストレージ エンジンで動作し、高度に最適化されたバッチで列データを処理します。計算列によりモデルのサイズは増加しますが、クエリ時間が大幅に短縮されます。

SUMX を使用する場合: 行レベルの条件ロジックが必要な場合 (SUMX(Sales, IF(Sales[Type] = "Return", -Sales[Amount], Sales[Amount])) など)、または小さなテーブル (数百万ではなく数千の行を含むディメンション テーブル) を反復処理する場合は、SUMX を使用します。

パターン 4: 大規模な中間テーブル

問題:

Slow Measure =
SUMX(
    SUMMARIZE(Sales, Products[Category], Date[Month]),
    [Complex Calculation]
)

SUMMARIZE は、数式エンジンに中間テーブルを作成します。カテゴリと月の組み合わせで 10,000 行が生成され、[複雑な計算] が行ごとに追加の SE クエリをトリガーすると、結果は 10,000 を超えるクエリになり、「SE クエリ ストーム」として知られる壊滅的なパフォーマンス パターンになります。

修正:

Fast Measure =
VAR SalesTable =
    ADDCOLUMNS(
        SUMMARIZE(Sales, Products[Category], Date[Month]),
        "@SubTotal", CALCULATE(SUM(Sales[Amount]))
    )
RETURN
    SUMX(SalesTable, [@SubTotal] * [SomeMultiplier])

ADDCOLUMNS 内で小計を具体化することで (コンテキスト遷移を効率的に使用します)、その後の @SubTotal への参照によって追加の SE クエリがトリガーされることはありません。変数 (VAR) を使用すると、テーブルが複数回参照された場合でも、確実に 1 回だけ評価されます。

パターン 5: 行レベルのセキュリティ パフォーマンスへの影響

問題:

複雑な DAX 式を使用した RLS はすべてのクエリを評価し、ビジュアル全体にわたってオーバーヘッドが追加されます。 RLS ルールが適切に記述されていないと、レポートの読み込み時間が 2 倍または 3 倍になる可能性があります。

一般的な RLS パフォーマンスの低下要因:

• RLS フィルターの LOOKUPVALUE (行ごとに FE 評価を強制します)
• 大きなテーブルでの CONTAINS または IN 演算子
• 単純な列フィルターではなくメジャーを参照する RLS ルール
• クロスフィルター方向の問題を伴うマルチテーブル RLS

修正:

• 単純な列比較を使用します: [TenantId] = USERNAME() または [Region] IN VALUES(SecurityTable[Region])
• 直接的な関係を持つ専用のディメンション テーブルでセキュリティ マッピングを事前計算します
• RLS ルールでの対策を避ける --- 列レベルのフィルターのみを使用する
• RLS がアクティブな場合とない場合のクエリ時間を比較することで、DAX Studio で RLS のパフォーマンスをテストします

---

モデル サイズの縮小

モデルのサイズが重要な理由

Power BI インポート モードでは、データを高度に圧縮された列形式 (VertiPaq エンジン) で保存します。モデルのサイズは以下に直接影響します。

• メモリ消費量: モデル全体がメモリに収まる必要があります。プレミアム/ファブリックでは、より大きなモデルはより多くの容量を消費し、メモリ プレッシャー スロットリングを引き起こす可能性があります。
• 更新期間: モデルが大きいほど、より多くのデータを処理、圧縮、ロードする必要があるため、更新に時間がかかります。
• クエリ パフォーマンス: モデルが大きくなるとスキャンも大きくなり、適切に最適化された DAX であってもクエリ時間が増加します。
• ファイル サイズ: モデルが大きい PBIX ファイルは、保存、公開、ダウンロードに時間がかかります。

モデル サイズの寄与者の特定

DAX Studio の VertiPaq Analyzer ([詳細] > [メトリクスの表示]) を使用して、最大のテーブルと列を特定します。

最適化手法

未使用の列を削除します:

最も大きな影響を与える単一の最適化。モデル内のすべての列は、使用されているかどうかに関係なくメモリを消費します。モデルを監査し、ビジュアル、メジャー、リレーションシップ、または RLS ルールで参照されていない列を削除します。

一般的な影響: モデル サイズが 20 ～ 40% 削減されます。

テキスト列のカーディナリティを減らす:

多くの一意の値 (説明、アドレス、メモ) を含むテキスト列は、あまり圧縮されません。列が表示のみに必要な場合 (フィルタリングやグループ化ではない)、詳細専用のテーブルに移動するか、長い値を切り捨てることを検討してください。

グループ化/フィルタリングに使用される列については、バケット化を検討してください。50,000 個の一意の製品名の代わりに、個々の製品の詳細に個別の参照テーブルを使用して、500 個の製品カテゴリにグループ化します。

データ型の最適化:

• 値が整数の場合は、10 進数ではなく整数を使用します (列ごとに 50% を節約)
• 時間が必要ない場合は、DateTime の代わりに Date を使用します (カーディナリティを減らします)。
• 数値をテキストとして保存しないようにします (テキストは数値よりもはるかに圧縮率が低くなります)。
• Yes/No または True/False 列にはテキストの代わりにブール値を使用します

一般的な影響: モデル サイズが 10 ～ 20% 縮小します。

大きなテーブルを分割する:

1 億行のファクト テーブルは、アクティブ データ (当年、更新ごとにロードされる) と履歴データ (前年度、それほど頻繁にロードされない、または集計として保存される) に分割できます。これにより、モデルのサイズと更新期間の両方が短縮されます。

集計テーブル (以下で詳しく説明します):

大規模なファクト テーブルの場合、集計テーブルは、一般的にクエリされる粒度で概要データを事前計算することにより、パフォーマンスを最大に向上させます。

---

集計テーブル

集計テーブルとは

集計テーブルは、Power BI が完全な詳細テーブルをスキャンする代わりにクエリを実行する、事前に計算された概要テーブルです。ユーザーが地域別の月次収益を示すグラフを表示すると、Power BI は詳細テーブル (5,000 万のトランザクション行を含む可能性がある) ではなく、集計テーブル (10 地域 x 12 か月の 120 行を含む可能性がある) をクエリします。

集計テーブルの利点は、レポート利用者に対して透過的であることです。ユーザーは同じビジュアルと測定値を操作します。 Power BI は、クエリの粒度が一致するとクエリを自動的に集計テーブルにルーティングし、ドリルダウン クエリまたは詳細レベルのクエリの場合は詳細テーブルに転送します。

集計テーブルの設計

ステップ 1: 集計の粒度を特定します。

レポートを分析して、最も一般的なクエリの粒度を決定します。販売ダッシュボードの場合:

• ほとんどのエグゼクティブ ビジュアル クエリは月 + 地域 + 製品カテゴリ レベルで行われます
• 週 + 店舗 + 製品レベルでのマネージャーのビジュアル クエリ
• 個々のトランザクション レベルでの詳細テーブル クエリ

最もよくクエリされる粒度で 1 つまたは 2 つの集計テーブルを設計します。

ステップ 2: 集計テーブルを作成します。

Power Query で、ファクト テーブルを集計粒度でグループ化する新しいテーブルを作成します。

ステップ 3: 集計マッピングを構成します。

Power BI Desktop で、集計テーブルを選択し、 [プロパティ] > [集計の管理] に移動し、各集計列を対応する詳細テーブルの列と関数にマップします。

|集計列 |要約 |詳細コラム | |--------------||--------------|---------------| |総収益 |合計 |売上[収益] | |合計数量 |合計 |販売[数量] | |注文数 |カウント |販売[注文ID] | |地域 |グループ別 |店舗[地域] | |製品カテゴリ |グループ別 |製品[カテゴリー] | |月 |グループ別 |日付[月] |

ステップ 4: 集計テーブルを非表示にします。

ユーザーは集計テーブルを直接操作しないでください。レポート ビューから非表示にします。 Power BI は、これを自動的かつ透過的に使用します。

集約パフォーマンスへの影響

これらの改善はレポート ページ全体で複合的に行われます。 10 個のビジュアルを含むページは、それぞれが詳細テーブルではなく集計テーブルをクエリすると、30 秒ではなく 1 秒で読み込まれる可能性があります。

集計テーブルのメンテナンス

• 整合性を維持するために、詳細テーブルと同じスケジュールで集計テーブルを更新します。
• DAX Studio を使用して集計ヒット率を監視します (クエリが集計にヒットしたか、失敗したかをトレース イベントが示します)
• 追加の一般的なクエリ パターンを特定するときに、新しい集計テーブルを追加します
• ヒット率が 50% を下回る集計テーブルを削除します (十分なメリットがなくスペースを消費します)。

---

DirectQuery の最適化

DirectQuery が必要な場合

DirectQuery は、Power BI のメモリ内エンジンにデータをインポートするのではなく、ソース データベースにリアルタイムでクエリを実行します。次の場合に必要になります。

• データの鮮度要件には 1 分未満の遅延が必要です (株取引、IoT モニタリング、不正行為検出)
• データセットが Power BI のモデル サイズ制限 (Premium P1 では 10 GB、P2 では 25 GB など) を超えています。
• コンプライアンスまたはセキュリティでは、データがソース システムから決して流出しないことが必要です
• ソース データベースにはすでに広範なマテリアライズド ビューと集約インフラストラクチャが存在します

他のすべてのシナリオでは、インポート モードが強く推奨されます。インポート モードは対話型クエリの速度が 10 ～ 100 倍速く、より優れたユーザー エクスペリエンスを提供します。

DirectQuery のパフォーマンス戦略

ページごとのビジュアルの数を減らします。

DirectQuery モードの各ビジュアルは、ソース データベースに対して個別のクエリを生成します。 20 個のビジュアルを含むページでは、ページの読み込み時に 20 個の同時クエリが生成され、さらにフィルターが変更されたときに追加のクエリが生成されます。 DirectQuery ページのビジュアル数を最大 8 ～ 10 に制限します。

ソース データベースを最適化します。

Power BI は、SQL クエリ (または非 SQL ソースのネイティブ クエリ) をソースに送信します。ソース データベースのパフォーマンスはレポートのパフォーマンスに直接影響します。以下を確認してください:

• インデックスは、フィルタ、リレーションシップ、メジャーで使用されるすべての列に存在します。
• クエリされたテーブルの統計は最新です
• データベース サーバーには、運用ワークロードと同時に分析クエリを実行するのに十分な CPU とメモリが備わっています。
• 一般的なクエリ パターン用にマテリアライズド ビューまたはインデックス付きビューの作成を検討する

クエリ削減オプションを有効にします。

Power BI Desktop > オプション > クエリ削減で、次を有効にします。

• 「クロスハイライト クエリを送信しないことで、送信されるクエリの数を減らす」: ビジュアル間のクロス フィルターによって追加のクエリが生成されるのを防ぎます。
• 「各スライサーに適用ボタンを追加」: ユーザーはクエリを実行する前に複数のスライサーを調整し、クエリの総量を削減します。
• 「フィルター ペインに適用ボタンを追加」: フィルター ペインと同じ原理

デュアル ストレージ モードを戦略的に使用してください。

テーブルは、インポート モード (高速ローカル クエリ用) と DirectQuery 接続 (DirectQuery テーブルとの関係用) の両方でデータを保存する「デュアル」モードに設定できます。 DirectQuery で大きなファクト テーブルを維持しながら、ディメンション テーブル (製品、顧客、日付) をデュアル モードに設定します。これにより、ファクト テーブルのデータの鮮度を犠牲にすることなく、フィルターとスライサーのパフォーマンスが大幅に向上します。

クエリ キャッシュを実装します。

Power BI サービスのデータセット設定で「クエリ キャッシュ」を有効にします。これにより、設定可能な期間にわたってクエリ結果がキャッシュされ、同一のクエリに対してキャッシュされた結果が提供されます。クエリ キャッシュは、多くのユーザーが同じフィルターを使用して表示するダッシュボード (全社的な指標を表示するエグゼクティブ ダッシュボードなど) に特に効果的です。

---

容量パフォーマンスの監視

主要な容量メトリクス

プレミアムまたはファブリックの容量を使用している組織の場合、インフラストラクチャのパフォーマンスはレポートのデザインと同じくらい重要です。容量調整により、適切に最適化されたレポートであってもパフォーマンスが低下する可能性があります。

監視する指標:

Microsoft ファブリック キャパシティ メトリック アプリ

Microsoft は、Power BI サービスで専用の容量監視アプリを提供しています。 AppSource からインストールし、容量に接続します。それは以下を提供します:

• ワークロードの種類ごとの内訳を含むリアルタイムおよび履歴の CPU 使用率
• どの操作がスロットリングをトリガーしたかを示す対話型スロットル分析
• エビクション履歴のあるデータセットによるメモリ消費量
• パフォーマンス傾向を更新
• クエリパフォーマンスパーセンタイル

このアプリは、最適化フェーズでは毎週、定常状態では毎月レビューしてください。

容量の適切なサイジング

プロビジョニングされた容量が不足していると、スロットルが発生し、ユーザー エクスペリエンスが低下します。過剰にプロビジョニングされた容量はコストを無駄にします。適切なサイジングには、ワークロード パターンを理解する必要があります。

• ピーク使用時間: ほとんどの組織では、営業時間中は夜間に比べて 2 ～ 3 倍の負荷が発生します。ピークに合わせてサイジングを行っており、Fabric F SKU を使用している場合は、夜間に一時停止するか、営業時間外にスケールダウンすることを検討してください。
• 更新と対話型の競合: データ更新と対話型クエリは、同じ容量リソースをめぐって競合します。インタラクティブなピーク時間外に大量の更新をスケジュールします。これが不可能な場合は、更新ワークロードと対話型ワークロード用に別の容量を検討してください。
• 成長予測: 6 ～ 12 か月の成長を計画します。モデルのサイズ、ユーザー数、クエリの複雑さはすべて、時間の経過とともに増加する傾向があります。容量サイジングに 30 ～ 50% の余裕を持たせます。

---

ベンチマークの前後

ベンチマークが重要な理由

測定を行わない最適化は推測にすぎません。ベンチマークの前後で、変更によってパフォーマンスが向上したことが証明され、関係者向けに改善が定量化され、将来の回帰を検出するためのベースラインが作成されます。

ベンチマーク方法

ステップ 1: メトリクスを定義します。

ステップ 2: ベースラインを記録します。

変更を加える前に、すべてのメトリックを記録してください。パフォーマンス アナライザーを 10 回実行して、キャッシュのウォーミングと変動を考慮します。各メトリックの中央値 (P50) と 95 パーセンタイル (P95) を記録します。

ステップ 3: 変更を段階的に実装します。

一度に 1 つの最適化を実行し、変更するたびに再測定します。これにより、どの最適化が最も大きな影響を与えたかが特定され、他の部分の改善によって回帰が隠蔽されることを防ぎます。

ステップ 4: 最適化後のメトリクスを記録します。

すべての最適化が完了したら、同じ方法論を使用して同じメトリクスを記録します。結果を比較表に表示します。

ステップ 5: 継続的なモニタリングをスケジュールします。

データが増大し、新しいメジャーが追加され、新しいビジュアルが作成されると、時間の経過とともにパフォーマンスが低下します。後退を早期に発見するために、同じ方法論を使用して四半期ごとのパフォーマンス レビューをスケジュールします。

文書化された前後のメトリックによる体系的なパフォーマンスの最適化を必要とする組織に対して、ECOSIRE は、DAX Studio 分析、モデルの最適化、容量調整などの 包括的な Power BI パフォーマンス サービス を提供します。

---

高度な最適化手法

計算グループ

計算グループは、反復的なメジャー バリアントを再利用可能な計算ロジックに置き換えます。基本メジャーごとに MTD、QTD、YTD、前年度、および前年比成長の個別のメジャーを作成する代わりに、計算グループはこれらの変換を動的に適用します。

パフォーマンスの利点: モデル内のメジャーが少ないということは、メタデータのフットプリントが小さくなり、モデルの読み込みが高速になることを意味します。さらに重要なことは、計算グループは、複雑なオールインワンの測定よりもパフォーマンスが優れている傾向にある、より単純な基本測定を奨励することです。

複合モデル

複合モデルは、インポート モードと DirectQuery テーブルを 1 つのモデルに結合します。ディメンション テーブルや頻繁にクエリされるファクト テーブルにはインポート モードを使用し、インポートするには頻繁に変更される非常に大きなテーブルには DirectQuery を使用します。

パフォーマンスの利点: ディメンション ルックアップとフィルター操作はインポート速度 (マイクロ秒) で実行され、ファクト テーブル クエリは DirectQuery 速度 (数百ミリ秒から数秒) で実行されます。最終的な結果は、純粋な DirectQuery よりも大幅に優れています。

増分更新

増分更新では、データセット全体を再ロードするのではなく、更新中に新しいデータと変更されたデータのみをロードします。毎日 100,000 行のみが変更される 1 億行のテーブルの場合、増分リフレッシュによりリフレッシュ時間が 99% 短縮されます。

構成: Power Query で RangeStart パラメーターと RangeEnd パラメーターを定義します。増分更新ポリシーを構成して、更新するデータの日数/月数と保持する履歴データの量を指定します。 Power BI は、データセットを自動的にパーティション分割し、アクティブなパーティションのみを更新します。

パフォーマンスの利点: リフレッシュ期間とリフレッシュ中の容量消費が大幅に削減されます。また、ファブリック容量上の DirectQuery パーティションを使用したリアルタイム更新も有効になります。

クエリの折りたたみ

クエリ フォールディングは、Power Query 変換をソース データベースにプッシュして戻し、Power Query エンジンではなくネイティブ SQL として実行します。データベース エンジンがクエリを最適化してネイティブに実行するため、フォールド クエリははるかに高速に実行されます。

確認方法: Power Query エディターの任意のステップを右クリックし、[ネイティブ クエリの表示] が利用可能かどうかを確認します。存在する場合、クエリはそのステップにフォールドされます。グレー表示されている場合は、前のステップで折りたたみが失敗しました。

一般的なフォールディング ブレーカー: M 式を含むカスタム列、異なるソースからのテーブルのマージ、特定の変換 (ピボット、複雑な型変換)。フォールディングが中断されると、後続のすべての変換は Power Query エンジンで実行され、大規模なデータセットの場合は大幅に時間がかかります。

---

よくある質問

Power BI レポートの読み込み時間の適切な目標はどれくらいですか?

頻繁に使用するダッシュボードの場合は 3 秒未満、詳細な分析レポートの場合は 5 秒未満を目標とします。これらの目標は、Web アプリケーションに対するユーザーの期待と一致しており、エンゲージメントを高く保ちます。一貫して 10 秒を超えるレポートは、最適化のために優先順位を付ける必要があります。 DAX クエリ時間だけでなく、ユーザーの観点から読み込み時間を測定します (ネットワークとレンダリングを含む)。パフォーマンス アナライザー DAX クエリ時間とビジュアル レンダリング時間の合計は、8 ～ 10 個のビジュアルで 3 秒のページ読み込みを達成するために、各ビジュアルで 2 秒未満になるはずです。

常に DirectQuery よりもインポート モードを優先する必要がありますか?

ビジネス ユーザーが使用する対話型レポートの場合は、はい --- ほとんどの場合、インポート モードがより良い選択です。インポート モードはクエリが 10 ～ 100 倍高速で、レポート表示中にソース データベースのパフォーマンスに依存せず、DAX 関数と AI 機能の全範囲をサポートします。 DirectQuery は、1 分未満のデータの鮮度に対する真の要件がある場合、データセットがインポート サイズの制限を超えている場合、またはコンプライアンス上、データをソース システムに保持する必要がある場合にのみ使用してください。中間点として複合モデルを検討します。ディメンションと頻繁にクエリされるファクトをインポートし、リアルタイムの最新性が本当に必要なテーブルのみを DirectQuery でインポートします。

Power BI レポートのパフォーマンス監査はどのくらいの頻度で実行する必要がありますか?

製造レポートのために四半期ごとに包括的なパフォーマンス監査を実施します。監査と監査の間には、容量メトリックを毎週監視し、ユーザーから報告された遅延を直ちに調査します。即時監査をトリガーする必要がある主なイベントには、データ量の大幅な増加 (25% 以上の増加)、新しいレポート ページまたは複雑な DAX メジャーの追加、ユーザーの同時実行性の変化 (起動後のユーザーの増加)、容量の変更 (アップグレード、ダウングレード、または移行) が含まれます。

レポートを変更せずに Power BI のパフォーマンスを最適化できますか?

はい、ある程度はそうです。インフラストラクチャ レベルの最適化には、容量 SKU のアップグレード、サービス設定でのクエリ キャッシュの有効化、ピーク時間外の大量更新のスケジュール設定、スループット向上のためのゲートウェイ クラスタリングの構成、ソース データベース (インデックス、統計、マテリアライズド ビュー) の最適化が含まれます。これらの変更により、レポート ファイルに影響を与えることなくパフォーマンスが向上します。ただし、最も影響力のある最適化には通常、DAX メジャーの書き換え、モデル サイズの削減、集計テーブル、視覚的なカウントの削減といったレポート レベルの変更が含まれます。インフラストラクチャの最適化により、容量の制約に対処します。レポートの最適化により効率が向上します。

時間の経過とともに Power BI レポートが遅くなる原因は何ですか?

一般的な 5 つの原因: (1) データ量の増加 --- テーブルが 100 万行から 1,000 万行に増加するにつれて、同じクエリの時間が長くなります。 (2) 施策の蓄積 --- 既存の施策を最適化することなく新たな施策が追加され、施策間の相互作用により複雑さが増します。 (3) ビジュアルのスプロール --- ユーザーはページごとにビジュアルを追加し、それぞれが追加のクエリを生成します。 (4) モデルの肥大化 --- 未使用のものを削除せずに、新しい列とテーブルが追加されます。 (5) 同時ユーザーの増加 --- 同じ容量リソースを求めて競合するユーザーが増加します。これらに対処するには、四半期ごとのパフォーマンス監査、視覚的なカウントを制限して複雑さを測定するガバナンス ポリシー、プロアクティブな容量モニタリングを使用します。