本文将详细解释Hive如何优化查询效率。边肖觉得很实用，就分享给大家参考。希望你看完这篇文章能有所收获。
1，开启FetchTask
简单查询语句是指没有函数、排序等功能的语句。打开提取任务功能时，将执行简单的查询语句，而不会生成映射减少作业。相反，FetchTask将直接用于从hdfs文件系统中查询和输出数据，从而提高效率。
如何设置：
默认情况下，Hive.fetch.task.conversion是最小的。
修改配置文件hive-site.xml
财产
name hive . fetch . task . conversion/name
value more/值
描述
somesselectqueries可转换到单个文件任务
最小化危险。当前查询应该是单个的
sourcednothavinganysubqueryandshouldnothave不应有
anyaggregationsordistincts(哪种情况会发生)，
lateralviewsandjoins。
1.minimal:SELECTSTAR，FILTERonpartitioncolumns，LIMITonly
2.more:SELECT，FILTER，LIMITonly(TABLESAMPLE，virtualcolumns)
/描述
/property
或当前会话修改。
hivethetive . fetch . task . conversion=more；
执行选择，货币限额10；不，先生。
00-1010在日志文件中，每一行记录都会有很多字段，四五十个字段是正常的。在实践中，经常使用几个字段根据业务需求提取原表中的数据，并将数据放入相应的业务表(子表)中，为业务表分析实际业务。
在实践中，我们会发现在一些业务流程中，有常见的数据集，比如用户表、订单表、商品表。这三个表需要连接，连接将产生一个结果集，许多业务将为这个jion结果集进行分析。
优化：将众多的业务中相同的中间结果集，抽取到一个Hive中的表中去。
00-1010外部表和分区表结合使用，采用多级分区。数据采用存储格式(文本文件、orcfile、拼花)或数据压缩(爽快)。
详细数据一般按天划分。对于特别大的表，可以使用子分区。每个分区其实对应到HDFS上就是一个目录。数据可以以良好的压缩性能存储在parquet列式存储。同时，可以减少大量的表扫描和反序列化时间。在OLAP查询场景中，我们选择需要查询的列信息，而不是直接选择*来查询所有字段。
2，合并中间表
JVM重用
是hadoop调优参数的内容，对hive的性能具有非常大的影响，特别是对于很难避免小文件的场景或者task特别多的场景，这类场景大多数执行时间都很短。hadoop默认配置是使用派生JVM来执行map和reduce任务的，这是jvm的启动过程可能会造成相当大的开销，尤其是执行的job包含有成千上万个task任务的情况。JVM重用可以使得JVM实例在同一个JOB中重新使用N次，N的值可以在Hadoop的mapre-site.xml文件中进行设置
mapred.job.reuse.jvm.num.tasks 1
也可在hive的执行设置：
set mapred.job.reuse.jvm.num.tasks = 10;
JVM的一个缺点是，开启JVM重用将会一直占用使用到的task插槽，以便进行重用，直到任务完成后才能释放。如果某个“不平衡“的job中有几个reduce task 执行的时间要比其他reduce task消耗的时间多得多的话，那么保留的插槽就会一直空闲着却无法被其他的job使用，直到所有的task都结束了才会释放。
5，speculative execution（推测执行）
所谓的推测执行，就是当所有task都开始运行之后，Job Tracker会统计所有任务的平均进度，如果某个task所在的task node机器配置比较低或者CPU load很高（原因很多），导致任务执行比总体任务的平均执行要慢，此时Job Tracker会启动一个新的任务（duplicate task），原有任务和新任务哪个先执行完就把另外一个kill掉。
推测执行需要设置Job的两个参数：
mapred.map.tasks.speculative.execution=true
mapred.reduce.tasks.speculative.execution=true
7，合理设置reduce个数
reduce个数
参数1：
hive.exec.reducers.bytes.per.reducer=256000000 //每个reduce任务处理的数据量
参数2：
hive.exec.reducers.max=1009 //每个任务最大的reduce数目
计算公式：reducer个数=min(参数2,总输入数据量/参数1)
set mapred.reduce.tasks =N：
每个任务默认的reduce数目。典型为0.99* reduce槽数，hive默认为-1，即自动确定reduce数目。
reduce个数并不是越多越好
同map一样，启动和初始化reduce也会消耗时间和资源；另外，有多少个reduce，就会有多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题。小文件过多会非常影响查询效率，文件越多造成的IO就越多，同时还会增加元数据（namenode）的压力。在生产环境中，一定要避免小文件问题，如果核查发现，及时合并文件！！
8，开启并行执行
并行执行，意思是同步执行hive的多个阶段，hive在执行过程，将一个查询转化成一个或者多个阶段。某个特定的job可能包含众多的阶段，而这些阶段可能并非完全相互依赖的，也就是说可以并行执行的，这样可能使得整个job的执行时间缩短
hive.exec.parallel.thread.number 8//job并行执行的数目，一个SQL语句可能有很多mapreduce任务，限制
hive.exec.parallel false
hive执行开启：
set hive.exec.parallel=true
9，优化sql
-
where条件优化
优化前（关系数据库不用考虑会自动优化）：
select m.cid,u.id from order m join customer u on( m.cid =u.id )where m.dt='20180808';
优化后(where条件在map端执行而不是在reduce端执行）：
select m.cid,u.id from （select * from order where dt='20180818'） m join customer u on( m.cid =u.id);
-
union优化
尽量不要使用union （union 去掉重复的记录）而是使用 union all 然后在用group by 去重
-
count distinct优化
不要使用count (distinct cloumn) ,使用子查询。
select count(1) from (select id from tablename group by id) tmp;
-
用in 来代替join
如果需要根据一个表的字段来约束另为一个表，尽量用in来代替join 。
select id,name from tb1 a join tb2 b on(a.id = b.id);
select id,name from tb1 where id in(select id from tb2);
in 要比join 快
-
消灭子查询内的 group by 、 COUNT(DISTINCT)，MAX，MIN。可以减少job的数量。
-
join 优化：
Common/shuffle/Reduce JOIN：连接发生的阶段，发生在reduce 阶段，适用于大表连接大表(默认的方式)
Map join ：连接发生在map阶段，适用于小表连接大表 大表的数据从文件中读取；小表的数据存放在内存中（hive中已经自动进行了优化，自动判断小表，然后进行缓存）。
set hive.auto.convert.join=true;
SMB join：Sort -Merge -Bucket Join 对大表连接大表的优化，用桶表的概念来进行优化。在一个桶内发送生笛卡尔积连接（需要是两个桶表进行join）
set hive.auto.convert.sortmerge.join=true;
set hive.optimize.bucketmapjoin = true;
set hive.optimize.bucketmapjoin.sortedmerge = true;
set hive.auto.convert.sortmerge.join.noconditionaltask=true;
关于“Hive怎么优化查询效率”这篇文章就分享到这里了，希望
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/141707.html