Power BI の増分更新: 大規模なデータセットを効率的に処理する

5,000 万行のトランザクション テーブルは 4 時間ごとに完全に更新されますが、時間がかかるだけでなく、変更されていないデータを再ロードするためにリソースが無駄になります。増分更新は、変更されない履歴データを保持しながら、新しいレコードと変更されたレコードのみをロードすることでこの問題を解決します。正しく実行すると、以前は更新に 3 時間かかっていたデータセットを 10 分以内に最新の状態にすることができます。

このガイドでは、Power BI の増分更新について、基本原則から高度な構成まで説明します。これには、実装を破壊するよくある間違いや、運用環境での信頼性を高めるためのベスト プラクティスも含まれます。

重要なポイント

• 増分更新は日付ごとにデータセットを分割し、更新サイクルごとに最近のデータのみをロードします
• ファクト テーブルの datetime 列と 2 つの Power Query パラメーター (RangeStart、RangeEnd) が必要です
• 履歴データは古いパーティションに保持され、初期ロード後に再クエリされることはありません
• 標準の増分更新は Power BI Pro をサポートします。 リアルタイム DirectQuery パーティションを追加するには、サポートされている Premium、PPU、または Embedded モデルが必要です。
• データ変更の検出オプションにより、データが変更されたパーティションのみをリフレッシュすることで処理がさらに削減されます
• ハイブリッド テーブル (インポートと DirectQuery を組み合わせたもの) により、履歴インポート パーティションと並行してリアルタイム データが有効になります。
• 適切な構成には Power Query の折りたたみについて理解する必要があります - 折りたたみ不可能なクエリでは増分更新が中断されます
• XMLA エンドポイントおよびサードパーティ ツールを介してパーティションの状態を監視することで、サイレント障害を防止します

---

増分リフレッシュの仕組み

増分更新を理解するには、Power BI がデータを分割する方法を理解することから始まります。

標準のインポート モデルでは、データセット全体が単一のパーティション内に存在します。更新するたびに、このパーティションが完全に置き換えられます。小規模なデータセットの場合は、これで問題ありません。大きなテーブルの場合、上記の問題が発生します。

増分更新では、ファクト テーブルが複数のパーティションに分割され、それぞれが特定の日付範囲をカバーします。

• パーティション 1: 2020-01-01 から 2020-12-31 (履歴、更新されません)
• パーティション 2: 2021-01-01 から 2021-12-31 (履歴、更新されません)
• パーティション 3: 2022-01-01 から 2022-12-31 (履歴、更新されません)
• パーティション 4: 2023-01-01 から 2023-12-31 (履歴、更新されません)
• パーティション 5: 2024-01-01 から 2024-12-31 (毎月更新)
• パーティション 6: 2025-01-01 ～ 2025-03-31 (毎日更新)
• パーティション 7: 2025-04-01 から現在まで (1 時間ごとまたはオンデマンドで更新)

スケジュールされた更新ごとに、最新のパーティション (この例では 5、6、および 7) のみが処理されます。履歴パーティションは、最初にロードされたときからそのまま残ります。これは、リフレッシュ サイクルで全データの一部のみが処理されることを意味し、時間、メモリ、ソース システムの負荷が大幅に削減されます。

---

前提条件と要件

増分リフレッシュを構成する前に、次の前提条件が満たされていることを確認してください。

ライセンス: Power BI Pro は増分更新をサポートしており、1 回の更新時間の上限は 2 時間です。モデルのサイズ、ワークロード、必要な機能に応じて容量を選択してください。 マイクロソフトの要件.

日時列: ファクト テーブルには、Power BI がデータを分割するために使用する日時列 (日付キー整数ではなく、実際の日時型である必要があります) が必要です。これは通常、トランザクション日付、イベント タイムスタンプ、または作成日列です。

クエリ フォールディング: ファクト テーブルを読み込む Power Query クエリは、クエリ フォールディング、つまり Power Query 変換ステップをソース システムが実行するソース クエリ (SQL など) に変換する機能をサポートする必要があります。クエリの折りたたみが壊れると、増分更新はサイレントに失敗します。更新のたびにすべてのデータが読み込まれ、目的が果たせなくなります。

