palantir深度解析（九）

Palantir Foundry 变更数据捕获（CDC）

一、CDC的核心定义与本质：解决什么核心问题？

1. 一句话大白话定义

变更数据捕获（Change Data Capture，简称CDC），是一种实时捕获业务数据库里「增、删、改」操作的技术。它会把数据库里每一行数据的每一次变更（新增客户、修改维修工单、删除无效记录），都实时生成一条变更日志，同步到Foundry中，最终还原出和源数据库完全一致的最新数据视图。

它是你之前学习的批量同步（Batch Sync） 的升级替代方案，专门解决批量同步的核心痛点：

二、CDC的核心底层逻辑：变更日志三要素 + 数据还原策略

CDC的核心是把数据库的每一次变更，变成一条可追溯的变更日志，再通过固定规则，把日志还原成源库的最新数据视图。文档里明确了CDC必须满足的3个核心元数据要求，以及标准的还原策略，这是所有CDC功能的基础。

1. 变更日志的三大核心必填要素（文档强制要求）

每一条CDC变更日志，必须包含这三类字段，否则无法完成数据还原，完全对应你截图里的配置：

2. CDC标准数据还原策略（文档核心规则）

有了上面的三要素，Foundry就可以通过固定的3步，把零散的变更日志，折叠成和源数据库完全一致的最新数据视图，这个过程也叫「变更日志解析」：

1. 按主键分组：把所有变更日志，按主键列分组，同一个主键的所有变更（增、删、改）分到一组；
2. 取排序列最大值的条目：在每个主键的分组里，找到排序列数值最大的那条日志——也就是这行数据的最后一次变更；
3. 判断删除标记：如果这条最新的日志，删除列的值是true，就把这行数据从最终视图里移除；如果是false，就保留这条日志的内容，作为这行数据的最新状态。

举个直观的例子

假设你的工单表，主键是工单编号，排序列是操作时间戳，删除列是是否删除，变更日志如下：

按照还原策略：

1. 按主键WO001分组；
2. 取排序列最大值1004的那条日志；
3. 删除列是false，保留这条数据；
4. 最终视图里，WO001工单的状态是「已完成」，和源数据库里的最新状态完全一致。

如果新增一条日志：

那最终视图里，WO001这行数据会被移除，和源数据库里删除这条数据的操作完全同步。

三、Foundry中CDC的全链路实操流程

文档里明确了Foundry中使用CDC的完整流程，从源库配置到最终数据落地，每一步都和你的截图完全对应，下面逐环节拆解：

第一步：在源数据库启用CDC功能

要捕获数据库的变更日志，首先要在源数据库里开启CDC功能，让数据库开始记录所有的增删改操作。 文档里给了SQL Server的标准启用脚本，分为两步：

1. 给整个数据库开启CDC：

USE 你的业务数据库名
GO
EXEC sys.sp_cdc_enable_db  -- 给当前数据库开启CDC功能
GO

1. 给需要同步的单张表开启CDC：

EXEC sys.sp_cdc_enable_table
    @source_schema = N'dbo',        -- 表所属的Schema
    @source_name = N'Customers',    -- 要同步的表名
    @role_name = NULL,               -- 访问权限角色，NULL表示无限制
    @supports_net_changes = 0,
    @filegroup_name = N'PRIMARY';
GO

其他数据库（PostgreSQL、MySQL、Oracle）也有对应的CDC开启方式，需要参考对应数据库的官方文档。

第二步：在Foundry数据连接中配置CDC源

源库开启CDC后，需要在Foundry的「数据连接」应用里，创建一个指向源数据库的CDC源，截图1就是SQL Server CDC源的配置页面：

1. 连接详情配置：
   • 主机类型：选Hostname（主机名），也可以填IPv4/IPv6地址；
   • Hostname：源SQL Server数据库的主机地址；
   • Port：数据库端口，SQL Server默认是1433；
   • Database name：你开启了CDC的数据库名；
2. 认证配置：选择数据库的认证方式，最常用的是Username/Password（用户名+密码），也支持Active Directory等企业级认证方式；
3. 配置完成后保存，完成源连接的创建。

第三步：创建CDC同步任务

源连接创建完成后，就可以创建CDC同步任务，把源库的变更日志同步到Foundry中：

1. 进入源的概览页面，找到CDC syncs模块（截图2红框），点击Create CDC sync创建同步任务；
2. 选择要同步的源表（截图3里的dbo.Customers），Foundry会自动做两件事：
   • 自动推导输出流的Schema，把源表的字段、类型完整映射过来；
   • 自动识别变更日志元数据：主键列、排序列（__timestamp）、删除列（__is_deleted），无需手动配置；
3. 配置流的吞吐量：默认是5MB/s，对于绝大多数业务数据库的CDC场景完全足够（业务数据库的变更都是人工操作的，远小于机器传感器的数据流）；
4. 配置输出位置，保存同步任务，Foundry会自动创建一个流（Stream） 作为CDC同步的输出。

