hive数据倾斜（超详细）

说到hive的数据倾斜，可能有的小伙伴还不了解什么是数据倾斜，所以咱们这一次就从hive数据倾斜的表现、hive数据倾斜发生的原因、hive数据倾斜的解决方案这三个方面来聊一聊hive的数据倾斜

1、hive数据倾斜的表现

我们都知道hive的底层其实是mr（MapReduce）引擎，hsql其实就是把sql语言转换成mr去运行，这样就大大缩减了咱们去写mr的时间，然而有时候咱们会发现在你运行一个任务的时候，明明所有的map task都完成了，并且99%的reduce task也完成，只剩下一个后者少数几个reduce task一直在执行，等了半天就是不动，其实这种情况一般都是发生了数据倾斜，说白了，hive的数据倾斜本质上就是MapReduce的数据倾斜（感兴趣的小伙伴可以去查看任务监控页面）

** 2、hive数据倾斜的原因**

其实数据倾斜这个问题，在MapReduce编程模型中十分常见，根本原因就是大量相同的key被分配到一个reduce里，造成一个reduce任务累死了，但是其他的reduce任务闲死（和我现在上班一样，，，，）。下面咱们来罗列一下常见的数据倾斜有哪些原因：

一、key分布不均衡

二、业务问题后者业务数据本身的问题，某些数据比较集中

三、建表的时候考虑不周

四、某些sql语句本身就有数据倾斜，例如：

（1）大表join小表：其实小表的key集中，分发到某一个或者几个reduce上的数据远远高于平均值

（2）大表join大表：空值或无意义值：如果缺失的项很多，在做join时这些空值就会非常集中，拖累进度。

（3）group by： group by的时候维度过小，某值的数量过多，处理某值的reduce非常耗时间。

（4）Count distinct：某特殊值过多，处理此特殊值的reduce耗时。

3、Hive数据倾斜解决

【参数调节】 hive.map.aggr = true

Map端部分聚合。

有数据倾斜的时候进行负载均衡，当选项设定为true，生成的查询计划会有两个MRJob。第一个MRJob中，Map的输出结果集合会随机分不到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同于Group By Key 有可能被分发到不同的Reduce中，从而达到负载均衡的目的；第二个MRJob再根据预处理的数据结果按照Group By Key分不到Reduce中(这个过程可以保证相同的Group By Key被分布到同一个Reduce中)，最后完成最终的聚合操作。

【SQL调整】

1）如何join：关于驱动表的选取，选用join key分布最均匀的表作为驱动表，做好列裁剪和filter操作，以达到两表做join的时候，数据量相对变小的效果。

2）大小表join的时候：使用map join 让小的维度表先进内存，在map端完成reduce。效率很高。

3）大表join大表的时候：把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后不影响最终的结果。

4）count distinct 大量相同特殊值，将这些值为空的情况单独处理，如果是计算count distinct，可以不用处理，直接过滤，在最后结果中加1即可。如果还有其他的计算，需要进行group by，可以先将那些值为空的记录单独处理，再和其他计算结果进行 union。

5）group by 维度过小的时候：采用sum() group by 的方法来替换count(distinct)完成计算。

6）单独处理倾斜key：一般来讲倾斜的key都很少，我们可以将它们抽样出来，对应的行单独存入临时表中，然后打上随机数前缀，最后再进行聚合。或者是先对key做一层hash，先将数据随机打散让它的并行度变大，再汇集。其实办法一样。