Performance & Scalabilityシリーズの一部
完全ガイドを読むPower BI の増分更新: 大規模なデータセットを効率的に処理する
すべての Power BI 実装は、最終的には同じ壁にぶつかります。データセットが大きくなりすぎて、完全な更新に時間がかかりすぎ、リソースを消費しすぎ、ユーザーがデータを必要とするまでに利用可能な時間枠を超過してしまいます。
5,000 万行のトランザクション テーブルは 4 時間ごとに完全に更新されますが、時間がかかるだけでなく、変更されていないデータを再ロードするためにリソースが無駄になります。増分更新は、変更されない履歴データを保持しながら、新しいレコードと変更されたレコードのみをロードすることでこの問題を解決します。正しく実行すると、以前は更新に 3 時間かかっていたデータセットを 10 分以内に最新の状態にすることができます。
このガイドでは、Power BI の増分更新について、基本原則から高度な構成まで説明します。これには、実装を破壊するよくある間違いや、運用環境での信頼性を高めるためのベスト プラクティスも含まれます。
重要なポイント
- 増分更新は日付ごとにデータセットを分割し、更新サイクルごとに最近のデータのみをロードします
- ファクト テーブルの datetime 列と 2 つの Power Query パラメーター (RangeStart、RangeEnd) が必要です
- 履歴データは古いパーティションに保持され、初期ロード後に再クエリされることはありません
- 10 個を超えるパーティションの増分更新には Power BI Premium (または Fabric) が必要です
- データ変更の検出オプションにより、データが変更されたパーティションのみをリフレッシュすることで処理がさらに削減されます
- ハイブリッド テーブル (インポートと 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 (制限付き) および Power BI Premium/Fabric (フル機能) で利用できます。 Pro では、最大 10 個の更新期間を設定できます。 Premium ではこの制限がなくなり、「データ変更の検出」機能が追加されます。
日時列: ファクト テーブルには、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 サービスに発行します。公開後の最初の更新は、その後の更新よりも時間がかかります。すべての履歴データがロードされ、すべてのパーティションが初めて作成されます。これは予想通りです。
詳細構成: データ変更の検出
Premium の「データ変更の検出」オプションにより、効率がさらに高まります。これは、指定された列 (通常は last_modified_date 列) をクエリして、履歴パーティション内のレコードが更新されたかどうかを判断することによって機能します。データが実際に変更されたパーティションのみが更新されます。
データの変更を検出しない場合: 過去 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 経由で利用できます。
一般的な失敗パターン:
| 問題 | 症状 | 解像度 |
|---|---|---|
| クエリの折りたたみが壊れています | すべてのサイクルで完全にリフレッシュされ、リフレッシュ時間が遅くなります。 Power Query をリファクタリングして折りたたみを復元する | |
| datetime 列にインデックスがありません | パーティションの更新が遅い | ソースデータベースにインデックスを追加 |
| ソース データの変更がキャプチャされない | 履歴パーティションに古いデータが含まれています。データ変更の検出を有効にするか、ローリング ウィンドウを拡大します。 | |
| パーティション数が制限を超えています | 10 個のパーティションを作成すると更新が失敗する (Pro) | プレミアムまたはファブリックにアップグレード |
| タイムゾーンの不一致 | 各パーティション内の間違ったレコード | RangeStart/RangeEnd が UTC を使用していることを確認します。 |
クエリ折りたたみ検証の実際
増分リフレッシュが約束されたパフォーマンスの向上を実現できない最も一般的な理由は、クエリの折りたたみです。ここでは、一般的な折り畳みの破損を診断して修正する方法を説明します。
テスト 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 (更新期間 10 回に制限)、Power BI Premium Per Capacity、Power BI Premium Per User (PPU)、および Microsoft Fabric の容量で利用できます。 「データ変更の検出」機能とハイブリッド テーブルには、Premium または Fabric が必要です。 10 を超える履歴パーティションがあるほとんどのエンタープライズ実装では、Premium または Fabric が必要です。
増分更新は遅れて到着したデータをどのように処理しますか?
遅延到着データ (トランザクション日以降に到着するレコード (たとえば、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 パフォーマンス最適化サービス には、大規模なエンタープライズ データセットの増分更新設計と実装が含まれています。現在の更新アーキテクチャを評価し、最適化の機会を特定するには、お問い合わせください。
執筆者
ECOSIRE Research and Development Team
ECOSIREでエンタープライズグレードのデジタル製品を開発。Odoo統合、eコマース自動化、AI搭載ビジネスソリューションに関するインサイトを共有しています。
関連記事
Building Financial Dashboards with Power BI
Step-by-step guide to building financial dashboards in Power BI covering data connections to accounting systems, DAX measures for KPIs, P&L visualisations, and best practices.
Case Study: Power BI Analytics for Multi-Location Retail
How a 14-location retail chain unified their reporting in Power BI connected to Odoo, replacing 40 spreadsheets with one dashboard and cutting reporting time by 78%.
GoHighLevel + Power BI: Advanced Reporting and Analytics
Connect GoHighLevel to Power BI for advanced marketing analytics. Build executive dashboards, track multi-channel ROI, and create automated reports that go beyond GHL's native reporting.
Performance & Scalabilityのその他の記事
k6 Load Testing: Stress-Test Your APIs Before Launch
Master k6 load testing for Node.js APIs. Covers virtual user ramp-ups, thresholds, scenarios, HTTP/2, WebSocket testing, Grafana dashboards, and CI integration patterns.
Nginx Production Configuration: SSL, Caching, and Security
Nginx production configuration guide: SSL termination, HTTP/2, caching headers, security headers, rate limiting, reverse proxy setup, and Cloudflare integration patterns.
Odoo Performance Tuning: PostgreSQL and Server Optimization
Expert guide to Odoo 19 performance tuning. Covers PostgreSQL configuration, indexing, query optimization, Nginx caching, and server sizing for enterprise deployments.
Odoo vs Acumatica: Cloud ERP for Growing Businesses
Odoo vs Acumatica compared for 2026: unique pricing models, scalability, manufacturing depth, and which cloud ERP fits your growth trajectory.
Testing and Monitoring AI Agents in Production
A complete guide to testing and monitoring AI agents in production environments. Covers evaluation frameworks, observability, drift detection, and incident response for OpenClaw deployments.
Compliance Monitoring Agents with OpenClaw
Deploy OpenClaw AI agents for continuous compliance monitoring. Automate regulatory checks, policy enforcement, audit trail generation, and compliance reporting.