参考:http://blog.csdn.net/pursuitbeauty/article/details/45827469
http://blog.csdn.net/pursuitbeauty/article/details/38236171
总结为一下的几点:
现象:
就是某些map的文件个数过大,由于hash函数分配不均匀,导致有一些reduce的停滞的时间过长。
产生原因:
关键词 | 情形 | 后果 |
Join | 其中一个表较小, 但是key集中 | 分发到某一个或几个Reduce上的数据远高于平均值 |
大表与大表,但是分桶的判断字段0值或空值过多 | 这些空值都由一个reduce处理,灰常慢 | |
group by | group by 维度过小, 某值的数量过多 | 处理某值的reduce灰常耗时 |
Count Distinct | 某特殊值过多 | 处理此特殊值的reduce耗时 |
1、Key太多
2、.null过多
3、group by 维度过少
4、不同的值类型进行关联造成某种类型的数据倾斜
处理方法:
第一层:
1、设置combine.
2、设置groupby=true属性,让groupby任务平均分发到各个reduce节点,然后reduce节点在统一进行处理。
第二层:
1、小表连接大表
2、设置NULL为随机数
3、将不同的数据类型进行转换。
3、控制MAP,可以合并文件
4、控制reduce
5、文件的大小
6、合并group by语句