Flink CDC面试题：我被问到的那些问题

最近面试了几家公司，被问到了很多Flink CDC相关的问题。本文整理了我被问到的高频面试题，以及我的回答思路，包括Flink CDC的原理、架构、使用场景、常见问题、性能优化等。如果你在准备大数据相关的面试，或者想深入了解Flink CDC，希望这篇文章能帮到你。

一、什么是Flink CDC

先从最基础的问题开始。

面试题1：什么是Flink CDC？它和传统的数据同步方式有什么区别？

Flink CDC是基于Flink的Change Data Capture（变更数据捕获）工具，用来实时捕获数据库的变更数据，包括插入、更新、删除操作，然后实时同步到其他系统。

传统的数据同步方式有两种：一种是定时批量同步，比如每天凌晨把MySQL的数据同步到数据仓库，这种方式延迟高，是T+1的；另一种是双写，业务代码在写数据库的同时也写一份到目标系统，这种方式对业务代码有侵入，而且很难保证数据一致性。

Flink CDC的优势在于：

实时性高，秒级延迟
对业务无侵入，不需要修改业务代码
基于数据库的binlog，能捕获所有变更
支持全量和增量同步，自动断点续传
基于Flink，支持复杂的流处理和转换

面试题2：Flink CDC支持哪些数据源？

Flink CDC支持的数据源包括MySQL、PostgreSQL、Oracle、SQL Server、MongoDB等主流数据库。不同的数据库有不同的连接器，实现方式也略有不同。

对于MySQL，是通过解析binlog来捕获变更的。对于PostgreSQL，是通过逻辑复制来捕获的。对于Oracle，是通过LogMiner或者XStream来捕获的。

现在社区还在不断增加新的数据源支持，比如TiDB、DB2等。

二、原理和架构

这部分是面试的重点，面试官喜欢问原理。

面试题3：Flink CDC的工作原理是什么？

Flink CDC的核心原理是通过读取数据库的事务日志（比如MySQL的binlog）来捕获数据变更。

具体流程是：

连接到数据库，读取binlog的位置信息
先做全量快照，把现有数据读出来
全量完成之后，切换到增量模式，实时读取binlog
把变更数据转换成统一的格式（DataChange或者RowData）
发送到下游，比如Kafka、数据仓库、其他数据库等

整个过程是基于Flink的流处理引擎，支持分布式、容错、 checkpoint。

面试题4：Flink CDC是如何保证数据不丢不重的？

这是一个高频问题。Flink CDC通过以下机制保证数据不丢不重：

基于Flink的checkpoint机制，定期保存同步的位置信息（binlog位点）
任务失败恢复的时候，从最近的checkpoint恢复，从上次的位置继续同步
对于全量同步阶段，用快照算法保证数据一致性
对于增量同步阶段，binlog本身是有序的，按位点消费不会丢数据
下游如果支持幂等写入，可以配合实现精确一次（Exactly-Once）语义

要注意的是，Flink CDC本身只能保证至少一次（At-Least-Once）语义，要实现精确一次，需要下游支持幂等写入或者事务写入。

面试题5：Flink CDC的全量和增量是怎么切换的？

Flink CDC在全量同步完成之后，会自动切换到增量同步。切换的过程是这样的：

全量同步开始的时候，记录当前的binlog位点
全量同步读取表中的数据，同时binlog也在不断产生
全量同步完成之后，从之前记录的binlog位点开始读取增量数据
增量数据中包含了全量同步期间产生的变更，这样就不会漏掉数据
增量数据追上当前的binlog位置之后，就进入了实时同步状态

这个切换过程是自动完成的，用户不需要干预。

面试题6：Flink CDC和Canal、Debezium有什么区别？

这也是一个常见的对比问题。

Canal是阿里开源的MySQL binlog解析工具，只能解析MySQL，功能比较单一，需要自己开发下游处理逻辑。

Debezium是一个比较成熟的CDC工具，支持多种数据库，但是它主要是把变更数据发到Kafka，下游的处理需要另外做。

Flink CDC的优势在于：

基于Flink，天然支持流处理，可以在同步的同时做数据转换、清洗、关联
支持多种数据源，而且社区活跃
支持SQL API，用SQL就能完成数据同步，开发效率高
和Flink生态无缝集成，可以用Flink的所有功能

简单来说，Canal是一个binlog解析工具，Debezium是一个CDC工具，Flink CDC是一个基于流处理引擎的CDC+数据处理平台。

三、使用场景

面试题7：你们在什么场景下使用Flink CDC？