ソース システムのサポート: ソースは日付範囲フィルタリングを効率的にサポートする必要があります。 datetime 列にインデックスのないソース テーブルでは、増分リフレッシュが構成されている場合でもリフレッシュが遅くなります。これは、各パーティションのリフレッシュで日付範囲内のレコードを検索するためにテーブル全体のスキャンが実行されるためです。

---

段階的な構成

ステップ 1: 必要な Power Query パラメーターを作成する

Power BI Desktop で、Power Query エディターを開きます。 「パラメータの管理」→「新規パラメータ」に移動します。

次のように 2 つのパラメータを正確に作成します (名前は大文字と小文字が区別され、正確に一致する必要があります)。

これらのパラメータは、日付型ではなく、日付/時刻型である必要があります。これらは実行時に Power BI の更新エンジンによってオーバーライドされますが、開発とテストには有効な既定値が必要です。

ステップ 2: これらのパラメータを使用してファクト テーブルをフィルタリングします

Power Query エディターで、ファクト テーブルを選択します。次のパラメータを使用して日時列にフィルタを適用します。

= Table.SelectRows(Source, each [TransactionDate] >= RangeStart and [TransactionDate] < RangeEnd)

このフィルタリング手順は重要です。データ ソースに折り畳む必要があります。折りたたみを確認するには、最後のクエリ ステップを右クリックし、[ネイティブ クエリの表示] が利用可能かどうかを確認します。グレー表示になっている場合は、折りが壊れています。その上のどの変換ステップが折りチェーンを壊しているのかを調べてください。

ステップ 3: クエリの折りたたみを確認する

クエリの折りたたみが壊れるのは、次のような理由が最も一般的です。

• SQL に変換できないカスタム関数
• 一方または両方が折りたたまれない 2 つのクエリをマージ (結合)
• 特定のテキスト変換関数 (Text.Upper、Text.PadStart)
• リスト操作 (List.Contains) の使用
• インデックス列の追加
• 特定の型変換操作

折りたたみが壊れた場合は、クエリをリファクタリングして、問題のある操作を日付フィルターの後のステップにプッシュするか、Power Query ではなくソース データベースのビューで変換を実行します。

ステップ 4: 増分更新ポリシーを構成する

Power BI Desktop で、[フィールド] ウィンドウでファクト テーブルを右クリック→ [増分更新] をクリックします。

構成オプション:

• 過去 N 暦年/月/日の行を保存: これは、モデルに保持される合計履歴ウィンドウを定義します。これより古いデータはモデルから自動的に削除されます (パーティションの削除)。

• 過去 N 暦年/月/日の行のみを更新: これは、各サイクルで再更新されるローリング ウィンドウを定義します。この期間より古いデータは履歴 (不変) として扱われ、再度更新されることはありません。

• データ変更の検出: 構成された増分更新範囲内の変更されていない期間をスキップするには、別の監査日時列を使用します。

5 年間の履歴を持つトランザクション データベースの構成例:

• 過去 5 年間の行を保存します
• 過去 3 日間の行のみを更新します

これにより、5 年間のデータをカバーするパーティションが作成されますが、各サイクルで更新されるのは過去 3 日間のパーティションのみです。

ステップ 5: 公開および検証

レポートを Power BI サービスに発行します。公開後の最初の更新は、その後の更新よりも時間がかかります。すべての履歴データがロードされ、すべてのパーティションが初めて作成されます。これは予想通りです。

---

詳細構成: データ変更の検出

変更検出では、古いアーカイブされたパーティションは自動的に更新されません。 更新ウィンドウ外での遅い変更をどのように処理するかを定義します。 Microsoft の構成.

データの変更を検出しない場合: 過去 3 日間にデータが変更されなかった場合でも、3 日間のローリング ウィンドウが常に更新されます。

