2. 金融主数据概述
在进入 Flink CDC 的技术细节之前，必须先厘清一个根本问题：我们到底在同步什么数据？如果连“主数据”的边界都没有界定清楚，后续的采集、转换、分发都会失去准绳。本节从主数据的定义出发，逐层展开金融行业的分类体系、治理约束，以及实时同步在其中的价值定位。
一、主数据定义：不是所有数据都叫主数据
主数据（Master Data）是指描述企业核心业务实体、在整个组织范围内被多个业务系统共享、且相对稳定但需要持续维护的一致性数据。它回答的是“谁、什么、哪里”这类基础问题，而不是“发生了什么”这类交易问题。
可以用一个判断清单来界定一条数据是否属于主数据：
- 共享性：是否被两个以上业务系统引用？只在一个系统内部使用的数据通常不是主数据。
- 实体性：是否描述一个可识别的业务实体（客户、产品、机构、账户）？
- 稳定性：是否变化频率较低，但一旦变化影响面很广？
- 权威性：是否存在一个权威源系统（System of Record）对其负责？
与之相对的是交易数据（如转账流水、成交记录）和分析数据（如报表指标）。交易数据描述“事件”，量大且持续增长；主数据描述“对象”，量相对可控但质量要求极高。二者的同步策略、时效要求和治理方式完全不同。
二、金融行业主数据分类
金融行业的主数据分类比一般行业更细，因为它同时受到业务复杂性和监管要求的双重约束。常见的分类维度如下表所示：
| 主数据域 | 典型实体 | 权威源系统 | 变化特征 |
|---|---|---|---|
| 客户主数据 | 个人客户、对公客户、集团客户 | CRM / 客户信息系统 | 中低频，但涉及敏感信息 |
| 产品主数据 | 存款产品、理财产品、基金、保险 | 产品管理系统 | 低频，版本化管理 |
| 机构主数据 | 分支机构、网点、部门、法人 | 组织架构系统 | 极低频 |
| 账户主数据 | 存款账户、证券账户、支付账户 | 核心系统 / 账户系统 | 中频，开户销户频繁 |
| 协议主数据 | 合约、协议、授信额度 | 信贷 / 合约系统 | 中频，状态流转多 |
| 参考数据 | 币种、汇率、国家、行业代码 | 数据标准平台 | 低频，但要求全局一致 |
这张表揭示了一个关键事实：不同主数据域的变化频率、敏感级别和权威源各不相同。客户主数据涉及个人信息保护，产品主数据涉及版本追溯，参考数据涉及全局一致性。因此，同步方案不能“一刀切”，而应按域制定差异化的采集频率、脱敏策略和分发范围。
三、数据治理要求：同步不是搬运，而是受控流转
金融行业的数据治理要求，决定了主数据同步不能是简单的“从 A 库复制到 B 库”。至少需要满足以下约束：
- 唯一权威源：每个主数据实体必须有且只有一个权威源，同步链路只能从权威源向外单向流动，禁止反向写入造成多源冲突。
- 数据标准：字段命名、编码规则、值域范围必须遵循企业数据标准，同步过程中需完成标准化映射。
- 质量校验：同步前后需校验完整性、唯一性、一致性，异常数据应进入隔离区而非直接污染下游。
- 安全合规：客户敏感字段需脱敏或加密传输，访问需审计留痕，满足个人信息保护与监管报送要求。
- 可追溯：每一次主数据变更都应能追溯到来源、时间、操作者和变更内容。
四、同步价值：从 T+1 到秒级一致
传统主数据同步多采用批量抽取，T+1 甚至 T+7 的延迟在金融场景下会带来实质性问题：新开户客户在风控系统中查不到、产品下架后交易系统仍可下单、机构调整后报表口径错乱。实时同步的价值正体现在这些“时间窗口”上。
结合 Flink CDC 的能力，主数据同步的价值可以归纳为三点：
- 时效性：基于数据库日志的变更捕获，将主数据变更从小时级压缩到秒级，消除业务系统间的信息差。
- 一致性：以权威源日志为唯一事实来源，保证变更顺序和内容不失真，避免批量抽取中的快照错位。
- 可扩展：一份变更流可同时分发给风控、报表、数据仓库、营销等多个下游，无需为每个下游单独开发抽取逻辑。
下面的示意图展示了金融主数据从权威源到多下游的受控同步结构，以及治理约束在链路中的位置：
从图中可以看到，治理约束并非事后检查，而是嵌入在从权威源到同步引擎的整条链路上。Flink CDC 承担的是“受控流转”的执行角色，而权威源界定、标准映射、脱敏规则等治理决策，需要在同步任务设计之前就明确下来。