Azure Data Lake の変更データ

ほぼリアルタイムのデータ変更を有効にするオプションを選択した場合、データは Data Lake でほぼリアルタイムで挿入、更新、および削除されます。 データが財務と運用環境内で変更されると、数分以内に Data Lake 内のデータが更新されます。 データの変更は、別の変更フィード フォルダーでも取得できます。

Data Lake のデータ変更により、財務と運用アプリのデータ変更に反応するほぼリアルタイムのデータ パイプラインを構築できます。 変更フィード フォルダーには、財務と運用アプリでデータを変更するごとに格納されます。 このフォルダーは、Data Lake へのエクスポート機能により自動的に作成され、管理されます。

Data Lake のデータを変更する必要があるのはなぜですか?

Data Lake のデータは、レポートの目的でよく使用されます。 Data Lake のテーブル データを使用してレポートを作成できますが、データの追加コピーを作成してレポートを改善することもできます。 たとえば、パワーユーザーを有効にするように設計されたデータ マートがあるとします。 このデータ マートでは、簡略化された、多くの場合集約されたファクト テーブルと分析コード テーブルを使用している可能性があります。

Data Lake のテーブル データが更新される場合は、対応するファクト テーブルおよび分析コード テーブルを更新した Data Lake に保持する必要があります。 それ以外の場合、レポートには最新のデータが反映されません。

ファクト テーブルと分析コード テーブルを更新する最も簡単な方法は、テーブルを使用して完全なコピーを定期的に作成することです。 ただし、この方法は非効率的です。 テーブルが大きい場合 (たとえば、数千万や数千万の行がある場合) は、完全なコピーを作成してファクト テーブルを更新するプロセスには数時間かかり、大量の計算リソースが消費される場合があります。 したがって、ユーザーが時間内にレポートを作成していない場合があります (つまり、レポートの最新データを表示するために数時間待たなければならない場合があります)。 データが再処理されるたびに計算リソースが消費されるため、消費したサービスからより大きな請求書を受け取る場合があります。

ファクト テーブルと分析コード テーブルの差分更新は、両方の問題 (時間の消費と計算リソースの消費) に対する答えを提供します。 差分更新では、変更されたレコードのみをソース テーブルから選択し、対応するファクト テーブルおよび分析コード テーブルで更新します。

差分更新は、Azure Data Factory などの多くのデータ変換ツール の標準機能です。 ただし、差分更新機能を使用するには、ソース テーブルで変更されたレコードを識別する必要があります。

変更フィード フォルダーには、Data Lake内のテーブル データ変更の履歴が表示されます。 この履歴は、差分更新を使用するデータ パイプラインに使用できます。

変更フィード フォルダーの詳細

変更フィード機能は、変更データ キャプチャ (CDC) という名前の SQL Server 機能に依存します。 CDC は、財務と運用アプリの背後にあるデータ ストアである SQL Server データベースの変更データをキャプチャするネイティブな方法です。 変更フィード機能を使用すると、Data Lake の CDC 変更ログにアクセスできます。

次の図は、財務と運用アプリでの変更フィードの機能を示しています。

1. 財務と運用アプリでデータが変更されるたびに、基になるデータベース (AXDB) が更新されます。 CDC 機能は、更新がデータベースに反映されることを保証します。 CDC は、論理シーケンス番号 (LSN 値)、日付/タイム スタンプ (日時変更 値)、および変更されたデータを識別するペイロード変更値とともに、ログ (変更ログ) に変更をキャプチャします。
2. Data Lake へのエクスポート マイクロサービスはデータベース内の変更をキャプチャし、変更ログを顧客の Data Lake に書き込みます。 Data Lake の変更フィード フォルダーはテーブルごとに整理されます。 各フォルダーには、特定のテーブルの変更ログが含まれます。
3. さらに、テーブル フォルダー、変更された各行にはいくつかの新しいフィールドも含まれます。 各行には、対応する変更レコードの LSN 値と日時変更値が含まれています。 テーブル フォルダーの LSN フィールドと日時変更フィールドを使用して、行が変更されたかどうかを識別できますが、最新の変更のみが含まれています。 同じ行が複数回変更された場合は、最新の変更だけがテーブル フォルダーに表示されます。
4. 変更は、データベースでコミットされるのと同じ順序で (つまり、LSN) 変更フィード フォルダーに書き込まれます。 変更フィード ファイルは Data Lake にバッチに書き込まれるので、そのサイズは読み取り用に最適化されます。 変更フィード ファイルが書き込まれた後は、更新されません。

