00:00
那么接下来咱们来聊一聊精细控制,也就是说你现在全局设置变形度可能有点浪费,有点不好。啊,效果不怎么样,那这个时候你就要去算子级别去单独去指定了,一些繁忙的算子你可以并行度是大一点,一些比较呃,空闲的算子你可以变形度给小一点,啊就这么来更精确的精打细算,怎么设呢?那么首先我们自己呢,把算子分为source。也就击败之前,另一块呢,我们分为就正常的一些转换算子。还有一块呢,咱们是think端啊,这么来区分,我们挨个来看一下,首先SAS端link不用讲数据来源很多呢,应该都是卡不卡,或者其他的消息队列,像这种呢。不用考虑最优的消费是不是1:1啊,比如说你卡夫卡是。刚才讲了五个分区,那你将哨子算子的并行度设为五。
01:04
那如果小了,会有什么问题呢?比如说我造纸并行度只有三,那就不太好了,那就不均衡,因为它会出现这么一个状况情况啊,你看这个比如说是卡不卡的分区啊,用红色表示,那么flink s算子并行度比如说是三。那就会出现这么个情况啊,同学们。是不是有可能是这样的啊我。你看是不有的消费一个分,有的消费个分,就他们互相之间是不均衡的,这种很容易产生倾斜啊,就是不的时候都有倾斜。那这肯定不合适,第二一个咱们这个消费速率可能效率没1:1高吧,所以咱们推荐建议的时候,还是达到什么sources并行度跟分区数一样,那就达到1:1的一个消费。这样是最好的。一般来讲,这个不会是瓶颈。
02:01
瓶颈在哪里呢?瓶颈在于你后面的计算逻辑对吧?那你首先要保证sources是最优的效率啊,这点就够了,那么如果是其他的数据来源,那你要结合那个你对接数据源的特点对吧?他能就最优的比例是什么样啊,这个你再去考虑,咱们这边是以卡不卡为例啊。另外一个纯属缝算子。也就是说中间的除了S子跟S,中间这些算子,咱们细分为K之前跟K之后,为什么要这么区分呢?一般来讲咱们击败之前都是什么类型的扇子啊?是不是都是什么map Fiat flat map对吧,相对来讲我们正常要么做一些清洗呀,数据格式的转换呢,字段补全呢,呃,修正啊。过滤啊,就等等一堆,像这种操作一般计算逻辑不会特别重,我说的是一般啊,不绝对啊。像这种的算子,咱们并行度就不用再去调了,跟什么你跟SS保持一致就够了,就OK了啊,那如果K败之后啊,一般咱们是要进行一些啊,比如说开窗聚合呀,或者聚合呀,或者怎么样等等,是不是涉及到计算。
03:18
对吧,那这个时候咱们像击败之后的算子,比如说你击败之后做了一个process啊,做了一堆你呃,这个指标对应的一些计算逻辑啊,还比较复杂,那这个时候比如说process你就可以。比如说S跟KY之前都是五,那你这边PROCESS5的话。呃,效率有点差,或者说你反压定位到就是process产生的反压。那瓶颈在它,你是不是可以考虑将process并行度调大一点了?那一般来讲,这个并行度设多少合适呢?啊,我比较接近是二的次方。什么意思啊,就比如说二的五次方。
04:01
多少啊,是不是32呀,对吧,二的六次方64就调成这种二的N次方的数量,或者十六八这种。为什么呢?这个跟它的一些,呃,涉及到一些底层原理啊,咱们的一个不知道大家知不知道啊,简单提一嘴,咱们key by的话,它是不是有个分区器叫建组分区器啊。他是不是要取哈希值在?对吧,哈希,而且是不是两次。两次,哈希得到一个建组ID。ID,它再乘以一个下游并行度,再除以最大并行度128。也就是说最后就这么一个公式。哈希结果的乘以下游算子的并行度,比如说process嘛,啊,Process。然后再除以最大变形度啊,取这个值。你首先最大并行度默认就是二的几次方啊,七次方呗,对吧。那下游上的变形度你设多少啊,最好跟他能够。
05:03
约掉对吧。或者说是有一定的啊最大公因数,比如说你给个五合不合适呢,五跟128哪有公约数啊。不,没有最大公约数,最大公约数就一呗,那这种就不太好啊。就类似的啊,大家明白就好,那比如说你,呃,就是把process之后的。Process。或者说你做的什么reduce啊这种。你可以比如说尝试着调成16啊,32这样子。这比较推荐的。但是也不绝对,只是建议啊,如果你的并发,你说八跟七之间在犹豫,其实我觉得无所谓啊。并发比较大的时候,比如说达到了几十,你要去调,那遵循这个二的整次幂的原则,那么第三一个就是S端呢。
06:00
这个还是比较呃容易。经常看到大家出问题的地方,为什么呢?因为think端我们往往是要写到什么外部系统。那外部系统可能是一个数据库,可能是消息队列,卡不卡?可能是no circle的数据库,可能是关系型数据库,可能是写文件,这得看你具体的需求来。那这就涉及到一个问题了,你flink,你说你很强,哎,你能每秒钟处理多大的数据量,你的延迟能低到多少,那都是你强,但是你要写到外部系统。你是不是得看别人受不受得了啊,你说啊,你非常快。啊处数据量很大对吧,你又,但是你要输出给部的话,你再有用呢不。所以这个时候,呃,S端往往咱们考虑的是外部系统啊,它的性能怎么样。
07:01
那如果是卡夫卡,其实没有什么太大问题,就跟分区数保持1:1 think变形度等于卡夫卡分区数就行了。如果写卡不卡,这个毋庸置疑。那其他的话你就得掂量掂量了。这个咱们也没有具体的,因为你指不定你要写哪个吧,啊,主要看别人扛不扛得住。另外就是你写的数据量。比如说你写的数据量非常大,那这个时候你也得考虑一下变形度是不是可以大一点了,对吧。所以这个呢,就提醒一下大家啊,这端啊,没有唯一的通用的非常好的原则。因为你要具体问题具体分析啊。唯一能够量化的就是卡夫卡这种啊,你我们很明确知道达到1:1就最好了。好,那这个呢,是给大家介绍一下啊。嗯,那像咱们刚才这个任务,其实已经满足需求了。
08:02
我都不需要再精确的去调整,因为它每秒钟达到了7000条,但我们一般实际企业高峰能超过几万条每秒的,我觉得应该不是特别多。或者说呃,也不应该没那么多吧,啊,但至少说比如说一个案例说2万条3万条,那我调成这个并行度已经够了,那我就不需要再也懒得再去精细调整。
我来说两句