hive优化总结

Posted 2020-10-05

一、表设计

    合理分表

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

二、扫描相关

    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】。

本文版权归作者，禁止转载，否则保留追究法律责任的权利。