Data Lake 内の変更フィード フォルダを検索

ほぼリアルタイムのデータ変更を有効にする機能を有効にした場合、テーブルを Data Lake に追加すると、変更フィードが自動的に追加されます。

Data Lake にテーブルを追加する場合、または非アクティブ化されたテーブルをアクティブ化すると、システムは Data Lake 内のデータの初期コピーを作成します。 この時点で、テーブルの状態は初期化と表示されます。 初期コピーが完了すると、状態が実行中に変更されます。 テーブルの実行中状態の場合は、財務と運用データベース内の変更が Data Lake に反映され、変更フィードが追加されます。 変更フィード フォルダーは、初期化後、テーブルに変更が加えられていない場合、空である場合があります。

変更フォルダーにアクセスするには、Azure ポータルを開き、財務と運用環境に関連付けられているストレージ アカウントを見つけて選択します。 Data Lake 構造内の変更フィード フォルダーが表示されます。 次の図は、例を示します。

変更フィード フォルダーを開くと、Data Lake に追加したテーブルに対応するフォルダーが表示されます。 変更フォルダー データを説明する CDM メタデータ ファイルも表示されます。 次の図は、例を示します。

CDM メタデータ ファイルは、フォルダーに含まれる変更フィード データの構造を記述します。 CDM メタデータ ファイルや Data Factory などのデータ変換ツールを使用すると、生のカンマ区切り値 (CSV) ファイルを読み取ることなく、変更フィード データを読み取ることができます。 メタデータを調べるには、メタデータ ファイルを選択し、テキスト エディターで開きます。

メタデータ定義から通知されるため、変更フィード フォルダーには、追加のフィールドとともに CDC 変更ログの詳細が含まれています。 次の図と表は、変更フォルダーの変更の形式に関する詳細を示しています。

変更フィードを使用する場合のベスト プラクティス

変更フィードは、財務と運用アプリの Data Lake へのエクスポート機能によって有効になる強力な機能です。 このセクションでは、変更フィードを使用するときに従う必要のあるいくつかのベスト プラクティスについて説明します。

ほぼリアルタイムのデータ マートの更新

データ ウェアハウスまたはデータ マートをほぼリアルタイムで更新する必要がある場合 (つまり、財務と運用アプリでデータが変更されてから数分以内に更新する必要がある場合)、変更フィードを使用する必要があります。

ただし、理解する必要のある重要な概念がいくつかあります。

• 変更レコードは、サイズが約 4 メガバイト (MB) または 8 MB のファイルにグループ化されます。 Microsoft は、ファイルが Synapse SQL Serverless によってクエリされるときに最適なクエリ応答時間を提供するように、ファイル サイズを最適化しました。 最適化されたファイル サイズ (およびバッチ書き込み) により、Data Lake の更新時に発生する可能性のある Azure の料金も削減されます。
• 変更レコードは追加されるだけです。 変更フィード フォルダー内のファイルは更新されません。 各変更レコードには変更の LSN 番号と日時が含まれますが、CSV ファイルの日時スタンプを使用して変更を識別することもできます。
• 財務と運用でテーブルを再有効化する場合、変更フィード フォルダーがクリアされ、システムは次に使用可能な変更から変更フィードを開始します。 この動作によって、変更はテーブル フォルダーと一貫しています。 テーブルが再有効化された場合、下流のデータ パイプラインに対する完全な更新をトリガーする必要があります。
• 下流のジョブは、定期的に (10 分ごとなど) 調整したり、新しい変更フィード ファイルがフォルダーに追加されるときにトリガーすることができます。
• いずれの場合でも、下流のデータ パイプラインには、最後に処理されたマーカー (透かしとも呼ばれる) があります。 可能な限り、透かしとしてレコードの LSN フィールドを使用する必要があります。 ただし、ファイルの日時スタンプを透かしとして使用することもできます。 LSN に依存することにより、財務と運用データベースで確定されたのと同じ順序で変更を確実に消費することができます。

下流のパイプラインをビルドする方法を示す例については、Synapse データ インジェスト テンプレートを参照してください。 これを使用して、SQL ベースのデータ ウェアハウスにデータを段階的に取り込むことができます。

BYOD ベースの ETL パイプラインの簡略化

