00:00
另一个比较重要的就是压缩,哎,就是咱们经常提到的compassion,那这个东西在我们使用Mo,特别是flink流式场景,并且用mor表的时候要尤其注意,因为这个compassion它嗯可能会严重影响我们的性能啊。然后我们先在聊这个性能之前,我们先聊聊它的参数吧,啊,首先第一个最核心的参数是这个是压缩的开关。那如果你翻译单词的话,这里翻译为是什么异步的对吧?啊,但其实这个我们义务习惯上称,因为它本来就是异步的嘛,也就是说执行到compassion的时候,我调用一下compassion,让他呃单独去做compassion,不要阻塞我,但是这样的话,嗯。因为compassion,我们Mo本来就是读时合并,但是你确实在写入的时候在不断的执行compassion,这有点违背咱们Mo的那个理念啊,啊,并且也会影响性能啊,那所以我们经常把什么compaion关掉,把它变成false啊,所以这个参数是比较重要,我们先先先记住这个啊,Enable,那这个compassion关掉之后,嗯,那有的人就有疑问,那我一直不执行compassion吗?啊,也不是,咱们可以离线compassion,也就是说由我们自己手动来控制,多久做一次compassion。
01:22
啊,这样就比较舒服了啊。对于离线的方式compassion,好,那另外一个就是要区分的是schedule,这个叫compassion的调度阶段啊,它compassion的原理是先进行调度分配,调度完之后再进行compassion啊,那一般这个调度我们还是建议开启的,那对应的话,咱们可以看一下老作业啊,完成的作业这里。在这个节点当中有一个叫什么呢?在compasson之前还有一个叫P阶段啊,这个就是我们刚才讲到的调度阶段啊,这这个一般呢,这个不会怎么影响性能啊,这个我们就在线调度啊,还是正唱启,然后这个呢,一般是关掉生产上啊。
02:05
好,再往下走啊,这两个就过了啊,接下来这个刚才提过,这个是compassion的一个并发度,默认是四,对不对,好,那还有就是compassion的策略啊多它是按照什么条件来进行compassion,那么它的策略有四种,默认呢,是按照数量,比如说你几次提交啊,经过了四次提交啊,经过了五默认是五次提交啊,默认有五次增量提交,那就会触发一次compassion。那这是纯粹基于数量,那么还可以纯粹基于时间,那就是这个参数啊。Seconds。呃,那还有呢,就是数量跟时间两者同时满足,我才compassion,大家注意这个是且还有一种策略是货,呃,要么数量达到,要把时间达到,其中一个达到我就compassion,那么在生产上呢,我们由于是流失不断的提交啊,那我们更习惯于用这个number。
03:02
那这个也是默认的一个策略啊,默认策略,那这个默认策略是多少呢?是五啊。那这个时间默认是3600秒啊。那还有其他的就是关于compassion的一个资源使用,后面这两个是关于资源的,一个是他使用的内存,另外一个是他使用的IO啊,如果是内存的话,它压缩去重的时候,这个内存默认啊是100兆,那么大家很显然可以,嗯,应该有感觉到这100兆不算大吧。对吧,所以你处理的数据量大,流速快啊,没Q呃,TPS比较高啊,那这个时候你可以把100兆调适当的调大了啊,调大你可以去观察flink的web UI的内存使用情况啊,适量的调大。呃,那一般建议我们说,嗯,可以调到一个G左右,你再去观察情况啊,这是一个建议值,另外一个是IO,呃,这个是压缩计划用的啊。
04:00
啊,不一样啊,上面这个是压缩任务,这个是压缩计划用的时候的IO上线默认是五个G啊,默认五个G,呃,所以说如果你加上这些compassion,整体看起来还是比较吃资源的,而且效率也也不会特别高啊,所以一般就回到那个话题啊,这个在线压缩我们一般是关掉了,呃,那么看一看指定的方式啊,指定的方式比如说我以前写过的一些。就比如说这里吧,我这边不是会指定一些并发参数嘛,对不对啊,在位里面写就可以了啊,位里面写放大一点了,那之外呢,我们看一下我还会指定什么,呃,这个调度调度是开启的,当然我当前案例是演示,快速演示,所以是。呃,在线压缩也是开启的,那你看我的策略还是用的默认的number,还是用默认值五啊,虽然都是默认值,但还是写出来让大家看一下啊,那后面是其他参数先不用管啊,就是这么一个用法就可以了,当然呢,你也可以再用hi去写啊,可以用hi。
我来说两句