如何控制Hive执行中的Map和Reduce数量

最新推荐文章于 2022-04-30 21:46:17 发布

猿说新宇

最新推荐文章于 2022-04-30 21:46:17 发布

阅读量753

点赞数

分类专栏： Hive 文章标签： Hive调优调优

本文链接：https://blog.csdn.net/W1331808514/article/details/83474073

版权

Hive 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

调整hive.exec.reducers.bytes.per.reducer参数的值

调整mapred.reduce.tasks参数的值

是不是reduce个数越多越好

只有一个reduce的情况

Map

map任务的个数

map任务的个数是在Map阶段中InputSplit决定的，InputSplit将作业的Input目录下的文件切片，每个片大小默认是等于block块大小的。所以不同的map个数的控制方法从根本上都是来控制输入文件的大小和个数来进行实现的。主要决定因素有input的文件总个数，input的文件大小，集群设置的文件块大小（目前为128M,可在hive中通过set dfs.block.size；命令查看到，该参数不能自定义修改。）

切片与块的关系

假设input目录下有1个文件a，大小为800M，那么hadoop会将该文件a分割成7块（6块为128M,1块为32M），从而在运行mapreduce的时候会产生7个map任务（InputSplit切片大小默认等于块大小，若最后一个切片大小小于块大小的%10，那么它会跟上一个切片合并为一个切片，即6个map数）。
假设input目录下有3个文件a,b,c，大小分别为10M，20M和130.，那么hadoop会将这3个文件分隔成4个块（10M,20M,128M,2M）。在运行mapreduce的时候会被InputSplit切成3个切片，即产生3个map任务。
切片是逻辑上的，而块是物理上的。
一般切片大小事默认等于块大小的，若一个切片包含多个block，总会从其他节点读取数据，也就是做不到所有的计算都是本地化，所以应该尽量使InputSplit切片大小与block大小相当。

是不是map数越多越好

如果一个任务有很多小文件（远远小于块大小128M），则每个小文件也会被当做一个块，用一个map任务来完成，而一个map任务启动和初始化的时间远远大于逻辑处理的时间，就会造成很大的资源浪费。而且，同时可执行的map数是受限制的。

故并不是map数越多越好

合理的map数设置

比如有一个127M的文件，正常会用一个map任务去完成，但这个文件只有一个或者两个小字段，却有几千万的记录，如果map处理的逻辑比较复杂，用一个map任务去做，肯定也比较耗时。

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

如何合并小文件，减少map数？

假设一个SQL任务：

Select count(1) from popt_tbaccountcopy_mes where pt = ‘2012-07-04’;

该任务的input目录：

/group/p_sdo_data/p_sdo_data_etl/pt/popt_tbaccountcopy_mes/pt=2012-07-04

共有194个文件，其中很多是远远小于128M的小文件，总大小9G，正常执行会用194个map任务。

Map总共消耗的计算资源：SLOTS_MILLIS_MAPS=623020

通过以下方法在map执行前合并小文件，减少map数：

set mapred,.max.split.size=100000000;（10000000代表了100M）

set mapred.min.split.size.per.node=100000000;

set mapred.min.split.size.per,rack=100000000;

set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

再执行上面的语句，用了74个map任务，map消耗的计算资源：

SLOTS_MILLIS_MAPS=333500

对于这个简单SQL任务，执行时间上可能差不多，但节省了一半的计算资源。

set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;这个参数指定了执行前进行小文件合并的类。

前面三个参数确定合并文件块的大小，大于文件块大小128M的，按照128M来切分，小于128M，大于100M的，按照100M来切分，那些小于100M的（包括小文件和分隔大文件剩下的）按照指定的合并类进行合并，最终生成了74个块。

如何适当的增加map数？

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

假设有这样一个任务：

select data_desc,

count(1),

count(distinct id),

sum(case when…),

sum(…)

from a group by data_desc

如果表a只有一个文件，大小为120M，但包含几千万的记录，如果用1个map去完成这个任务，肯定是比较耗时的，这种情况下，我们要考虑将这一个文件合理的拆分成多个，这样就可以用多个map任务去完成。

set mapred.map.tasks=10;

create table a_1 as

select * from a

distribute by rand(123);

这样会将a表的记录，随机的分散到包含10个文件的a_1表中，再用a_1代替上面sql中的a表，则会用10个map任务去完成。每个map任务处理大于12M（几百万记录）的数据，效率肯定会好很多。

控制map的个数主要就是两个思路：合并小文件、将大文件拆分成小文件。在方法实现上遵循两个原则：使大数据量利用合适的map数；使单个map任务处理合适的数据量。

Reduce

hive自己如何确定reduce数

reduce个数的设定极大的影响了任务执行效率，不指定reduce个数的情况下，Hive会猜测确定一个reduce个数，基于以下两个设定：

hive.exec.reducers.bytes.per.reducer（每个reduce任务处理的数据量，默认为1000^3=1G）

hive.exec.reducer.max（每个任务最大的reduce数，默认为999）

计算reducer数的公式很简单N=min（参数2，总输入数据量/参数1）

即，如果reduce的输入（map的输出）总大小不超过1G，那么只会有一个reduce任务；如：

select pt,count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04' group by pt; /group/p_sdo_data/p_sdo_data_etl/pt/popt_tbaccountcopy_mes/pt=2012-07-04

总大小为9G多，因此这个sql任务有10个reduce。

调整reduce个数方法

调整hive.exec.reducers.bytes.per.reducer参数的值

set hive.exec.reducers.bytes.per.reducer=500000000;(500M)

select pt,count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04' group by pt;

这次会有20个reduce。

调整mapred.reduce.tasks参数的值

set mapred.reduce.tasks=15;

select pt,count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04' group by pt;

那么这次会有15个reduce。

是不是reduce个数越多越好

同map一样,启动和初始化reduce也会消耗时间和资源;

另外,有多少个reduce,就会有多少个输出文件,如果生成了很多小文件,那么如果这些小文件作为下一个任务的输入,则也会出现小文件过多的问题.

只有一个reduce的情况

很多时候你会发现任务中不管数据量多大，不管你有没有设置调整reduce个数的参数，任务中一直都只有一个reduce任务；其实只有一个reduce任务的情况，除了数据量小于hive.exec.reducers.bytes.per.reducer参数值的情况外，还有以下原因：

a) 没有group by的汇总，比如把select pt,count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04' group by pt; 写成 select count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04'。

b) 用了Order by

c) 有笛卡尔积通常这些情况下，除了找办法来变通和避免，暂时没有什么好的办法，因为这些操作都是全局的，所以hadoop不得不用一个reduce去完成；同样的，在设置reduce个数的时候也需要考虑这两个原则：使大数据量利用合适的reduce数；使单个reduce任务处理合适的数据量；