hive性能优化模板.pdfVIP

优化时，把 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_hived() ) else a.user_id end =’ ,ran 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 排序）。 问题