关键注意事项

• CDC任务在修改配置后，必须手动重启才能生效；
• 同一个源的所有CDC同步，会作为一个多输出任务运行，新增/删除同步表时，需要短暂停止现有CDC流，重启后会自动补全停机期间的变更数据，不会丢失。

第四步：查看CDC同步的流数据

CDC同步任务启动后，变更日志会实时流入Foundry的流中，文档明确了CDC流有两个核心视图，对应截图4的下拉选项：

1. Live（实时视图）
   • 对应文档里的「完全展开的变更日志条目列表」，展示所有的原始变更日志，每一次增删改都会单独显示一行；
   • 数据来自流的热缓冲区，是秒级实时的最新变更数据，适合监控实时变更情况。
2. Archive（归档视图）
   • 对应文档里的「按解析策略折叠后的最新数据视图」，也就是我们上面讲的CDC还原策略处理后的、和源库完全一致的最新数据；
   • 数据来自流的冷存储归档，是结构化的数据集，和普通的Foundry数据集完全一致，可用于下游流水线、分析、Ontology建模。

同时，在流的Details → Schema页面（截图5），可以看到完整的CDC变更日志元数据配置：

• 主键列：CustomerId；
• 解析策略：latestWins（按排序列取最新值）；
• 排序列：__timestamp；
• 删除列：__is_deleted； 你可以在这里手动编辑、修改这些配置，适配自定义的变更日志格式。

四、CDC在Foundry全平台的应用能力

文档里明确了CDC数据可以在Foundry的所有核心组件中使用，和你之前学习的能力完全打通：

1. 在Pipeline Builder中处理CDC数据

Pipeline Builder是处理CDC数据的核心工具，支持两种核心操作：

1. 自动传播元数据：只要你不对主键、排序列、删除列做修改，CDC的变更日志元数据会自动在流水线的输出流中传播，下游可以继续使用CDC的解析能力；
2. 手动配置CDC元数据（Key By算子）：如果你的输入流没有自带CDC元数据（比如从Kafka同步的自定义变更日志），可以用截图6里的Key By算子，手动给数据配置CDC元数据：
   • Key by columns：选主键列；
   • Primary key ordering columns：选排序列；
   • Primary key is deleted column：选删除列； 配置完成后，输出的流就会自带CDC元数据，和原生CDC同步的流完全一致。

2. 在Ontology中使用CDC数据

CDC是Ontology实现实时数据更新的最佳方式，文档明确了核心规则：

• Ontology会用CDC的变更日志元数据，把流数据实时索引到Object Storage V2中，生成实时更新的业务对象；
• 源数据库里的工单新增、状态修改、删除，会实时同步到Ontology的对象中，Workshop里的业务应用可以立刻看到最新数据；
• 关键坑点（文档重点提醒）：Ontology会忽略CDC元数据里的排序列，只按数据到达Foundry的顺序索引数据。如果数据乱序到达（比如回填历史数据），会导致Ontology里的数据和源库不一致。
  • 解决方案：在Pipeline Builder里先给数据按排序列做重排序，再同步到Ontology中。

3. 在Workshop中使用CDC数据

Workshop原生支持CDC数据的自动刷新：只要Ontology里的对象通过CDC实时更新了，Workshop里的表格、图表、详情页会自动刷新，展示最新的数据，无需用户手动刷新页面。

• 典型场景：维修调度大屏，工单状态实时更新、配件库存实时变化，完全不需要人工干预。

五、CDC使用的关键注意事项与最佳实践（文档重点）

1. 历史数据回填（Backfill）

文档明确：CDC同步仅处理开启后的实时变更，不会自动回填历史数据。

• 原因：大多数数据库默认不开启CDC，开启前的变更日志不会被记录，无法自动回溯；就算开启了CDC，变更日志也有保留期，过期会被删除。
• 官方推荐的回填方案：
  1. 先启动CDC流，实时捕获新增的变更；
  2. 做一次批量同步，把源表的全量历史数据同步到Foundry；
  3. 把历史批量数据转换成「创建记录」的变更日志，合并到CDC流中；
  4. 回填后如果出现数据乱序，在Pipeline Builder里手动重排序，再同步到Ontology。

（1） 为什么要「先启动 CDC 流，再做批量同步」？—— 为了不丢数据

如果反过来：先做批量同步，再启动 CDC 流，会出现一个致命问题：

批量同步需要时间（比如几小时、几天），在这段时间里，源库可能又产生了新的“增删改”操作；

等你批量同步完再开 CDC，这中间产生的新变更就完全漏掉了，Foundry 里的数据会比源库少一截。

而先开 CDC 流，相当于先给源库“装了个监控”，把批量同步期间产生的所有新变更先实时抓下来存着；等批量同步完历史 数据，再把这段时间存的新变更补进去，这样就100% 不会丢数据。

