108-尚硅谷-Hive-优化 GroupBy 数据倾斜

好，那接下来呢，我们看一下go相关的一个操作，呃，他说默认情况下呢，脉部阶段会将相同的K一定发到同一个radio，那肯定是的，对吧？那我们看当一个K数据量过大的时候，就产生什么属于倾斜，就跟刚才我们所说的nu发送的一个六子一样啊，那假如说我们那个数据不是钠。就是我们要的数据，我们ID等于一的这个数据量特别大，对吧，它是不是也会发送到一个维流塞呀，啊那这个时候就比较麻烦，所以呢，我们怎么做呢？我们就开启脉不单聚合，最终呢，它是这样的，一旦我们开启了这个聚合的内容之后啊，它自动的负载均衡对吧？做不带均衡它干什么事呢？它会对我们的任务生成两个mmr，就假如说本来是一个的，它额外生成一个。额外申请一个，他第一次呢，会将数据呢，随机的分配到维度当中，就是说我们之前说的一对吧。

一这个内容它可能数据倾斜了，我给它拼接一个什么零拼接一个一拼接二，这样的话是不是把一这个东西分散到不同的reduce里面了，但是这个内容不是我们最终想要的结果，因为最终我们想要的结果是把一是不是放到一起啊，对吧，聚合到一起，所以第二个任务呢，它干什么事了？他会把那个后面拼接的内容给它去掉，你第一次已经做聚合了，我在聚合的基础上再去干什么。再做一个聚合啊，我再去做一个聚合，类似于这样的效果。就是说假如说啊，我们是有呃100万个一吧，假如说现在如果说我简简单单做一个group什么内容，对吧，去算一个some吗？看没呀，它这100万个一是不是一定进到同一个维对吧？假如说默认情况下，我们也可以其实也的手动做这个啊，我给这个所有的ID后面加一个什么东西呢？加个随机数，我加十个随机数，现在这100万是不是拆成了十个10万。

对吧，可能是十个10万个1011，一直到一九，对吧，可能拼接成这样的东西，那它呢，是不是说这十万一聚合，这十万一聚合，这个十万一聚合，最后把一这个数据第一次MR出来，一这个数据是不是分散到十个数据当中，那接下来我们一定为了拿到最终的结果，是不是还得再起一个MR任务，把这个随机数啊，这些东西给他干掉，把这十个数据又给他聚合一次，是不是拿到我们最终的结果了，对吧？啊，他是通过这种思想，那这个事呢，其实我们可以自己做啊，我们手动去康开的一个随机数是不是也可以。嗯，对吧，我们contact一个随机数拼追加一个，然后呢，按照追加好的这个字段进行重新分组，那第二个任务呢，嵌套一层，把这个用Li把它切开，取第零位，对吧，然后呢，重新去做计算啊，做这个式的啊行它呢，呃，但是其实如果说这个内容啊，如果数据量小的话，你这样设置的，假如说这个条目啊都都很小，设置很小的时候，反而会整个任务时间会干什么，会变长，因为你现在有两个任务了呀，对吧，但是在真正的数据倾斜的场景当中。

用两个任务是绝对划算的，对吧，用两个任务来做这个事情是绝对划算的，因为如果真的产生了严重的数据细节，其实你这个任务压根就干什么，跑不起来的，压根就跑不起来的，而且你整个任务的完成时间是看谁啊，看那个最慢的任务最终的完成时间吧，对吧，所以他的完成时间也非常长。啊，而且对于妈的这种架构啊，一旦延安申请到了资源，就算你释放掉了，其他人用不了啊，其他人用不了。

好，那我们把这个来测一下啊，然后呢，在外端聚合的一个条数，也不是说无限的多少多少东西我都能放在map端去去做聚合，对吧？啊，然后接下来呢，是我们有数据倾斜的时候做负载均衡啊，一般的当我们知道有数据倾斜的时候，才设置这个数据啊，不是说我们的内容你就直接把它全部设为处理好了，因为像我们刚才说的，当你数据量太小的时候，你用那种方式反而让怎么样。变长了啊，反而不好啊，反而不好行，那我们来直接执行这个啊，直接这个还是一个group派这个DVD number正常的这个任务啊，如果你没做的话，应该只有就是说你没设置这些东西，它只有一个任务，现在呢。两个任务啊，现在两个任务就是因为我们设置了，这就是说我们第一批的担保才几条数据啊，四条吧，他都给我们开两个任务，那你觉得总时长。

比刚才怎么样，如果说不设置的话，肯定比刚才长了，对吧，因为你跑两个任务，其实数据量并不大啊，所以说我们这套参数呢，它都是在特定场景下去用的，不是说你什么时候都去用，对吧。其实如果在生产环境当中，你这个表数据量小的话，你什么事都不能做。对吧，啊，数据量小，你不用什么调优啊，肯定就是在数据量大的时候它才会有问题啊。但这个跑的还挺久的，50秒对吧？啊，我们之前那个两个桶装100万条数据才跑了多久，49秒对吧，因为它启动时间就占了很久了啊，就任务的启动时间很慢啊，这两个任务对吧？行，这是我们所聊的当使用group，如果说有这个数据倾斜，那我们可以呢，使用两个M2任务来做这个事情啊。