卧槽草草
来源于其它博客：
貌似我只知道group by key带来的倾斜
hive在跑数据时经常会出现数据倾斜的情况，使的作业经常reduce完成在99%后一直卡住，最后的１%花了几个小时都没跑完，这种情况就很可能是数据倾斜的原因，解决方法要根据具体情况来选择具体的方案
１、join的key值发生倾斜，key值包含很多空值或是异常值
这种情况可以对异常值赋一个随机值来分散key
如：
select userid,name
from user_info a
join(
select case when userid is null then cast(rand(47)*100000 as int)
else userid
from user_read_log
) b on a.userid = b.userid
通过rand函数将为null的值分散到不同的值上，在key值比较就能解决数据倾斜的问题
注：对于异常值如果不需要的话，最好是提前过滤掉，这样计算量可以大大减少
2、当key值都是有效值时，解决办法为设置以下几个参数
set hive.exec.reducers.bytes.per.reducer = 1000000000
也就是每个节点的reduce 默认是处理1G大小的数据，如果你的join 操作也产生了数据倾斜，那么你可以在hive 中设定
set hive.optimize.skewjoin = true;
set hive.skewjoin.key = skew_key_threshold （default = 100000）
hive 在运行的时候没有办法判断哪个key 会产生多大的倾斜，所以使用这个参数控制倾斜的阈值，如果超过这个值，新的值会发送给那些还没有达到的reduce, 一般可以设置成你
（处理的总记录数/reduce个数）的2-4倍都可以接受.
倾斜是经常会存在的，一般select 的层数超过2层，翻译成执行计划多于3个以上的mapreduce job 都很容易产生倾斜，建议每次运行比较复杂的sql 之前都可以设一下这个参数. 如果你不知道设置多少，可以就按官方默认的1个reduce 只处理1G 的算法，那么 skew_key_threshold = 1G/平均行长. 或者默认直接设成250000000 (差不多算平均行长4个字节)
3、reduce数太少
set mapred.reduce.tasks=800;
默认是先设置hive.exec.reducers.bytes.per.reducer这个参数，设置了后hive会自动计算reduce的个数，因此两个参数一般不同时使用
4、对于group by 产生倾斜的问题
set hive.map.aggr=true (开启map端combiner); //在Map端做combiner,假如map各条数据基本上不一样, 聚合没什么意义，做combiner反而画蛇添足,hive里也考虑的比较周到通过参数hive.groupby.mapaggr.checkinterval = 100000 (默认)
hive.map.aggr.hash.min.reduction=0.5(默认)
两个参数的意思是：预先取100000条数据聚合,如果聚合后的条数/100000>0.5，则不再聚合
set hive.groupby.skewindata=true；//决定 group by 操作是否支持倾斜的数据。注意：只能对单个字段聚合.控制生成两个MR Job,第一个MR Job Map的输出结果随机分配到reduce做次预汇总,减少某些key值条数过多某些key条数过小造成的数据倾斜问题
5、小表与大表关联
此时，可以通过mapjoin来优化，
set hive.auto.convert.join = true ; //将小表刷入内存中
set hive.mapjoin.smalltable.filesize = 2500000 ;//刷入内存表的大小(字节)
select
pag_id,
tag_name,
substr(gmt_create,1,10) as pt,
row_number() over
(
partition by pag_id order by substr(gmt_create,1,10) desc
) as rownumbers
from dj_dw.ods_dm_pas_member_ds_result
where year='2016'