数据倾斜即为数据在节点上分布不均，是常见的优化过程中常见的需要解决的问题。常见的Hive调优的方法：列剪裁、Map Join操作、 Group By操作、合并小文件。
一、表现
1.任务进度长度为99%，在任务监控页面中发现只有几个 reduce 子任务未完成；
2.单一 reduce 记录与平均记录数差异过大（大于3倍），最长时长＞＞平均时长；
3.job数多的，效率低，多次关联后，产生几个jobs，起码半小时以上才跑完；
二、原因
1.key分布不均；
2.业务数据本身问题；
3.建表有问题；
4.sql语句本身数据倾斜；
数据倾斜问题：
|
关键词 |
情形 |
后果 |
|
join |
1.小表与大表.其中一表较小，但key集中； 2.大表与大表，但分桶到判断字段0或空值过多； |
分发到一个或几个reduce上数据远大于平均值；空值由一个reduce处理，很慢 |
|
group by |
group by 维度过小，某值数量过多 |
处理某值的reduce很耗时，解决：用sum() group代替 |
|
count distinct |
某特殊值过多 |
处理此特殊值reduce耗时 |
三、解决思路
1.好的模型设计事半功倍；
2.解决数据倾斜问题；
3.减少job数；
4.设置合理的map,reduce 的task 数，有效提升性能；
5.自己动手写sql 可以解决数据倾斜；
6.对sum, count不存在数据倾斜问题，自己写；
7.对小文件合并；
8.优化时把握整体，单个作业最优不一定整体最优。
（注：sql相关→(1)倾斜的数据用 map join，不倾斜的数据用 join；
(2) union join：把2个具有相同列的数据类型的结果放到一起显示，并且不去重；
(3)有几个列参与join就有几个job，不是看独立的语句(eg.select)有几个！）
四、解决方案
4.1 参数调节
hive.map.aggr = true （map 端部分聚合，当于 combiner）
hive.groupby.skewindata = true （有数据倾斜时负载均衡）
4.2 sql语句调节
(1) 如何join：关于驱动表的选取，应选分布均匀的作为驱动表；做好列剪裁与 filter 操作，达到两表 join 时，数量变小的效果。
(2) 大小表join：使用map join，让小表先进内存，在 map 端完成reduce 。
(3) 大表 join 大表：把空值 null key变成字符串加上随机数，倾斜数据分到不同 reduce 上。
(4) groupby 维度过小：采用sum() group by 代替count (distinct) 完成计算。
五、典型案例
5.1. 空值产生的数据倾斜：userid为空的表去 join另一表
方法一：为空的userid 不参与关联：select * from a join b on a.userid is not null and a.id = b.id
方法二：赋空值分新的 key值，字符串加上随机数。（比方法一好，io少了，作业job也少了：方法一读取log 为2次，job为2；方法二读取的job 为1）
5.2 不同数据类型关联的数据倾斜：userid在2个表中，一个为 string，一个为 int
解决方法：把数值类型转化为 string。
eg. select *from a left join b on (a.id = cast(b.id as string))
5.3 小表 join 大表时，小表很大：一般 map join会有 bug
两个待连接表中，小表可以进内存（小表小于内存装得下），而大表很大。可以将小表复制多份，让每个Map Task 内存中存在一份（比如放到 hash table 中），然后只扫描大表。
对大表中每条记录 key-value，在 hash table中查找是否有相同的 key 记录，如果有，连接后输出即可。（不用 reducer，直接在 map端就可以完成 join）