（2）为什么要「把历史批量数据转换成‘创建记录’的变更日志，合并到 CDC 流中」？—— 为了让下游统一处理

这里有两个关键原因：

（1）格式统一：下游只认“变更日志”

Foundry 下游的 Pipeline、Ontology 都是专门为 CDC 变更日志设计的，它们只认“创建、更新、删除”这种带元数据的变更 格式，不认普通的批量静态数据。 如果不把历史批量数据转成变更日志，下游就得写两套逻辑：一套处理批量历史数据，一套处理 CDC 实时变更，维护成本极高，还容易出错。

（2）逻辑统一：历史数据也是一种“变更”

从 CDC 的视角看，“历史全量数据”本质上就是**“在过去某个时间点，一次性创建了所有这些记录”**。把它转成“创建记录”的 变更日志，就能和后续的实时变更完美合并成一条完整的“时间线”，下游可以按统一的逻辑处理，不用区分“历史”和“实时”。

（3）为什么要「回填后如果出现数据乱序，手动重排序」？—— 为了保证数据状态正确

数据乱序是这个方案最容易出现的问题，原因很现实：

批量同步可能很慢（比如同步 1 年的历史数据要 10 小时），而在这 10 小时里，CDC 已经实时抓了很多新变更（比如“更新 了某条记录”“删除了某条记录”）；

当你把历史批量数据转成“创建记录”的变更日志时，这些“创建”的时间戳是过去的时间（比如 1 年前），而 CDC 抓的新变更时间戳是现在的时间（比如 10 小时前到现在）；

但在合并流的时候，可能因为处理速度、网络延迟等原因，出现**“现在的更新”先到，“过去的创建”后到**的情况——下游如果先执行了“更新”，再执行“创建”，就会导致数据完全错乱（比如“更新了一条不存在的记录”，或者“创建覆盖了更新后的状态”）。

所以必须手动重排序，把所有变更（历史创建 + 实时变更）严格按源库的真实时间顺序重新排一遍，保证下游按“先创建、再更新、最后删除”的顺序执行，这样最终的数据状态才和源库完全一致。

先开 CDC 抓新变更（防丢）→ 批量同步补历史（补全）→ 转格式合并（统一处理）→ 重排序（保证正确）

2. 停机处理

CDC同步过程中，可能出现网络中断、数据库停机、Foundry停机、代理停机等情况，文档给出了标准解决方案：

• 核心原则：只要源数据库的变更日志保留窗口，大于最大预期停机时间，就不会丢失数据。
• 举个例子：SQL Server的变更日志保留窗口设置为7天，就算网络中断3天，恢复连接后，Foundry会自动补全这3天的所有变更数据，不会丢失，只是会有短暂的延迟，直到追上最新的变更。

3. 非CDC源的CDC数据使用

文档明确：不是只有数据库原生CDC同步的数据，才能用CDC能力。 任何流数据，只要你给它配置了主键、排序列、删除列这三要素，就可以当成CDC数据使用，比如：

• 从Kafka、MQTT等消息中间件同步的业务变更日志；
• 自定义程序生成的设备状态变更流；
• 从第三方系统API推送的实时数据。

4. 移除CDC元数据

如果不需要CDC解析能力，只想分析原始的变更日志，可以通过两种方式移除CDC元数据：

1. 在Pipeline Builder里对主键、排序列、删除列做任意变换，元数据会自动移除；
2. 手动在流的Schema页面，删除解析策略的配置，移除CDC元数据。

CDC 元数据到底是个啥？

它不是你业务表里的字段（比如姓名、金额、时间），而是系统为了正确处理 CDC 变更流，额外带的一套 “说明书数据”，主要包括这几类：

哪一列是主键（用来定位哪一行）

哪一列是排序列（保证变更先后顺序）

哪一列是删除标记（识别是不是删除操作）

变更类型：insert /update/delete

变更时间、事务序号、源库位置等

这些信息合在一起，就叫 CDC 元数据。

六、CDC与之前学习内容的完整闭环

CDC能力和你之前学习的所有Foundry核心能力，形成了完整的实时数据链路闭环：

1. 数据接入：通过数据连接的CDC同步，把业务数据库的实时变更，同步到Foundry的流中；
2. 数据加工：在Pipeline Builder中对CDC流做清洗、关联、聚合，同时保留CDC元数据；
3. 数据存储：流的热缓冲区存储实时变更数据，冷存储自动归档为结构化数据集，支持历史数据回溯；
4. 语义建模：把CDC流同步到Ontology中，生成实时更新的业务对象；
5. 业务应用：在Workshop中搭建实时调度大屏、客户管理应用，通过自动刷新展示最新的业务数据；
6. 运维监控：通过健康检查监控CDC流的运行状态、数据新鲜度，异常时自动告警；
7. 调度自动化：通过调度配置下游加工流水线，实现实时数据的自动化处理。