データフローでの増分更新の使用

データフローを使用すると、Power BI または組織が提供するストレージに大量のデータを取り込むことができます。 ただし、場合によっては、更新のたびにソース データの完全なコピーを更新するのが実際的ではないことがあります。 そのような場合に適している別の方法は 増分更新 であり、データフローに対して次のような利点があります。

  • 更新が高速化される: 更新する必要があるのは変更されたデータのみです。 たとえば、更新なら 10 年間のデータフローのうち過去 5 日間だけで済みます。
  • 更新の信頼性が高くなる: たとえば、揮発性のソース システムに対して長時間の接続を維持する必要がありません。
  • リソースの使用が減る: 更新するデータが少ないと、メモリや他のリソースの全体的な使用が減ります。

増分更新は、Power BI で作成されたデータフローと、Power Apps で作成されたデータフローで使用できます。 この記事では、Power BI の画面を示しますが、これらの手順は、Power BI または Power Apps で作成されたデータフローに適用されます。

データフローの増分更新。

Power BI で作成されたデータフローで増分更新を使用するには、データフローが Premium 容量内のワークスペースに存在する必要があります。 Power Apps での増分更新には、Power Apps プラン 2 が必要です。

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 日あたりのバレル数など、一部のビジネス メトリックでは、部分的な日に基づいて考慮するのは実用的ではない、または賢明ではありません。

    完全な期間の更新のみが適切であるもう 1 つの例は、財務システムからデータの更新です。 前月のデータが 12 日に承認されるような財務システムを想像してください。 増分の範囲を 1 か月に設定し、12 日に実行するように更新をスケジュールできます。 このオプションを選択すると、システムによって、1 月のデータ (最も最近の完全な月単位期間) が 2 月 12 日に更新されます。

注意

データフローの増分更新では、次のロジックに従って日付が決定されます。更新がスケジュールされている場合、データフローの増分更新では更新ポリシーで定義されているタイム ゾーンが使用されます。 更新スケジュールが存在しない場合、増分更新では、更新を実行しているコンピューターの時刻が使用されます。

増分更新を構成すると、データフローによって、クエリが日付によるフィルタリングを含むように自動的に変更されます。 Power Query の詳細エディターを使用して、自動生成されたクエリを編集し、更新を微調整またはカスタマイズすることができます。 増分更新とそのしくみについて詳しくは、次のセクションをご覧ください。

増分更新と、リンクされたエンティティおよび計算されたエンティティ

"リンクされた" エンティティの場合、増分更新ではソース エンティティが更新されます。 リンクされたエンティティは元のエンティティへのポインターでしかないので、増分更新によるリンクされたエンティティへの影響は何もありません。 定義された更新ポリシーに従ってソース エンティティが更新された場合、リンクされたエンティティではソース内のデータが更新されたものと想定する必要があります。

"計算された" エンティティはデータ ストアに対して実行されるクエリに基づいており、別のデータフローである可能性があります。 そのため、計算されたエンティティの動作は、リンクされたエンティティと同じです。

計算されたエンティティとリンクされたエンティティは同じように動作するので、要件と構成手順はどちらも同じです。 1 つの違いは、計算されたエンティティの場合、特定の構成では、パーティションの構築方法により、増分更新を最適化された方法で実行できないことです。

増分更新と完全更新の間の変更

データフローでは、増分更新と完全更新の間での更新ポリシーの変更がサポートされています。 いずれかの方向 (完全から増分または増分から完全) で変更が発生すると、その変更は次回の更新後にデータフローに影響します。

データフローを完全更新から増分更新に移動すると、新しい更新ロジックにより、増分更新の設定で定義されている更新ウィンドウと増分に従って、データフローが更新されます。

データフローを増分更新から完全更新に移動すると、増分更新で累積されたすべてのデータは、完全更新で定義されているポリシーによって上書きされます。 このアクションを承認する必要があります。

増分更新でのタイム ゾーンのサポート

データフローの増分更新は、実行される時刻に依存します。 クエリのフィルター処理は、実行される日付に依存します。

これらの依存関係に対応してデータの整合性を保証するため、データフローの増分更新では、"今すぐ更新" シナリオに対する次のヒューリスティックが実装されています。

  • スケジュールされた更新がシステムで定義されている場合、増分更新では、スケジュールされた更新セクションのタイムゾーン設定が使用されます。 これにより、ユーザーがデータフローを更新するタイム ゾーンに関係なく、確実にシステムの定義と常に一致するようになります。

  • スケジュールされた更新が定義されていない場合、データフローでは、更新を実行しているユーザーのコンピューターのタイム ゾーンが使用されます。

増分更新は、API を使用して呼び出すこともできます。 この場合、更新で使用されるタイムゾーンの設定が、API 呼び出しで保持できます。 API を使用すると、テストと検証のために役立つことがあります。

増分更新の実装の詳細

データフローでは、増分更新に対してパーティション分割が使用されます。 Power BI Premium に対する XMLA エンドポイントが使用可能になった後、パーティションが表示されるようになります。 データフローの増分更新では、更新ポリシーの要件を満たす最小限の数のパーティションが維持されます。 範囲外の古いパーティションは削除され、ローリング ウィンドウが維持されます。 パーティションは状況に応じてマージされ、必要なパーティションの合計数が削減されます。 これにより、圧縮が向上し、場合によっては、クエリのパフォーマンスを向上できます。

このセクションの例では、次の更新ポリシーが共有されています。

  • 過去 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 での増分更新

考慮事項と制限事項

Microsoft Power Platform データフローでの増分更新は、送信先として Dataverse を使用するデータフローではなく、Azure Data Lake Storage アカウントを使用するデータフローでのみサポートされています。

関連項目

この記事では、データフローの増分更新について説明しました。 他にも役に立つ可能性がある記事がいくつかあります。

Power Query とスケジュールされた更新について詳しくは、次の記事をご覧ください。

Common Data Model について詳しくは、次の概要記事をご覧ください。