Hive语句优化

参考地址：http://www.cnblogs.com/end/archive/2013/01/15/2861448.html

hive玩得好不好，在于你对mapreduce理解深不深叻；当然借鉴学习也很重要

倾斜分成group by造成的倾斜和join造成的倾斜


假设网站访问日志中会记录用户的user_id，并且对于注册用户使用其用户表的user_id，对于非注册用户使用一个user_id=0代表。那么鉴于大多数用户是非注册用户（只看不写），所以user_id=0占据了绝大多数。而如果进行计算的时候如果以user_id作为group by的维度或者是join key，那么个别Reduce会收到比其他Reduce多得多的数据——因为它要接收所有user_id=0的记录进行处理，使得其处理效果会非常差，其他Reduce都跑完很久了它还在运行。

1.group by造成的倾斜

group by造成的倾斜有两个参数可以解决：

• map 一个是Hive.Map.aggr，默认值已经为true，意思是会做Map端的combiner。所以如果你的group by查询只是做count(*)的话，其实是看不出倾斜效果的，但是如果你做的是count(distinct)，那么还是会看出一点倾斜效果。
• reduce 另一个参数是Hive.groupby. skewindata。这个参数的意思是做Reduce操作的时候，拿到的key并不是所有相同值给同一个Reduce，而是随机分发，然后Reduce做聚合，做完之后再做一轮MR，拿前面聚合过的数据再算结果。

set Hive.optimize.skewjoin = true; 
还有要告诉Hive如何判断特殊值，根据Hive.skewjoin.key设置的数量Hive可以知道，比如默认值是100000，那么超过100000条记录的值就是特殊值。



所以这个参数其实跟Hive.Map.aggr做的是类似的事情，只是拿到Reduce端来做，而且要额外启动一轮Job，所以其实不怎么推荐用，效果不明显。

优化思路是： 先替从后统计

/*改写前*/select a， count(distinct b) as c from tbl group by a;/*改写后*/select a， count(*) as cfrom (select distinct a， b from tbl) group by a;

count(distinct ),在数据量大的情况下，效率较低，因为count(distinct)是按group by 字段分组，按distinct字段排序，一般这种分布方式是很倾斜的

2.join造成的倾斜

join造成的倾斜，就比如上面描述的网站访问日志和用户表两个表join：

select a.* from logs a join users b on a.user_id = b.user_id;

1.倾斜的单独处理

另外对于特殊值的处理往往跟业务有关系，所以也可以从业务角度重写sql解决。比如前面这种倾斜join，可以把特殊值隔离开来（从业务角度说，users表应该不存在user_id = 0的情况，但是这里还是假设有这个值，使得这个写法更加具有通用性）：

select a.* from (select a.*from (select * from logs where user_id = 0)  a join (select * from users where user_id = 0) b on a.user_id =  b.user_idunion allselect a.* from logs a join users bon a。user_id <> 0 and a。user_id = b.user_id)t;

2.倾斜的随机化处理

Select *from log aleft outer join bmw_users bon case when a.user_id is null then concat(‘dp_hive’,rand() ) else a.user_id end = b.user_id;

3.字符类型的hash倾斜处理

统一hash规则，int和string的区别？
本质上：
h(1) 和h('1') ，本质上分配到partition上没有什么区别，根本就解决不了数据倾斜的问题。

区别在于： 
h(10)可能与h(1)产生hash碰撞，因为hash值可能一样，导致进一步的数据倾斜
而：
h('10') h('1') ，本质上hash不一样；但是如果partition数量较小，可能导致分配到同一个partition里面

HashPartitioner是mapreduce的默认partitioner。
计算方法是
which reducer=(key.hashCode() & Integer.MAX_VALUE) % numReduceTasks

所以下面问题二的优化思路就是这个意思：

问题2：不同数据类型id的关联会产生数据倾斜问题。
一张表s8的日志，每个商品一条记录，要和商品表关联。但关联却碰到倾斜的问题。s8的日志中有字符串商品id,也有数字的商品id,类型是string的，但商品中的数字id是bigint的。猜测问题的原因是把s8的商品id转成数字id做hash来分配reduce，所以字符串id的s8日志，都到一个reduce上了，解决的方法验证了这个猜测。
方法：把数字类型转换成字符串类型
Select * from s8_log a
Left outer join r_auction_auctions b

On a.auction_id = cast(b.auction_id as string);