hive性能优化模板.docxVIP

优化时，把hive sql当做map reduce 程序来读，会有意想不到的惊喜。 理解hadoop的核心能力，是 hive优化的根本。这是这一年来，项目组所有成员宝贵的经 验总结。 长期观察hadoop处理数据的过程，有几个显著的特征 ： 不怕数据多，就怕数据倾斜。 2 ?对jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多 次汇总，产生十几个 jobs，没半小时是跑不完的。 map reduce作业初始化的时间是比较长 的。 对sum , count来说，不存在数据倾斜问题。 对count(distinct ),效率较低，数据量一多，准出问题，如果是多count(distinct )效率更低。 优化可以从几个方面着手： 好的模型设计事半功倍。 解决数据倾斜问题。 减少job数。 设置合理的map reduce的task数，能有效提升性能。(比如，10w+级别的计算，用160 个reduce，那是相当的浪费，1个足够)。 自己动手写sql解决数据倾斜问题是个不错的选择。 set hive.groupby.skewindata=true; 这是通用的算法优化，但算法优化总是漠视业务，习惯性提供通用的解决方法。 Etl开发人 员更了解业务，更了解数据，所以通过业务逻辑解决倾斜的方法往往更精确，更有效。 对count(distinct)采取漠视的方法，尤其数据大的时候很容易产生倾斜问题，不抱侥幸心 理。自己动手，丰衣足食。 对小文件进行合并，是行至有效的提高调度效率的方法，假如我们的作业设置合理的文 件数，对云梯的整体调度效率也会产生积极的影响。 优化时把握整体，单个作业最优不如整体最优。 迁移和优化过程中的案例： ，如果取其中的问题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 n ull. 解决方法2 : Select * from log a dp_hive dp_hive ,rand() ) else a.user_id end = on case whe n a.user_id is null the n con cat( b.user_id; 总结：2比1效率更好，不但io少了，而且作业数也少了。 1方法log读取两次，jobs是2。 2方法job数是1。这个优化适合无效id（比如-99, ,n等）产生的倾斜问题。 把空值的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_auct ion _aucti ons b On a.aucti on_id = cast(b.auct ion_id as stri ng); 问题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怎么都看显得多余（