我们主要在以下几个场景使用Flink CDC：

数据同步：把业务数据库的数据实时同步到数据仓库，用于数据分析
数据集成：把多个数据源的数据实时同步到一个统一的平台
实时数仓：用Flink CDC把数据同步到Kafka，然后用Flink做实时计算，构建实时数仓
缓存更新：数据库变更的时候，实时更新缓存，保证缓存和数据库的一致性
数据迁移：数据库迁移的时候，用Flink CDC做全量+增量同步，最后切换，停机时间短

面试题8：Flink CDC适合同步大表吗？全量同步的时候会不会影响源库性能？

Flink CDC可以同步大表，但是全量同步的时候会对源库有一定的压力，因为要全表扫描。

为了减少对源库的影响，可以采取以下措施：

从只读库读取，不要直接读主库
控制全量同步的并发度，不要太高
错峰同步，在业务低峰期做全量同步
用快照方式读取，减少锁表时间
对于特别大的表，可以先手动导出历史数据，然后用Flink CDC只做增量同步

我们的经验是，亿级以下的表，用Flink CDC全量同步没问题，对源库的影响可控。几十亿的大表，建议先手动导出历史数据，再用CDC做增量。

四、常见问题和解决方案

这部分是面试官最喜欢问的，因为能看出实际经验。

面试题9：Flink CDC同步延迟高怎么办？

延迟高是一个常见问题，可能的原因和解决方案：

源库binlog产生太快，Flink消费不过来：增加Flink的并行度，提升消费能力
全量同步阶段慢：增加全量读取的并发数，或者从只读库读取
下游写入慢：优化下游的写入性能，比如批量写入、增加并行度
数据倾斜：某些分片的数据量特别大，导致某个subtask成为瓶颈。可以调整分片策略，让数据均匀分布
Flink资源不足：增加TaskManager的内存和CPU

排查的时候，先看是哪个环节慢，是源端读取慢，还是中间处理慢，还是下游写入慢，然后针对性地优化。

面试题10：Flink CDC任务失败了怎么恢复？

Flink CDC任务失败之后，会从最近的checkpoint恢复。如果checkpoint正常的话，恢复之后会从上次的binlog位点继续同步，不会丢数据。

但是有几种情况需要注意：

如果checkpoint也丢了，就需要重新做全量同步，或者手动指定binlog位点
如果源库的binlog被清理了，位点找不到了，就只能重新全量同步
如果是因为数据异常导致的失败，修复之后需要跳过异常数据或者修复数据

所以，生产环境中一定要：

开启checkpoint，并且保留足够多的checkpoint
源库的binlog保留时间要足够长，至少7天
监控任务状态，失败了及时告警和处理

面试题11：Flink CDC同步的数据有重复怎么办？

数据重复可能有几个原因：

Flink的容错机制导致的重试：这个是正常的，Flink保证至少一次，重复是可能的。解决方法是下游做幂等写入，比如用主键upsert
全量和增量切换的时候有重叠：这个是设计如此，因为全量期间的变更会在增量阶段重新同步一次。下游用主键去重就好
任务恢复的时候重复消费：同样，下游做幂等处理

所以，使用Flink CDC的时候，下游最好支持幂等写入，比如用MySQL的ON DUPLICATE KEY UPDATE，或者用ClickHouse的ReplacingMergeTree。这样即使有重复数据，最终结果也是一致的。

面试题12：MySQL的binlog格式有什么要求？

Flink CDC要求MySQL的binlog格式是ROW格式，因为ROW格式的binlog包含了每行数据变更的完整信息，包括变更前和变更后的值。

如果是STATEMENT或者MIXED格式，Flink CDC可能无法正确解析变更数据。

另外，binlogrowimage参数要设置为FULL，这样binlog中才会包含所有列的信息，而不只是变更的列。

还有，数据库的时区设置要正确，否则同步过来的时间可能会有偏差。

面试题13：Flink CDC支持DDL同步吗？

Flink CDC支持部分DDL同步，比如CREATE TABLE、ALTER TABLE、DROP TABLE等。但是DDL的处理比较复杂，不同数据库的支持程度不一样。

在实际使用中，我们一般不建议用Flink CDC同步DDL，因为DDL的变更可能会导致下游表结构不匹配，任务失败。

比较稳妥的做法是：DDL变更手动处理，先改下游表结构，再让Flink CDC继续同步。或者用专门的工具来管理Schema变更。

五、性能优化

面试题14：如何优化Flink CDC的同步性能？

性能优化可以从几个方面入手：