データ変更の検出: リフレッシュ エンジンは、各パーティションを処理するかどうかを決定する前に、ローリング ウィンドウ内のレコードが変更されたかどうかを確認します。月曜日のデータが月曜日の夜に更新され、それ以降レコードが変更されなかった場合、火曜日の夜の更新では月曜日のパーティションがスキップされます。

これは、次のようなシナリオで特に価値があります。

• ソース データは一度書き込まれ、めったに更新されません (不変の追加のみのイベント)
• ローリングウィンドウは大きい（例：30日）が、ほとんどの日は変化がありません
• ソース システムのクエリ容量には制限があります

データ変更の検出列にはソース データベースでインデックスを付ける必要があります。リフレッシュ エンジンは、リフレッシュ サイクルごとにすべてのパーティションに対してこの列をクエリします。

---

ハイブリッド テーブル: リアルタイム + 履歴データ

Power BI Fabric/Premium では、インポート モード (履歴パーティション) と DirectQuery モード (現在のデータ) の強力な組み合わせであるハイブリッド テーブルが導入されています。これにより、過去のインポート データとともに、現時点までに更新されたデータを表示するダッシュボードが有効になります。

ハイブリッド テーブル構成の場合:

• 履歴パーティション (昨日以降) はインポート モード - 高速、キャッシュ、完全に集約可能
• 現在のパーティションは DirectQuery モードです - クエリはソース データベースに対してライブで実行されます

ユーザー エクスペリエンスはシームレスであり、クエリは両方のモードに透過的にまたがります。 「今週と先週の売上」のクエリは、インポート パーティションから昨日のデータを取得し、DirectQuery 経由で今日のデータを取得し、それらを 1 つの結果に結合します。

ハイブリッド テーブルに関する考慮事項:

• DirectQuery のパフォーマンスはソース データベースのパフォーマンスに完全に依存します。データベースが遅いということは、当日のクエリも遅いことを意味します。
• DirectQuery パーティションはインポート モードの最適化の恩恵を受けません (VertiPaq 圧縮や事前集計はありません)。
• プレミアムまたはファブリックのワークスペースが必要です

---

増分更新の健全性の監視

増分リフレッシュの失敗はサイレントであることが多く、一部のパーティションが失敗したり完全リフレッシュに戻った場合でも、モデルでは「正常にリフレッシュされた」と表示されます。監視は生産の信頼性にとって不可欠です。

XMLA エンドポイント検査: Power BI Premium は、SQL Server Management Studio (SSMS)、表形式エディター、Azure Analysis Services などのツールが接続できる XMLA エンドポイントを公開します。そこから、パーティションのメタデータをクエリして、各パーティションの最終更新時刻と、エラー状態にあるパーティションがあるかどうかを確認できます。

Tabular Editor 2 (無料): XMLA 経由でプレミアム ワークスペースに接続し、モデル内のパーティション テーブルを検査します。各パーティションには、その名前、日付範囲、最終更新タイムスタンプ、および状態が表示されます。これは、増分更新の問題を診断するための最も実用的なツールです。

Power BI アクティビティ ログ: 管理アクティビティ ログには、処理されたパーティションやエラーなどの更新操作が記録されます。 Power BI REST API 経由で利用できます。

一般的な失敗パターン:

---

クエリ折りたたみ検証の実際

増分リフレッシュが約束されたパフォーマンスの向上を実現できない最も一般的な理由は、クエリの折りたたみです。ここでは、一般的な折り畳みの破損を診断して修正する方法を説明します。

テスト 1: ネイティブ クエリを表示。 Power Query で RangeStart/RangeEnd フィルター ステップを追加した後、ステップを右クリックします。 [ネイティブ クエリの表示] が利用可能で、日付範囲をフィルタリングする WHERE 句を含む SQL クエリが表示されている場合、折りたたみは機能しています。

テスト 2: 生成された SQL を確認します。ネイティブ クエリには次のようなものが含まれている必要があります。

WHERE [TransactionDate] >= @RangeStart AND [TransactionDate] < @RangeEnd

WHERE 句が欠落している場合は、折りたたみが壊れており、ソースからすべてのデータを読み込んだ後、Power Query のエンジンでフィルターが適用されています。

