00:00
那介绍完两个比较常用的合并术引擎,那大家觉得哪一种会更好用一点,或者说更符合咱们实际开发一点?啊。那好了,假设咱们可里卡house存储的就是一一张宽表啊,聚合完了,那也不一定聚合完对吧,也可能是存明细也都有可能啊,反正各种场景都有可能,那很多时候咱们是不是要做一些聚合查询,你可能觉得是不是用三。类似的,这种聚合类型的预聚合的合并数引擎会好一点,但是它有一个问题,同学们,它能保证幂等性吗?咱们实时系统非呃经常会比较讲究这个数据的一致性,对吧,一致性,那你想想密等性能保证吗。这就看你的取舍了,为啥呢?如果啊,这假设这是你的一个计算引擎,比如说flink吧。那你呃,往克里号里面写。那你是不是有一个问题重复写入啊,那什么情况下会出现一个重复写入呢?就是说我已经写进去了。
01:06
但是我这个程序挂。我我这个计算引擎这个任务挂了,然后呢,你是不是flink本身有一个,呃,那个什么check po机制,对吧,它是不是又恢复了他的一个状态,然后他如果又重新写入了呢。比如说他这一批次写入要写100条,但已经写了50条,但还没写完,他挂了,他是不是认为是失败的,他重启起来。作业重新启动起来,他是不是还会将这100条数据再写一遍?有可能吧,那你想想,对于click house来讲,它是不是产生了50条的重复数据啊,那你自动的三米引擎,它是把重复的50条也算进去了,对不对?那如果你对幂等性要求特别高的话,呃,就数据的一致性,那很显然是不符合要求的,那这个时候你只能选择谁呀?这个是比较合适啊。
02:02
Replacing me。他能保证一个最终一致性,对吧?他会帮我们去宠,但是我们说用它并不是高枕无忧。为啥呢?我们说了,如果不是同一批次插入的,并且。你查的时候他没执行,呃,合并分片的话,那这个时候可能数据还是有重复的呗,那我们说呢,你你可以当然是有办法解决的,基于这个引擎的话,呃,那办法呢,在咱们高阶里面会谈到对吧,一个是。有的同学就说啊。战斗民族就要简单直接或怎么样。每次查询前执行一个手动。合并分片,那你想想,你每次都要去查的时候,都要执行一次分片,那肯定可耗,还玩啥,天天在服务你就得了呗。对吧,那你执行分配的时候,数据还能写入吗?还能读吗?对吧,所以你要悠着点啊,你不要以为手动咱们前面演示那么多都是什么手动手动合合并手动合并这种是为了咱们快速演示这个效果。
03:13
当然你在生产环境要执行这个命令,你要考虑清楚啊,因为可能你会影响线上的业务,对吧,这个得慎重。第二种方式就是自己去从。也就是说,比如说利用group,或者说我可以加一个字段做标记,对吧,咱们后面展开介绍啊呃,就有点参考,而且base的一个做法,那还有一种呢,可以加final。关键字final呢,它其实。会自动帮我们做一个过滤。只查最新的数据啊,重复的数据它只会选择一条啊,但是这个final你也得想想,它有版本区别,再老一点的版本,你加final查询的话,它是单线程的。
04:00
在20.8,也就20年八月份之发布的稳定版呢,它才支持多线程。这个也是一个点对吧,所以在早期呃,在早一点呃,有些企业装的是一些老版本的话,他们优先选的方案估计是这种自己通过语法来实现。啊,通过语法来实现,但是。甚至有些企业会怎么选呢?我不管。你只要能定期给我去重就行了,说为什么呢?这就有一个取舍问题,我的数据量,比如说每天有100亿条,每天啊,那我可能发生重复的概率是比较小的,对吧?除非你中间某一个环节出现了故障,重启了,重试了,才会产生一小部分的重复数据,是不是一小部分,那这个时候我是可以忍受的呀。比如说我100亿,那最终统计出来是100亿啊,零一万条,那你这1万重复出来无所谓啊,那这种场景你是可以忽略,但如果是跟钱相关,这1万条也不能忽略。
05:05
对吧,这所以要结合你实际的业务场景来看啊,那至于后面这几种方案,我还是建议大家好好去了解了解,好吧,那咱们高级部分有展开详细介绍。
我来说两句