Hadoop如何计算map数和reduce数

                               原地址：http://www.songyafei.cn/post/a0d5b_140a7cf

Hadoop在运行一个mapreduce job之前，需要估算这个job的maptask数和reducetask数。首先分析一下job的maptask数，当一个job提交时，jobclient首先分析job被拆分的split数量，然后吧job.split文件放置在HDFS中，一个job的MapTask数量就等于split的个数。

job.split中包含split的个数由FileInputFormat.getSplits计算出，方法的逻辑如下：

1. 读取参数mapred.map.tasks，这个参数默认设置为0，生产系统中很少修改。

2. 计算input文件的总字节数，总字节数/(mapred.map.tasks==0 ? 1: mapred.map.tasks )=goalsize

3. 每个split的最小值minSize由mapred.min.split.size参数设置，这个参数默认设置为0，生产系统中很少修改。

4. 调用computeSplitSize方法，计算出splitsize= Math.max(minSize, Math.min(goalSize, blockSize)),通常这个值=blockSize，输入的文件较小，文件字节数之和小于blocksize时，splitsize=输入文件字节数之和。

5. 对于input的每个文件，计算split的个数。

a) 文件大小/splitsize>1.1，这个相对于输入文件中的单个文件，创建一个split，这个split的字节数=splitsize，文件剩余字节数=文件大小-splitsize

          length=file.getLength()//单个文件
          long bytesRemaining = length;
          while (((double) bytesRemaining)/splitSize > SPLIT_SLOP) {
            String[][] splitHosts = getSplitHostsAndCachedHosts(blkLocations,
                length-bytesRemaining, splitSize, clusterMap);
            splits.add(makeSplit(path, length-bytesRemaining, splitSize,
                splitHosts[0], splitHosts[1]));
            bytesRemaining -= splitSize;
          }

 

b) 文件剩余字节数/splitsize<1.1，剩余的部分作为一个split

举例说明：

1. input只有一个文件，大小为100M,splitsize=blocksize,则split数为2，第一个split为64M,第二个为36M

2. input只有一个文件，大小为65M,splitsize=blocksize，则split数为1，split大小为65M

3. input只有一个文件，大小为129M,splitsize=blocksize，则split数为2，第一个split为64M,第二个为65M(最后一个split的大小可能超过splitsize)

4. input只有一个文件，大小为20M ,splitsize=blocksize，则split数为1，split大小为20M

5. input有两个文件，大小为100M和20M,splitsize=blocksize,则split数为3，第一个文件分为两个split，第一个split为64M,第二个为36M，第二个文件为一个split，大小为20M

6. input有两个文件，大小为25M和20M,splitsize=blocksize,则split数为2，第一个文件为一个split，大小为25M，第二个文件为一个split，大小为20M

假设一个job的input大小固定为100M,当只包含一个文件时，split个数为2，maptask数为2，但当包含10个10M的文件时，maptask数为10。

下面来分析reducetask，纯粹的mapreduce task的reduce task数很简单，就是参数mapred.reduce.tasks的值，hadoop-site.xml文件中和mapreduce job运行时不设置的话默认为1。

在HIVE中运行sql的情况又不同，hive会估算reduce task的数量，估算方法如下：

通常是ceil(input文件大小/1024*1024*1024)，每1GB大小的输入文件对应一个reduce task。

特殊的情况是当sql只查询count(*)时，reduce task数被设置成1。

 

总结：通过map和reducetask数量的分析可以看出，hadoop/hive估算的map和reduce task数可能和实际情况相差甚远。假定某个job的input数据量庞大，reduce task数量也会随之变大，而通过join和group by，实际output的数据可能不多，但reduce会输出大量的小文件，这个job的下游任务将会启动同样多的map来处理前面reduce产生的大量文件。在生产环境中每个user group有一个map task数的限额，一个job启动大量的map task很显然会造成其他job等待释放资源。

Hive对于上面描述的情况有一种补救措施，参数hive.merge.smallfiles.avgsize控制hive对output小文件的合并，当hiveoutput的文件的平均大小小于hive.merge.smallfiles.avgsize-默认为16MB左右，hive启动一个附加的mapreducejob合并小文件，合并后文件大小不超过hive.merge.size.per.task-默认为256MB。

尽管Hive可以启动小文件合并的过程，但会消耗掉额外的计算资源，控制单个reduce task的输出大小>64MB才是最好的解决办法。