hive常用的调优方案

  • Fetch抓取(走集群，不走MR)
  • 示例
  • 本地模式
  • 示例
  • 表的优化
  • join调优
  • group by调优
  • count调优
  • 笛卡尔积
  • 过滤不需要的数据
  • 并行执行
  • 严格模式
  • 严格模式的设置
  • 严格模式禁止的3种模式
  • JVM重用
  • JVM重用的配置
  • 优缺点
  • 推测执行
  • 推测执行的开启（慎用）
  • 压缩
  • 数据倾斜
  • 合理设置Map数
  • 引言
  • 小文件合并
  • 复杂文件增加Map数
  • 增加map的方法为
  • 合理设置Reduce数


Fetch抓取(走集群，不走MR)

  • Fetch抓取是指，Hive中对某些情况的查询可以不必使用MapReduce计算
  • 例如：select * from score;
  • 在这种情况下，Hive可以简单地读取employee对应的存储目录下的文件，然后输出查询结果到控制台
  • 在hive-default.xml.template文件中 hive.fetch.task.conversion默认是more，老版本hive默认是minimal，该属性修改为more以后，在全局查找、字段查找、limit查找等都不走mapreduce。

示例

  • 把 hive.fetch.task.conversion设置成**none**，然后执行查询语句，都会执行mapreduce程序
set hive.fetch.task.conversion=none;
select * from score;
select s_id from score;
select s_id from score limit 3;
  • 把hive.fetch.task.conversion设置成==more==，然后执行查询语句，如下查询方式都不会执行mapreduce程序。
set hive.fetch.task.conversion=more;
select * from score;
select s_id from score;
select s_id from score limit 3;

本地模式

  • 在Hive客户端测试时，默认情况下是启用hadoop的job模式,把任务提交到集群中运行，这样会导致计算非常缓慢；
  • Hive可以通过本地模式在单台机器上处理任务。对于小数据集，执行时间可以明显被缩短。

示例

--开启本地模式，并执行查询语句
set hive.exec.mode.local.auto=true;  //开启本地mr

--设置local mr的最大输入数据量，当输入数据量小于这个值时采用local  mr的方式，
--默认为134217728，即128M
set hive.exec.mode.local.auto.inputbytes.max=50000000;

--设置local mr的最大输入文件个数，当输入文件个数小于这个值时采用local mr的方式，
--默认为4
set hive.exec.mode.local.auto.input.files.max=5;


--执行查询的sql语句
select * from student cluster by s_id;
--关闭本地运行模式
set hive.exec.mode.local.auto=false;
select * from student cluster by s_id;

表的优化

join调优

参考之前的：join的优化

group by调优

参考之前的：group by 优化

count调优

通过增加一个Job的方式调高效率，数据量大是划算。

  • 数据量小的时候无所谓，数据量大的情况下，由于count distinct 操作需要用一个reduce Task来完成，这一个Reduce需要处理的数据量太大，就会导致整个Job很难完成，
  • 一般count distinct使用先group by 再count的方式替换
# 每个reduce任务处理的数据量 默认256000000（256M）
 set hive.exec.reducers.bytes.per.reducer=32123456;
 
 select count(distinct ip) from log_text;
 
# 转换成
 set hive.exec.reducers.bytes.per.reducer=32123456;
 select count(ip) from (select ip from log_text group by ip) t;
 
 
 虽然会多用一个Job来完成，但在数据量大的情况下，这个绝对是值得的。

笛卡尔积

  • 尽量避免笛卡尔积，即避免join的时候不加on条件，或者无效的on条件
  • Hive只能使用1个reducer来完成笛卡尔积

过滤不需要的数据

  • 列剪裁
  • 只获取需要的列的数据，减少数据输入。
  • 分区裁剪
  • 分区在hive实质上是目录，使用分区表或分桶表，只需要部分指定数据时，减少全表扫描。
  • 尽量使用列剪裁和分区过滤，少用select *

HSQL 先执行 form…join…on…后执行where。。
通过on或子句提前过滤掉不需要的数据，避免大量数据流入外层SQL
先关联再Where

SELECT a.id
FROM bigtable a
LEFT JOIN ori b ON a.id = b.id
WHERE b.id <= 10;

正确的写法是写在ON后面：先Where再关联

SELECT a.id
FROM ori a
LEFT JOIN bigtable b ON (b.id <= 10 AND a.id = b.id);

先关联再Where：

SELECT a.id
FROM bigtable a
RIGHT JOIN (SELECT id
FROM ori
WHERE id <= 10
) b ON a.id = b.id;

