Flink CDC 是什么
Flink CDC 把 CDC 数据源封装成 Flink 连接器：mysql-cdc、postgres-cdc、oracle-cdc、mongo-cdc 等可以直接在 Flink SQL 里声明为一张表，然后像写普通 SQL 一样做过滤、关联与聚合。底层使用日志解析引擎读取变更，因此对源库的侵入很小。
为什么它比传统链路省事
传统做法是 CDC 工具先写入 Kafka，Flink 再从 Kafka 读，中间多一跳存储与一套运维；Flink CDC 让作业直接连接源库消费变更，省掉这一跳。2.x 引入的增量快照支持并发读取存量数据与断点续读，3.x 进一步提供 YAML 管道，用配置完成多表整库同步与表结构变更同步。
基本信息
| 定位 | Flink 生态的 CDC 连接器与整库同步工具 |
|---|---|
| 引擎 | 连接器底层基于 Debezium 引擎解析数据库日志 |
| 关键能力 | 增量快照（无锁并发读取）、checkpoint 提交位点、整库同步 |
| 入口 | Flink SQL、DataStream API，3.x 起支持 YAML pipeline |
| 前置条件 | 源库日志已开启且格式正确（MySQL 需 binlog_format=ROW） |
典型使用场景
- 实时宽表加工：CDC 源表与维表 join，持续产出宽表落库
- 整库同步：把多张表按配置一次性同步到目标存储（3.x 管道）
- 实时对账：把源库变更与目标端数据持续比对，尽早发现差异
- 轻量链路：不想额外维护 Kafka 时，用作业直连源库消费变更
- 实时看板：CDC 源表直接做分组聚合，输出到在线存储供查询
SQL 声明 CDC 源表并直接加工
SQL 声明 CDC 源表并直接加工
-- 源表：直接指向业务库表，底层按日志解析增量
CREATE TABLE orders (
order_id BIGINT,
user_id BIGINT,
amount DECIMAL(10,2),
status STRING,
update_time TIMESTAMP(3),
PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
'connector' = 'mysql-cdc',
'hostname' = '10.0.0.5',
'port' = '3306',
'username' = 'cdc_ro',
'password' = '******',
'database-name' = 'app',
'table-name' = 'orders',
'scan.startup.mode' = 'initial', -- 先做增量快照，再持续追变更
'server-time-zone' = 'Asia/Shanghai' -- 时区不匹配会导致时间字段整体偏移
);
-- 持续查询：按状态实时统计，结果随变更更新
SELECT status, COUNT(*) AS cnt, SUM(amount) AS amt FROM orders GROUP BY status;3.x 管道式整库同步（YAML 片段）
3.x 管道式整库同步（YAML 片段）
# 用配置文件描述源与目标，由 pipeline 作业完成多表同步
source:
type: mysql
hostname: 10.0.0.5
port: 3306
username: cdc_ro
password: '******'
tables: app\.orders,app\.order_items # 指定需要同步的表
sink:
type: values # 示例输出，实际可指向目标存储
pipeline:
name: mysql-to-dw
parallelism: 4关键点读法
| 要点 | 含义 | 注意 |
|---|---|---|
| scan.startup.mode | 首次启动读取位置：initial 做快照，latest-offset 只读新数据 | 选错会漏掉全部存量数据 |
| 增量快照 | 并发读取存量数据，过程中不加全表锁 | 大表快照期间对源库仍有读压力 |
| checkpoint | 位点与状态一起提交，故障后从快照恢复 | 不开启则每次重启都从头回放 |
| server-time-zone | 与源库一致的时区 | 不一致会让时间字段整体偏移数小时 |
| CDC 源表性质 | 持续变更的动态表，不是静态表 | 不能当维表反复全量扫描 |
CDC 源表在 Flink SQL 里是持续变更的流表：对它的查询是常驻作业，结果会随源端变更不断更新。把它当成批表反复扫描，会在源库上产生持续压力，也拖垮作业状态。
作业必须开启 checkpoint：位点随 checkpoint 提交，否则重启后要么从最早的位点重放导致重复，要么跳过中间变更造成缺数。