hive常用的调优方案
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种模式
- 对于分区表：除非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';
- 对于使用了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;
-
限制笛卡尔积的查询
- 严格模式下，避免出现笛卡尔积的查询
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会生成很多个文件，也有可能出现小文件问题
1655
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