并行执行

  • 把一个sql语句中没有相互依赖的阶段并行去运行。提高集群资源利用率
--开启并行执行
set hive.exec.parallel=true;
--同一个sql允许最大并行度，默认为8。
set hive.exec.parallel.thread.number=16;

严格模式

  • Hive提供了一个严格模式，开启严格模式可以禁止3种类型的查询。可以防止用户执行那些可能意想不到的不好的影响的查询。

严格模式的设置

  • 通过设置属性hive.mapred.mode值为默认是非严格模式nonstrict 。开启严格模式需要修改hive.mapred.mode值为strict
--设置非严格模式（默认）
set hive.mapred.mode=nonstrict;

--设置严格模式
set hive.mapred.mode=strict;

严格模式禁止的3种模式

  1. 对于分区表：除非where语句中含有分区字段过滤条件来限制范围，否则不允许执行
--设置严格模式下 执行sql语句报错； 非严格模式下是可以的
select * from order_partition；

异常信息：Error: Error while compiling statement: 
FAILED: SemanticException [Error 10041]: No partition predicate found for 
Alias "order_partition" Table "order_partition" 

#严格模式下
select o_id from order_partition where  month='2020-06';
  1. 对于使用了order by语句的查询：要求必须使用limit语句
--设置严格模式下 执行sql语句报错； 非严格模式下是可以的
select * from order_partition where month='2020-06' order by order_price; 

异常信息：Error: Error while compiling statement: 
FAILED: SemanticException 1:61 In strict mode, if ORDER BY is specified, 
LIMIT must also be specified. Error encountered near token 'order_price' 

# 严格模式下
select * from order_partition where month='2020-06' order by order_price
limit 1000;
  1. 限制笛卡尔积的查询
  • 严格模式下，避免出现笛卡尔积的查询

JVM重用

JVM重用主要应用与难以表面小文件或task特别多的场景

  • hadoop默认使用派生的JVM来执行map和reduce任务，当执行成百上千个job的时候，大量的JVM启动过程会造成无谓的开销。
  • JVM重用可以试一个JVM实例在一个job中重新使用N次，从而减小重启的开销。
  • 通常为10-20之间。具体数量根据具体业务测试设置。

JVM重用的配置

  • 在mapred-site.xm中进行配置
<property>
  <name>mapreduce.job.jvm.numtasks</name>
  <value>10</value>
  <description>How many tasks to run per jvm. If set to -1, there is
  no limit. 
  </description>
</property>
  • 在hive中设置
set  mapred.job.reuse.jvm.num.tasks=10;

优缺点

  • 优点
  • 减小了大量JVM启动的开销
  • 缺点
  • 开启JVM重用后，在整个Job结束前，将一直占用task插槽。当某些Job中的reduce task执行时间过长时，保留的task插槽会空闲等待job结束，其他job无法使用，从而造成浪费

推测执行

在分布式集群环境下，因为程序Bug（包括Hadoop本身的bug），负载不均衡或者资源分布不均等原因，会造成同一个作业的多个任务之间运行速度不一致，有些任务的运行速度可能明显慢于其他任务（比如一个作业的某个任务进度只有50%，而其他所有任务已经运行完毕），则这些任务会拖慢作业的整体执行进度。为了避免这种情况发生，Hadoop采用了推测执行（Speculative Execution）机制，它根据一定的法则推测出“拖后腿”的任务，并为这样的任务启动一个备份任务，让该任务与原始任务同时处理同一份数据，并最终选用最先成功运行完成任务的计算结果作为最终结果。

推测执行的开启（慎用）

  • Hadoop中设置开启推测执行参数：Hadoop的mapred-site.xml文件中进行配置
<property>
  <name>mapreduce.map.speculative</name>
  <value>true</value>
  <description>If true, then multiple instances of some map tasks 
               may be executed in parallel.</description>
</property>

<property>
  <name>mapreduce.reduce.speculative</name>
  <value>true</value>
  <description>If true, then multiple instances of some reduce tasks 
               may be executed in parallel.</description>
</property>
  • hive中设置reduce-side推测执行参数
<property>
    <name>hive.mapred.reduce.tasks.speculative.execution</name>
    <value>true</value>
    <description>Whether speculative execution for reducers should be
     turned on. </description>
  </property>

关于调优这些推测执行变量，还很难给一个具体的建议。如果用户对于运行时的偏差非常敏感的话，那么可以将这些功能关闭掉。如果用户因为输入数据量很大而需要执行长时间的map或者Reduce task的话，那么启动推测执行造成的浪费是非常巨大大。

