データフローでの増分更新の使用
データフローを使用すると、Power BI または組織が提供するストレージに大量のデータを取り込むことができます。 ただし、場合によっては、更新のたびにソース データの完全なコピーを更新するのが現実的ではありません。 優れた代替手段は増分更新です。これにより、データフローに次の利点が得られます。
- 更新が高速化される: 更新する必要があるのは変更されたデータのみです。 たとえば、10 年間のデータフローの最後の 5 日間のみを更新します。
- 更新の信頼性が高くなる: たとえば、揮発性のソース システムに対して長時間の接続を維持する必要がありません。
- リソースの使用が減る: 更新するデータが少ないと、メモリや他のリソースの全体的な使用が減ります。
増分更新は、Power BI で作成されたデータフローと、Power Apps で作成されたデータフローで使用できます。 この記事では、Power BI の画面を示しますが、これらの手順は、Power BI または Power Apps で作成されたデータフローに適用されます。
Note
分析データフロー内のテーブルのスキーマが変更されると、結果のすべてのデータが新しいスキーマと一致することを確認するために完全更新が行われます。 その結果、増分的に保存されたデータはすべて更新され、ソース システムに履歴データが保持されていない場合、場合によっては失われます。
Power BI で作成されたデータフローで増分更新を使用するには、データフローが Premium 容量内のワークスペースに存在する必要があります。 Power Apps の増分更新には、Power Apps のアプリごとまたはユーザーごとのプランが必要で、宛先として Azure Data Lake Storage を使用するデータフローでのみ使用できます。
Power BI と Power Apps のいずれの場合も、増分更新を使用するには、データフローに取り込まれたソース データに増分更新でフィルター処理できる DateTime フィールドが必要です。
データフローの増分更新の構成
データフローには多くのテーブルを含めることができます。 増分リフレッシュはテーブル レベルで設定され、1 つのデータフローで完全にリフレッシュされたテーブルと増分リフレッシュされたテーブルの両方を保持できるようになります。
増分更新テーブルを設定するには、他のテーブルと同様にテーブルを構成することから始めます。
データフローを作成して保存した後、次の図に示すように、テーブル ビューで [増分更新] 
を選択します。
アイコンを選択すると、[増分更新の設定] ウィンドウが表示されます。 増分更新を有効にします。
次のリストは、増分更新設定 ウィンドウの設定を説明します。
増分更新のオン/オフ切り替え: テーブルの増分更新ポリシーをオンまたはオフにします。
フィルター フィールド ドロップダウン: テーブルを増分フィルターするクエリ フィールドを選択します。 このフィールドには DateTime フィールドのみが含まれます。 テーブルに DateTime フィールドが含まれていない場合、増分更新は使用できません。
重要
増分更新フィルターの変更されていない日付フィールドを選択します。 フィールド値が変更された場合 (たとえば、日付が変更されたフィールドなど)、データ内の値が重複しているために更新エラーが発生する可能性があります。
過去の行を格納/更新する: 前の画像の例は、これらの次のいくつかの設定を示しています。
この例では、合計で 5 年分のデータを格納し、10 日間のデータを増分更新するように更新ポリシーを定義します。 テーブルが毎日更新されると仮定すると、更新操作ごとに次のアクションが実行されます。
新しい日のデータを追加します。
現在の日付までの 10 日分が更新されます。
現在の日付より 5 年以上前のカレンダー年が削除されます。 たとえば、現在の日付が 2019 年 1 月 1 日の場合は、2013 年が削除されます。
最初のデータフロー更新では 5 年分がすべてインポートされるのに時間がかかる場合がありますが、それ以降の更新ははるかに迅速に完了する可能性があります。
データ変更の検出: 10 日間の増分更新は、5 年間の完全更新よりはるかに効率的ですが、さらに効率的にできる場合があります。 [データ変更の検出] チェック ボックスをオンにすると、識別する日付/時刻列を選択して、データが変更された日だけを更新することができます。 これは、通常は監査目的でそのような列がソース システムに存在することを前提としています。 この列の最大値が、増分範囲の各期間に対して評価されます。 そのデータが前回の更新以降変更されていない場合、その期間を更新する必要はありません。 例では、増分更新される日数がさらに 10 日からおそらく 2 日に減る可能性があります。
ヒント
現在の設計では、データ変更の検出に使用される列を永続化してメモリにキャッシュする必要があります。 カーディナリティとメモリ消費量を減らすために、次のいずれかの手法を検討することをお勧めします。
- おそらく Power Query 関数を使って、更新時にこの列の最大値のみを保持します。
- 更新頻度の要件を考慮して許容されるレベルに有効桁数を減らします。
完了期間のみを更新: 毎日午前 4 時 00 分に実行するように、更新がスケジュールされているとします。 その日の最初の 4 時間の間にソース システムにデータが表示される場合は、考慮しない方がよい場合があります。 石油ガス業界での 1 日あたりのバレル数など、一部のビジネス メトリックでは、部分的な日に基づいて考慮するのは実用的ではない、または賢明ではありません。
全期間のリフレッシュのみが適切な別の例は、金融システムからのデータのリフレッシュです。 前月のデータが毎月 12 暦日に承認される金融システムを想像してください。 増分の範囲を 1 か月に設定し、12 日に実行するように更新をスケジュールできます。 このオプションを選択すると、システムによって、1 月のデータ (最も最近の完全な月単位期間) が 2 月 12 日に更新されます。
Note
データフローの増分更新では、次のロジックに従って日付が決定されます。更新がスケジュールされている場合、データフローの増分更新では更新ポリシーで定義されているタイム ゾーンが使用されます。 更新スケジュールが存在しない場合、増分更新では、更新を実行しているコンピューターの時刻が使用されます。
増分更新が構成された後、データフローは日付によるフィルターを含むようにクエリを自動的に変更します。 データフローが Power BI で作成された場合は、Power Query の高度なエディターを使用して、自動生成されたクエリを編集して、更新を微調整またはカスタマイズすることもできます。 増分更新とそのしくみについて詳しくは、次のセクションをご覧ください。
Note
データフローを編集すると、Power Query エディターはデータ ソースに直接接続し、増分更新ポリシーによって処理された後は、データフローでキャッシュまたはフィルター処理されたデータは表示されません。 データフロー内にキャッシュされたデータをチェックするには、増分更新ポリシーを構成してデータフローを更新した後、Power BI Desktop からデータフローに接続します。
増分リフレッシュとリンクされたテーブルと計算されたテーブルの比較
リンク テーブルの場合、増分リフレッシュによりソース テーブルが更新されます。 リンク テーブルは元のテーブルへの単なるポインタであるため、増分更新はリンク テーブルに影響を与えません。 定義されたリフレッシュ ポリシーに従ってソース テーブルがリフレッシュされると、リンクされたテーブルはソース内のデータがリフレッシュされると想定する必要があります。
計算済み テーブルは、別のデータフローであるデータ ストア上で実行されるクエリに基づいています。 そのため、計算テーブルはリンク テーブルと同じように動作します。
計算テーブルとリンク テーブルは同様に動作するため、両方の要件と構成手順は同じです。 1 つの違いは、計算テーブルの場合、特定の構成では、パーティションの構築方法が原因で、増分更新を最適化された方法で実行できないことです。
増分リフレッシュと完全リフレッシュの間の変更
データフローでは、増分更新と完全更新の間での更新ポリシーの変更がサポートされています。 いずれかの方向 (完全から増分または増分から完全) で変更が発生すると、その変更は次回の更新後にデータフローに影響します。
データフローを完全更新から増分更新に移動すると、新しい更新ロジックにより、増分更新の設定で定義されている更新ウィンドウと増分に従って、データフローが更新されます。
データフローを増分更新から完全更新に移動すると、増分更新で累積されたすべてのデータは、完全更新で定義されているポリシーによって上書きされます。 このアクションを承認する必要があります。
増分更新でのタイムゾーンのサポート
データフローの増分更新は、実行される時刻に依存します。 クエリのフィルター処理は、実行される日付に依存します。
これらの依存関係に対応し、データの一貫性を確保するために、データフローの増分更新では、今すぐ更新 シナリオに対して次のヒューリスティックを実装します。
スケジュールされた更新がシステムで定義されている場合、増分更新では、スケジュールされた更新セクションのタイムゾーン設定が使用されます。 これにより、ユーザーがデータフローを更新するタイム ゾーンに関係なく、確実にシステムの定義と常に一致するようになります。
スケジュールされた更新が定義されていない場合、データフローでは、更新を実行しているユーザーのコンピューターのタイム ゾーンが使用されます。
増分更新は、API を使用して呼び出すこともできます。 この場合、更新で使用されるタイムゾーンの設定が、API 呼び出しで保持できます。 API の使用は、テストと検証の目的に役立ちます。
増分更新の実装の詳細
データフローは増分更新にパーティショニングを使用します。 データフローの増分更新では、更新ポリシーの要件を満たす最小限の数のパーティションが維持されます。 範囲外の古いパーティションは削除され、ローリング ウィンドウが維持されます。 パーティションは状況に応じてマージされ、必要なパーティションの総数が減ります。 これにより圧縮が向上し、場合によってはクエリのパフォーマンスが向上する可能性があります。
このセクションの例では、次の更新ポリシーを共有します。
- 過去 1 四半期の行を保存する
- 過去 10 日間の行を更新する
- データ変更の検出 = False
- 完了した日のみ更新 = True
パーティションを結合する
この例では、増分の範囲外になった後、日パーティションは月レベルに自動的にマージされます。 増分範囲のパーティションは、その日のみを更新できるように毎日の粒度で維持する必要があります。 実行日 2016 年 12 月 11 日 の更新操作では、増分範囲外にあるため、11 月の日がマージされます。
古いパーティションを削除する
合計範囲外の古いパーティションは削除されます。 "実行日 2017 年 1 月 2 日" の更新操作では、合計の範囲外になるため、2016 年の第 3 四半期のパーティションが削除されます。
長期にわたる障害からの回復
この例では、システムが長期にわたる障害からどのように正常に回復するかをシミュレートします。 データ ソースの資格情報の有効期限が切れたため、更新が正常に実行されず、問題の解決に 13 日かかったとします。 増分範囲はわずか 10 日です。
次に成功する更新操作 (実行日: 2017 年 1 月 15 日) では、不足している 13 日間をバックフィルして更新する必要があります。 また、その前の 9 日間も、通常のスケジュールで更新されなかったため、更新する必要があります。 つまり、増分範囲は 10 日から 22 日に増加します。
"実行日 2017 年 1 月 16 日" の次の更新操作では、12 月の日と 2016 年の第 4 四半期の月をマージする機会があります。
データフローの増分更新とデータ セット
データフローの増分更新とデータ セットの増分更新は、連携して動作するように設計されています。 データフロー内の増分更新テーブルをデータ セットに完全にロードすること、またはデータフロー内の完全にロードされたテーブルをデータ セットに増分ロードすることは許容され、サポートされています。
どちらの方法も、更新設定で指定された定義に従って動作します。 詳細情報: Power BI Premium での増分更新
関連項目
この記事では、データフローの増分更新について説明しました。 他にも役に立つ可能性がある記事がいくつかあります。
- Power BI でのセルフサービスのデータ準備
- データフローでの計算テーブルの作成
- データフロー用のデータ ソースに接続する
- データフロー間でテーブルをリンクする
- Power BIでデータフローを作成して使用する
- オンプレミス データ ソースでのデータフローの使用
- Power BI データフローの開発者リソース
Power Query とスケジュールされている更新については、これらの記事を参照してください。
Common Data Model について詳しくは、次の概要記事をご覧ください。