API でのソース接続の change data capture の有効化

Adobe Experience Platform ソースでチェンジ・データ・キャプチャを使用して、ほぼリアルタイムでソース・システムとデスティネーション・システムの同期を維持します。

Experience Platformは現在、増分データコピー をサポートしています。このコピーは、新しく作成または更新されたレコードを、ソースシステムから取り込んだデータセットに定期的に転送します。 この方法は、変更を追跡するために timestamp 列 に依存しますが、時間の経過に伴うデータの不整合を引き起こす可能性がある削除は検出しません。

これに対し、チェンジ・データ・キャプチャは、ほぼリアルタイムで挿入、更新、削除をキャプチャして適用します。 この包括的な変更の履歴管理により、データセットがソース・システムと完全に整合した状態で維持され、差分コピーのサポート以外の完全な変更履歴が提供されます。 ただし、削除操作はターゲットデータセットを使用するすべてのアプリケーションに影響を与えるので、特別な考慮が必要です。

Experience Platformでのチェンジ データ キャプチャには、モデルベースのスキーマ を持つ 0}Data Mirror} が必要です(リレーショナル スキーマとも呼ばれます)。 ​Data Mirrorに変更データを提供するには、次の 2 つの方法があります。

どちらのアプローチでも、関係を保持し一意性を強化するために、モデルベースのスキーマを使用したData Mirrorが必要です。

モデルベースのスキーマを使用したData Mirror

AVAILABILITY
Data Mirrorおよびモデルベースのスキーマは、Adobe Journey Optimizer オーケストレートキャンペーン のライセンスホルダーが使用できます。 ライセンスとイネーブルメント機能に応じて、Customer Journey Analytics ユーザー向けの 限定リリース としても使用できます。 アクセスについては、Adobe担当者にお問い合わせください。
NOTE
調整されたキャンペーンユーザー:このドキュメントで説明されているData Mirror機能を使用して、参照整合性を維持するカスタマーデータを操作します。 ソースが CHANGE DATA CAPTURE フォーマットを使用していない場合でも、Data Mirrorは、プライマリキーの適用、レコードレベルのアップサート、スキーマの関係などのリレーショナル機能をサポートします。 これらの機能により、接続されたデータセット間で一貫した信頼性の高いデータモデリングが可能になります。

Data Mirrorでは、モデルベースのスキーマを使用してチェンジ・データ・キャプチャを拡張し、高度なデータベース同期機能を有効にします。 Data Mirrorの概要については、Data Mirrorの概要 ​ を参照してください。

モデルベースのスキーマは、Experience Platformを拡張して、プライマリキーの一意性を適用し、行レベルの変更を追跡し、スキーマレベルの関係を定義します。 チェンジ・データ・キャプチャでは、挿入、更新、削除をデータ・レイク内で直接適用し、抽出、変換、ロード(ETL)または手動の紐付けの必要性を減らします。

詳しくは、​ モデルベースのスキーマの概要 ​ を参照してください。

チェンジ・データ・キャプチャのモデル・ベースのスキーマ要件

チェンジ・データ・キャプチャでモデル・ベースのスキーマを使用する前に、次の識別子を設定します。

  • 各レコードをプライマリキーで一意に識別します。
  • バージョン識別子を使用して、更新を順番に適用します。
  • 時系列スキーマの場合は、タイムスタンプ識別子を追加します。

列の処理を制御 control-column-handling

_change_request_type の列を使用して、各行の処理方法を指定します。

  • u — アップサート(列がない場合はデフォルト)
  • d – 削除

この列は取り込み時にのみ評価され、XDM フィールドには保存もマッピングもされません。

ワークフロー workflow

モデルベースのスキーマでチェンジ・データ・キャプチャを有効にするには、次の手順に従います。

  1. モデルベースのスキーマを作成します。

  2. 必要な記述子を追加します。

  3. スキーマからデータセットを作成し、変更データキャプチャを有効にします。

  4. ファイルベースの取り込みのみ:削除操作を明示的に指定する必要がある場合は、ソースファイルに _change_request_type 列を追加します。 CDC の書き出し設定では、データベースソースに対してこれを自動的に処理します。

  5. ソース接続の設定を完了して取り込みを有効にします。

NOTE
_change_request_type 列は、行レベルの変更動作を明示的に制御する場合に、ファイルベースのソース(Amazon S3、Azure Blob、Google Cloud Storage、SFTP)にのみ必要です。 ネイティブの CDC 機能を持つデータベース・ソースの場合、変更操作は CDC エクスポート構成を通じて自動的に処理されます。 ファイルベースの取り込みは、デフォルトでアップサート操作を想定します。ファイルアップロードで削除操作を指定する場合にのみ、この列を追加する必要があります。
IMPORTANT
データ削除の計画が必要です。 モデルベースのスキーマを使用するすべてのアプリケーションは、変更データキャプチャを実装する前に、削除の影響を理解する必要があります。 削除が関連するデータセット、コンプライアンス要件およびダウンストリームプロセスに与える影響を計画します。 詳しくは、​ データハイジーンに関する考慮事項 ​ を参照してください。