压缩

采用合适的压缩算法可以提高效率，参考之前的：压缩格式的选择

数据倾斜

合理设置Map数

引言

  • 通常情况下，作业会通过input的目录产生一个或者多个map任务。
主要的决定因素有：input的文件总个数，input的文件大小，集群设置的文件块大小。

举例：
a)  假设input目录下有1个文件a，大小为780M，那么hadoop会将该文件a分隔成7个块
（6个128m的块和1个12m的块），从而产生7个map数。
b) 假设input目录下有3个文件a，b，c大小分别为10m，20m，150m，
那么hadoop会分隔成4个块（10m，20m，128m，22m），从而产生4个map数。
即，如果文件大于块大小(128m)，那么会拆分，如果小于块大小，则把该文件当成一个块。
  • 是不是map数越多越好？
答案是否定的。如果一个任务有很多小文件（远远小于块大小128m），
  则每个小文件也会被当做一个块，用一个map任务来完成，
  而一个map任务启动和初始化的时间远远大于逻辑处理的时间，就会造成很大的资源浪费。
  而且，同时可执行的map数是受限的。
  • 是不是保证每个map处理接近128m的文件块，就高枕无忧了？
答案也是不一定。比如有一个127m的文件，正常会用一个map去完成，
但这个文件只有一个或者两个小字段，却有几千万的记录，
如果map处理的逻辑比较复杂，用一个map任务去做，肯定也比较耗时。

针对上面的问题2和3，我们需要采取两种方式来解决：即减少map数和增加map数；

小文件合并

针对情况2，即一个任务有很多小文件，需要做小文件合并，减少Maptask数

  • 在map执行前合并小文件，减少map数
  • CombineHiveInputFormat 具有对小文件进行合并的功能（系统默认的格式）
set mapred.max.split.size=112345600;#每个Map最大输入大小
set mapred.min.split.size.per.node=112345600;#一个节点上split的至少的大小
set mapred.min.split.size.per.rack=112345600;#一个交换机下split的至少的大小
set hive.input.format= 
org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; #执行Map前进行小文件合并
  • 在开启了org.apache.hadoop.hive.ql.io.CombineHiveInputFormat后，
  • 一个data node节点上多个小文件会进行合并，合并文件数由mapred.max.split.size限制的大小决定。
  • mapred.min.split.size.per.node决定了多个data node上的文件是否需要合并
  • mapred.min.split.size.per.rack决定了多个交换机上的文件是否需要合并

复杂文件增加Map数

针对情况3，即input的文件都很大，任务逻辑复杂，map执行的非常慢的时候，可以考虑增加map数量。使得每个map处理的数据量减少，从而提高任务的执行效率。

增加map的方法为

  • mapTask数量计算公式：
  • computeSliteSize(Math.max(minSize,Math.min(maxSize,blocksize)))
  • 减小maxSize最大值。让maxSize最大值低于blocksize(hadoop2.0x默认为128M)就可以增加map的个数。
mapreduce.input.fileinputformat.split.minsize=1 默认值为1

mapreduce.input.fileinputformat.split.maxsize=Long.MAXValue 
默认值Long.MAXValue因此，默认情况下，切片大小=blocksize 

maxsize（切片最大值): 参数如果调到比blocksize小，则会让切片变小，
而且就等于配置的这个参数的值。

minsize(切片最小值): 参数调的比blockSize大，则可以让切片变得比blocksize还大。
  • 例如
--设置maxsize大小为10M，也就是说一个fileSplit的大小为10M
set mapreduce.input.fileinputformat.split.maxsize=10485760;

更多关于maptask数量相关知识可以参考之前的：MapTask及输入切片机制

合理设置Reduce数

  • 通过控制每个reduce处理的数据量来间接设置reduce数量
  • 每个Reduce处理的数据量默认是256MB
set hive.exec.reducers.bytes.per.reducer=256000000;
  • 每个任务最大的reduce数，默认为1009
set hive.exec.reducers.max=1009;
  • 计算reducer数的公式
N=min(参数2，总输入数据量/参数1)

一般来讲，参数1不变，参数2设置为0.95*maptask的数量

  • 直接设置reduce数量
--设置每一个job中reduce个数
set mapreduce.job.reduces=3;

注意： reduce个数并不是越多越好

  • 过多的启动和初始化reduce也会消耗时间和资源；
  • 同时过多的reduce会生成很多个文件，也有可能出现小文件问题