hive优化总结

1、表设计

    合理分表

    合理设计表分区，静态分区、动态分区

2、扫描相关

    一、谓词下推（Predicate Push Down）

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

    三、分区剪裁（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

3、关联JOIN相关

    一、JOIN操做左边为小表

        应该将条目少的表/子查询放在Join操做符的左边。

        缘由是在Join操做的Reduce阶段，位于Join操做符左边的表的内容会被加载到内存，将条目少的表放在左边能够有效减小OOM（内存溢出）的概率

        原理就是关系数据库中驱动表与被驱动表

        若是是mapjoin，能够放在右边

    二、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)

    三、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。

    四、join不支持不等值链接

        !=、<>、>、<在join的on条件中不支持

        select ……from ……

        join ……

        on (a.key!=b.key)

        由于若是用不等值号的话，它会查其余节点上的数据，那么其余查不到的，mapreduce是不支持这样的机制，因此hive是不支持不等值链接的

4、分组Group By相关

    一、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中），最后完成最终的聚合操做

 

        无法经过部分值推导出最终值的，如中位数和众数

5、合并小文件

    合并功能会增长任务运行时间

    合并操做的性能很大程度上取决与“单个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。

6、多做业

    共享中间结果集

    多做业共用输入或输出，以下场景

        每日几千个做业访问大日志表trackinfo

        访问多个表的相同统计存在于不少做业里面

    经常使用复杂或低效统计统计给出，以免上层做业过多计算

7、参数调优

    有时会起到很好效果

 

 

若是，您认为阅读这篇博客让您有些收获，不妨点击一下右下角的【推荐】。
若是，您但愿更容易地发现个人新博客，不妨点击一下左下角的【关注我】。
若是，您对个人博客所讲述的内容有兴趣，请继续关注个人后续博客，我是【刘超★ljc】。

本文版权归做者，禁止转载，不然保留追究法律责任的权利。