Hive 分区优化以及jon 优化
来源:互联网 发布:mac好看的电子相册 编辑:程序博客网 时间:2024/06/05 20:02
Hive 针对不同的查询进行了优化,优化可以通过配置进行控制,本文将介绍部分优化的策略以及优化控制选项。
列裁剪(Column Pruning)
在读数据的时候,只读取查询中需要用到的列,而忽略其他列。例如,对于查询:
SELECT a,b FROM T WHERE e
其中,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) subqWHERE 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_usersSELECT pv.pageid, u.age FROM page_view pJOIN 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_usersSELECT pv.pageid, u.age FROM page_view pJOIN user u ON (pv.userid = u.userid)JOIN newuser x on (u.age = x.age);
Map-Reduce 的任务数目和 Join 操作的数目是对应的,上述查询和以下查询是等价的:
INSERT OVERWRITE TABLE tmptableSELECT * FROM page_view p JOIN user uON (pv.userid = u.userid);INSERT OVERWRITE TABLE pv_usersSELECT x.pageid, x.age FROM tmptable xJOIN newuser y ON (x.age = y.age);
Map Join
Join 操作在 Map 阶段完成,不再需要Reduce,前提条件是需要的数据在 Map 的过程中可以访问到。比如查询:
INSERT OVERWRITE TABLE pv_usersSELECT /*+ MAPJOIN(pv) */ pv.pageid, u.ageFROM page_view pvJOIN user u ON (pv.userid = u.userid);
相关的参数为:
- 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 合并文件的大小
Hive 优化
Hive 针对不同的查询进行了优化,优化可以通过配置进行控制,本文将介绍部分优化的策略以及优化控制选项。
列裁剪(Column Pruning)
在读数据的时候,只读取查询中需要用到的列,而忽略其他列。例如,对于查询:
SELECT a,b FROM T WHERE e
其中,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) subqWHERE 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_usersSELECT pv.pageid, u.age FROM page_view pJOIN 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_usersSELECT pv.pageid, u.age FROM page_view pJOIN user u ON (pv.userid = u.userid)JOIN newuser x on (u.age = x.age);
Map-Reduce 的任务数目和 Join 操作的数目是对应的,上述查询和以下查询是等价的:
INSERT OVERWRITE TABLE tmptableSELECT * FROM page_view p JOIN user uON (pv.userid = u.userid);INSERT OVERWRITE TABLE pv_usersSELECT x.pageid, x.age FROM tmptable xJOIN newuser y ON (x.age = y.age);
Map Join
Join 操作在 Map 阶段完成,不再需要Reduce,前提条件是需要的数据在 Map 的过程中可以访问到。比如查询:
INSERT OVERWRITE TABLE pv_usersSELECT /*+ MAPJOIN(pv) */ pv.pageid, u.ageFROM page_view pvJOIN 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 合并文件的大小
- Hive 分区优化以及jon 优化
- Hive-如何基于分区优化
- mysql hive sqoop 分区,优化
- Hive优化----基础知识以及效率的优化
- hive sql分区和条件优化
- Hive优化1---分区、桶、index
- Hive优化以及参数配置
- hive的查询注意事项以及优化总结
- hive的查询注意事项以及优化总结 .
- Hive语言的使用,以及性能优化
- hive基本介绍以及性能优化
- hive的查询注意事项以及优化总结
- Hive 参数介绍以及优化记录
- hive的查询注意事项以及优化总结 .
- hive的查询注意事项以及优化总结 .
- hive的查询注意事项以及优化总结
- hive的查询注意事项以及优化总结
- hive的查询注意事项以及优化总结
- java通过zxing生成二维码
- python单核多线程
- 实现一个简单动画
- python多进程
- AfxBeginThread的基本用法及作用
- Hive 分区优化以及jon 优化
- 图片平移缩放
- SlidingMenu
- mac上运行报错:syntax error near unexpected token `('
- linux让Apache支持.htaccess伪静态文件时遇到的坑
- 前端面试知识整理-2017年7月10日
- django学习
- IDC:函数列表
- PHP使用glob方法遍历文件夹下所有文件