海盗的小菜园

一个stage是由一组相同运算的task组成，他们分别计算不同的partition，stage的提交实际是向调度器提交一组包含相同计算的task，这里调度器的名字是TaskScheduler，其调度单位是taskset，stage在提交是使用了递归算法，会先提交没有parent stage的stage，代码如下： private def submitStage(stage: Stage) {

ExpireLaunchingTasks为JobTracker的后台线程，该线程记录了task的启动时间，每当TaskTracker发送心跳时，JobTracker会分配合适的任务给TaskTracker，并且将TaskAttemptID和启动时间以键值对的形式记录到launchingTasks集合中，待下次心跳如果JT得知该任务启动成功，则会从launchingTasks集合中删除，否则记录失败

原文地址：http://www.tbdata.org/archives/1470hadoop作业调优参数整理及原理1 Map side tuning参数1.1 MapTask运行内部原理当map task开始运算，并产生中间数据时，其产生的中间结果并非直接就简单的写入磁盘。这中间的过程比较复杂，并且利用到了内存buffer来进行已经产生的部分

Map任务执行完前会对spill文件进行合并操作，每次spill都会生成一个spill文件，在传向reduce前，map会把这些文件合并为一个文件，文件合并不是一次性把所有文件合并的，每次合并的个数可以通过参数io.sort.factor指定，当实际spill文件数量超过该值的时候，会生成相应的中间临时文件，总之，每次合并文件的数量不会超过io.sort.factor。文件合并由mergePart

TaskLauncher线程监控到有新任务到达的时候，便会通过startNewTask启动一个新的线程来执行任务，该线程独立运行不会影响TT的其他线程，通过源码中的注释也能看到这个意思，任务启动之初会先做本地化操作，然后通过launchTaskForJob启动，在child JVM启动之前的过程比较复杂，会经过一系列的线程创建，过程如下图：/** * Start a new task

Hadoop MapReduce之任务启动（一）TaskTracker在启动好后会通过主线程不停发送心跳包，以报告自身状态，如果JobTracker有了新作业，会把相应的任务返回给TaskTracker，此时TT就会解析返回值，并解析为自身任务执行，框架流程比较简单，这里我们看下TT接收到返回值后到任务执行前所做的操作。TT接收的任务会通过新启动的JVM来执行，并不是由TT来执行的，这样也是为

一个作业运行时，在maptask阶段出现了如下错误：FATAL org.apache.hadoop.mapred.Child: Error running child : java.lang.OutOfMemoryError: Java heap space at org.apache.hadoop.io.Text.setCapacity(Text.java:240)

MR在初始化阶段会把任务创建好，待TT心跳时会把任务发送给TT，这里涉及到如何分配任务的问题，例如该节点是否适合分配任务、分配map还是reduce、还要保留多少事物槽用于推测执行，这些都要通过调度器的计算才能合理分配任务，在hadoop中这个调度器是一个单独的组件TaskScheduler，这是一个抽象类，继承这个类就可以实现自己的调度，hadoop默认的调度器是JobQueueTaskSche

在服务端提交一个job成功后，JobInitManager就会对其进行初始化操作，该线程是EagerTaskInitializationListener的一个内部类线程类，JT启动成功后，这个线程就存在了，他不停的检测jobInitQueue结构，一旦有新的作业提交成功，他就会构建一个作业初始化线程，丢入线程池中执行，这样设计也是为了消除并发较高的场景下作业初始化带来的瓶颈，在构建具体任务时，为了

前面我们介绍了作业的提交（客户端和服务端）、任务分解和调度、任务的启动，这些操作完成之后就是任务执行了，在hadoop中一个任务的执行是包含在一个单独的JVM中的，在任务启动阶段会生成一个shell（taskjvm.sh)，然后会通过ShellCommandExecutor类来执行这个脚本，底层通过ProcessBuiler来实现进程启动，那么在启动之后就是任务执行的部分，在执行时hadoop要了

客户端在提交一个作业的时候，会通过RPC调用服务端接口提交该作业，此时运行做的配置文件可jar文件已经上传到了HDFS中，服务端作业提交的过程中会创建该作业的实例JobInProgress,然后把该对象加入作业监控和初始化两个Listener中，另外还包含一些校验操作，比如所在队列是否在运行，内存配置是否超出限制等，重头戏是JobInProgress的创建，提交过程如下： public

前面讲到KV的输出，会先写入KV buffer，当buffer用完或达到一定比例的时候spillThread会将buffer中的数据写入磁盘，以便buffer重用，刷新过程并不是直接写入的，写入前会先进行一个排序操作，写入时会将一个partition的数据写在一起，并且会生成一个index文件作为标记文件。每次spill都会生成一个新的数据文件，数据文件和索引文件的结构图如下：     

在reduce端的文件拷贝阶段，会将数据放入内存或直接放入磁盘中，如果文件全部拷贝完再进行合并那样必然降低作业效率，所以在拷贝进行到一定阶段，数据的合并就开始了，负责该工作的有两个线程：InMemFSMergeThread和LocalFSMerger，分别针对内存和磁盘Segment的合并。首先看内存合并线程InMemFSMergeThread的run函数 public void run

上一篇讲了reduce如何把map输出下载到本地的过程，这个过程中包含了文件合并操作，本文主要讲reduce的下一个阶段：排序。reduce端的合并单位是Segment，在对Segment合并的过程中就已经实现排序了，大家如果对Oracle比较熟悉的话，这种合并排序的方式就容易理解了，对于两个排序好的数组，每次取其中的最小值，那么结果就是一个大的有序数组，这就是merge的基本原理，当然在Hado

本节分析ReduceTask的最后一个阶段：reduce，经历了copy、sort后，reduce的输入数据就准备好了，reduce数据输入由Reducer.Context提供，该Context封装了sort阶段的迭代器，可以对内存和磁盘的KV进行迭代，这部分需要注意两个大的循环：1、对KEY的循环由Reducer类实现，具体参考run函数 2、在自定义的reduce函数中对VALUE的循环。在自

     客户端构建好RDD的DAG以后，会提交至DAGScheduler来处理，这是一个Stage级别的调度器，他首先会把作业切分为一个个Stage，每个Stage由一组相同运算的tasks组成，然后会以taskset的形式提交给TaskScheduler。DS还会跟踪stage的输出与物化情况、检测task运行时的最优位置，重新提交失败的stage。    DAGSheduler接收到J...

YARN作业提交的客户端仍然使用RunJar类，和MR1一样，可参考 http://blog.youkuaiyun.com/lihm0_1/article/details/13629375在1.x中是向JobTracker提交，而在2.x中换成了ResourceManager，客户端的代理对象也有所变动，换成了YarnRunner，但大致流程和1类似，主要的流程集中在JobSubmitter.subm

在NM各服务初始化完毕之后，会进入启动阶段，该阶段的调用栈如下由于NM也是一个综合服务类，所以他会进入CompositeService的serviceStart循环启动各个服务，代码如下：protected void serviceStart() throws Exception { //获得服务列表 List services = getServices(); if (LO

reduce任务为获得map的输出要和TaskTracker 通信以获得map的完成情况，负责这个工作的是GetMapEventsThread。线程运行时会通过TT的代理调用TaskUmbilicalProtocol协议的getMapCompletionEvents来获得MapTaskCompletionEventsUpdate，该返回数据总包含了最新map任务的完成状态：SUCCEEDED FA

NM和RM类似，也是以服务的形式启动，但服务相对于RM来说少些，也经历服务初始化和服务启动两个阶段，NM继承自CompositeService。NM的服务初始化列表如下：NM的启动入口public static void main(String[] args) { //异常处理 Thread.setDefaultUncaughtExceptionHandler(new Yar

在RM的启动过程中有两个重要的步骤，1、服务初始化 2、启动服务。在初始化阶段会将RM中各个功能以服务的形式保存到RM的服务列表中（ArrayList）并执行初始化操作，RM中几乎所有的重要组件都是以服务的形式提供的，RM对服务做了抽象，方便统一管理。下面我们先看RM的服务初始化阶段做了哪些事情.

RM是个综合服务类，内部包含了多个服务，所有的服务被放在列表中，通过循环逐个启动，其他服务的列表如下：

RM接收到客户端作业提交请求时会通过RPC server做回应，其实客户端就是通过ApplicationClientProtocol的RPC客户端提交作业的，客户端的提交流程参见上篇文章，在提交阶段的代码中，首先会调用getNewApplication来获得一个GetNewApplicationResponse，该返回类中包含了APP的ApplicationId，调度器资源信息。需要注意的是在RM

Hadoop MapReduce之Join示例关于MR中的数据连接是在数据处理中经常遇到的问题，可以用一些上层框架来实现此功能，比如Hive、Pig等，这里用MR实现主要是为了理解连接的思路，MR中的连接可以在Reduce端做，也可以在Map端做，本例在Reduce端做，想了解更多连接的内容可以参考>5.2章节,需要连接的表数据如下用户订单表：UserID OrderID

reduce执行流程经历三个阶段：copy、sort、reduce，在第一阶段reduce任务会把map的输出拷贝至本地，通过线程MapOutputCopier，该线程通过http协议将map输出拷贝至本地，该copy操作可以并行进行，默认情况下有5个线程执行此操作，如果map数量较大时可以适当调大此值，拷贝时使用http协议，此时reducetask为client，map端以jetty作为web

前面我们分别讨论了reduce的三个阶段，copy、sort、reduce，都是分开解析的，其实这些功能都包含在一个函数中，而且阶段分明，通过下面的分析，会对reduce流程理解会更清晰。下面函数的入口是Child.main -> taskFinal.run(job, umbilical)public void run(JobConf job, final TaskUmbilicalProto

（为了简单起见，我们这里分析官方文档中使用的WordCount程序）  上一篇我们已经看到自己的map函数是如何被调用的，这是一个循环调用的过程，这里我们分析下，从KV读入到KV写出的过程，通常我们只要写map函数就可以了，但在一些特殊的情况下我们也可以覆盖run函数，来实现自己的执行流程。  这个例子中我们使用默认的InputFormat，在初始化的时候被初始化为TextInputFor

Hadoop MapReduce之jar文件上传   在提交作业时，我们经常会执行下面类似命令：hadoop jar wordcount.jar test.WordCount，然后等待作业完成，查看结果。在作业执行流程中客户端会把jar文件上传至HDFS内，然后由JT初始化作业，并发放给TT执行具体的任务，这里我们主要看客户端的操作，了解这些我们可以自定义更为方便的作业提交方式。hadoop是

offerService包含了DN主循环线程的核心功能，DN对其提供保护，如果该函数执行失败，则由DN线程sleep5秒后重新执行，在DN的线程体中，我们可以看到该逻辑。对于offerService中的部分功能，以前的文章里已经描述过，比如心跳、异步块报告，但都是单独描述，他们之间的协调可以通过offerService体现出来，例如执行先后顺序，执行间隔这里都有体现。 pub

该线程负责节点退役的检查，HDFS集群内的节点是不能随便退役的，因为DD退役会造成某些文件的副本数下降，所以在退役前会把这个节点上的block复制到其他节点，然后才能退役。这些检查由DecommissionManager的内部类Monitor来实现public void run() { for(; fsnamesystem.isRunning(); ) {

书接上回，继续讲解ReplicationMonitor,做完块复制后，开始进入processPendingReplications，很显然这个函数处理复制超时的块。至于为什么把超时块的监控放入另外一个线程来监控，我认为应该是为了防止复制监控线程任务过重。  /**   * 如果块的复制请求超时，则重新把它们放回needReplication队列   */ void process

该类是一个FSNameSystem内部类，负责清理无效块、维护副本数的一个线程，相对于前面提到的线程，这是个大块头，线程运行也是周期性的，主要由两个函数来实现，而这两个函数也是比较大的，我们分开讲。          computeDatanodeWork();          processPendingReplications();先看computeDatanodeWork()，

Namenode格式化后，会生成FSImage文件，位于dfs.name.dir参数指定目录的current目录中，记录了最初文件系统元数据的信息，随着系统运行，系统文件会越来越多，如果我们有一个要统计HDFS文件数的需求，通过shell或API来遍历都是比较麻烦的，HDFS经常跑离线数据处理，如果延时一段时间可以接受的话，我们可以通过直接解析FSIMAGE的方法来统计相关信息，这时统计的信息是来

租约管理是在客户端写文件时用到的一种机制，当客户端打文件进行写操作是要先申请租约，该租约由LeaseManager来管理，说通俗点，客户端写文件不能无时间限制的写，打开文件持续太长会影响其他用户的使用，这时就要有个机制来限制，在HDFS中采用的租约机制，看下一个lease的成员变量就明白了： private final String holder; //持有者，类似DFSClient_1

Nanode启动是会启动一个心跳检测线程HeartbeatMonitor，该线程会周期性的检测数据节点的状态，如果数据节点在指定时间内未发送心跳信号，则认为该节点已死，namenode会进行块复制以维护文件的副本数。 class HeartbeatMonitor implements Runnable { private long lastHeartbeatCheck; pr

PendingReplicationMonitor为PendingReplicationBlocks的内部类，先看PendingReplicationBlocks，主要记录被复制的块，周期性的检测块复制请求，主要维护以下几个变量： private Map pendingReplications; private ArrayList timedOutItems; Daemon time

Namenode启动过程中，在FSImage载入后，会对FSImage和edits重置，相当于创建一组新的镜像文件和日志文件，但前提是前面的载入都已经成功了，这个操作紧跟fsImage.recoverTransitionRead之后，具体调用流程如下：Namenode.main ->NameNode.createNameNode -> NameNode.initialize -> FSName

Namenode在启动时，有个重要步骤就是载入fsimage文件，下面分析下这个流程NameNode.main-> NameNode(conf) -> NameNode.initialize(conf)-> FSNamesystem(this,conf) -> FSNamesystem.initialize(nn, conf)->FSNamesystem.dir.loadFSIma

上一篇分析了启动过程中，载入FSImage之前的一系列校验，这次开始看下FSImage真正的载入部分，在这里可以看到对该文件读操作，通过这些操作可以知道该文件的结构，以及内存中的结构，个人觉得HDFS出于安全、恢复方面的考虑，在启动过程中做了相当的校验，但就单纯读取该文件来说，流程还是比较好理解的，如果熟悉JAVA的文件读写的话，这个函数喽一眼就知道个大概了。有一点需要注意，比如我们在集群中有这样

Namenode格式化是由NameNode FSImage Configuration三个类共同作用完成的，在执行格式化前由Configuration和Namenode两个类载入相应的配置文件，在静态代码段完成。NameNode.javastatic{    Configuration.addDefaultResource("hdfs-default.xml");    Confi