Flink CDC直接读MySQL Binlog——替代Canal的新方案
先说结论
Flink CDC的核心价值：把“Canal + Kafka + Flink”三个组件的活减少到“Flink”一个组件。架构更简单、运维成本更低、而且自带Exactly-Once语义。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
CDC（Change Data Capture）是数据同步的核心技术。传统方案是Canal/Debezium解析Binlog→Kafka→Flink，链路很长。Flink CDC的理念是：让Flink直接读MySQL的Binlog，省掉中间的Canal和Kafka。这是近两年最热的技术方向之一。
传统方案 vs Flink CDC
| 维度 | 传统方案（Canal+Kafka+Flink） | Flink CDC |
|---|---|---|
| 组件数 | 3个（Canal+Kafka+Flink） | 1个（Flink） |
| 运维复杂度 | 高（要维护3套系统） | 低（只维护Flink） |
| 延迟 | 秒级（多一跳Kafka） | 毫秒级（直接读Binlog） |
| Exactly-Once | 需要手动配置 | 内置支持 |
| 全量+增量 | 全量需要额外工具（DataX等） | 全量和增量无缝切换 |
| 生态 | 成熟（生产验证充分） | 快速成熟（已经被大量公司采用） |
Flink CDC的使用方式
-- Flink SQL直接读MySQL Binlog
CREATE TABLE mysql_orders (
order_id BIGINT,
user_id BIGINT,
amount DECIMAL(10,2),
status STRING,
create_time TIMESTAMP(3),
PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
'connector' = 'mysql-cdc',
'hostname' = '10.0.0.1',
'port' = '3306',
'username' = 'flink_cdc',
'password' = '***',
'database-name' = 'order_db',
'table-name' = 'orders',
'scan.startup.mode' = 'initial' -- 先全量再增量
);
-- 直接写入Doris（整套链路只需要这两条SQL）
INSERT INTO doris_dwd_orders
SELECT * FROM mysql_orders;scan.startup.mode='initial'的含义：作业第一次启动时先做全量快照（读取MySQL当前所有数据），然后自动切换到增量模式（读Binlog）。这是Flink CDC最大的亮点——以前全量和增量需要两套代码，现在一条SQL搞定。
实战经验：什么时候用Flink CDC，什么时候还是用Canal
用Flink CDC： 新项目、数据量不是特别大（单表不超过几亿行）、想简化架构。
仍用Canal+Kafka： 已有的成熟架构不想改、多个下游需要消费同一份CDC数据（Kafka的多消费者优势）、全量快照时对MySQL的压力太大。
我在当前短剧出海公司用的是阿里云的DataWorks集成方案，底层也是基于Flink CDC的原理。
总结
Flink CDC把“Canal+Kafka+Flink”简化为“Flink”一个组件。核心优势：架构简单、全量增量无缝切换、内置Exactly-Once。面试时能对比传统方案和Flink CDC的优劣、写出一条完整的CDC SQL、说清楚选型依据，就很有深度。
下一篇聊一个很多人忽视的话题：Flink作业上线后指标不对——怎么做实时数据质量监控？
你们生产环境用的是Flink CDC还是Canal？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长