深度分析如何在Hadoop中控制Map的数量

http://blog.csdn.net/strongerbit/article/details/7440111

很多文档中描述，Mapper的数量在默认情况下不可直接控制干预，因为Mapper的数量由输入的大小和个数决定。在默认情况下，最终input占据了多少block，就应该启动多少个Mapper。如果输入的文件数量巨大，但是每个文件的size都小于HDFS的blockSize，那么会造成启动的Mapper等于文件的数量（即每个文件都占据了一个block），那么很可能造成启动的Mapper数量超出限制而导致崩溃。这些逻辑确实是正确的，但都是在默认情况下的逻辑。其实如果进行一些客户化的设置，就可以控制了。

在Hadoop中，设置Map task的数量不像设置Reduce task数量那样直接，即：不能够通过API直接精确的告诉Hadoop应该启动多少个Map task。

你也许奇怪了，在API中不是提供了接口org.apache.hadoop.mapred.JobConf.setNumMapTasks(int n)吗？这个值难道不可以设置Map task的数量吗？这个API的确没错，在文档上解释”Note: This is only a hint to the framework.“，即这个值对Hadoop的框架来说仅仅是个提示，不起决定性的作用。也就是说，即便你设置了，也不一定得到你想要的效果。

1. InputFormat介绍

在具体设置Map task数量之前，非常有必要了解一下与Map-Reduce输入相关的基础知识。

这个接口（org.apache.hadoop.mapred.InputFormat）描述了Map-Reduce job的输入规格说明（input-specification），它将所有的输入文件分割成逻辑上的InputSplit，每一个InputSplit将会分给一个单独的mapper；它还提供RecordReader的具体实现，这个Reader从逻辑的InputSplit上获取input records并传给Mapper处理。

InputFormat有多种具体实现，诸如FileInputFormat（处理基于文件的输入的基础抽象类）, DBInputFormat（处理基于数据库的输入，数据来自于一个能用SQL查询的表）,KeyValueTextInputFormat（特殊的FineInputFormat，处理Plain Text File，文件由回车或者回车换行符分割成行，每一行由key.value.separator.in.input.line分割成Key和Value），CompositeInputFormat，DelegatingInputFormat等。在绝大多数应用场景中都会使用FileInputFormat及其子类型。

通过以上的简单介绍，我们知道InputFormat决定着InputSplit，每个InputSplit会分配给一个单独的Mapper，因此InputFormat决定了具体的Map task数量。

2. FileInputFormat中影响Map数量的因素

在日常使用中，FileInputFormat是最常用的InputFormat，它有很多具体的实现。以下分析的影响Map数量的因素仅对FileInputFormat及其子类有效，其他非FileInputFormat可以去查看相应的 getSplits(JobConf job, int numSplits) 具体实现即可。

请看如下代码段（摘抄自org.apache.hadoop.mapred.FileInputFormat.getSplits，hadoop-0.20.205.0源代码）：

[java]  view plain copy

1. long goalSize = totalSize / (numSplits == 0 ? 1 : numSplits);  
2. long minSize = Math.max(job.getLong("mapred.min.split.size", 1), minSplitSize);  
3.   
4. for (FileStatus file: files) {  
5.   Path path = file.getPath();  
6.   FileSystem fs = path.getFileSystem(job);  
7.   if ((length != 0) && isSplitable(fs, path)) {   
8.     long blockSize = file.getBlockSize();  
9.     long splitSize = computeSplitSize(goalSize, minSize, blockSize);  
10.       
11.     long bytesRemaining = length;  
12.     while (((double) bytesRemaining)/splitSize > SPLIT_SLOP) {  
13.       String[] splitHosts = getSplitHosts(blkLocations,length-bytesRemaining, splitSize, clusterMap);  
14.       splits.add(new FileSplit(path, length-bytesRemaining, splitSize, splitHosts));  
15.       bytesRemaining -= splitSize;  
16.     }  
17.   
18.     if (bytesRemaining != 0) {  
19.       splits.add(new FileSplit(path, length-bytesRemaining, bytesRemaining, blkLocations[blkLocations.length-1].getHosts()));  
20.     }  
21.   } else if (length != 0) {  
22.     String[] splitHosts = getSplitHosts(blkLocations,0,length,clusterMap);  
23.     splits.add(new FileSplit(path, 0, length, splitHosts));  
24.   } else {   
25.     //Create empty hosts array for zero length files  
26.     splits.add(new FileSplit(path, 0, length, new String[0]));  
27.   }  
28. }  
29.   
30. return splits.toArray(new FileSplit[splits.size()]);  
31.   
32. protected long computeSplitSize(long goalSize, long minSize, long blockSize) {  
33.     return Math.max(minSize, Math.min(goalSize, blockSize));  
34. }  

totalSize：是整个Map-Reduce job所有输入的总大小。

numSplits：来自job.getNumMapTasks()，即在job启动时用org.apache.hadoop.mapred.JobConf.setNumMapTasks(int n)设置的值，给M-R框架的Map数量的提示。

