在API中为源连接启用更改数据捕获

在Adobe Experience Platform源中使用变更数据捕获,使您的源和目标系统近乎实时地保持同步。

Experience Platform当前支持​ 增量数据副本,该副本会定期将新创建或更新的记录从源系统传输到摄取的数据集。 此方法依赖于​ 时间戳列 ​来跟踪更改,但它不检测删除,这可能会导致数据随时间而出现不一致。

相反,变更数据捕获会近乎实时地捕获并应用插入、更新和删除。 这一全面的更改跟踪确保数据集与源系统保持完全一致,并提供完整的更改历史记录,超出增量拷贝所支持的范围。 但是,删除操作需要特别考虑,因为它们会影响使用目标数据集的所有应用程序。

Experience Platform中的变更数据捕获需要​ Data Mirror ​和基于模型的架构(也称为关系架构)。 您可以通过两种方式将更改数据提供给Data Mirror:

这两种方法都要求具有基于模型的架构的Data Mirror保持关系并强制实施唯一性。

带有基于模型的架构的Data Mirror

AVAILABILITY
Data Mirror和基于模型的架构可供Adobe Journey Optimizer 协调的营销活动 ​许可证持有人使用。 根据您的许可证和功能启用,它们也可用作Customer Journey Analytics用户的​ 有限版本。 请联系您的Adobe代表以获取访问权限。
NOTE
协调的营销活动用户:使用本文档中介绍的Data Mirror功能处理保持引用完整性的客户数据。 即使您的源不使用变更数据捕获格式,Data Mirror也支持关系功能,例如主键实施、记录级别更新插入和架构关系。 这些功能可确保跨连接的数据集进行一致且可靠的数据建模。

Data Mirror使用基于模型的架构来扩展变更数据捕获并启用高级数据库同步功能。 有关Data Mirror的概述,请参阅Data Mirror概述

基于模型的架构扩展了Experience Platform以强制实施主键唯一性、跟踪行级更改和定义架构级关系。 使用变更数据捕获,它们直接在数据湖中应用插入、更新和删除,从而减少了对提取、转换、加载(ETL)或手动协调的需要。

有关详细信息,请参阅基于模型的架构概述

变更数据捕获的基于模型的架构要求

在将基于模型的方案用于变更数据捕获之前,请配置以下标识符:

  • 用主键唯一地标识每个记录。
  • 使用版本标识符按顺序应用更新。
  • 对于时间序列架构,请添加时间戳标识符。

控制列处理 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 (upsert)或u (delete)的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一起使用,您必须在源表中启用​ 变更数据馈送,并在Experience Platform中使用基于模型的架构配置Data Mirror。

使用以下命令在表上启用更改数据馈送:

新表

要将更改数据馈送应用到新表,必须在delta.enableChangeDataFeed命令中将表属性TRUE设置为CREATE TABLE

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

现有表

要将更改数据馈送应用于现有表,必须在delta.enableChangeDataFeed命令中将表属性TRUE设置为ALTER 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一起使用,您必须在源表中启用​ 变更数据馈送,并在Experience Platform中使用基于模型的架构配置Data Mirror。

请阅读以下文档,以了解如何为Data Landing Zone源连接启用更改数据捕获的步骤:

Google BigQuery

要对Google BigQuery使用变更数据捕获,您必须在源表中启用变更历史记录,并在Experience Platform中为Data Mirror配置基于模型的架构。

要在Google BigQuery源连接中启用更改历史记录,请在Google BigQuery控制台中导航到您的Google Cloud页面,并将enable_change_history设置为TRUE。 此属性启用数据表的更改历史记录。

有关详细信息,请阅读 GoogleSQL中数据定义语言语句的指南。

请阅读以下文档,以了解如何为Google BigQuery源连接启用更改数据捕获的步骤:

Snowflake

若要通过Snowflake使用变更数据捕获,您必须在源表中启用​ 变更跟踪,并在Experience Platform中为Data Mirror配置基于模型的架构。

在Snowflake中,通过使用ALTER TABLE并将CHANGE_TRACKING设置为TRUE来启用更改跟踪。

ALTER TABLE mytable SET CHANGE_TRACKING = TRUE

有关详细信息,请阅读有关使用changes子句Snowflake 的指南。

请阅读以下文档,以了解如何为Snowflake源连接启用更改数据捕获的步骤:

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