ファイルベースのソースの変更データの提供 file-based-sources

IMPORTANT
ファイルベースの CHANGE DATA CAPTURE には、モデルベースのスキーマを持つData Mirrorが必要です。 以下のファイル形式設定手順に従う前に、このドキュメントで前述した Data Mirror セットアップワークフローを完了してい ​ ことを確認してください。 次の手順では、Data Mirrorで処理される変更のトラッキング情報を含めるようにデータファイルをフォーマットする方法について説明します。

ファイルベースのソース(Amazon S3、Azure Blob、Google Cloud Storage および SFTP)の場合は、ファイルに _change_request_type 列を含めます。

上記の _change_request_type コントロール列の処理 ​ の節で定義した ​ の値を使用します。

IMPORTANT
ファイルベースのソースのみ の場合、変更追跡機能を検証するために、特定のアプリケーションで、_change_request_type (アップサート)または u (削除)を含む d 列が必要になる場合があります。 例えば、Adobe Journey Optimizerの オーケストレートキャンペーン 機能では、「オーケストレートキャンペーン」切替スイッチを有効にし、ターゲティング用のデータセット選択を許可するために、この列が必要です。 アプリケーション固有の検証要件は異なる場合があります。

次のソース固有の手順に従います。

クラウドストレージソース cloud-storage-sources

次の手順に従って、クラウドストレージソースの CHANGE DATA CAPTURE を有効にします。

  1. ソースのベース接続を作成します。

    table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2
    ソース ベース接続ガイド
    Amazon S3 ​ ベ Amazon S3 ス接続の作成 ​
    Azure Blob ​ ベ Azure Blob ス接続の作成 ​
    Google Cloud Storage ​ ベ Google Cloud Storage ス接続の作成 ​
    SFTP ​ ベ SFTP ス接続の作成 ​
  2. ​ クラウドストレージのソース接続の作成 ​

すべてのクラウドストレージソースは、上記の _change_request_type ファイルベースのソース ​ の節で説明したのと同じ ​ 列形式を使用します。

データベースソース database-sources

Azure Databricks

Azure Databricks で change data capture を使用するには、ソーステーブルで change data feed を有効にする必要があり、Experience PlatformでData Mirrorをモデルベースのスキーマと設定する必要があります。

以下のコマンドを使用して、テーブルで変更データフィードを有効にします。

新規テーブル

変更データフィードを新しいテーブルに適用するには、delta.enableChangeDataFeed コマンドでテーブルプロパティ TRUECREATE TABLE に設定する必要があります。

CREATE TABLE student (id INT, name STRING, age INT) TBLPROPERTIES (delta.enableChangeDataFeed = true)

既存のテーブル

変更データフィードを既存のテーブルに適用するには、delta.enableChangeDataFeed コマンドでテーブルプロパティ TRUEALTER TABLE に設定する必要があります。

ALTER TABLE myDeltaTable SET TBLPROPERTIES (delta.enableChangeDataFeed = true)

すべての新規テーブル

すべての新規テーブルに変更データフィードを適用するには、デフォルトのプロパティを TRUE に設定する必要があります。

set spark.databricks.delta.properties.defaults.enableChangeDataFeed = true;

詳しくは、Azure Databricks 変更データフィードの有効化に関するガイド ​ を参照してください。

Azure Databricks ソース接続の change data capture を有効にする手順については、次のドキュメントを参照してください。

Data Landing Zone

Data Landing Zone で change data capture を使用するには、ソーステーブルで change data feed を有効にする必要があり、Experience PlatformでData Mirrorをモデルベースのスキーマと設定する必要があります。

Data Landing Zone ソース接続の change data capture を有効にする手順については、次のドキュメントを参照してください。

Google BigQuery

Google BigQuery で CHANGE DATA CAPTURE を使用するには、ソーステーブルで変更履歴を有効にし、Experience PlatformでData Mirrorをモデルベースのスキーマと設定する必要があります。

Google BigQuery ソース接続の変更履歴を有効にするには、Google BigQuery コンソールで Google Cloud ページに移動し、enable_change_historyTRUE に設定します。 このプロパティは、データ テーブルの変更履歴を有効にします。

詳しくは、​ のデータ定義言語ステートメント GoogleSQL に関するガイドを参照してください。

Google BigQuery ソース接続の change data capture を有効にする手順については、次のドキュメントを参照してください。

Snowflake

Snowflake で CHANGE DATA CAPTURE を使用するには、ソーステーブルで 変更のトラッキング を有効にする必要があり、Experience PlatformでData Mirrorをモデルベースのスキーマと設定する必要があります。

Snowflake では、ALTER TABLE を使用し、CHANGE_TRACKINGTRUE に設定して、変更の追跡を有効にします。

ALTER TABLE mytable SET CHANGE_TRACKING = TRUE

詳しくは、Snowflake changes 句の使用に関するガイド ​ を参照してください。

Snowflake ソース接続の change data capture を有効にする手順については、次のドキュメントを参照してください。

recommendation-more-help
337b99bb-92fb-42ae-b6b7-c7042161d089