标签：业务 负载 win 操作 处理 key com distinct 过程
数据倾斜
使用join(map join/reduce join/group by等)聚合数据时,某一个特殊的key (空值/特殊值)匹配到的记录过多而导致记录被分发到reduce的记录远大于平均值(总记录数平均配配到 各个reduce的值),这样在运行时reduce时某一reduce负载过大而导致运行效率远大于平均任务时常
操作导致
map join 其中一个表相对较小,但是key集中 分配到某一个或几个reduce上的数据远高于平均值 reduce join 两个比较大的表使用分桶操作中,字段0或空值过多 这些空值都有一个reduce处理 group by group by 维度过小,某值数量过多 处理某值的reduce非常耗时 count distinct 某特殊值过多 处理特殊值的reduce非常耗时
原因
1. key 值分配不均匀(业务数据本身问题) 2. 建表时考虑不周 3. 编写sql语句时使用某些聚合函数导致
表现
在运行HIVE任务时,发现少量reduce子任务迟迟未完成,原因就是数据分布,导致reduce负载不均衡
解决方案
参数调节 1. hive.map.aggr=true(提前对map部分聚合,相当于Conmbiner) 2.hive,groupby.skewindata=true 该选项生成的查询计划会有两个MR job,第一个MR job中,Map 的输出结果集被随机分布到Reduce中,每个Reduce做部分聚合操作,并输出结果,这样处理的结果是相同Group by Key 有 可能分发到不同的Reduce中,从而达到负载均衡的目的,第二个MR Job 再将预处理的数据按照Group By Key 分发到Reduce中,(这个过程可以保证相同的Group By key被分布到同一个Reduce ,最后完成最终的聚合操作)
转自: http://www.cnblogs.com/ggjucheng/archive/2013/01/03/2842860.html
标签：业务 负载 win 操作 处理 key com distinct 过程
原文地址：http://www.cnblogs.com/eRrsr/p/6070355.html
