hive优化总结
一、表设计
合理分表
合理设计表分区，静态分区、动态分区
二、扫描相关
1、谓词下推（Predicate Push Down）
2、列裁剪（Column Pruning）
在读数据的时候，只关心感兴趣的列，而忽略其他列
对于查询：select a,b from src where e < 10
其中，src包含5个列(a、b、c、d、e)，列c、d将会被忽略，只会读取a,b,e列
选项默认为真，hive.optimize.cp=true
3、分区剪裁（Partition Pruning）
在查询的过程中减少不必要的分区
对于下列查询：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相关
1、JOIN操作左边为小表
应该将条目少的表/子查询放在Join操作符的左边。
原因是在Join操作的Reduce阶段，位于Join操作符左边的表的内容会被加载到内存，将条目少的表放在左边可以有效减少OOM（内存溢出）的几率
原理就是关系数据库中驱动表与被驱动表
如果是mapjoin，可以放在右边
2、JOIN启动的job个数
如果join的key相同，不管有多少个表，都会合并为一个Map-Reduce
一个Map-Reduce(Tez)任务，而不是‘n’个
在做outer join的时候也是一样
insert over write table pv_users select pv.pageid,u.age from page_view pv join user u on (pv.userid=u.userid) join newuser x on (u.userid = x.userid)
3、MapJoin
join操作在map阶段完成，不再需要reduce，前提条件是需要的数据在map的过程可以访问到
新版本,Hint已经去了，这里只是演示，应该尽可能使用mapjoin
不会倾斜，默认64M来并发处理数据
对表的大小有限制，通常来讲大于100M，就做不了了
insert over write table pv_users select /*+MAPJOIN(pv)*/pv.pageid,u.age from page_view pv join user u on (pv.userid=u.userid);
需要设置的相关数据hive.join.emit.inter-1,hive.mapjoin.size.key,hive.map-join.cache.numrows。
4、join不支持不等值连接
!=、<>、>、<在join的on条件中不支持
select ……from ……
join ……
on (a.key!=b.key)
因为如果用不等值号的话，它会查其他节点上的数据，那么其他查不到的，mapreduce是不支持这样的机制，所以hive是不支持不等值连接的
四、分组Group By相关
1、Skew In Data
主要关注的是数据倾斜
hive.groupby.skewindata = true
当选项设定为true，生成的查询计划会有两个MR Job。第一个MR Job中，Map的输出结果集合会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的Group By Key有可能被分发到不同的Reduce中，从而达到负载均衡的目的
第二个MR Job再根据预处理的数据结果按照Group By Key分布 到Reduce中（这个过程可以保证相同的Group By Key被分布到一个Reduce中），最后完成最终的聚合操作
没法通过部分值推导出最终值的，如中位数和众数
五、合并小文件
合并功能会增加任务运行时间
合并操作的性能很大程度上取决与“单个reduce端输出文件大小”。Reduce端的输出越大，耗时越长
合并操作会对每个Hive任务增加一次MapRedce任务
原因：
Hive在处理时，Client会从MetaStore中把文件的名字读到内存中，小文件过多会导致在SQL解析过程中，可能就根本就解析不出来
通过合并Map和Reduce的结果文件来消除小文件影响。需要设定的参数：
hive.merge.mapfiles=true,是否合并Map输入文件默认为true。
hive.merge.mapredfiles=false,设定是否合并Reduce输出文件，默认为false。
hive.merge.size.per.task=256*1000*1000，设定合并文件的大小，默认为256000000。
六、多作业
共享中间结果集
多作业共用输入或输出，如下场景
每日几千个作业访问大日志表trackinfo
访问多个表的相同统计存在于很多作业里面
常用复杂或低效统计统计给出，以避免上层作业过多计算
七、参数调优
有时会起到很好效果
如果，您认为阅读这篇博客让您有些收获，不妨点击一下右下角的【推荐】。
如果，您希望更容易地发现我的新博客，不妨点击一下左下角的【关注我】。
如果，您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是【刘超★ljc】。
本文版权归作者，禁止转载，否则保留追究法律责任的权利。
