hive性能优化.doc

优化时，把hive sql当做map reduce程序来读，会有意想不到的惊喜。 理解hadoop的核心能力，是hive优化的根本。这是这一年来，项目组所有成员宝贵的经验总结。 ? 长期观察hadoop处理数据的过程，有几个显著的特征: 1.不怕数据多，就怕数据倾斜。 2．对jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多次汇总，产生十几个jobs，没半小时是跑不完的。map reduce作业初始化的时间是比较长的。 3.对sum，count来说，不存在数据倾斜问题。 4.对count(distinct ),效率较低，数据量一多，准出问题，如果是多count(distinct )效率更低。 ? 优化可以从几个方面着手： 1.?好的模型设计事半功倍。 2.?解决数据倾斜问题。 3.?减少job数。 4.?设置合理的map reduce的task数，能有效提升性能。(比如，10w+级别的计算，用160个reduce，那是相当的浪费，1个足够)。 5.?自己动手写sql解决数据倾斜问题是个不错的选择。set hive.groupby.skewindata=true;这是通用的算法优化，但算法优化总是漠视业务，习惯性提供通用的解决方法。?Etl开发人员更了解业务，更了解数据，所以通过业务逻辑解决倾斜的方法往往更精确，更有效。 6.?对count(distinct)采取漠视的方法，尤其数据大的时候很容易产生倾斜问题，不抱侥幸心理。自己动手，丰衣足食。 7.?对小文件进行合并，是行至有效的提高调度效率的方法，假如我们的作业设置合理的文件数，对云梯的整体调度效率也会产生积极的影响。 8.?优化时把握整体，单个作业最优不如整体最优。 ? 迁移和优化过程中的案例： ? 问题1：如日志中，常会有信息丢失的问题，比如全网日志中的user_id，如果取其中的user_id和bmw_users关联，就会碰到数据倾斜的问题。 方法：解决数据倾斜问题 解决方法1. User_id为空的不参与关联，例如： Select * From log a Join? bmw_users b On a.user_id is not null And a.user_id = b.user_id Union all Select * from log a where a.user_id is null.解决方法2?： Select * from log a left outer join bmw_users b on case when a.user_id is null then concat(‘dp_hive’,rand() ) else a.user_id end = b.user_id; ? 总结：2比1效率更好，不但io少了，而且作业数也少了。1方法log读取两次，jobs是2。2方法job数是1?。这个优化适合无效id(比如-99,’’,null等)产生的倾斜问题。把空值的key变成一个字符串加上随机数，就能把倾斜的数据分到不同的reduce上?,解决数据倾斜问题。因为空值不参与关联，即使分到不同的reduce上，也不影响最终的结果。附上hadoop通用关联的实现方法（关联通过二次排序实现的，关联的列为parition key,关联的列c1和表的tag组成排序的group key,根据parition key分配reduce。同一reduce内根据group key排序）。 ? 问题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); ? 问题3：利用hive?对UNION ALL的优化的特性 hive对union all优化只局限于非嵌套查询。 比如以下的例子： select * from (select * from t1 ?Group by c1,c2,c3 Union all Select * from t2 Group by c1,c2,c3) t3 ???Group by c1,c2,c3; 从业务逻辑上说，子查询内的group by?怎么都看显得