goalSize：是输入总大小与提示Map task数量的比值，即期望每个Mapper处理多少的数据，仅仅是期望，具体处理的数据数由下面的computeSplitSize决定。

minSplitSize：默认为1，可由子类复写函数protected void setMinSplitSize(long minSplitSize) 重新设置。一般情况下，都为1，特殊情况除外。

minSize：取的1和mapred.min.split.size中较大的一个。

blockSize：HDFS的块大小，默认为64M，一般大的HDFS都设置成128M。

splitSize：就是最终每个Split的大小，那么Map的数量基本上就是totalSize/splitSize。

接下来看看computeSplitSize的逻辑：首先在goalSize（期望每个Mapper处理的数据量）和HDFS的block size中取较小的，然后与mapred.min.split.size相比取较大的。

3. 如何调整Map的数量

有了2的分析，下面调整Map的数量就很容易了。

3.1 减小Map-Reduce job 启动时创建的Mapper数量

当处理大批量的大数据时，一种常见的情况是job启动的mapper数量太多而超出了系统限制，导致Hadoop抛出异常终止执行。解决这种异常的思路是减少mapper的数量。具体如下：

3.1.1 输入文件size巨大，但不是小文件

这种情况可以通过增大每个mapper的input size，即增大minSize或者增大blockSize来减少所需的mapper的数量。增大blockSize通常不可行，因为当HDFS被hadoop namenode -format之后，blockSize就已经确定了（由格式化时dfs.block.size决定），如果要更改blockSize，需要重新格式化HDFS，这样当然会丢失已有的数据。所以通常情况下只能通过增大minSize，即增大mapred.min.split.size的值。

3.1.2 输入文件数量巨大，且都是小文件

所谓小文件，就是单个文件的size小于blockSize。这种情况通过增大mapred.min.split.size不可行，需要使用FileInputFormat衍生的CombineFileInputFormat将多个input path合并成一个InputSplit送给mapper处理，从而减少mapper的数量。具体细节稍后会更新并展开。

3.2 增加Map-Reduce job 启动时创建的Mapper数量

增加mapper的数量，可以通过减小每个mapper的输入做到，即减小blockSize或者减小mapred.min.split.size的值。

• map task的数量即mapred.map.tasks的参数值，用户不能直接设置这个参数。Input Split的大小，决定了一个Job拥有多少个map。默认input split的大小是64M（与dfs.block.size的默认值相同）。然而，如果输入的数据量巨大，那么默认的64M的block会有几万甚至几十万的Map Task，集群的网络传输会很大，最严重的是给Job Tracker的调度、队列、内存都会带来很大压力。mapred.min.split.size这个配置项决定了每个 Input Split的最小值，用户可以修改这个参数，从而改变map task的数量。
• 一个恰当的map并行度是大约每个节点10-100个map，且最好每个map的执行时间至少一分钟。
•  reduce task的数量由mapred.reduce.tasks这个参数设定，默认值是1。
• 合适的reduce task数量是0.95或者0.75*( nodes * mapred.tasktracker.reduce.tasks.maximum), mapred.tasktracker.tasks.reduce.maximum的数量一般设置为各节点cpu core数量，即能同时计算的slot数量。对于0.95，当map结束时，所有的reduce能够立即启动；对于1.75，较快的节点结束第一轮reduce后，可以开始第二轮的reduce任务，从而提高负载均衡。

• 对一 个job的map数和reduce数的设定对一个job的运行是非常重要的，并且非常简单。以下是一些设 置这几个值的经验总结：

  • 如果job的每个map或者 reduce task的运行时间都只有30-40秒钟，那么就减少该job的map或者reduce数，每一个task(map|reduce)的setup和加入到 调度器中进行调度，这个中间的过程可能都要花费几秒钟，所以如果每个task都非常快就跑完了，就会在task的开始和结束的时候浪费太多的时间。JVM 的reuse方式也可以解决 这个问题。
  • 如 果某个input的文件 非常的大，比如 1TB，可以考虑将hdfs上的每个block size设大，比如设成256MB或者512MB，这样map和reduce的数据 可以减小。而且用户还可以通过命令 ：hadoop distcp -Ddfs.block.size=$[256*1024*1024] /path/to/inputdata /path/to/inputdata-with-largeblocks的方式来将已经存在咋hdfs上的数据进行大块化。然后删除掉原先的文件。
  • 只 要每个task都运行至少30-40秒钟，就可以考虑将mapper数扩大，比如集群的map slots为100个，那么就不要将一个job的mapper设成101，这样前100个map能够并行完成，而最后一个map要在前100个 mapper结束后才开始，因此在reduce开始运行前，map阶段的时间几乎就要翻倍。
  • 尽量不要运行太多的reduce task。对大多数job来说，最好rduce的个数最多和集群中的reduce持平，或者比集群的 reduce slots小。这个对于小集群而言，尤其重要。

http://irwenqiang.iteye.com/blog/1535809