增加并行度：Flink CDC支持并行读取，把表分成多个chunk，并行读取。并行度设置为源库CPU核数的1到2倍比较合适
优化全量读取：用增量快照算法，减少锁表时间；增加每次读取的fetch size，减少网络往返
优化下游写入：批量写入，增加写入并发，用异步IO
合理设置checkpoint：checkpoint间隔不要太短，否则会影响性能。一般设置为1到5分钟
资源配置：给TaskManager足够的内存和CPU，特别是全量同步的时候，内存不够会导致频繁GC
网络优化：Flink和源库、下游之间的网络要通畅，最好在同一个机房

面试题15：Flink CDC的并行度是怎么工作的？

Flink CDC的并行度分为全量阶段和增量阶段。

全量阶段，表会被分成多个chunk，每个chunk由一个subtask来读取，所以可以并行。chunk的数量由并行度决定，每个subtask负责一部分数据。

增量阶段，因为binlog是单线程有序的，所以只能由一个subtask来读取，不能并行。但是读取之后的数据可以分发给多个下游subtask来处理和写入。

所以，全量阶段的性能可以通过增加并行度来提升，增量阶段的读取性能受限于单线程，但是下游处理可以并行。

六、实战经验

面试题16：你们生产环境用Flink CDC遇到过最大的坑是什么？

这个问题是考察真实经验的。我遇到的最大的坑是：大表全量同步的时候，源库的binlog保留时间不够，全量还没同步完，binlog就被清理了，导致增量数据丢失，任务失败。

解决方案是：

把源库的binlog保留时间从3天改成了7天
大表全量同步之前，先评估同步时间，如果时间太长，先手动导出历史数据
监控binlog的使用情况，快满了及时清理或者扩容

还有一个坑是：下游用的是Kafka，但是Kafka的消息体太大，超过了默认的1MB限制，导致写入失败。解决方案是调大Kafka的message.max.bytes参数，或者在Flink端做数据拆分。

面试题17：如何监控Flink CDC任务？

我们监控的指标包括：

任务状态：是否在运行，有没有失败
同步延迟：binlog的位点和当前时间的差距，延迟超过阈值就告警
吞吐量：每秒同步多少条数据
checkpoint：checkpoint是否正常完成，耗时多少
错误日志：有没有异常或者错误
源库连接：连接是否正常，binlog是否在正常读取

用Prometheus采集Flink的指标，Grafana做大盘，异常的时候通过钉钉或者邮件告警。

面试题18：Flink CDC和Flink SQL怎么结合使用？

Flink CDC可以通过Flink SQL来使用，非常方便。只需要用CREATE TABLE语句定义一个CDC源表，然后就可以用SQL来查询和处理数据了。

比如：

CREATE TABLE mysql_source (
  id INT,
  name STRING,
  PRIMARY KEY (id) NOT ENFORCED
) WITH (
  'connector' = 'mysql-cdc',
  'hostname' = 'localhost',
  'port' = '3306',
  'username' = 'root',
  'password' = 'root',
  'database-name' = 'test',
  'table-name' = 'user'
);

然后就可以用SELECT查询，或者用INSERT INTO把数据写到其他表。

用SQL的好处是开发效率高，不需要写Java代码，而且SQL的可读性好，维护方便。

七、总结和建议

最后总结一下面试中关于Flink CDC的要点：

原理要清楚：知道CDC是什么，怎么工作的，怎么保证数据一致性
架构要了解：知道Flink CDC的组件和流程，全量和增量怎么切换
场景要熟悉：知道Flink CDC适合什么场景，不适合什么场景
问题要有经验：常见的问题（延迟、重复、失败、DDL）要知道怎么解决
优化要有方法：知道从哪些方面优化性能
实战要有故事：能讲出自己遇到的坑和解决方案

如果你在准备面试，建议把这些问题都过一遍，并且结合自己的实际项目经验来回答。面试官不只是听理论，更看重实际经验。

八、写在最后

Flink CDC是现在大数据领域很火的一个技术，实时数据同步、实时数仓都离不开它。面试中被问到的概率也很高。

本文整理了我面试中被问到的问题和回答思路，希望能帮到正在准备面试的同学。当然，面试题只是一个参考，最重要的还是自己真正理解和用过。

技术在不断发展，Flink CDC也在不断更新，新的功能和优化不断出现。保持学习，跟进社区，才能在面试和工作中游刃有余。

最后用一句话结束本文："面试不是终点，学习才是。"愿每一个技术人都能在学习中不断成长，在面试中取得好成绩。