00:00
那接下来呢,我们看一下5.2.3.4.5这几个呢,这三个参数呢,是咱们对shuffle的。执行效率,还有一个它的稳定性啊,做了一个调整,首先看第一个啊,通大reduce缓冲区,减少拉取的次数,这个其实呢,跟咱们咱们简单画个图理解一下,这是map端,这是reduce端,那么reduce啊,比如咱们比如说写了一个group某个字段,对吧,那他是不是要将相同分组的数据,Group by字段相同的那个数据拉到同一个reducer,同一个分区数据啊,对吧?那这个时候呢,咱们比如说map有好几百个,比如说有300个。那reduce在拉取数据的时候,它并不是说这200个我一次性都能够给你拉进来,甚至他拉取的过程可能持续的多次,那这中间就有几个参数呢?第一个就是reduce里面有一个缓冲区。
01:00
它是基于内存的,内存的缓冲区,它默认默认呢是48兆,也就是说它最多一次拉48兆,呃,那假设咱们需要拉的数据一共呢有500兆。那他你想想,如果48兆的话,它是不是至少要拉11次啊,对吧,那么如果我把这个参数调整为96兆或者100兆。那是不是只需要拉五到六次就行了,那么咱们就可以从这个拉取的次数上做了一个优化,执行效率上,那么这个参数呢,一般也不需要调整。那如果呢,你中间的数据量真的特别大的话,才来考虑调节这个参数啊,因为你调节这个参数同时会增大一个内存的一个压力,对吧,毕竟这个内缓冲区用的就是一个内存。每个reducer都调大,那你想想reduce reduce端的数量如果多的话,那整体呃,增加的内存量那就变大了,这就看大家去取舍,呃,迫不得已咱们再来调啊,数据量大啊,中间数据量大,那么也可以看看源码啊,在这个类里面。
02:08
给大家找找它的位置,CTRL加N,我们搜索一下。这个是源码的位置,其实这个类名就很直观了,对吧?Shuffle reader啊,也就读取阶段,这个就是reduce端做的事,它里边核心方法呢,就在咱们这个reduce方read的方法。那这边也有解释对吧,当前这个reduce task读取的一个数量,那在这里呢,有一个参数就是这个。Reduce in,就传输中的最大大小。那我们点一下这个参数啊,给大家打个点点进来,那我们可以看到参数名就是它默认值呢,是48兆。是第一个咱们可以调整的地方,就是来提高性能的,那我们来看看这个文档里面咱们。
03:06
2.4这个东西reduce端拉取数据的一个重试次数,就像咱们刚才讲的一个reduce,它可能要去拉,对吧,那么拉的过程中可能由于某些原因,比如说咱们的IO。呃,IO负载比较高了,那么可能我拉取的速率很慢对吧。那很慢呢,他可能就失败了。甚至说呢,咱们的网络不太好,传输的很慢很慢,那这个时候呢,可能他也失败了。那有可能你这个网络问题只是短暂的波动,那么如果他失败,整个作业停止呢,那咱们还要去慢慢的分析定位,还要去调整重新执行,那可能咱们不太希望这样,我们希望它有一定的呃健壮性,那这个时候呢,我们就可以添加一个重试的次数,它默认是有三次的,默认是会重试三次拉取,也就是说他拉取失败了,那再重试拉一下,再失败,再重试着拉,尝试着拉一下,那这个三次呢,咱们,呃,如果你真的网络情况不好,或者IO效率比较低的话,你可以稍微调高一点,对吧?那不建议调的太大,因为你想想嘛,嗯,如果你调的太大,代表你是要容忍他一直失败,一直失败,那其实已经没有意义了,你想想生活中的例子对吧?比如说一对恋人,一对夫妻,呃,其中一方呢,可能出轨了,给你戴织了一顶帽子,对吧?啊,不给你啊,给对方织了顶帽子,那可能对方就觉得,哎呀,想要生活过。
04:39
不得去,那总得容忍一些东西啊,好,他说这次我忍了,那么结果呢,这没有收敛,这个帽子越治越高,对吧?那第二次你想的,哎呀,为了家庭考虑,你再忍了,那么在第三次。你你应该。等待程度应该也差不多了吧,一而再,再而三,对吧,我说事不过三了,那这个时候呢,所以呢,其实你次数这种的次数不用太多了,你三次跟900跟99次,其实他背后的含义已经一样了,已经无无法挽回了,所以咱们呢,也没必要那样子,对吧,何必呢,对吧,放自己一马,有时候。
05:19
对吧,就是海阔天空啊,那一般呢,咱们建议这个参数你要调的话,可能调到六次左右就差不多了啊,调到六次。没必要太高啊,这是第一个参数啊,重试的一个次数。这提高呢,咱们沙的稳定性的,那还我们还得看一个参数,就是拉取数据的等待间隔,咱们上面不是说的reducer在拉取数据的时候,如果失败,它会进行重试吗?那么重试中间要间隔多长时间呢?对吧?这个就是由这个参数指定,比如说第一次执行它失败了。那这个参数呢,它默认是五秒,也就是他过了五秒之后,它会进行重试啊,尝试着再重新拉取,那如果再失败,那还得再间隔五秒钟。
06:07
那这个是这个参数的含义,那么你想想呃,那如果发生重一般呢,要么就是网络出现的波动,要么就是咱们的IO啊不行啊,那这种场景呢,咱们调大重试次数的同时,也要对每一次的这个间隔稍微拉长一点。对吧,缓一缓,让他缓一缓,你不要那么频繁对吧,一天支一下帽子,你哪受得了啊,那你说说一个月来观察一次,对你心脏好一点对吧?嗯,那这个就是这个参数的含义,那默认呢,它就是一个五秒。那么在这边咱们是比如说建议。已经到了这种情况的话,建议还是调到呃60秒左右啊,像给到大家的代码这边都是一些建议的值,那上面这两个是常规设置啊,第一个呢是关闭了map join,第二个并行度36,这跟以前都一样。
07:01
那接下来我们看看这几个参数,这是缓冲区的大小,这个是重试的次数,下面这个是重试的间隔。啊,我给大家写一下吧,这个呃,Reduce缓缓冲区它默认呢是48兆,那下面这个是呃,重试次数,这个默认三次。那再下面这个就是重试的间隔,默认呢四五秒钟,当然这些参数呢,这个时间你要不想这么长,你给个30秒也行啊,那么这边呢,我是已经把作业提交了两次了,那第一次呢,我是将它缓冲区大小改成了一兆,也就是说咱们模拟这个缓冲区大小比较小的情况下,我其他两个参数都其他参数都没有改啊,我执行了一次,那第二次呢,我把这个参数改成了96兆,重新打包,重新执行了一下,那我们直接来看历史服务器啊,我们来看看效率上到底有没有提升啊。
08:12
打开咱们这个历史服务器来看列表,这个呢是我提交的两次,这个对应的是缓冲区调为一兆,这个调为96兆。来,我们先看一兆的情况,点进来。那我们可以知道并行度是36对吧,是两次杀否啊,中间的这里面有杀否,那我们看一看reducer刚才是不是负责读取啊,哎,他们都是有什么。读取的啊,他们是reducer端啊,那么一个一个看呗,我们先看第一个。看沙Le瑞,你从下面呢,只能看到一个读取的大小。啊,读取的数据量啊,那这个你看不出效果的,要看的话就拉到上面看这个它的时间线在这里边呢,它有一项参数叫沙uffle瑞的T读取的时间橙色的那么可以看到,比如说这里是不是有啊,把鼠标放上去,这里你能看到啊。
09:11
那比如说这个比较明显的这个经历了0.3秒啊,这个task我们给他截个图跟呢,我们另外一个96兆缓冲区做一个对比啊。那回我回退到历史服务器列表,再点最新的这个点一下,这个是六十九十六兆的缓冲区。看一下它啊一样的,还是看第一个36的对吧,200多兆读读取的这个。点进来对比这个图啊,来我们对比一下啊。当然这个时候还是存在的,什么呢?读取时间,个别的啊,读取卖点,但是总体而言,我们看这些,看这些是基本都没有那个橙色的沙瑞的时间了,我们可以看一眼他们的时间是不是接近于零毫秒。这个也是零,这是六毫秒,这个很小对吧,六毫秒。
10:03
那现有个别可能还有一点时间,0.1秒啊,这个比较长的0.3秒,那总而言之呢,我们两张图对比起来,至少从这里可以看到它这边是不是还有很多的像这里这里这里这。这些。对吧,咱们这是一兆的时候,下面是96兆,我们可以很明显的发现96兆已经很好的,呃,缓解了,减少了咱们整体shuffle的一个时间。对吧,这个就是调整缓冲区带来的一个收益,但其实大家也可以发现,差距并不是特别特别的大啊,所以48兆默认一般是够用的,如果你中间数据量特别特别多的话,你看像我这个是几百兆的数据量,如果你是几百啊上T这种,你可以把这个缓冲区调大,你可以慢慢去调,调到一个你满意的啊。但不建议设的太大,太大的话咱们讲了整体的内存占用啊,那就上升了,对吧,因为毕竟缓冲区用的还是一个内存,这个看大家去取舍了,看集群的资源到底啊充不充足啊,或者任务的一个重要性,那另外两个参数,那个从事次数跟从事间隔,这只是为了提高稳定性了,只要你的任务不发生异常失败重试,那咱们一般也不用太去关注,对吧,咱们参数就放着就行。
我来说两句