現在自分のデータベースの持ち込み (BYOD) 機能を使用している場合は、データ管理フレームワーク (DMF) のシステム テーブルまたはバッチ テーブルに基づくエンティティのエクスポートに依存できます。 DMF システム テーブルのエクスポート ジョブ実行データを使用して、エクスポート ジョブの期間を特定している可能性があります。 下流のジョブは、ジョブの実行状態および、DMF テーブルから取得された詳細を介してトリガーされる場合があります。

変更フィードを消費することで、オーケストレーション パイプラインを簡略化できます。

データ マートを毎日または 1 日に何度か更新する必要がある場合にテーブル フォルダーを使用する

変更フィードは強力な機能ですが、ほぼリアルタイムのデータ パイプラインを構築および管理するプロセスは複雑です。 最新のデータ変換ツールと既製のテンプレートはこのプロセスを簡素化するのに役立ちますが、パイプラインの構築と実行に投資する必要がある場合があります。

ユーザーがデータ マートを毎日または 1 日に数回更新することを期待している場合、特にデータの量が少ないか中程度の場合は、完全な更新をトリガーすることが経済的な代替になる可能性があります。 小さなテーブルを定期的に完全更新するよう選択することもできますが、頻繁に更新される大きなテーブルに対してほぼリアルタイムのパイプラインを作成することもできます。

マスター データの更新を監査および検証するための変更フィード

変更フィード フォルダーは、財務と運用データベースによって管理される CDC 変更ログの完全な複製です。 財務と運用アプリのマスター データに加えた変更は CDC に反映されます。 したがって、拡張機能として、Data Lake の変更フィード フォルダーにも反映されます。

変更フィード フォルダー上に構築されたレポートを使用して、システム内のマスター データの変更を監査および検証できます。

変更フィード フォルダーを定期的に削除する

変更フィード フォルダーは、エラーから回復するためにデータを再初期化しない限り、Data Lake へのエクスポート プロセスによって削除されません。

テーブルは 実行 状態の間、変更を追加し続けるため、変更フィード フォルダーは Data Lake 内で拡大し続けます。 (ただし、Data Lake にデータを維持するための費用は、SQL データベースのコストのわずかな一部であることに注意してください。したがって、データ拡大のコストは大きな問題ではない可能性があります。)

Data Lake に格納されるデータの量を減らしたい場合は、Data Lake から変更ログを定期的に削除できます。 たとえば、90 日または 180 日間変更されていない変更ログ ファイルを削除するジョブを実行できます。

変更ログを定期的に削除しても、テーブル フォルダー内のデータには影響しません。 ただし、この記事で前述されているように、整合性チェックを実行する場合は、それらのチェックを容易にするために、変更ログをより長く保持することをお勧めします。

ヘッダーと明細行の一貫性を持つレポートを作成する

財務と運用環境で発注書を作成すると、複数のテーブルが更新されることがあります。 便宜上、ヘッダー テーブルにレコードを追加し、複数の注文明細行を明細行テーブルに追加したとします。 システムはヘッダー テーブルと明細行テーブルの両方を Data Lake にエクスポートし、対応する変更レコードは変更フィード フォルダーに追加されます。

ただし、Data Lake へのエクスポート プロセスは、ヘッダーと複数の明細行が Data Lake に書き込まれる正確な時間は同期しません。 ヘッダー テーブルには変更が 1 行しか含まれていないので、最初に Data Lake で更新されることがあります。 その後、少ししてから明細行テーブルが更新される場合があります。 変更フィードによって、テーブル内の変更が確実にデータベースでコミットされた順序で書き込まれますが、テーブル間の変更について同様の保証はありません。

一方、一部の明細行のみを含む購買レポートはユーザーに表示する必要がないので、ヘッダー テーブルと明細行テーブルの両方から一貫したデータを反映するレポートを作成する必要がある場合があります。 このパターンは、データ マート デザインでは一般的です。 変更フィード フォルダーにより、LSN を使用してこのシナリオを処理できます。

下流のデータ パイプラインが、ヘッダーと明細行レコードを一貫した方法でデータ マートに挿入する必要がある場合、LSN に一致するヘッダーと明細行を展開することを検討してください。 データ パイプラインにヘッダー行があるものの、同じ LSN 番号を持つ明細行が一致しない場合、対応する LSN が明細行テーブルに存在するようになるまで待つ必要があります。

また、データ パイプラインは、ヘッダーと明細行間の一貫性を待たずに Data Lake に到着した時にヘッダーと明細行を挿入することができます。 代わりに、レポートのヘッダー テーブルと明細行テーブルの間で結合を実行することができます。 このようにして、一貫したデータについてのみレポートします。