Flink CDC 同步表至Paimon 写数据流程,write算子和commit算子。(未吃透版)
流程图
一般基本flink cdc 任务同步数据至paimon表时包含3个算子,source、write、global commit。
source端一般是flink connector实现的连接源端进行获取数据的过程,本文探究的是
-
source算子获取的到数据如何传递给writer算子?
-
writer算子如何写数据?
-
global commit算子做了什么事情?
-
第一问:
默认根据primary key的hash值决定往哪个桶写入,一个桶对应了一个lsm tree writer。
-
第二问:简单来说就是将数据格式进行转换,然后写入到内存,内存满了就溢写到磁盘,最后再判断是否需要执行compaction。具体而言:
-
传入的数据是InternelRow格式,需要转换为BinaryRow格式
-
将数据写入内存
-
生成rowDataStoreWriteOperator算子,预写算子,不会生成snapshot,primary key table的最终调用到MergeTreeWriter
-
MergeTreeWriter中执行两个操作,内存够,就把数据put到内存,内存不够就flush到磁盘
-
如何put到内存?通过BinaryInMemorySortBuffer和BinaryExternalMemorySortBuffer
-
BinaryInMemorySortBuffer将BinaryRow 格式的数据序列化到memory segement
-
writeIndexAndNormalizedKey 方法将key进行归一化,将记录在output view中的offset记录到SortIndexSegment中。
-
-
-
-
内存满的情况下会将内存中的数据写入到磁盘,分为批作业和流作业
-
批作业
-
具体方法调用BinaryExternalMemorySortBuffer的spill() 方法,将内存中的数据进行排序,然后写到磁盘
-
当文件数大于128时(默认配置可以修改)将文件合并成1个,调用AbstractBinaryExternalMerger.mergeChannelList()方法
-
-
流作业
- 遇到checkpoint或checkpoint时,sort and merge
-
-
Flush数据生成真正的Orc文件,但是文件信息还是被缓存在内存中
-
调用MergeTreeWriter.flushWriteBuffer()方法,写磁盘之前进行merge,最终调用orc进行写操作
-
将新增文件缓存
-
-
将在内存中缓存的信息flush到下游commit节点
- prepareSnapshotPreBarrier()函数最终调用到StoreSinkWriteImpl.prepareCommit()算法
- 每个bucket都会有一个lsm tree writer,将内存中的数据flush到磁盘,再将新增文件封装到一个对象返回
-
-
第三问:接着上一步。(两阶段提交,具体流程如下)
- 下游commit operator 接收上游的新增文件信息,缓存到一个Deque中
- 做checkpoint,先执行snapshotState逻辑,将内存中的所有committable根据checkpointId聚合成一些ManifestCommittable
- 将List<ManifestCommittable> 写入State
- checkpoint完成时调用notifyCheckpointComplete(),执行commit 生成snapshot,一次checkpoint对应一次,这也是两阶段提交的第二个阶段。
- 记录修改
- 检查是否有冲突,比如多个writer同时执行compaction
- 循环执行commit 直到成功或者异常
- merge 新老manifest
- 写manifest文件
- 准备snapshot相关信息,一个json对象
- 将snapshot信息持久化到磁盘
参考文章
完全参考大佬的文章结合源码慢慢理解,还有些地方还没吃透或者理解有误的,在后续的使用过程中不断加深理解吧。
https://mp.weixin.qq.com/s/badeiuTFCpcNSmarCaSahw
https://paimon.apache.org/docs/