_Map和reduce数量调整

map和reduce数量调整

1. 是map数越多越好？

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

1. 是不是保证每个map处理接近128m的文件块，就高枕无忧了？

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

1. 是不是reduce数越多越好？

答案是否定的。如果reduce设置的过大，对整个作业会产生一定的影响。 ①过多的启动和初始化reduce也会消耗时间和资源； ②另外，有多少个reduce，就会有多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题；

Maptask个数调整

-- 小文件场景
-- 每个Map最大输入大小(这个值决定了合并后文件的数量)
set mapred.max.split.size=112345600;  
-- 一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并)
set mapred.min.split.size.per.node=112345600;
-- 一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并)  
set mapred.min.split.size.per.rack=112345600;
-- 执行Map前进行小文件合并
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
​
-- 大文件场景, 增加Map数
set mapred.reduce.tasks=10;

Reducetask个数调整

-- 总共受3个参数控制：
-- 每个Reduce处理的数据量默认是256MB
hive.exec.reducers.bytes.per.reducer=256123456
-- 每个任务最大的reduce数，默认为999
hive.exec.reducers.max=999
-- mapreduce.job.reduces
-- 该值默认为-1，由hive自己根据任务情况进行判断。也可以手动控制
set mapreduce.job.reduces = 8;

注意: 以下几种, 不管如何设置, 最终翻译后reduce只能有一个

1. 执行order by操作

2. 执行不需要group by直接聚合的操作

3. 执行笛卡尔积