00:00
我们回顾一下flink跟忽底集成时候的一些核心原理,第一个呢,就是去虫啊驱虫,那忽迪的驱虫分两步啊,第一个呢,它写入的时候是是不是要斩P对吧,它是不是有8Y的长,还有长buffer对不对,他在斩buffer的时候就会去虫了啊,另外就是写入的过程当中会做一个去虫,这个根据什么呢?根据咱们的index,还有咱们的那个record key。这个前面都聊过的,咱们简单说一下就行,还有一个什么呢?预合并字段啊BY啊,我们当时说了,如果就索引找到record key对不对,发现record key相同,那这个时候会比较预合并字段这个值大的啊,就以谁为准对吧,就相当于说实现一个覆盖效果了,所以不存在说就呃也不是不存在就这样是不是就是一个驱虫的效果呀。那么愈合并字段不指定,是不是就以插入的顺序谁后插以C为准是吧?
01:11
你看这个字段为可选,如果没指定,会看是否有TS,如果有TS就自动备选,如果没有,没有指定,而且也没有TS,则为处理的顺序啊,这个是新老消息的去重。另外呢,这个是展消息阶段的驱虫,呃,它将buffer发送给这个write的时候,可以执行一次驱虫啊,它就通过一个payro的接口。保他自己其实也一样,也是通过这个啊,他保留字段较大的消息啊。它是单纯在flink自己内存的一个计算啊,在同一个并行度里边啊。也就是说前两个都是一一回事儿啊,只是从不同的角度给你跟描述一下。
02:04
另外呢,就是后面的这个写pack的增量消息的去重,呃,我们说每写一个pack都会有一个,都会有一个新的park,呃,就是老的park跟新的一些数据的默局对不对?那这个时候呢,增量的数据我们前面也聊到了,增量会放到哪里啊,放到一个可刷写可溢写的慢和结构里面啊,这个是在内存,也就是说存不下它就会刷写啊,它是一个内存级别的所引,呃,增量数据如果没有提前去重,那么key的后来消息会覆盖原先的消息,你看它是map吗?对吧?那它的key就是,其实就是什么record key啊,Map的key就是我们指定的record key组件啊,那map结构你put不就是覆盖吗?也就是说这边也有一个去虫啊,那接接着往后呢,他会扫描这个base啊,PA会的文件,会不断的查看索引是否跟这个老文件是否有相同的key,如果有。
03:09
他就会。先来说判断还是判断什么,保留哪一条消息,还是根据谁啊啊默认的pay漏的就是按照咱们的pre字段啊,除非你指定为其他的啊,就是这个paylo的,咱们一般还是啊默认的这种方式的话,还是还是这个意思对吧?啊也就是说C,呃,我们这个。增量合并的时候也是根据这个玩意儿来了,其实说了这么多都是一回事啊,就是这个东西去虫最核心的东西。那哪一种表都有啊,另外就是跨分区消息的去重,那么要强调的是不同的分区消息是不去重的,这是默认情况下啊。呃,相同的key,如果新的消息换了分区,那么老的分区消息仍然保留。
04:07
这个就是有一个问题啊。啊,什么意思呢?原先比如说我是EAB,然后我按照这个字段做分区,后面呢,这个值改了变成一,因为分区字段的值变了,那这条数据是不是要挪到这里去啊,那那就出现这个老分区,A分区有一个一,B分区也有个一啊这个其实已经是过期失效了,对不对啊,但是如果我们开启一个全局索引的话,那是可以处理这种。呃,分区字段变更的去重啊,它会先往老的part发一条什么删先删除,然后再往新的写啊,就这么一个原理啊。是P於去虫。嗯。那表写入的原理我们其实也再三强调了,那么大家看这张书里的图,呃,先是读取输入之后呢,呃要把它写到户底里面,接下来要经过什么BUCK3呢?这些咱们在沃UI是不是经炒看的啊,我们说写的时候它是不是按照bucket去展消息对吧?64兆嘛。
05:21
那可能有多个对不对,完了buck完了之后是不是要丢给这个right。对吧,那这个right之后可能啊,看我们有没有设置一个异步的压缩,还有一还有还有另外一件事就是清理仪,那如果异步压缩开启,它就会先有一个调度的计划阶段,还有真正执行的阶段啊。那执行,呃,执行完之后是不是一个呃,Think阶段的对吧,Think commit,呃另外呢,就是另一块就数据清理,那这个流程大家应该是很清晰的,那这边就分三块详细的介绍一下,一个是数据写入,诶就上面这一大段啊,从八的SIGNON1直到string writer这里啊,不考虑压缩,这时候呃,你看先封装数据成护体实体,接下来呢,就是分配这个桶了啊,就给数据分配写入的文件地址,若为插入,则为大小最小的fire group的fair ID内进行插入,其实就是什么?这个就我们前面讲的,能蹭就蹭对不对啊,能蹭就蹭在此文件的后续写入中。
06:32
同一个fire group fire ID是不会变的啊,并且根据提交时间显示最新版本啊,其实就是啊,再啰嗦一遍,再啰嗦一遍。行吧,如果我一更新又怎么样?前面咱们都聊过了啊,我也不想再多讲。呃,另外呢,就是咱们这个who d stringri写的时候呢,它是先有一个缓存的设置,这个超过这个flash size就是1G啊,那或者是做缺point时刷,咱们前面刚刚聊过,就常见问题里面啊,说一直看不到数据,就是这个刷时机嘛,啊这是其中两个,还有一个是8Y的64兆对吧,三三种条件,那这里有一个协调器,这个主要是跟writeer进行一一些交互啊,处理check poon的事事务这些事儿啊,而且呢,提交我们所谓的instant。
07:27
啊,并生成什么什么,就是一个秘书嘛,这个东西啊,协调器一个秘书啊,中央空调啊。啊,这个也不啰嗦啊,那压缩这个咱们也知道主要是用在什么MR将log合并成趴回的啊,那么它会便利分区下最新的帕跟其对应的log进行合并啊,那这个东西也不用啰嗦了嘛,那这策略有四种嘛,啊前面也都介绍过了啊,我我也不不讲了,那数据清理是咱们前面没怎么讲的,但都知道会清理,呃,那每次我们往库里写数据都会可能生成一个新版本的数据文件,对吧?啊,如果是Co,如果是Mo呢?
08:10
是不是会做一个compassion,呃,对吧,那根据咱们写入插入的频率,咱们这个文件的版本数可能一直在增长,对吧,从第一个版本一到后面一直差,都指不定增长到1万个版本以上了啊,那我们历史记录不可能无限期保留,它会有一个服务来回收旧的数据,就是这个数据清理服务,那它的清理策略呢,官网都有啊,一般的清理策略是什么?保持最新的文件版本号保持几个啊。除了这个之外,全干掉啊。那就是作业图啊,作业图那在最后就简单说一下读的一个原理啊,咱们读的时候是不是有一个spirit monitor啊,就读忽地表的话,咱们select去s select from护地表的时候啊,没有注意看对吧?呃,那其实就是有一个东西啊,如果是互列表,它会开一个什么切分的monitor算子,每隔大家注意它是怎么实现的这个读啊,每隔N秒监听时间线上的变化,将。
09:17
变更的instance封装为文件片啊,另外呢,就是分发log文件的时候会按照什么fire ID进行key,这个是后面版本加的啊,以前不会做这个T啊。保证同一个fire group下的数据文件都给一个task处理,这样的话我们处理数据就是什么有序啊有序,而且更加的集中了每个人负责啊,同一个文件片行吧,这个就简单提一嘴而已,就是主要想强调的是这个东西。主要是想强调第二点。
我来说两句