hadoop源码分析之MapReduce

声明：

1. 本文假设读者已经掌握一些MapReduce的基本概念,曾经编写过MapReduce程序。

2. 此源代码分析是基于hadoop svn的trunk之上(目前0.20.0-dev),由于hadoop正在换新的MapReduce api(org.apache.hadoop.mapreduce包), 以后很多类会弃用,很多接口会改变,这儿只能尽量保持同步。

3. 关于hdfs源代码可以参考caibinbupt的hdfs源代码分析 ,这儿就不再详述。

4. 这篇文章是基于javen 的分析之上的，感谢javen的辛勤劳动。javen的源码分析是在早期的hadoop版本上,在这儿有一些内容会不一样。

一、基本概念

1.1 MapReduce逻辑过程
1.2 MapReduce物理分布

二、实现细节

2.1 总体结构

我们在编写MapReduce程序时通常是上是这样写的:

Java代码

    Configuration conf = new Configuration(); // 读取hadoop配置
    Job job = new Job(conf, "作业名称"); // 实例化一道作业
    job.setMapperClass(Mapper类型);
    job.setCombinerClass(Combiner类型);
    job.setReducerClass(Reducer类型);
    job.setOutputKeyClass(输出Key的类型);
    job.setOutputValueClass(输出Value的类型);
    FileInputFormat.addInputPath(job, new Path(输入hdfs路径));
    FileOutputFormat.setOutputPath(job, new Path(输出hdfs路径));
    // 其它初始化配置
    JobClient.runJob(job);

一道MapRedcue作业是通过JobClient.rubJob(job)向master节点的JobTracker提交的, JobTracker接到JobClient的请求后把其加入作业队列中。在这之前master节点的NameNode, SecondedNameNode,JobTracker和slaves节点的DataNode, TaskTracker都已经启动。JobTracker一直在等待JobClient通过RPC提交作业,而TaskTracker一直通过RPC向 JobTracker发送心跳heartbeat询问有没有任务可做，如果有，让其派发任务给它执行。如果JobTracker的作业队列不为空, 则TaskTracker发送的心跳将会获得JobTracker给它派发的任务。这是一道pull过程: slave主动向master拉生意。slave节点的TaskTracker接到任务后在其本地发起Task,执行任务。以下是简略示意图：

 

2.1.1 Mapper和Reducer

运行于Hadoop的MapReduce应用程序最基本的组成部分包括一个Mapper和一个Reducer类，以及一个创建JobConf的执行程序，在一些应用中还可以包括一个Combiner类，它实际也是Reducer的实现。

2.1.2  JobTracker和TaskTracker

它们都是由一个master服务JobTracker和多个运行于多个节点的slaver服务TaskTracker两个类提供的服务调度的。master负责调度job的每一个子任务task运行于slave上，并监控它们，如果发现有失败的task就重新运行它，slave则负责直接执行每一个task。TaskTracker都需要运行在HDFS的DataNode上，而JobTracker则不需要，一般情况应该把JobTracker部署在单独的机器上。

2.1.3 JobClient

每一个job都会在用户端通过JobClient类将应用程序以及配置参数Configuration打包成jar文件存储在HDFS，并把路径提交到JobTracker的master服务，然后由master创建每一个Task（即MapTask和ReduceTask）将它们分发到各个TaskTracker服务中去执行。

2.1.4 JobInProgress

JobClient提交job后，JobTracker会创建一个JobInProgress来跟踪和调度这个job，并把它添加到job队列里。JobInProgress会根据提交的job jar中定义的输入数据集（已分解成FileSplit）创建对应的一批TaskInProgress用于监控和调度MapTask，同时在创建指定数目的TaskInProgress用于监控和调度ReduceTask，缺省为1个ReduceTask。

2.1.5 TaskInProgress

JobTracker启动任务时通过每一个TaskInProgress来launchTask，这时会把Task对象（即MapTask和ReduceTask）序列化写入相应的TaskTracker服务中，TaskTracker收到后会创建对应的TaskInProgress（此TaskInProgress实现非JobTracker中使用的TaskInProgress，作用类似）用于监控和调度该Task。启动具体的Task进程是通过TaskInProgress管理的TaskRunner对象来运行的。TaskRunner会自动装载job jar，并设置好环境变量后启动一个独立的java child进程来执行Task，即MapTask或者ReduceTask，但它们不一定运行在同一个TaskTracker中。

