APIでソース接続の変更データキャプチャを有効にする

AVAILABILITY
  • 変更データキャプチャは、次のソースでサポートされています:Amazon S3、Data Landing Zone、Marketo Engage、Microsoft Dynamics、およびSalesforce。

  • また、VA6 データセンターでAmazon Web Services (AWS)でAdobe Experience Platformを使用する場合は、Amazon S3およびData Landing Zoneのソースに対して変更データキャプチャを有効にすることもできます。 AWS版Experience Platformは、現在、一部のユーザーのみが利用できます。 インフラストラクチャのサポートについて詳しくは、Experience Platform マルチクラウドの概要を参照してください。

Adobe Experience Platformのソースで変更データキャプチャを使用すると、ソースと宛先のシステムをほぼリアルタイムで同期できます。

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

これとは対照的に、変更データキャプチャは、ほぼリアルタイムで挿入、更新、削除をキャプチャして適用します。 この包括的な変更追跡により、データセットがソースシステムと完全に連携し、増分コピーがサポートするものを超えて、完全な変更履歴が提供されます。 ただし、削除操作は、ターゲットデータセットを使用するすべてのアプリケーションに影響を与えるため、特別な配慮が必要です。

Experience Platformでのデータキャプチャの変更には、リレーショナルスキーマ​を持つData Mirrorが必要です。 Data Mirrorには、次の2つの方法で変更データを提供できます。

どちらのアプローチも、関係を維持し、一意性を適用するために、リレーショナルスキーマを備えたData Mirrorが必要です。

Data Mirrorとリレーショナルスキーマ

AVAILABILITY
Data Mirrorとリレーショナルスキーマは、Adobe Journey Optimizer オーケストレーションキャンペーン​のライセンス保有者が利用できます。 また、ライセンスと機能の有効化に応じて、Customer Journey Analytics ユーザー向けの​ 限定リリース ​としても利用できます。 アクセスについては、Adobe担当者にお問い合わせください。
NOTE
キャンペーンのオーケストレーション ユーザー:このドキュメントに記載されているData Mirror機能を使用して、参照整合性を維持する顧客データを操作します。 ソースでデータキャプチャの変更フォーマットを使用していない場合でも、Data Mirrorでは、プライマリキーの適用、レコードレベルのアップサート、スキーマの関連付けなどのリレーショナル機能をサポートしています。 これらの機能により、接続されたデータセットをまたいで、一貫性のある信頼性の高いデータモデリングを実現できます。

Data Mirrorでは、リレーショナルスキーマを使用してchange data captureを拡張し、高度なデータベース同期機能を有効にします。 Data Mirrorの概要については、Data Mirrorの概要を参照してください。

リレーショナルスキーマ Experience Platformを拡張して、プライマリキーの一意性を適用したり、行レベルの変更を追跡したり、スキーマレベルの関係を定義したりできます。 変更データキャプチャを使用すると、データレイクに直接挿入、更新、削除が適用され、ETL (抽出、変換、格納)や手作業による紐付けの必要性が低減されます。

詳しくは、​ リレーショナルスキーマの概要を参照してください。

変更データ取得の関係スキーマ要件

変更データキャプチャでリレーショナルスキーマを使用する前に、次の識別子を設定します。

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

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

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

  • u — upsert (列が存在しない場合のデフォルト)
  • d – 削除

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

ワークフロー workflow

リレーショナルスキーマで変更データキャプチャを有効にするには:

  1. 関係スキーマの作成:

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

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

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

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

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

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

IMPORTANT
ファイルベースの変更データキャプチャには、リレーショナルスキーマを備えた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

次の手順に従って、クラウドストレージソースの変更データキャプチャを有効にします。

  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 ソース接続の変更データキャプチャを有効にする手順については、次のドキュメントを参照してください。

Data Landing Zone

Data Landing Zoneでchange data captureを使用するには、ソーステーブルで​ change data feed ​を有効にし、Experience PlatformのリレーショナルスキーマでData Mirrorを設定する必要があります。

Data Landing Zone ソース接続の変更データキャプチャを有効にする手順については、次のドキュメントを参照してください。

Google BigQuery

Google BigQueryでChange Data Captureを使用するには、ソーステーブルで変更履歴を有効にし、Experience Platformでリレーショナルスキーマを使用してData Mirrorを設定する必要があります。

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

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

Google BigQuery ソース接続の変更データキャプチャを有効にする手順については、次のドキュメントを参照してください。

Snowflake

Snowflakeでchange data captureを使用するには、ソーステーブルで​ change tracking ​を有効にし、Experience Platformでリレーショナルスキーマを使用してData Mirrorを設定する必要があります。

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

ALTER TABLE mytable SET CHANGE_TRACKING = TRUE

詳細については、Snowflake 変更条項の使用に関するガイド ​を参照してください。

Snowflake ソース接続の変更データキャプチャを有効にする手順については、次のドキュメントを参照してください。

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