折りたたみの復元: カスタム変換で折りたたみが壊れた場合は、日付フィルター手順の後に移動するか、ソース データベースの SQL ビューで変換を実行し、Power BI をテーブルではなくビューに接続します。

---

よくある質問

増分更新はすべてのデータ ソースで機能しますか?

増分更新は、SQL Server、Azure SQL、PostgreSQL、Snowflake、BigQuery、Azure Synapse、Databricks など、クエリの折りたたみと日付範囲フィルターをサポートするあらゆるデータ ソースで動作します。クエリの折りたたみをサポートしていないソース (Excel ファイル、フラット CSV、一部の REST API) ではうまく機能しません。その場合でも、完全な更新が必要です。折りたたみ不可能なソースの場合、Power BI が接続する前に SQL データベースにデータをステージングすることが推奨される回避策です。

増分更新にはどの Power BI ライセンスが必要ですか?

Power BI Pro は標準の増分更新をサポートしています。リアルタイムの DirectQuery パーティションには Premium、PPU、または Embedded が必要です。プランを選ぶ前に、モデルの制限、ワークロード、必要な機能を確認してください。 マイクロソフトの要件.

増分更新は遅れて到着したデータをどのように処理しますか?

遅延到着データ (トランザクション日以降に到着するレコード (たとえば、1 月のデータ抽出で到着する 12 月のトランザクション)) は、遅延到着をキャプチャするのに十分な幅のローリング更新ウィンドウを設定することで処理されます。データが最大 7 日遅れて到着する可能性がある場合、ローリング ウィンドウを 14 日に設定すると、関連するパーティションが再更新されたときに遅れた到着が確実にキャプチャされます。あるいは、最終変更列を使用したデータ変更の検出オプションは、ローリング ウィンドウの設定に関係なく、遅延到着をキャプチャします。

増分更新はファクトだけでなくディメンション テーブルでも機能しますか?

増分リフレッシュは大規模なファクト テーブル向けに設計されており、日時フィルター列が必要です。ほとんどのディメンション テーブル (製品、顧客、場所) には適切な日時パーティション列がなく、完全な更新が適切であるほど十分に小さいです。大きくなりつつあり、ゆっくりと変化するディメンション テーブル (5,000 万行以上の顧客テーブル) の場合、別のアプローチとして、ソース データベースで SQL ビューを使用して、最近変更されたレコードをフィルターし、Power BI ではなくデータベース レイヤーで履歴保持を処理することができます。

増分更新モデルにどのパーティションが存在するかを確認するにはどうすればよいですか?

最も簡単な方法は、XMLA エンドポイントを介して表エディター (無料バージョン 2) を Power BI Premium ワークスペースに接続することです。 [テーブル] → [テーブル] → [パーティション] の下に、作成されたすべてのパーティションとその日付範囲および最後に処理されたタイムスタンプが表示されます。 SQL Server Management Studio (SSMS) も XMLA 経由で接続し、オブジェクト エクスプローラーにパーティションの詳細を表示します。

増分更新が途中で失敗した場合はどうなりますか?

更新が途中で失敗した場合、Power BI は失敗したパーティションを再試行します。失敗する前に正常に完了したパーティションは再処理されず、失敗したパーティションのみが再試行されます。この再試行動作は、増分リフレッシュが完全リフレッシュよりもソース システムの一時的な停止に対する回復力が高いことを意味します。パーティションに一貫して障害が発生する場合、新しいパーティションは正常に更新され続けますが、そのパーティションは最後に正常にロードされた状態のままになります。

---

次のステップ

増分更新は、大規模なトランザクション データセットを処理する Power BI 実装の基礎です。適切なクエリの折りたたみ、適切なローリング ウィンドウ、および監視を使用して、最初から適切に実行することで、後で費用のかかる再設計を強いるパフォーマンスの問題を回避できます。

ECOSIRE の Power BI パフォーマンス最適化サービス には、大規模なエンタープライズ データセットの増分更新設計と実装が含まれています。現在の更新アーキテクチャを評価し、最適化の機会を特定するには、お問い合わせください。