2.1.6  MapTask和ReduceTask

一个完整的job会自动依次执行Mapper、Combiner（在JobConf指定了Combiner时执行）和Reducer，其中Mapper和Combiner是由MapTask调用执行，Reducer则由ReduceTask调用，Combiner实际也是Reducer接口类的实现。Mapper会根据job jar中定义的输入数据集按<key1,value1>对读入，处理完成生成临时的<key2,value2>对，如果定义了Combiner，MapTask会在Mapper完成调用该Combiner将相同key的值做合并处理，以减少输出结果集。MapTask的任务全完成即交给ReduceTask进程调用Reducer处理，生成最终结果<key3,value3>对。这个过程在下一部分再详细介绍。

 

2.2 JobTracker与作业处理

2.2.1 JobClient提交作业

JobClient.runJob(job)静态方法会实例化一个JobClient实例,然后用此实例的submitJob(job)方法向 master提交作业。此方法会返回一个RunningJob对象，它用来跟踪作业的状态。作业提交完毕后，JobClient会根据此对象开始轮询作业的进度，直到作业完成。
submitJob(job)内部是通过submitJobInternal(job)方法完成实质性的作业提交。  submitJobInternal(job)方法首先会向hadoop分布系统文件系统hdfs依次上传三个文件: job.jar, job.split和job.xml。
job.xml: 作业配置，例如Mapper, Combiner, Reducer的类型，输入输出格式的类型等。
job.jar: jar包,里面包含了执行此任务需要的各种类，比如 Mapper,Reducer等实现。
job.split: 文件分块的相关信息，比如有数据分多少个块，块的大小(默认64m)等。
这三个文件在hdfs上的路径由hadoop-default.xml文件中的mapreduce系统路径mapred.system.dir属性 + jobid决定。mapred.system.dir属性默认是/tmp/hadoop-user_name/mapred/system。写完这三个文件之后, 此方法会通过RPC调用master节点上的JobTracker.submitJob(job)方法，此时作业已经提交完成。关于RPC的细节,后续章节将会阐述。

2.2.2 JobTacker调度作业

JobTracker接到JobClient提交的作业后,即在JobTracker.submitJob(job)方法中，首先产生一个JobInProgress对象。此对象代表一道作业，它的作用是维护这道作业的所有信息，包括作业剖析JobProfile和最近作业状态JobStatus,并登记此作业所有Tasks进任务表中。随后JobTracker将此JobInProgress对象通过listener.jobAdded(job)方法加入到调度队列中，并用一个成员变量jobs来维护所有的作业。

下面将说明hadoop的作业调度

作业调度在hadoop-0.19.0版得到了很大的改进,原来的调度策略规定是先进先出(FIFO)的。随着hadoop的商业应用增多，各个公司对它的需求也增多。其中Facebook公司提交了一个公平调度器Fair Scheduler; Yahoo!公司提交了Capacity Scheduler。它们分别在hadoop源码树的src/contrib/fairscheduler和src/contrib/capacity- scheduler目录中。而hadoop默认的调度器是FIFO策略的JobQueueTaskScheduler,它有两个成员变量jobQueueJobInProgressListener与eagerTaskInitializationListener。

      其中eagerTaskInitializationListener负责任务Task的初始化。其具体实现是这样的: 这个listener在初始化时会开启一个JobInitThread线程，当作业通过jobAdded(job)加入到初始化队列jobInitQueue中,根据作业的优先级排序(resortInitQueue方法)后, 这个线程就会调用JobInProgress.initTasks()立即初始化作业的所有任务。

