Hive中三种join
map join (小表join大表,将小表加入到内存) 设置map join: hive.auto.convert.join=true hive.mapjoin.smalltable.filesize=2500000; PS:如果有一张表是小表便自动执行mapjoin,根绝表大小是否超过2500000区分 隐式的执行 /*+MAPJOIN(tb_name)*/ reduce join(大表join大表,效率很低) SMB join(sort merge bucket join) A表:10000~50000 10000~20000---------------- 20001~30000---------------|--------- 30001~40000---------------|--------|-------- 40001~50000 > join | | B表: 10000~50000 | > join | 10000~20000---------------- | > join 20001~30000------------------------- | 30001~40000--------------------------------- 40001~50000 条件: AB桶个数相同,或者B桶的个数是A桶倍数 set hive.auto.convert.sortmerge.join=true; set hive.optimize.bucketmapjoin = true; set hive.optimize.bucketmapjoin.sortedmerge = true; set hive.auto.convert.sortmerge.join.noconditionaltask=true; create table emp_info_bucket(ename string,deptno int) partitioned by (empno string) clustered by(deptno) into 4 buckets; insert overwrite table emp_info_bucket partition (empno=7369) select ename ,deptno from emp create table dept_info_bucket(deptno string,dname string,loc string) clustered by (deptno) into 4 buckets; insert overwrite table dept_info_bucket select * from dept; select * from emp_info_bucket emp join dept_info_bucket dept on(emp.deptno==dept.deptno);
数据倾斜
使用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