一、背景为什么需要 CDC1.1 传统数据集成的痛点在数据仓库和数据湖建设中将业务数据库的数据同步到分析系统是最基础也最关键的环节。传统方案主要有两种方案原理问题全量定时抽取如 DataX/Sqoop定期 SELECT 全表数据延迟高通常 T1、资源浪费大、对源库压力大基于时间戳增量抽取按 update_time 字段拉取增量无法捕获删除操作、依赖业务表设计、时间窗口容易遗漏数据这两种方式的核心缺陷在于无法实时感知数据变更且对业务系统存在侵入性。1.2 CDC 技术的演进CDCChange Data Capture变更数据捕获技术通过监听数据库日志如 MySQL Binlog、PostgreSQL WAL来捕获数据变更天然具备实时性变更即时捕获端到端延迟可达亚秒级完整性INSERT / UPDATE / DELETE 全部捕获不遗漏低侵入读取日志而非查询表对源库几乎无影响CDC 领域的关键里程碑时间事件意义2011LinkedIn 开源 Databus早期 CDC 方案绑定特定数据库2017Debezium 1.0 发布基于 Kafka Connect 的通用 CDC 框架2020Flink CDC 1.0 发布将 CDC 与流计算深度融合2021Flink CDC 2.0 发布增量快照算法无锁并发读取2023.12Flink CDC 3.0 发布YAML Pipeline端到端数据集成平台2024.05Flink CDC 3.1加入 Apache Flink 子项目transform route 能力2025.05Flink CDC 3.4 发布新增 Iceberg sink、Batch 执行模式1.3 Flink CDC 的定位Flink CDC 是 Apache Flink 的子项目定位为「分布式实时数据集成工具」它可以把数据库表的全量数据和增量变更数据接入 Flink使数据库表在 Flink 中表现为一张持续变化的动态表。与传统 Debezium Kafka 方案相比它最大的差异是去除了中间件依赖将 Source → Transform → Sink 整合为单一 Flink 作业降低了架构复杂度和运维成本。从使用视角看Flink CDC 通常有两类能力Flink SQL / Table API Source Connector在 Flink SQL 中通过CREATE TABLE ... WITH (connector mysql-cdc)等方式定义 CDC 源表适合实时 ETL、实时宽表、实时数仓建模。Flink CDC Pipeline / Data Integration 能力通过 YAML 等声明式方式定义 source、sink、route、transform 等更偏向端到端数据同步与整库同步。二、架构设计与核心原理2.1 整体架构Flink CDC 3.xFlink CDC 3.x 采用四层架构设计2.2 数据模型抽象Flink CDC 将外部系统的存储对象统一抽象为「表Table」每个表由 Table IDnamespace schemaName tableName 三元组唯一标识。内部数据流基于 Event 接口传输分为两类DataChangeEvent数据变更事件包含before变更前和after变更后字段值类型有 INSERT / UPDATE / DELETE / REPLACESchemaChangeEvent结构变更事件包含 AddColumn、DropColumn、AlterColumnType、RenameColumn、CreateTable、DropTable、TruncateTable 等2.3 核心算法增量快照Incremental Snapshot增量快照算法是 Flink CDC 的核心创新借鉴 Netflix DBLog 论文解决了传统 CDC 全量阶段需要锁表的致命问题。关键优势无锁设计全程不需要FLUSH TABLES WITH READ LOCK对线上业务零影响并发读取多个 SourceReader 并行处理不同 Chunk水平扩展能力强断点续传基于 Flink Checkpoint 机制支持 Chunk 粒度的故障恢复Exactly-Once 语义结合 Flink 的两阶段提交保证端到端精确一致2.4 Schema Evolution 机制Flink CDC 3.x 支持上游 DDL 变更的实时同步通过SchemaOperator和SchemaRegistry协调实现(schema.change.behavior)行为模式配置值说明异常中断exception遇到 DDL 变更直接抛出异常严格应用evolve强制将 DDL 变更同步到下游失败则触发 Failover尝试应用try_evolve尝试同步 DDL失败则忽略继续宽松模式lenient默认仅应用下游兼容的 DDL 变更完全忽略ignore忽略所有 DDL 变更三、优缺点对比分析3.1 核心优势优势说明架构简洁单一 Flink 作业无需 Kafka/Kafka Connect 等中间件无锁全量读取增量快照算法全量阶段不锁表、不影响在线业务并发水平扩展全量阶段多并发读取增量阶段可按表并行端到端 Exactly-Once结合 Flink Checkpoint 两阶段提交保障一致性Schema 自动演进上游 DDL 变更可自动同步到下游声明式 YAML零 Java 代码YAML 定义全链路同步整库同步一个作业可同步整个数据库所有表低延迟省去 Kafka 中间层亚秒级端到端延迟3.2 局限与不足局限说明应对建议Sink 单一消费一条 Pipeline 只能写入一个 Sink不支持广播到多消费者需要多消费者时仍需引入 Kafka生态宽度有限Sink 连接器不如 Kafka 生态丰富3.x 版本在持续扩展已支持 Doris/StarRocks/Paimon/Iceberg/Fluss 等大状态管理压力整库同步时 State 可能很大对 RocksDB 和 Checkpoint 存储要求高合理设置并行度、使用增量 Checkpoint运维成熟度相比 DebeziumKafka 方案社区运维经验积累相对较少建立完善的监控体系Schema 变更风险复杂 DDL如列类型收窄可能导致下游兼容问题使用 try_evolve 或 lenient 模式四、适用场景4.1 推荐使用 Flink CDC 的场景实时数据入仓/入湖MySQL/PostgreSQL → Doris/StarRocks/Paimon/Iceberg追求低延迟和简单架构整库同步将业务库全量表一次性同步到分析系统减少连接占用分库分表合并通过route规则将上游分片表路由合并到下游单表实时 ETL 流水线结合transform做列投影、过滤、计算列等轻量 ETL实时物化视图数据库变更驱动的实时聚合/指标计算数据库迁移利用全量增量无缝切换实现在线迁移4.2 不推荐使用 Flink CDC 的场景需要多下游消费同一数据源此时 Kafka 作为解耦层更合适需要数据回放能力Kafka 天然支持按 offset 回放源端非关系型数据库且无成熟连接器需确认连接器可用性超大规模数千张表且表间有复杂依赖单一 Pipeline 的状态管理可能成为瓶颈五、配置详解Flink CDC 3.x YAML Pipeline5.1 配置结构总览一个完整的 Flink CDC YAML Pipeline 由以下部分组成source: # [必填] 数据源配置 type: mysql ... sink: # [必填] 数据目标配置 type: doris ... route: # [可选] 表路由规则 - source-table: ... sink-table: ... transform: # [可选] 数据转换规则 - source-table: ... projection: ... filter: ... pipeline: # [必填] 流水线全局配置 name: ... parallelism: ...5.2 Source 配置以 MySQL 为例核心连接参数参数必填默认值说明type是-连接器类型如 mysqlhostname是-数据库主机地址port否3306数据库端口username是-用户名password是-密码tables是-监控的表支持正则如 db..*tables.exclude否-排除的表server-id否-MySQL server-id集群中需唯一如 5400-5404快照与增量参数参数默认值说明scan.startup.modeinitial启动模式initial全量增量、latest-offset仅增量、snapshot仅全量等scan.incremental.snapshot.chunk.size8096Chunk 行数影响全量阶段并发粒度scan.snapshot.fetch.size1024每次 fetch 的最大行数scan.incremental.close-idle-reader.enabledfalse快照完成后关闭空闲 Reader节省资源connection.pool.size20连接池大小server-time-zone-数据库时区避免 8 小时偏移问题启动模式详解模式行为initial默认先执行全量快照再无缝切换到增量 Binloglatest-offset跳过全量从最新 Binlog 位点开始仅捕获启动后的变更earliest-offset从最早可用 Binlog 位点开始specific-offset从指定 Binlog 位点/GTID 开始timestamp从指定时间戳位点开始snapshot仅执行全量快照完成后退出5.3 Sink 配置以 Doris 为例sink: type: doris fenodes: 127.0.0.1:8030 username: root password: table.create.properties.light_schema_change: true table.create.properties.replication_num: 15.4 Route 配置表路由route: - source-table: app_db.orders # 精确匹配 sink-table: ods_db.ods_orders - source-table: app_db.order_\d # 正则匹配 - 分表合并 sink-table: ods_db.ods_orders_all description: 分表合并5.5 Transform 配置数据转换transform: - source-table: app_db.users projection: id, UPPER(name) AS name, age, created_at # 列投影 计算列 filter: age 18 AND status active # 行过滤 description: 过滤未成年用户5.6 Pipeline 全局配置参数默认值说明name-作业名称parallelism1全局并行度schema.change.behaviorlenientDDL 变更处理策略execution.runtime-modeSTREAMING运行模式STREAMING / BATCHlocal-time-zone-时区设置5.7 完整配置示例source: type: mysql hostname: 192.168.1.100 port: 3306 username: cdc_user password: ${CDC_PASSWORD} tables: trade_db..* tables.exclude: trade_db.tmp_.* server-id: 5400-5404 scan.startup.mode: initial scan.incremental.snapshot.chunk.size: 16384 scan.snapshot.fetch.size: 2048 scan.incremental.close-idle-reader.enabled: true connection.pool.size: 30 sink: type: doris fenodes: 10.0.0.1:8030 username: doris_admin password: ${DORIS_PASSWORD} table.create.properties.light_schema_change: true table.create.properties.replication_num: 3 route: - source-table: trade_db.orders sink-table: ods.ods_orders - source-table: trade_db.order_detail_\d sink-table: ods.ods_order_detail_all description: 订单明细分表合并 transform: - source-table: trade_db.users projection: id, name, phone, city, created_at filter: status ! deleted description: 过滤已删除用户裁剪敏感列 pipeline: name: Trade DB Full Sync to Doris parallelism: 4 schema.change.behavior: try_evolve local-time-zone: Asia/Shanghai六、最佳实践6.1 生产部署建议资源规划并行度设置建议按表数量和吞吐量需求设置初始全量阶段可适当调高如 4-8增量阶段可降低内存配置TaskManager 建议 4-8GB大表场景需关注 RocksDB State 大小Checkpoint 配置间隔 1-3 分钟金融场景 30s使用增量 Checkpoint 持久化存储S3/HDFSserver-id 配置# 使用范围语法每个并发分配独立 ID server-id: 5400-5408 # 如果 parallelism4至少需要 4 个 ID⚠️ 注意server-id在 MySQL 集群中必须全局唯一不能与主从复制的 slave ID 冲突。时区一致性source: type: mysql server-time-zone: Asia/Shanghai # 必须与源库会话时区一致 pipeline: local-time-zone: Asia/Shanghai⚠️ 注意时区不一致是生产中最常见的数据错误来源之一典型表现为时间偏移 8 小时。6.2 性能调优手册调优项建议原理增大 chunk.size8192 → 16384 ~ 65536减少 Chunk 数量提升全量读取速度增大 fetch.size1024 → 2048 ~ 4096减少网络往返提升单 Chunk 读取效率开启 close-idle-readertrue全量完成后释放空闲 Reader 资源合理设置并行度按表数量和下游承载力避免过高导致 Source 连接过多或 Sink 压力过大Sink 批写配置增大 batch size / flush interval减少下游小写入提升吞吐列裁剪Transform 中只投影必要列减少网络传输和序列化开销State Backend使用 RocksDB 增量 Checkpoint适应大状态场景6.3 监控关键指标指标关注点告警阈值建议端到端延迟E2E LatencyP95/P99 5s 告警Backpressure定位瓶颈在 Source/Transform/SinkisBackPressured 持续 trueCheckpoint 成功率失败影响恢复能力连续 3 次失败告警Binlog 位点差值Record Lag与源端最新位点的差值持续增大告警吞吐量 TPS异常下降下降 30% 告警Sink 写入错误率唯一键冲突/超时等 0.1% 告警6.4 常见故障排查故障现象原因解决方案server-id xxx is already in useID 与其他 Slave 冲突更换唯一的 server-id 范围时间错位 8 小时时区配置不一致配置 server-time-zone全量阶段卡住大表快照/锁等待/带宽不足增大 chunk.size、检查网络下游写入报错鉴权/建表失败/唯一键冲突检查 Sink 连接和表结构Sink 反压严重下游写入能力不足增大 Sink 并发/批写参数DDL 变更不兼容列类型收窄/重命名使用 try_evolve 或手动处理七、总结与展望Flink CDC 3.x 代表了实时数据集成领域的一个重要方向——声明式、端到端、去中间件化。它的核心价值在于通过增量快照算法实现了无锁、并发、可恢复的全增量一体化同步通过 YAML Pipeline 实现了零代码的数据集成体验通过 Schema Evolution 实现了上游 DDL 变更的自动传播作为 Apache Flink 子项目拥有强大的社区支撑和活跃的迭代节奏对于技术栈以 Flink 为核心、目标是构建实时数仓/湖仓一体架构的团队Flink CDC 是目前最值得优先评估的方案。