您的当前位置:首页hive优化之——控制hive任务中的map数和reduce数

hive优化之——控制hive任务中的map数和reduce数

来源:小侦探旅游网
hive优化之——控制hive任务中的map数和reduce数

⼀、 控制hive任务中的map数:

1. 通常情况下,作业会通过input的⽬录产⽣⼀个或者多个map任务。

主要的决定因素有: input的⽂件总个数,input的⽂件⼤⼩,集群设置的⽂件块⼤⼩(⽬前为128M, 可在hive中通过set dfs.block.size;命令查看到,该参数不能⾃定义修改);2. 举例:

a) 假设input⽬录下有1个⽂件a,⼤⼩为780M,那么hadoop会将该⽂件a分隔成7个块(6个128m的块和1个12m的块),从⽽产⽣7个map数b) 假设input⽬录下有3个⽂件a,b,c,⼤⼩分别为10m,20m,130m,那么hadoop会分隔成4个块(10m,20m,128m,2m),从⽽产⽣4个map数即,如果⽂件⼤于块⼤⼩(128m),那么会拆分,如果⼩于块⼤⼩,则把该⽂件当成⼀个块。

3. 是不是map数越多越好?

答案是否定的。如果⼀个任务有很多⼩⽂件(远远⼩于块⼤⼩128m),则每个⼩⽂件也会被当做⼀个块,⽤⼀个map任务来完成,⽽⼀个map任务启动和初始化的时间远远⼤于逻辑处理的时间,就会造成很⼤的资源浪费。⽽且,同时可执⾏的map数是受限的。

4. 是不是保证每个map处理接近128m的⽂件块,就⾼枕⽆忧了?

答案也是不⼀定。⽐如有⼀个127m的⽂件,正常会⽤⼀个map去完成,但这个⽂件只有⼀个或者两个⼩字段,却有⼏千万的记录,如果map处理的逻辑⽐较复杂,⽤⼀个map任务去做,肯定也⽐较耗时。

针对上⾯的问题3和4,我们需要采取两种⽅式来解决:即减少map数和增加map数;

如何合并⼩⽂件,减少map数? 假设⼀个SQL任务:

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

该任务的inputdir /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= 623,020

我通过以下⽅法来在map执⾏前合并⼩⽂件,减少map数:set mapred.max.split.size=100000000;

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= 333,500对于这个简单SQL任务,执⾏时间上可能差不多,但节省了⼀半的计算资源。

⼤概解释⼀下,100000000表⽰100M, 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(case when …),sum(…)

from a group by data_desc

如果表a只有⼀个⽂件,⼤⼩为120M,但包含⼏千万的记录,如果⽤1个map去完成这个任务,肯定是⽐较耗时的,这种情况下,我们要考虑将这⼀个⽂件合理的拆分成多个,这样就可以⽤多个map任务去完成。set mapred.reduce.tasks=10;create table a_1 asselect * from a

distribute by rand(123);

这样会将a表的记录,随机的分散到包含10个⽂件的a_1表中,再⽤a_1代替上⾯sql中的a表,则会⽤10个map任务去完成。每个map任务处理⼤于12M(⼏百万记录)的数据,效率肯定会好很多。

看上去,貌似这两种有些⽭盾,⼀个是要合并⼩⽂件,⼀个是要把⼤⽂件拆成⼩⽂件,这点正是重点需要关注的地⽅,根据实际情况,控制map数量需要遵循两个原则:使⼤数据量利⽤合适的map数;使单个map任务处理合适的数据量;

⼆、 控制hive任务的reduce数:

1. Hive⾃⼰如何确定reduce数:

reduce个数的设定极⼤影响任务执⾏效率,不指定reduce个数的情况下,Hive会猜测确定⼀个reduce个数,基于以下两个设定:hive.exec.reducers.bytes.per.reducer(每个reduce任务处理的数据量,默认为1000^3=1G)hive.exec.reducers.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多,因此这句有10个reduce2. 调整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个reduce3. 调整reduce个数⽅法⼆;set mapred.reduce.tasks = 15;

select pt,count(1) from popt_tbaccountcopy_mes where pt = ‘2012-07-04′ group by pt;这次有15个reduce4. reduce个数并不是越多越好;

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

另外,有多少个reduce,就会有多少个输出⽂件,如果⽣成了很多个⼩⽂件,那么如果这些⼩⽂件作为下⼀个任务的输⼊,则也会出现⼩⽂件过多的问题;

5. 什么情况下只有⼀个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 byc) 有笛卡尔积

通常这些情况下,除了找办法来变通和避免,我暂时没有什么好的办法,因为这些操作都是全局的,所以hadoop不得不⽤⼀个reduce去完成;同样的,在设置reduce个数的时候也需要考虑这两个原则:使⼤数据量利⽤合适的reduce数;使单个reduce任务处理合适的数据量; 待研究:

map的数量通常是由hadoop集群的DFS块⼤⼩确定的,也就是输⼊⽂件的总块数,正常的map数量的并⾏规模⼤致是每⼀个Node是 10~100个,对于CPU消耗较⼩的作业可以设置Map数量为300个左右,但是由于hadoop的没⼀个任务在初始化时需要⼀定的时间,因此⽐较合理 的情况是每个map执⾏的时间⾄少超过1分钟。具体的数据分⽚是这样的,InputFormat在默认情况下会根据hadoop集群的DFS块⼤⼩进⾏分 ⽚,每⼀个分⽚会由⼀个map任务来进⾏处理,当然⽤户还是可以通过参数mapred.min.split.size参数在作业提交客户端进⾏⾃定义设置。还有⼀个重要参数就是mapred.map.tasks,这个参数设置的map数量仅仅是⼀个提⽰,只有当InputFormat 决定了map任务的个数⽐mapred.map.tasks值⼩时才起作⽤。同样,Map任务的个数也能通过使⽤JobConf 的conf.setNumMapTasks(int num)⽅法来⼿动地设置。这个⽅法能够⽤来增加map任务的个数,但是不能设定任务的个数⼩于Hadoop系统通过分割输⼊数据得到的值。当然为了提⾼ 集群的并发效率,可以设置⼀个默认的map数量,当⽤户的map数量较⼩或者⽐本⾝⾃动分割的值还⼩时可以使⽤⼀个相对交⼤的默认值,从⽽提⾼整体hadoop集群的效率。

因篇幅问题不能全部显示,请点此查看更多更全内容