00:00
接下来我们看一下另一种常见的数据倾斜。就是我们在使用join的时候发生数据倾斜,这个是非常常见的,那么第一种呢,咱们如果是由于有大小表的话,咱们可以用广播join,因为咱们前面也介绍过了,广播join呢,咱们是可以避免shuffle的,加载到driver,然后呢,小表加载到driver,然后发送呃广播给大表。各个里面,那这样的话避免了杀Le,就不会产生了一个倾斜了,那这个可以说是咱们在实际实践中非常好用的一个方式啊,广播均当然这个前提是咱们有一个小表对吧,如果是大表跟大表这个就不太合适了,那咱们前面也做过一些案例啊。前面做过一些案例,像咱们2.2那个。Partition Penny,咱们看一下这个代码啊,大概的回忆一下,在咱们partition这个里边,Penny那这边的代码,当时呢,我是把这个自动广播这个参数咱默认不是十兆吗。
01:10
我把它写成负一,把它给定用掉了,然后后面做的事就是查询出这三张表,呃,然后呢,把三张表就用起来,那么通过咱们前面的。K的采样。咱们知道这张表。它的cos ID,它的一个ID字段是不是有101跟103是呃,达到了50万条啊,其他都是几条几条对吧,我们很明显知道join的key里面它是存在数据倾斜的,那我们直接去历史服务器看一眼就行了,也不再去跑了啊嗯,咱们那个名字叫什么呢?Partition turning对吧?哎,这里啊,这里有一个,那我们点进来。点进来,那这边我们可以看到这边有一个三六,这边有个三六,这个呢,就是分别对应两处蚯蚓啊,两处join,那我们其实看一下咱们的代码。
02:07
这是这张表交上这张有倾斜key的表,那其实他俩交的时候就应该发生一个倾斜了,这个咱们是,呃,通过前面采样是知道的,就这张表csc的cos ID有101103倾斜。那这里就应该第一次救援就应该有了,所以咱们直接瞅眼第一个第一第一个36的这个分stage点一下,那倾斜呢,咱们说了可以从几个地方看,第一个看它的一个和的执行情况,那么大家可以看到这里明显。是不是他?是不是有他跟他明显执行的时间比较长啊,你像包括其他的平均才这么长一点,那或者这么长一点,那他俩呢,明显就长了,当然呢,咱们的数据这个量也倾斜的不够明,不够大,但是这里应该相对也是比较明显了,那再回忆一下咱们前面的采样是不是应该一个对应幺零应幺的,一个对应103的,对吧?有这两个大T所在,这个都是很都有逻辑关系在里面,另外一个呢,咱们可以拉到下面看一看这个杀否过程的一个数据量。
03:22
那就比如说啊。咱们直接排序,你看不管是right还是read,咱们就看shale right。其他的咱们是倒叙的,是不是最大的有两个接近60兆的,其他的都只只有什么十来兆啊,那包括读的时候也是其他的都是六七兆,这边就30多兆。很明显,而且他们还发生了中间序列化的一个一些对吧。从这两个地方咱们就可以去看数据听写,这个是很直观的啊,很直观,结合咱们的采样一分析全对上,这个就是来精准定位大K,好了,那我们接下来再瞅一瞅,呃,解决数据倾斜的那个咱们使用的广播当时没有提交执行对吧,那我一一会提交执行一下,就这诶。
04:23
啊,那这个案例不好。那咱们这边准备了一个ski map join ten,那在这一块呢,下面的逻辑都一模一样啊,一模一样。就三张表交易,然后呢,无非就是这个参数不再是负一了,你把它注掉呢,或者写成默认值十兆都行啊,这无所谓,然后呢,咱们提交执行首页,那咱们拷贝一下这个。提交代码。
05:02
好,等他执行完,咱们再去看一下它那个执行情况,一做对比就很明显了。咱把刚才那个刚好截个图对吧?啊,这个在历史服务器看的啊,咱们之前执行过的一张图。好,等他跑完。听完了我们来看一下啊呃,直接到历史服务器瞅一眼。呃,最新的这个map就点进来。这里是做了一个广播对吧。那其实广播这一块我们可以看看。它就一个就行了,广播到driver嘛,所以你这个咱们看不出啥,那再看另一端这边的。
06:03
大家首先可以发现它是不是省略到了之前。第一个小表大表对吧,这个咱们之前讲map,就你也讲过了,那这个就属于后面的事了,也就是说第一次沙uffle已经被完完全全避免掉,第一次杀小表跟大表的join,这是第二次了啊,第二次。也就是说咱们之前截图想看的这个玩意儿已经不在了,被map join所规避了,就这么一回事,那执行时间呢,我们看看有没有提升啊,我们刚好在这看一下就行了。执行时间这个是两分钟,那那个partition tening呢是三分多钟,这个就是咱们刚才看的这个。没有进行一个。广播。那时间呢,省的特别多了,对吧,那这边只需要两分钟,避免了一个沙,这个是非常非常好使的一招啊,那能广播的尽量就用广播处理掉这么一个场景。
07:07
好,这个是咱们对这个做一个回顾。
我来说两句