2.2.3 JobInProgress初始化任务

 

       任务Task分两种: MapTask 和reduceTask，它们的管理对象都是TaskInProgress 。
 JobInProgress.initTasks()方法首先从JobClient上传的job.split文件中读取所有数据块的列表，然后根据这个列表创建对应数目的Map执行管理对象TaskInProgress。创建这些TaskInProgress对象完毕后，initTasks()方法会通过createCache()方法为这些对象产生一个未执行任务的Map缓存nonRunningMapCache。slave端的TaskTracker向master发送心跳时，就可以直接从这个cache中取任务去执行。createCache()方法的作用是为以上TaskInProgress对象在网络拓扑结构上分配拥有此任务数据块的节点。从近到远一层一层地寻找，首先是同一节点，然后在寻找同一机柜上的节点，接着寻找相同关换机下的节点，直到找了maxLevel层结束。这样的话，在JobTracker给TaskTracker派发任务的时候，可以迅速找到最近的TaskTracker，让它执行任务。
 其次JobInProgress会创建Reduce的监控对象，这个比较简单，根据JobConf里指定的Reduce数目创建，缺省只创建1个Reduce任务。监控和调度Reduce任务的也是TaskInProgress类，不过构造方法有所不同，TaskInProgress会根据不同参数分别创建具体的MapTask或者ReduceTask。同样地，initTasks()也会通过createCache()方法对这些TaskInProgress对象寻找maxLevel层的可行TaskTracker，进而产生nonRunningReduceCache成员。
 JobInProgress创建完TaskInProgress后，最后构造JobStatus并记录job正在执行中，然后再调用JobHistory.JobInfo.logStarted()记录job的执行日志。到这里JobTracker里初始化job的过程全部结束，执行则是通过另一异步的方式处理的，下面接着介绍它。

任务的申请、派发与执行

TaskTracker.run() 连接JobTracker

TaskTracker 的启动过程会初始化一系列参数和服务（另有单独的一节介绍），然后尝试连接JobTracker 服务（即必须实现InterTrackerProtocol 接口），如果连接断开，则会循环尝试连接JobTracker ，并重新初始化所有成员和参数，此过程参见run() 方法。

TaskTracker.offerService() 主循环

如果连接JobTracker 服务成功，TaskTracker 就会调用offerService() 函数进入主执行循环中。这个循环会每隔10 秒与JobTracker 通讯一次，调用transmitHeartBeat() 获得HeartbeatResponse 信息。然后调用HeartbeatResponse 的getActions() 函数获得JobTracker 传过来的所有指令即一个TaskTrackerAction 数组。再遍历这个数组，如果是一个新任务指令即LaunchTaskAction 则调用startNewTask() 函数执行新任务，

如果是 CommitTaskAction

否则加入到tasksToCleanup 队列，交给一个taskCleanupThread 线程来处理，如执行KillJobAction 或者KillTaskAction 等。

TaskTracker.transmitHeartBeat() 获取JobTracker 指令

在transmitHeartBeat() 函数处理中，TaskTracker 会创建一个新的TaskTrackerStatus 对象记录目前任务的执行状况，然后通过IPC 接口调用JobTracker 的heartbeat() 方法发送过去，并接受新的指令，即返回值TaskTrackerAction 数组。在这个调用之前，TaskTracker 会先检查目前执行的Task 数目以及本地磁盘的空间使用情况等，如果可以接收新的Task 则设置heartbeat() 的askForNewTask 参数为true 。操作成功后再更新相关的统计信息等。

JobTracker 调度作业第二步：派发任务

JobTracker 接到TaskTracker 的heartbeat() 调用后，首先会检查上一个心跳响应是否完成，是没要求启动或重启任务，如果一切正常，则会处理心跳。JobTracker 会使用它的调度器taskScheduler 来组装任务到一个任务列表tasks 中。具体实现在taskScheduler 的assignTasks() 方法。得到tasks 的数据后，把这些任务封装在一些LanuchTaskAction 中，发回给TaskTracker ，让它去执行任务。此时JobTracker 的hearbeat() 结束派发任务。

下面简单分析下 hadoop 默认的作业调度器 JobQueueTaskScheduler 怎么实现以上所说的 assignTasks() 方法。首先它会检查 TaskTracker 端还可以做多少个 map 和 reduce 任务，将要派发的任务数是否超出这个数，是否超出集群的任务平均剩余可负载数。如果都没超出，则为此 TaskTracker 分配一个 MapTask 或 ReduceTask 。产生 Map 任务使用 JobInProgress 的 obtainNewMapTask() 方法，实质上最后调用了 JobInProgress 的 findNewMapTask() 访问 nonRunningMapCache 得到 Map 任务的 TaskInProgress ；而产生 Reduce 任务使用 JobInProgress.obtainNewReduceTask() 方法，实质上最后调用了 JobInProgress 的 findNewReduceTask() 访问 nonRuningReduceCache 得到 Reduce 任务的 TaskInProgress 。