1. 课程导入
欢迎进入《Flink CDC金融主数据同步实战》。在开始写第一行配置之前，我们需要先建立一张清晰的“业务地图”：金融主数据同步到底在解决什么问题，它为什么比一般的数据同步更棘手，以及本课程会用什么样的技术路线把这些问题逐一拆解。本章不涉及复杂代码，但它是后续29章所有实操的认知地基。
一、业务背景：金融主数据为什么必须“同步”
金融主数据是贯穿银行、证券、保险、支付等机构的核心实体数据，典型对象包括客户、账户、产品、机构、协议、交易对手等。这些数据通常分散在多个业务系统中：核心银行系统维护账户与客户基本信息，信贷系统维护授信与担保关系，理财系统维护产品与持仓，风控系统维护黑名单与评级。每个系统都有自己的数据库，且往往由不同团队、不同时期、不同技术栈建设。
当客户在手机银行修改手机号，或柜面完成一笔账户冻结，或风控系统更新客户风险等级时，这些变更必须及时、准确地反映到下游的数据仓库、实时风控引擎、反洗钱系统、客户画像平台和监管报送系统中。如果同步延迟过高，风控可能基于过期信息放款；如果数据不一致，监管报送会出现口径偏差；如果同步链路中断，业务部门会直接失去对客户状态的实时感知。因此，金融主数据同步不是“锦上添花”的数据集成，而是支撑实时决策与合规运营的基础设施。
核心判断：金融主数据同步的目标不是“把数据搬过去”，而是“在正确的时间、以正确的顺序、把正确的变更、完整且可追溯地送达正确的下游”。
二、核心挑战：为什么传统方案在金融场景下容易失效
很多团队最初会采用“定时批量抽取 + 全量覆盖”的方式同步主数据。这种方式在数据量小、实时性要求低的场景下可以工作，但在金融主数据场景中会迅速暴露问题。我们可以从五个维度来理解这些挑战。
- 实时性要求高：风控、反欺诈、实时营销等场景要求秒级甚至亚秒级感知客户状态变化，T+1批量无法满足。
- 数据源异构且分散：Oracle、MySQL、DB2、PostgreSQL、MongoDB等多种数据库并存，部分系统还有主从架构和分库分表。
- 变更顺序与事务一致性：同一客户可能先改手机号、再改地址、再调整风险等级，下游必须按正确顺序应用，否则会出现状态回退。
- 对业务库零侵入或低侵入：核心银行系统不允许随意增加触发器、开归档日志或部署额外Agent，同步方案必须尽量旁路。
- 数据质量与合规审计：金融数据要求可追溯、可重放、可对账，任何丢失或重复都必须能被发现和修复。
这些挑战叠加在一起，使得“简单抽数”升级为“变更数据捕获 + 流式处理 + 一致性保障”的系统工程。Flink CDC正是在这一背景下成为金融主数据同步的主流技术选择：它通过读取数据库日志（如MySQL Binlog、Oracle Redo Log）捕获变更，借助Flink的流处理能力完成过滤、清洗、关联、路由和写入，并利用Checkpoint机制保障端到端一致性。
三、方法流程：一条可落地的金融主数据同步链路
把上面的挑战转化为工程动作，一条典型的金融主数据同步链路可以拆成六个阶段。理解这条链路，有助于你在后续章节中定位每个配置项和每段代码的作用。
- 变更捕获：通过Flink CDC Source连接业务库，读取Binlog或Redo Log，将INSERT、UPDATE、DELETE转换为Changelog事件。
- 数据清洗与标准化：对字段做类型映射、空值处理、编码转换、敏感字段脱敏，统一主数据模型。
- 关联与打宽：将客户、账户、产品等多张表的变更流按主键关联，形成下游可直接消费的宽表或主题数据。
- 路由与分发：根据业务规则将不同主数据路由到不同下游Topic或表，例如风控Topic、报送Topic、画像Topic。
- 写入与提交：通过Kafka、Doris、Hudi、JDBC等Sink写入目标系统，并借助Checkpoint实现Exactly-Once或至少一次加幂等。
- 监控与对账：采集延迟、积压、失败率、数据量差异等指标，定期与源端对账，形成闭环。
学习提示：后续章节会按照“环境准备 → Source配置 → 数据清洗 → 关联打宽 → Sink写入 → 一致性保障 → 监控运维 → 综合实战”的顺序展开。本章只需要记住这条主链路，不必急于记住所有参数。
四、案例与场景：一个客户手机号变更的完整旅程
假设某银行客户在手机银行把手机号从138****1234改为139****5678。这个看似简单的动作，在金融主数据同步链路中会经历如下过程：
| 阶段 | 发生位置 | 关键动作 | 失败后果 |
|---|---|---|---|
| 业务变更 | 核心银行系统 | 更新客户表手机号字段，写入Binlog | 业务本身成功，但下游无感知 |
| 变更捕获 | Flink CDC Source | 解析Binlog，生成+U事件 | 下游继续使用旧手机号 |
| 清洗标准化 | Flink算子 | 校验手机号格式，脱敏中间字段 | 脏数据进入下游 |
| 关联打宽 | Flink双流Join | 关联客户基本信息与账户信息 | 下游缺少上下文 |
| 路由分发 | Flink侧输出流 | 分别发送到风控、画像、报送Topic | 部分下游漏收 |
| 写入下游 | Kafka / Doris Sink | 幂等写入，提交偏移量 | 重复或丢失 |
| 监控对账 | 监控平台 | 比对源端与目标端手机号 | 问题无法及时发现 |
这个案例说明：金融主数据同步的难点不在单点技术，而在链路的完整性与一致性。任何一个环节缺失，都会导致下游看到错误或过期的客户信息。
五、常见误区与复盘
误区一：把CDC当成“全量同步工具”。CDC的核心价值是捕获增量变更，全量初始化只是启动阶段的一次性动作。如果每次同步都做全量覆盖，会放大业务库压力并丢失变更顺序。
误区二：忽略Changelog语义。UPDATE在CDC中通常表现为“-U旧值 +U新值”，如果下游只处理+U而不处理-U，聚合结果会重复计算。
误区三：认为开启Checkpoint就自动Exactly-Once。端到端一致性还依赖Sink的幂等或事务能力，以及Source偏移量与状态的一致性快照。
误区四：不做对账。金融场景必须假设“链路可能出错”，通过定期对账发现差异，而不是等业务投诉。
复盘这些误区，可以提炼出三条原则：第一，以变更流为中心，而不是以表为中心；第二，顺序与一致性优先于吞吐，尤其在客户状态、账户余额等敏感数据上；第三，可观测性是一等公民，没有监控和对账的同步链路不具备生产可用性。
六、学习目标与课程框架
完成本课程后，你应该能够独立设计并实现一条面向金融主数据的Flink CDC同步链路，具体目标包括：
- 理解Flink CDC的底层原理、Changelog语义与一致性模型；
- 能够配置MySQL、Oracle等主流数据源的CDC Source，并处理常见连接与权限问题；
- 能够使用Flink SQL和DataStream API完成主数据清洗、关联、路由与打宽；
- 能够将变更流可靠写入Kafka、Doris、Hudi、JDBC等下游系统；
- 能够设计Checkpoint、重启策略、幂等写入与对账方案，保障端到端一致性；
- 能够搭建监控告警体系，定位延迟、积压、数据倾斜与失败任务。
课程整体分为八个模块：基础与环境准备、CDC Source深入、数据清洗与标准化、多流关联与打宽、Sink与下游集成、一致性与容错、监控与运维、综合实战项目。每个模块都会围绕真实金融场景展开，并配有可运行的配置与代码片段。
# 本课程后续会反复使用的一条最小CDC SQL示例
CREATE TABLE customer_source (
customer_id BIGINT,
customer_name STRING,
phone STRING,
risk_level STRING,
update_time TIMESTAMP(3),
PRIMARY KEY (customer_id) NOT ENFORCED
) WITH (
'connector' = 'mysql-cdc',
'hostname' = '10.0.0.10',
'port' = '3306',
'username' = 'cdc_user',
'password' = '******',
'database-name' = 'core_bank',
'table-name' = 'customer',
'server-time-zone' = 'Asia/Shanghai'
);