设为首页 收藏本站
查看: 887|回复: 0

[经验分享] Hive 随谈(五)– Hive 优化

[复制链接]
累计签到:1 天
连续签到:1 天
发表于 2014-6-6 10:24:21 | 显示全部楼层 |阅读模式
Hive 针对不同的查询进行了优化,优化可以通过配置进行控制,本文将介绍部分优化的策略以及优化控制选项。
列裁剪(Column Pruning)在读数据的时候,只读取查询中需要用到的列,而忽略其他列。例如,对于查询:
SELECT a,b FROM T WHERE e < 10; 其中,T 包含 5 个列 (a,b,c,d,e),列 c,d 将会被忽略,只会读取a, b, e 列
这个选项默认为真: hive.optimize.cp = true
分区裁剪(Partition Pruning)在查询的过程中减少不必要的分区。例如,对于下列查询:
SELECT * FROM (SELECT c1, COUNT(1)   FROM T GROUP BY c1) subq   WHERE subq.prtn = 100;SELECT * FROM T1 JOIN   (SELECT * FROM T2) subq ON (T1.c1=subq.c2)   WHERE subq.prtn = 100; 会在子查询中就考虑 subq.prtn = 100 条件,从而减少读入的分区数目。
此选项默认为真:hive.optimize.pruner=true
Join在使用写有 Join 操作的查询语句时有一条原则:应该将条目少的表/子查询放在 Join 操作符的左边。原因是在 Join 操作的 Reduce 阶段,位于 Join 操作符左边的表的内容会被加载进内存,将条目少的表放在左边,可以有效减少发生 OOM 错误的几率。
对于一条语句中有多个 Join 的情况,如果 Join 的条件相同,比如查询:
INSERT OVERWRITE TABLE pv_users   SELECT pv.pageid, u.age FROM page_view p   JOIN user u ON (pv.userid = u.userid)   JOIN newuser x ON (u.userid = x.userid);
  • 如果 Join 的 key 相同,不管有多少个表,都会则会合并为一个 Map-Reduce
  • 一个 Map-Reduce 任务,而不是 ‘n’ 个
  • 在做 OUTER JOIN 的时候也是一样
如果 Join 的条件不相同,比如:
   INSERT OVERWRITE TABLE pv_users     SELECT pv.pageid, u.age FROM page_view p     JOIN user u ON (pv.userid = u.userid)     JOIN newuser x on (u.age = x.age); Map-Reduce 的任务数目和 Join 操作的数目是对应的,上述查询和以下查询是等价的:
   INSERT OVERWRITE TABLE tmptable     SELECT * FROM page_view p JOIN user u     ON (pv.userid = u.userid);  INSERT OVERWRITE TABLE pv_users     SELECT x.pageid, x.age FROM tmptable x     JOIN newuser y ON (x.age = y.age); Map JoinJoin 操作在 Map 阶段完成,不再需要Reduce,前提条件是需要的数据在 Map 的过程中可以访问到。比如查询:
   INSERT OVERWRITE TABLE pv_users     SELECT /*+ MAPJOIN(pv) */ pv.pageid, u.age     FROM page_view pv       JOIN user u ON (pv.userid = u.userid); 可以在 Map 阶段完成 Join,如图所示:

相关的参数为:
  • hive.join.emit.interval = 1000 How many rows in the right-most join operand Hive should buffer before emitting the join result.
  • hive.mapjoin.size.key = 10000
  • hive.mapjoin.cache.numrows = 10000
Group By
  • Map 端部分聚合:
    • 并不是所有的聚合操作都需要在 Reduce 端完成,很多聚合操作都可以先在 Map 端进行部分聚合,最后在 Reduce 端得出最终结果。
    • 基于 Hash
    • 参数包括:
      • hive.map.aggr = true 是否在 Map 端进行聚合,默认为 True
      • hive.groupby.mapaggr.checkinterval = 100000 在 Map 端进行聚合操作的条目数目
  • 有数据倾斜的时候进行负载均衡
    • hive.groupby.skewindata = false
    • 当选项设定为 true,生成的查询计划会有两个 MR Job。第一个 MR Job 中,Map 的输出结果集合会随机分布到 Reduce 中,每个 Reduce 做部分聚合操作,并输出结果,这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中,从而达到负载均衡的目的;第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中(这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中),最后完成最终的聚合操作。
合并小文件文件数目过多,会给 HDFS 带来压力,并且会影响处理效率,可以通过合并 Map 和 Reduce 的结果文件来消除这样的影响:
  • hive.merge.mapfiles = true 是否和并 Map 输出文件,默认为 True
  • hive.merge.mapredfiles = false 是否合并 Reduce 输出文件,默认为 False
  • hive.merge.size.per.task = 256*1000*1000 合并文件的大小


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-20252-1-1.html 上篇帖子: Hive 随谈(四)– Hive QL 下篇帖子: Hive 随谈(六)– Hive 的扩展特性
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表