2024年最全Flink CDC 高频面试题_flinkcdc面试(1)
[*]支持所有 MySQL 数据类型
包括 枚举类型、数组类型、地理信息类型 等复杂类型。
[*]支持 metadata column
用户可以在 Flink DDL 中通过 db_name STRING METADATA FROM ‘database_name’ 的方式来访问库名(database_name)、表名（table_name）、变动时间（op_ts）等 meta 信息。这对分库分表场景的数据集成非常实用。
[*]支持并发读取的 DataStream API
在 2.0 版本中，无锁算法，并发读取等功能只在 SQL API 上透出给用户，而 DataStream API 未透出给用户。
2.1 版本支持了 DataStream API，可通过 MySqlSourceBuilder 创建数据源。用户可以同时捕获多表数据，借此搭建整库同步链路。同时通过 MySqlSourceBuilder#includeSchemaChanges 还能捕获 schema 变动。
[*]支持 currentFetchEventTimeLag，currentEmitEventTimeLag，sourceIdleTime 监控指标
这些指标依照 FLIP-33 的连接器指标规范，可以检察 FLIP-33 获取每个指标的含义。其中，currentEmitEventTimeLag 指标记录的是 Source 发送一条记录到下游节点的时间点和该记录在 DB 里产生时间点差值，用于衡量数据从 DB 产生到离开 Source 节点的延迟。用户可以通过该指标判断 source 是否进入了 binlog 读取阶段：
即当该指标为 0 时，代表还在全量汗青读取阶段；当大于 0 时，则代表进入了 binlog 读取阶段。
2.2 新增 Oracle CDC 连接器
Oracle 也是使用很广泛的数据库， Oracle CDC 连接器支持捕获并记录 Oracle 数据库服务器中发生的行级变动。
其原理是 使用 Oracle 提供的 LogMiner 工具或者原生的 XStream API 从 Oracle 中获取变动数据。
LogMiner 是 Oracle 数据库提供的一个分析工具，该工具可以解析 Oracle Redo 日记文件，从而将数据库的数据变动日记解析成变动变乱输出。通过 LogMiner 方式时，Oracle 服务器对解析日记文件的历程做了严格的资源限定，以是对规模特别大的表，数据解析会比力慢，优点是 LogMiner 是可以免费使用的。
XStream API 是 Oracle 数据库为 Oracle GoldenGate (OGG) 提供的内部接口, 客户端可以通过 XStream API 高效地获取变动变乱，其变动数据不是从 Redo 日记文件中获取，而是从 Oralce 服务器中的一块内存中直接读取，省去了数据落盘到日记文件息争析日记文件的开销，效率更高，但是必须购买 Oracle GoldenGate (OGG) 的 License。
https://img-blog.csdnimg.cn/img_convert/54f22abfe5be94b8b19d90e573017e54.png
Oracle CDC 连接器支持 LogMiner 和 XStream API 两种方式捕获变动变乱。理论上能支持各种 Oracle 版本，目前 Flink CDC 项目里测试了 Oracle 11，12 和 19 三个版本。使用 Oracle CDC 连接器，用户只必要声明如下 Flink SQL 就能及时捕获 Oracle 数据库中的变动数据：
https://img-blog.csdnimg.cn/img_convert/6992f426cab7742b7d4bad54933519d5.png
Oracle CDC 连接器已经将底层的 CDC 细节屏蔽，整个及时同步链路，用户只必要几行 Flink SQL，不用开辟任何 Java 代码，就可以将 Oracle 的数据变动及时捕获并发送。
别的，Oracle CDC 连接器也提供两种工作模式，即读取 全量数据 + 增量变动 数据，和只读取增量变动数据。Flink CDC 框架均包管一条不多一条不少的 exactly-once 语义。
2.3 新增 MongoDB CDC 连接器
mongoDB CDC 连接器并不依赖 Debezium，是在 Flink CDC 项目里独立开辟。MongoDB CDC 连接器支持捕获并记录 MongoDB 数据库中及时变动数据，其原理是伪装一个 MongoDB 集群里副本，利用 MongoDB 集群的高可用机制，该副本可以从 master 节点获取完整 oplog(operation log) 变乱流。Change Streams API 则提供及时订阅这些 oplog 变乱流的能力，可以将这些及时的 oplog 变乱流推送给订阅的应用步伐。
https://img-blog.csdnimg.cn/img_convert/fdf3066aa1eb9f683591261fa5aad391.png
从 ChangeStreams API 获取的更新变乱中，对于 update 变乱，没有 update 变乱的前镜像值，即 MongoDB CDC 数据源只能作为一个 upsert source。不过 Flink 框架会主动为 MongoDB CDC 附加一个 Changelog Normalize 节点，补齐 update 变乱的前镜像值（即 UPDATE_BEFORE 变乱)，从而确保 CDC 数据的语义正确性。
使用 MongoDB CDC 连接器，用户只必要声明如下 Flink SQL 就能及时捕获 MongoDB 数据库中的全量和增量变动数据，借助 Flink 强大的集成能力，用户可以非常方便地将 MongoDB 中的数据及时同步到 Flink 支持的所有下游存储。
https://img-blog.csdnimg.cn/img_convert/3f0d8535b315e455014bd8080b66d704.png
整个数据捕获过程，用户不必要学习 MongoDB 的副本机制和原理，极大地简化了流程，降低了使用门槛。MongoDB CDC 也支持两种启动模式：
[*]默认的 initial 模式是先同步表中的存量数据，然后同步表中的增量数据；
[*]latest-offset 模式则是从当前时间点开始只同步表中增量数据。
别的，MongoDB CDC 还提供了丰富的配置和优化参数，对于生产环境来说，这些配置和参数能够极大地提升及时链路的性能和稳固性。
3 焦点知识点解刨
3.1 flink cdc 1.x 加锁计划
在 Flink cdc 1.x 全量 + 增量读取的版本计划中， flink cdc 底层选用 debezium 作为收罗工具，Debezium 为包管数据一致性，通过对读取的数据库或者表进行加锁，而加锁是发生在全量阶段。
以全局锁为例，重要流程如下：
https://img-blog.csdnimg.cn/img_convert/7bfc6ca93a0ac07e2f2a588c7f4469f3.png
（1）首先是获取一个锁，然后再去开启可重复读的事件。
这里锁住操作是读取 binlog 的起始位置和当前表的 schema。
这样做的目的是包管 binlog 的起始位置和读取到的当前 schema 可以一一对应，由于表的 schema 是会改变的，好比删除列或者增加列。
在读取这两个信息后，SnapshotReader 会在可重复读事件里读取全量数据，在全量数据读取完成后，会启动 BinlogReader 从读取的 binlog 起始位置开始增量读取，从而包管全量数据 + 增量数据的无缝衔接。
3.2 flink cdc 1.x 问题点
当使用 Flush tables with read lock 语句时：
(1) 该命令会等待所有正在进行的 update 完成，同时阻止所有新来的 update。
(2) 该命令执行前必须等待所有正在运行的 select 完成，所有等待执行的 update 会等待更久。更坏的情况是，在等待正在运行 select 完成时，DB 实际上处于不可用状态，纵然是新加入的 SELECT 也会被阻止，这是 Mysql Query Cache 机制。
(3) 该命令阻止其他事件 commit。
结论：加锁时间不确定，极端情况会锁住数据库。
3.3 DBlog Paper
针对 一致性加锁的痛点 Flink cdc 2.x 借鉴 Netflix 的 DBlog paper 计划了全程无锁算法
DBlog paper 论文的 chunk 切分算法
https://img-blog.csdnimg.cn/img_convert/527b31410f258a5dcabcc638eacd5d76.png
Chunk 切分算法其实和许多数据库的分库分表原理类似：通过表的主键对表中的数据进行分片。
假设每个 Chunk 的步长为 10，按照这个规则进行切分，只必要把这些 Chunk 的区间做成左开右闭或者左闭右开的区间，包管衔接后的区间能够便是表的主键区间即可。
https://img-blog.csdnimg.cn/img_convert/b20e2e7951ddb0828e4fa17de90ca6fb.png
由于每个 chunk 只负责本身主键范围内的数据，不难推导，只要能够包管每个 Chunk 读取的一致性，就能包管整张表读取的一致性，这便是无锁算法的根本原理。
在 Netflix 的 DBLog 论文中
Chunk 读取算法是通过在 DB 维护一张信号表，再通过信号表在 binlog 文件中打点，记录每个 chunk 读取前的 Low Position (低位点) 和读取竣事之后 High Position (高位点) ，在低位点和高位点之间去查询该 Chunk 的全量数据。在读取出这一部分 Chunk 的数据之后，再将这 2 个位点之间的 binlog 增量数据合并到 chunk 所属的全量数据，从而得到高位点时刻，该 chunk 对应的全量数据。
3.4 flink cdc 2.x 无锁算法
Flink CDC 2.x 结合自身的情况，在 Chunk 读取算法上做了去信号表的改进，不必要额外维护信号表，通过直接读取 binlog 位点替代在 binlog 中做标记的功能，整体的 chunk 读算法形貌如下图所示：
https://img-blog.csdnimg.cn/img_convert/44c47b4f3a04ede7b98de442c427db44.png
(1) 单个 Chunk 的一致性读:
好比正在读取 Chunk-1，Chunk 的区间是 ，首先直接将该区间内的数据 select 出来并把它存在 buffer 中，在 select 之前记录 binlog 的一个位点 (低位点)，select 完成跋文录 binlog 的一个位点 (高位点)。然后开始增量部分，消耗从低位点到高位点的 binlog。
[*]图中的 - ( k2,100 ) + ( k2,108 ) 记录表示这条数据的值从 100 更新到 108；
[*]第二条记录是删除 k3；
[*]第三条记录是更新 k2 为 119；
[*]第四条记录是 k5 的数据由原来的 77 变动为 100。
观察图片中右下角最终的输出，会发如今消耗该 chunk 的 binlog 时，出现的 key 是 k2、k3、k5，我们前往 buffer 将这些 key 做标记。
对于 k1、k4、k6、k7 来说，在高位点读取完毕之后，这些记录没有变化过，以是这些数据是可以直接输出的；
对于改变过的数据，则必要将增量的数据合并到全量的数据中，只保存合并后的最终数据
例如，k2 最终的结果是 119 ，那么 只必要输出 +(k2,119)，而不必要中心发生过改变的数据。
通过这种方式，Chunk 最终的输出就是在高位点 chunk 中最新的数据。
(2) 并发读取 Snapshot Chunk
基于 FLIP-27 实现，通过下图可以看到有 SourceEnumerator 的组件，这个组件重要用来划分 chunk,将划分好的 Chunk 提供给下游的快照读取器（SourceReader）去读取，通过把 chunk 分发给差别的 SourceReader 便实现了并发读取 Snapshot Chunk 的过程， 同时基于 FLIP-27 方便地做到 chunk 粒度的 checkpoint。
https://img-blog.csdnimg.cn/img_convert/5a44d1f2607a2c2edcc7580ff6b7f163.png
当 Snapshot Chunk 读取完成之后，必要有一个报告的流程，如下图中橘色的报告信息，将 Snapshot Chunk 完成信息报告给 SourceEnumerator。
https://img-blog.csdnimg.cn/img_convert/47e4862ba283b7a9a5bdb8e0729406d9.png
报告的重要目的是为了后续分发 binlog chunk (如下图)。由于 Flink CDC 支持全量 + 增量同步，以是当所有 Snapshot Chunk 读取完成之后，还必要消耗增量的 binlog，这是通过下发一个 binlog chunk 给恣意一个 Source Reader 进行单并发读取实现的。
https://img-blog.csdnimg.cn/img_convert/da9adba09820c5b09d31e3c80c967f62.png
总结如下：
（1）在快照阶段，根据表的主键和表行的大小将 快照（Snapshot） 切割成多个 快照块(Snapshot Chunk) ，然后将 快照块 被分配给多个 快照读取器（SourceReader）。
（2）每个 快照读取器 使用 块读取算法（单个 Chunk 的一致性读） 读取其吸取到的块，并将读取的数据发送到下游。源管理块的历程状态变动为（已完成或未完成），因此 快照阶段的源可以支持块级别的检查点。假如发生故障，可以规复源并继续从末了完成的块中读取块。
（3）在所有快照块完成后，源将继续在单个使命（task）中读取 binlog。为了包管快照记录和 binlog 记录的全局数据顺序，binlog reader 会开始读取数据，直到 snapshot chunks 完成后有一个完整的 checkpoint，以确保所有的快照数据都被下游消耗了。
（4）binlog reader 在 state 中跟踪斲丧的 binlog 位置，因此 binlog phase 的 source 可以支持行级别的 checkpoint。
Flink 定期为源执行检查点，在故障转移的情况下，作业将从上次成功的检查点状态重新启动并规复，并包管恰好一次语义。
https://img-blog.csdnimg.cn/img_convert/c414be63fdbae4263f511a4cd0f27a01.png
4 CDC 高频面试题
1 flink Dynamic Table & ChangeLog Stream 相识吗？
Dynamic Table 是 Flink SQL 界说的动态表，动态表和流的概念是对等的参照上图，流可以转换成动态表，动态表也可以转换成流。
在 Flink SQL 中，数据从一个算子以 Changelog Stream 的情势流向另外一个算子时，恣意时刻的 Changelog Stream 可以翻译为一个表，也可以翻译为一个流。
https://img-blog.csdnimg.cn/img_convert/4069794cf88e3ff26448c38d6e52a415.png
2 mysql 表与 binlog 的关系是什么?
MySQL 数据库的一张表所有的变动都记录在 binlog 日记中，假如不绝对表进行更新，binlog 日记流也不绝会追加，数据库中的表就相当于 binlog 日记流在某个时刻点物化的结果；日记流就是将表的变动数据连续捕获的结果。
这说明 Flink SQL 的 Dynamic Table 是可以非常自然地表示一张不断变化的 MySQL 数据库表。
https://img-blog.csdnimg.cn/img_convert/8176ee8b6bb9c51a89a22e1361ee224b.png
3 flink cdc 底层的收罗工具用哪个？
选择 Debezium 作为 Flink CDC 的底层收罗工具，原因是 debezium 支持全量同步，也支持增量同步，同时也支持全量 + 增量的同步，非常灵活，同时基于日记的 CDC 技能使得提供 Exactly-Once 成为可能。
4 flink sql 与 debezium 的数据结构有哪些相似性？
通过对 Flink SQL 的内部数据结构 RowData 和 Debezium 的数据结构进行对比，可以发现两者非常相似。
（1）每条 RowData 都有一个元数据 RowKind，包括 4 种类型， 分别是插入 (INSERT)、更新前镜像 (UPDATE_BEFORE)、更新后镜像 (UPDATE_AFTER)、删除 (DELETE)，这四种类型和数据库里面的 binlog 概念保持一致。
（2）Debezium 的数据结构，也有一个类似的元数据 op 字段， op 字段的取值也有四种，分别是 c、u、d、r，各自对应 create、update、delete、read。对于代表更新操作的 u，其数据部分同时包罗了前镜像 (before) 和后镜像 (after)。
两者相似性很高，以是接纳 debezium 作为底层收罗工具
5 flink cdc 1.x 有哪些痛点？
(1) 一致性加锁的痛点
由于 flink cdc 底层选用 debezium 作为收罗工具，在 flink cdc 1.x 全量 + 增量读取的版本计划中，Debezium 为包管数据一致性，通过对读取的数据库或者表进行加锁，但是 加锁 在数据库层面上是一个非常高危的操作。全局锁可能导致数据库锁住，表级锁会锁住表的读，DBA 一般不给锁权限。
（2）不支持程度扩展的痛点
由于 Flink CDC 底层是基于 Debezium，Debezium 架构是单节点，以是 Flink CDC 1.x 只支持单并发。
在全量读取阶段，假如表非常大 (亿级别)，读取时间在小时乃至天级别，用户不能通过增加资源去提升作业速度。
（3）全量读取阶段不支持 checkpoint
Flink CDC 读取分为两个阶段，全量读取和增量读取，目前全量读取阶段是不支持 checkpoint 的;
因此会存在一个问题：当我们同步全量数据时，假设必要 5 个小时，当我们同步了 4 小时的时候作业失败，这时候就必要重新开始，再读取 5 个小时。
6 flink cdc 1.x 的加锁发生在哪个阶段？
加锁是发生在全量阶段。
https://img-blog.csdnimg.cn/img_convert/b71df427f6ec143d9454db86581c54fc.png
https://img-blog.csdnimg.cn/img_convert/aa2cb4ad75f720735f8df91a6f5a59c2.png
网上学习资料一大堆，但假如学到的知识不成体系，碰到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技能提升。
必要这份体系化资料的朋友，可以戳这里获取
一个人可以走的很快，但一群人才气走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技能交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
加锁是发生在全量阶段。
[外链图片转存中…(img-8uoT6yRY-1714667932968)]
[外链图片转存中…(img-xDyRUoOt-1714667932968)]
网上学习资料一大堆，但假如学到的知识不成体系，碰到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技能提升。
必要这份体系化资料的朋友，可以戳这里获取
一个人可以走的很快，但一群人才气走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技能交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]