转自:https://blog.csdn.net/xinzhi8/article/details/71455883
操作:
关键词
情形
后果
Join
其中一个表较小,但是key集中
分发到某一个或几个Reduce 上的数据远高于平均值
大表与大表,但是分桶的判断字段0值或空值过多
这些空值都由一个reduce处理非常慢
group by
group by 维度过小,某值的数量过多
处理某值的reduce非常耗时
Count Distinct
某特殊值过多
处理此特殊值的reduce耗时
原因:
1)、key分布不均匀
2)、业务数据本身的特性
3)、建表时考虑不周
4)、某些SQL语句本身就有数据倾斜
解决方案
1.参数调节:
hive.map.aggr = true
Map 端部分聚合,相当于Combiner
hive.groupby.skewindata=true(万能药膏)
有数据倾斜的时候进行负载均衡,当选项设定为 true,生成的查询计划会有两个 MR Job。第一个 MR Job 中,Map 的输出结果集合会随机分布到 Reduce 中,每个 Reduce 做部分聚合操作,
并输出结果,这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中,从而达到负载均衡的目的;第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中
(这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中),最后完成最终的聚合操作。
2.SQL语句调节:
大小表Join:
使用map join让小的维度表(1000条以下的记录条数) 先进内存。在map端完成reduce.
大表Join大表:
把空值的key变成一个字符串加上随机数,把倾斜的数据分到不同的reduce上,由于null值关联不上,处理后并不影响最终结果。
count distinct大量相同特殊值:
count distinct时,将值为空的情况单独处理