注意:以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。
变更数据捕获 ↗ (CDC) 是一种企业数据集成模式,通常用于将实时更新从关系数据库流式传输到其他使用者。
Foundry 支持同步、处理和存储来自生成变更数据捕获馈送的系统的数据。平台中的组件,包括数据连接器、流、管道和Foundry Ontology,都可以使用配置在底层数据架构上的元数据本地处理此变更日志数据。
变更日志元数据要求数据具备以下属性:
此变更日志元数据用于指定一种解决策略,以将变更日志解析为源系统中数据的当前视图。变更数据捕获的解决策略如下:
true
,则将其移除。经过这些步骤后,变更日志现在应折叠为与上游源系统中生成的变更日志相同的视图。不同的 Palantir 组件以不同的方式使用变更日志元数据和解决策略,如下所述。
数据连接中可用的源可能支持以流的形式同步来自系统的数据,并应用变更日志元数据。源实现同步变更日志数据的功能取决于源系统生成具有所需属性(主键列、排序列和删除列)的日志数据的能力。
包括 MySQL、PostgreSQL、Oracle、Db2 和 SQL Server 在内的许多常用数据库都可以生成 CDC 变更日志数据。Foundry 中这些系统的数据连接器可能支持或不支持直接同步这些变更日志。即使连接器当前不支持 CDC 同步,您仍然可以通过 Kafka 或其他流式中间件同步数据,并在数据到达 Foundry 后用作变更日志。
数据连接中当前支持 CDC 同步的源类型如下:
此外,通过一个实验性连接器还可以使用以下系统的 CDC 同步。如果您想使用此连接器,请联系您的 Palantir 代表。
如果您从其他来源(如 Kafka、Kinesis、Amazon SQS 或基于推送的流集成)获得了变更日志形状的数据,请阅读如何在管道构建器中使用按键面板手动配置变更日志元数据。
要从支持的源类型同步变更日志馈送,您必须为相关表启用正确的设置,并且在某些情况下,还需为整个数据库启用这些设置。
例如,要为 Microsoft SQL Server 启用变更数据捕获,您必须运行一个命令以在数据库上启用 CDC:
Copied!1 2 3 4
USE <database> -- 使用指定的数据库 GO EXEC sys.sp_cdc_enable_db -- 启用当前数据库的更改数据捕获 (Change Data Capture) GO
然后,在每个应该记录更改日志的表上运行另一个命令:
Copied!1 2 3 4 5 6 7 8
EXEC sys.sp_cdc_enable_table @source_schema = N'<schema>' -- 源模式名称 , @source_name = N'<table_name>' -- 源表名称 , @role_name = NULL -- 角色名称,NULL表示没有特定角色 , @capture_instance = NULL -- 捕获实例名称,NULL表示使用默认实例名称 , @supports_net_changes = 0 -- 是否支持网络更改,0表示不支持 , @filegroup_name = N'PRIMARY'; -- 使用的文件组名称 GO
这个SQL脚本用于启用SQL Server中的表的更改数据捕获(CDC)。 上述示例提供了启用源系统生成变更日志数据可能需要的高层次解释。有关如何为特定系统启用变更数据捕获日志的详细信息,请参阅该系统提供的文档。
现在,您可以在数据连接中配置一个源,该源连接到您想要捕获变更日志的系统。继续我们的示例,使用Microsoft SQL Server连接器设置连接,如下所示:
在源概览页面上,您将看到一个空的CDC同步表。
选择创建CDC同步以添加新的变更数据捕获同步。指定您希望同步的表,以下信息将由连接器自动推导:
与其他流一样,您必须在创建时指定预期的吞吐量。同步创建后吞吐量无法更改;确保您的流配置支持预期的变更日志数据量。默认容量为5MB/s,这通常超过大多数变更数据捕获工作流所需。由于关系数据库中的变更通常以“人类规模”产生,变更的量和频率远小于“机器规模”传感器或设备数据所能达到的量。
保存同步配置以在指定的输出位置创建新的流。
当前,CDC任务在任何更改后必须手动(重新)启动。所有CDC同步作为单一多输出提取任务运行,这意味着每当添加或移除feed时,必须短暂停止来自同一源的任何现有CDC流。流将优雅地赶上在流同步任务停止期间更改的数据。
在启动输出流后,变更日志数据应开始流动并出现在输出流数据集的实时视图中。
具有变更日志元数据的流将显示两种数据视图:
模式将在详细视图中显示变更日志元数据作为主键解析策略。
流当前使用排序列进行解析。这意味着即使数据是乱序接收的,数据也将在存档中根据提供的排序列解析。这种行为不同于Foundry Ontology中的变更日志数据行为,后者根据在流中到达的顺序索引数据以支持对象类型。
Pipeline Builder中的流变换可用于处理变更日志数据。只要变换未更改元数据列,变更日志元数据将自动在任何输出上传播。
如果输入流没有变更日志元数据或元数据列被管道变换,您可以使用“key by”看板对数据进行“key”并在输出上应用变更日志元数据。
Ontology使用变更日志元数据将数据索引到由流数据源支持的Object Storage V2中的对象类型。流中到达的数据被解析并索引到一个最新的当前视图中,该视图在查询Ontology时可用(例如,用于在Workshop模块中显示)。
如果在具有变更日志元数据的数据源上配置了保留,则在保留窗口时间内未收到更新的任何记录将在Ontology中消失。
Ontology当前忽略变更日志元数据中指定的排序列。相反,Object Storage V2根据数据到达支持数据源的顺序索引数据。具体而言,这意味着对于给定的主键,如果一个排序值为2
的日志条目在t1
到达并且data_column=foo
,随后一个排序值为1
的日志条目在t2
到达并且data_column=bar
,记录将显示为data_column=bar
,即使在源系统中最新值为data_column=foo
。这可能导致Ontology错误地反映源系统中的数据,如果数据乱序到达。
由于与Palantir一起使用的连接器保证按顺序传输数据,并且Foundry流保持排序,这种Ontology行为可能只会影响自定义设置或手动回填且在同步前未重新排序的旧流变更日志。如果您遇到这种情况,我们建议在同步到Ontology之前在Pipeline Builder中应用变换以重新排序数据。
Workshop支持自动刷新以在数据在Ontology中可用时立即显示频繁更新的数据。自动刷新与CDC兼容,可以用于确保通过变更数据捕获流入的数据能够及时在Workshop应用程序中使用。
对于预计在Workshop模块打开期间频繁更新的任何数据,自动刷新可用。数据无需在支持数据源上具有变更日志元数据即可使用自动刷新。
我们建议在使用CDC工作流前查看以下有关回填、停机和其他已知限制的信息。
所有变更日志同步均以“向前进行”的方式处理;不执行自动回填。
通常,变更日志的完整回填是不可能的,因为大多数系统默认不启用CDC。即使启用了变更日志,大多数系统也包括一个保留期,超过此期限后变更日志将被永久删除且无法恢复。
如果需要完整回填,我们建议如下操作:
回填可能导致数据乱序,您可能需要手动重新排序或重放流以正确准备数据以同步到Ontology。
使用CDC工作流时,您可能会遇到以下停机:
如果数据库中的复制日志和变更日志上的保留窗口配置得比最大预期停机时间长,停机将得到优雅处理。
例如,如果到Foundry的连接中断了几个小时,并且Microsoft SQL Server上的日志保留窗口设置为一天,数据库将继续记录变更日志条目。一旦Foundry重新上线并重新连接到Microsoft SQL Server,Foundry将优雅地赶上。由于在清除变更日志条目的队列之前不会有新数据流入,因此可能会有一些延迟,直到变更再次以接近实时的速度流入Palantir。
数据不需要以变更日志形式摄取以使用CDC工作流。Palantir中的任何流数据都可以用变更日志元数据进行“key”,然后在同步到Ontology后用作工作流中的CDC数据。
这意味着,例如,可以使用流代理手动将变更日志形状的记录推送到流中。
类似地,如果变更日志数据在Kafka主题中可用,可以使用标准(非CDC)同步进行摄取。然后,可以使用Pipeline Builder对其进行“key”,并在Ontology及其他地方使用。
有时,移除变更日志元数据可能是有用的。例如,您可能希望移除元数据以分析变更日志捕获的流程。要移除变更日志元数据,请使用以下方法之一: