深化解读 Flink CDC 增量快照框架

sd642366

17位初级专家独特打造，波及15个畛域，133个体系框架，1000个细分常识点！
关注大众号“大话数智”，收费下载这份《数据智能常识地图》??

eya3dzaojo2.jpg

导读：跟着大数据的迅猛开展，企业愈来愈注重数据的价值，数据收集工具也在不停改进，实时收集工具也在由长链路向短链路开展，明天和大家分享一下 Flink CDC 技术。
明天的引见会环抱上面四点展开：
Flink CDC 简介Flink CDC 增量快照算法Flink CDC 增量快照框架社区开展布局分享佳宾｜徐榜江 Flink CDC Maintainer
编纂整顿｜刘步龙 硕磐智能
出品社区｜DataFun
01
Flink CDC 简介
首先总体引见一下 Flink CDC 技术。

amytnnz4x52.jpg

Flink CDC 是基于数据库的日志 CDC（ChangeDataCapture）技术，完成了全量和增量的一体化读取才能。全量就是常常说的历史数据，增量就是实时的数据，不停的在写入。经过 Flink CDC，用户在Flink中看到这张表就是该表的最新一个统一性快照。这个过程当中，不必去处置全量跟增量数据之间的连接和合并，这就是 Flink CDC 的全增量一体化读取才能。

xjlxie12rbs.jpg

有了 Flink CDC 技术，咱们一些传统的 ETL 剖析链路能够大大简化。
在传统的收集形式下，首先需求借助 Canal、Debezium 等技术把实时变卦的日志写入到 Kafka 等动静队列，而后经过 Flink 等计算引擎读取最新数据与历史数据进行合并从而获取残缺的数据，而后再写入上游。
在引入 Flink CDC 技术后，数据链路能够大大缩短，Flink CDC 能够间接读取下游数据，借助 Flink 优秀的管道才能和生态来实现以前的数据收集、计算和写入。

2slaoavm1wq.jpg

在 Flink CDC 现有生态中，接入端中主流的数据库根本都反对，在处置过程当中反对SQL API 和 DataStreamAPI 两种形式的处置，SQLAPI 处置的劣势是操作简略，用户门坎低，DataStreamAPI 的劣势是可扩展才能强，能够经过自定义开发完成一些定制功用。
02
Flink CDC 增量快照算法
1. Flink CDC1.0 痛点

xgkzsem0eqo.jpg

在 Flink CDC 1.0 中有三大痛点，第一个是统一性经过加锁包管，对业务不敌对；第二个是不反对程度扩展，在全量读取阶段只能单并发，假如表特别大，那末耗时就会很长；第三个是全量读取阶段不反对 checkpoint，假如读取失败，则只能从开始再次读取，耗时也会很长。
2. Flink CDC1.0 锁剖析

l5fowqv3fow.jpg

Flink CDC 1.0 完成中，底层封装了 Debezium，读取数据的时分就分为两个阶段，第一个是全量读取阶段，第二个是增量读取阶段。在全量读取阶段和增量阶段连接时是经过加锁来包管数据统一性。

wmylbpytro5.jpg

读取 MySQL 的加锁流程如上图所示，关于不同的数据库，权限也不同，有的是全局锁，有的是表锁，且它们的流程也不相反。

utv2b2h2hgn.jpg

但加锁是十分风险的操作，以 MySQL 的加锁为例，MySQL 的加锁时间是不肯定的，在某些极端状况下，会把数据库 hang住，影响数据库上承载的线上业务。
3. Flink CDC2.0 锁设计指标

05t5obnvfer.jpg

Flink CDC 2.0 的设计次要是为理解决 Flink CDC 1.0 的痛点问题，即全量读取阶段使用无锁读取，反对高并发的程度扩展，可断点续传解决失败重做问题。
4. Flink CDC2.0 设计计划

gxbxg5eoql5.jpg

Flink CDC 2.0 次要是鉴戒 DBLog 算法的一个变种同时结合 FLIP-27 Source 完成。
5. DBLog 算法原理

zfktl2tyvwb.jpg

DBLog 这个算法的原理分红两个部份，第一部份是分 chunk，第二部份是读 chunk。分 chunk 就是把一张表分为多个 chunk（桶/片）。我能够把这些 chunk 散发给不同的并发的 task 去做。例如：有 reader1 和 reader2，不同的 reader 担任读不同的 chunk。其实只有包管每个 reader 读的阿谁 chunk 是残缺的，也能跟最新的 Binlog 可以婚配在一同就能了。在读 chunk 的过程当中，会同时读属于这个 chunk的历史数据，也会读这个 chunk 期间产生的 Binlog 事情，而后来做一个 normalize。

dxspfiv4tn2.jpg

首先是 chunk 的划分。一张表，它的 ID 字段是主键 PK。经过 query 可以知道最大的 PK 也能知道最小的 PK。而后按照最大最小的 PK 设定一个步长，那末就可以把这个表分红一些 chunk。每个 chunk 是一个左闭右开的区间，这样能够完成 chunk 的无缝连接。第一个 chunk 和最初一个 chunk 最初一个字段，是一个正无量和负无量的表现， 即一切小于 k1 的 key 由第一个 chunk 去读，一切大于 K104 的 key 由最初一个chunk去读。

cynpx4yqyin.jpg

chunk 的读取，首先有一个 open 打点的进程，还有一个 close 打点的进程。例如，读属于这个 chunk1 的一切数据时，橘色的 K1 到 K7 是这些全量数据。橘黄色外面有下划线的数据，是在读期间这些 Binlog 在做改动。好比 K2 就是一条 update，从 100 变为 108，K3 是一条 delete。K2 前面又变为 十一9。还有 K5 也是一个update。在 K2、K3、K5 做标志，阐明它们曾经不是最新的数据了，需求从 Binlog 外面读出来，做一个 merge 获得最新的数据， 最初读出来的就是在 close 位点时辰的最新数据。最初的成果就是，将 update 最新的数据终究输入，将 delete 的数据如 K3 不输入。所以在 chunk1 读完的时分，输入的数据是 K0、K2、K4、K5、K6、K7 这些数据，这些数据也是在 close 位点时数据库中该 chunk 的数据。

fbah5epfzxl.jpg

接上去是 chunk 的散发。一张表切成为了 N 个 chunk 后，SourceEnumerator 会将这些 chunk 分给一些 SourceReader 并行地读取，并行读是用户能够配置的，这就是程度扩展才能。

ckt5droph53.jpg

每一个个 Snapshot chunk 读完了之后有一个信息报告请示进程，这个报告请示十分症结，包孕该 chunk 的根本信息和该 chunk 是在甚么位点读完的（即 close 位点）。在进入 Binlog 读取阶段之后， 在 close 位点之后且属于这个 chunk 的 binlog 数据，是要需求持续读取的，从而来包管数据的残缺性。

obg4sh2as50.jpg

在一切的 Snapshot chunk 读完之后会发一个特殊的 Binlog chunk，该 chunk 里包孕刚刚一切 Snapshot chunk 的报告请示信息。Binlog Reader 会按照一切的 Snapshot chunk 报告请示信息根据各自的位点进行跳读，跳读完后再进入一个纯正的 binlog 读取。跳读就是需求斟酌各个 snapshot chunk 读彻底量时的 close 位点进行过滤，防止反复数据，纯 binlog 读就是在跳读实现后只有是属于指标表的 changelog 都读取。

5asvvjricel.jpg

Flink CDC 增量快照算法流程为，首先，一张表按 key 分红一个个 chunk，Binlog在不停地写，全量阶段由 SourceReader 去读，进入增量阶段后，SourceReader 中会启一个 BinlogReader 来读增量的部份。全量阶段只会有 insert only 的数据，增量阶段才会有 update、delete 数据。SourceReader 中详细去担任读 chunk 的 reader 会按照收到的分片类型，抉择启动 SnapshotReader 仍是 BinlogReader。

hc1myyrq4gc.jpg

Flink CDC 增量快照算法的中心价值包罗：
第一，完成了并行读取，程度扩展的才能，即便十亿百亿的大表，只有资源够，那末程度扩展就可以够晋升效力；
第二，完成 Dblog 算法的变化，它可以做到在包管统一性的状况下，完成无锁切换；
第三，基于 Flink 的 state 和 checkpoint 机制，它完成了断点续传。好比 task 1 失败了，不影响其它正在读的task，只需求把 task 1 担任的那几个 chunk 进行重读；
第四，全增量一体化，全增量自动切换。
03
Flink CDC 增量快照框架
Flink CDC 的增量快照读取算法初期只在 MySQL CDC 上反对，为了其余 CDC Connector 也可以轻松地接入，获取无锁读取，并发读取，断点续传等初级才能。在 2.2 版本中，咱们推出了增量快照框架，把一些复用的、能够积淀的代码笼统了出来，把一些面向数据源的独有的完成进行笼统。

hxm5ft14y0c.jpg

Flink CDC 增量快照框架的架构如上图所示。

zf5c3dzqnql.jpg

增量快照框架的设计环抱一个中心的 API 展开，这个中心的 API 就是DataSourceDialect（数据源方言），这个方言关怀的就是面向某个数据源独有的，在接入全增量框架时需求完成的办法。


关于 JDBC 数据源，咱们还提供了 JdbcDataSourceDialect 这个 API，能够让JDBC 数据源以更低的本钱接入这个框架。


如上图所示，假如用户要完成 MySQL 接入的增量快照框架，只需求完成MySQLDialect 便可。


目前社区曾经有多个 Connector 正在对接到增量快照框架上，大家能够关注社区 PR 理解更多详情。
04
社区开展布局
Flink CDC 的增量快照算法和框架的发生都离不开开源社区的全体奉献者，最初来引见一下社区的开展和对将来的一些布局。首先来看一下过来两年中，咱们公布的一些版本：




社区目标标明咱们正在高速速开展的，特别是 2.0 版本公布之后，用户增长上了一个新的台阶。
Flink CDC 的社群目前也有十分多小火伴参加，开源社群曾经超过 6000 开发者，社群里大家能够自在地探讨开源和技术。


比来也统计了来自不同公司的关注者，如上图所示，能够发现其中不乏国际里头部互联网企业的身影。


全部社区在将来的布局次要环抱在框架推行，生态集成，易用性三小气面。
05
问答环节
Q1：表的联系数量怎么肯定？步长怎么肯定？假如全量数据对比大的时分，同时又在同时又变卦频繁，把增量 merge 到全量这个效力和完结时间怎么包管？
A1：第一，表的阿谁联系数量怎么肯定？默许每个分片大略是 8096，就是按照这个数量来的。这外面详细分的话实际上是有两种分片的形式。第一种，分片假如说你表现自增而且是平均的，咱们间接取一个 min 跟 max，就你能够经过一个简略的数学计算肯定这个分片数量。还有一种就是表的分片是不平均的，好比说它的 ID 是个 UUID 这个时分咱们就是经过 query 来查，就是经过数据库查问这个分片的界限。固然的话在社区也做了得多优化，就是说他会 lazy 地去查，由于一些 query 会对比耗时，反对一边查查问肯定分片，一边读取曾经肯定的分片内容。
那第二个问题就是说把增量 merge 到全量的这个效力跟完结时间怎么包管。其实的话读一个全量数据一个 Snapshot chunk 的时分之间产生的阿谁 Binlog 咱们是有过优化的。假如是说阿谁 Binlog 的位点没有后退，或者说后退的时分这张表没有做改动，那末我不会去读这个增量。那假如说有读，阿谁增量其实应该就很少一部份这些都是在内存外面做了一个 upsert 或者说叫 normalize 全部进程的话这个是十分快的，而且这个的话是能够并发做的。好比说咱们大的功课我搞个一千个并发在这个中央读一千个并发，或者说上几百个并发在这个中央读，效力跟这个时间跟这个并发相干。
Q2：增量 log 有得多，单个 reader 的压力很大，也是能够并行读取增量 log 吗？
A2：目前的设计是只反对单个 reader 的，能够把增量阶段的阿谁资源给它开大一些。这个设计的初衷登程点是在大部份的数据源下游的这个日志写的时分，它其实只要一个 binlog 文件，它全局是单文件的，实践上你写的话比读的开消是要大的，就是个别来读的阿谁开消，假如说不是一些网络或者说是资源不敷，阿谁读是要比写要快的。
明天的分享就到这里，谢谢大家。
｜分享佳宾｜


徐榜江（雪尽）｜阿里巴巴 技术专家
就职于阿里云 Flink SQL 引擎团队，是 Flink SQL 模块的中心开发和 Apache Flink Co妹妹itter。2021年开始专一于 Flink CDC 开源社区，作为 Flink CDC 社区 Maintainer，翻新性地提出并完成了增量快照读取框架，经过无锁算法完成并行读取和断点续传，成为业界首款同时解决以上问题的开源产品。
｜DataFun新媒体矩阵｜


｜对于DataFun｜
专一于大数据、人工智能技术运用的分享与交流。发动于2017年，在北京、上海、深圳、杭州等城市举行超过100+线下和100+线上沙龙、论坛及峰会，已约请超过2000位专家和学者参预分享。其大众号 DataFunTalk 累计出产原创文章900+，百万+浏览，近16万精准粉丝。?