hive优化总结

1.当hive执行join内存溢出时，可以修改hive的配置文件hive-site.xml，增大内存，如下： mapred.child.java.opts -Xmx 1024m

2.hive默认建表时的路径也可以在hive-site.xml里配置，如下: hive.metastore.warehouse.dir value >/user/hive/warehouse description >location of default database for the warehouse

3.执行join操作的时候，尽量把小表放前面，大表放前面可能会因为内存溢出而出错

4.对分区表进行操作需要对分区进行过滤（如：ds=$yday）。 特别是在JOIN操作的时候，分区过滤（如：ds=$yday）需要放到 ON语句 或子查询 里面。不能放到ON后面的WHERE里，这样会扫描所有表，最后才判断分区。也就是说程序会先执行JOIN操作，才会执行最后的WHERE操作。

5.在JOIN操作中，后面被连续JOIN且同一字段，只会执行一个mapreduce操作。 SELECT * FROM a LEFT OUTER JOIN b ON a.t=b.t LEFT OUTER JOIN c ON a.t=c.t; 推荐的 SELECT * FROM a LEFT OUTER JOIN b ON a.t=b.t LEFT OUTER JOIN c ON b.t=c.t; 效率低下的

6.当一个大表和一个很小的表进行JOIN操作的时候，使用MAPJOIN操作，这样会把小表读入内存进行JOIN，只需要一个map操作JOIN就完成了 select /*+ mapjoin(a)*/ a.c1,b.c2,b.c3 from a join b on a.c4=b.c4;

7.通过设置hive.merge.mapfiles可以关闭hive对于扫描表的优化，但有时候会提高效率。默认值为true。可以视情况设置：只含有SELECT的语句 或 MAPJOIN 推荐使用

8.ALTER TABLE a SET SERDEPROPERTIES('serialization.null.format' = ''); 可以使结果表不出现\N字符串，而用空串代替

列裁剪（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 Join

Join 操作在 Map 阶段完成，不再需要Reduce，前提条件是需要的数据在 Map 的过程中可以访问到。比如查询：

 INSERT OVERWRITE TABLE pv_users SELECT /*+ MAPJOIN(pv) */ pv.pageid, u.age FROM page_viewpv JOIN user u ON (pv.userid = u.userid);

可以在 Map 阶段完成 Join，如图所示：

 SHAPE  \* MERGEFORMAT

相关的参数为：

• 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 合并文件的大小

 转的，但地址找不到了，汗～～～～～～！