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