xhh198781的专栏

在前面的文章中，我详细的介绍了Job的任务分解以及Job任务的调度，同时也讲述了TaskTracker是每一通过向JobTracker发送心跳包heartbeat并从其响应中获取自己被分配的任务的。那么，在TaskTracker中，它是如何来执行这些Task的呢，或者说为这个Task的执行做了哪些准备工作呢？    其实，在一个TaskTracker节点中，每一Task的执行并不是在当前这个T

上一篇博文讲了JobTracker节点会在内存中缓存一部分已完成Jobs状态信息，其实JobTracker节点还可以持久化地保存这些已完成Jobs信息，即将每一个Job的状态信息保存在一个单独的文件中，这个文件可以属于本地文件系统，也可以属于分布式文件系统，如：HDFS。所以，JobTracker节点设计了一个组件——CompleteJobStatusStore，来负责读/写和管理这些作业状态文件

1. 概述       在传统数据库（如：MYSQL）中，JOIN操作是非常常见且非常耗时的。而在HADOOP中进行JOIN操作，同样常见且耗时，由于Hadoop的独特设计思想，当进行JOIN操作时，有一些特殊的技巧。本文首先介绍了Hadoop上通常的JOIN实现方法，然后给出了几种针对不同输入数据集的优化方法。    2. 常见的join方法介绍      假设要进行join的数据分

使用过Hadoop的MapReduce API的人大概都知道在我们配置好作业之后，就可以向JobTracker提交该作业了，然后JobTracker才能安排适当的TaskTracker来完成该作业。那么MapReduce在这个过程中到底做了那些事情呢？这就是本文以及接下来的一片博文将要讨论的问题，当然本文主要是围绕客户端在作业的提交过程中的工作来展开。先从全局来把握这个过程吧！

在前一篇文章中，我从客户端详细的讲解了Hadoop对Map执行框架的实现，即客户端可以自己定义或实现给map操作输入怎样的key-value值、map操作、如何根据map输出的key进行排序、如何对map输出的key-value集合进行合并等。用户在提交作业之前对它进行这些进行相应的配置即可。那么，TaskTracker在真正执行作业的任务时是如何根据用户的设置信息来把Map任务相关操作组合成一个

上一篇博文主要讲到了JobTracker节点的后台线程ExpireTrackers，其中谈到了TaskTracker节点要向JobTracker节点定时地发送心跳包，来报告它当前的状态信息(TaskTracker的第一个心跳包同时起到了向JobTracker注册的作用)，而JobTracker对TaskTracker发送过来的心跳包的响应主要内容是分配给该TaskTracker的任务，也就是Tas

客户端用户在向JobTracker节点成功地提交了一个Job之后，JobTracker节点并不会马上对这个作业进行调度，因为任何作业在被任务调度器TaskSchedule调度之前，都必须先被初始化，这一点笔者曾经在讲解Hadoop的默认调度器——JobQueueTaskSchedule时已经详细地谈到过了。而本文将要集中讨论的是Job是如何被初始化的，同时，Job的初始化又干了哪些事情。

在前面的一篇博文中，笔者详细的介绍了JobInProgress是如何给一个TaskTracker节点分配一个Map/Reduce任务的，但在讲述的过程中忽略了一个重要的细节，因为这个细节不是该博文所要讲述的重点，这个细节就是，JobInProgress在正式为TaskTracker节点分配一个任务之前，它都会先检查自己是否应该给该计算节点分配自己的计算任务。当这个计算节点满足要求时，JobInPr

客户端用户在成功提交Job之后，该Job并不会马上被JobTracker节点调度执行，因为这个Job还没有被初始化，至于JobTracker节点是如何初始化Job的，我在前面已经详细的谈到过。当一个提交的Job在被初始化之后，就可以正式地被JobTracker节点调度执行了，不过，JobTracker节点不会就此开始调度Job的Map/Reduce任务，而是调用该Job的SetupTask。因此，

基于目前Hadoop的实现，在很多时候大家都会诟病于它的NameNode/JobTracker单点故障问题，特别是NameNode节点，一旦它发生了不可恢复的故障之后就意味着整个HDFS文件系统不在可用了。对于NameNode节点的单点故障问题，Hadoop目前采取的解决办法是冷备份，就是在HDFS集群中另外开启一个SecondaryNameNode节点，这个节点会定期地对NameNode节点上的

在上一篇博文中，我着重谈到了客户端的JobClient对一个作业的提交所做的工作，那么在本文，我就要好好的谈一谈JobTracker为作业的提交到底干了那些个事情——一.为作业生成一个Job；二.接受该作业。      通过上一篇博文，我们都知道，客户端的JobClient把作业的所有相关信息都保存到了JobTracker的系统目录下(当然是HDFS了)，这样做的一个最大的好处就是客户端干了它

Hadoop平台的最大优势就是充分地利用了廉价的PC机，这也就使得集群中的工作节点存在一个重要的问题——节点所在的PC机内存资源有限(这里所说的工作节点指的是TaskTracker节点)，执行任务时常常出现内存不够的情况，如：堆溢出错误；同时，该PC机也可能部署了其它集群的工作节点。针对这个问题，Hadoop专门在TaskTracker节点内部设计了一个后台线程——任务内存管理器(TaskMemo

在前面的博文JobTracker任务调度器之JobQueueTaskScheduler中，我讲述Job任务调度的时候简单地讲述了一下Job任务的分解，也就是将一个作业Job切分为一个个相对独立的map任务，以及后面的reduce任务。那么，Hadoop的Mapreduce，确切的说是JobTracker是如何来分解作业Job的呢？当然，在JobTracker中并不把这个动作叫做作业分解，而是叫做“

在Hadoop的集群中，所有的TaskTracker在启动之后都会向Master节点JobTracker进行注册，通过TaskTracker的注册，JobTracker节点就知道集群中那些Slave节点可用，即可以给它们分配任务了。但是有时候某些TaskTracker节点会出现意外宕机的情况，而JobTracker节点也必须能及时的捕捉到该TaskTracker节点已经实现，然后不再给该节点分配任

在客户端把作业提交给JobTracker节点之后，JobTracker节点就可以使用任务调度器TaskScheduler将这个Job的任务分配给那些合适的TaskTracker节点来执行。当然在JobTracker调度该Job之前，必须要确保该Job的JobInProgress被初始化了，即将Job划分为若干个map任务和reduce任务。在JobTracker中有一个基于优先级的FIFO任务调度

一. MapFile文件   前面说过，SequenceFile文件是用来存储key-value数据的，但它并不保证这些存储的key-value是有序的，而MapFile文件则可以看做是存储有序key-value的SequenceFile文件。MapFile文件保证key-value的有序(基于key)是通过每一次写入key-value时的检查机制，这种检查机制其实很简单，就是保证当前正要写入

众所周知，JobTracker节点使用配置的任务调度器TaskScheduler来为某一个具体的TaskTracker节点分配任务，同时这个任务调度器只能决定给该TaskTracker节点分配哪一个Job或者那些Job的任务以及分配多少个任务，但是它却不能决定给当前的TaskTracker节点分配一个Job的具体的哪一个任务。另外，针对一个具体的TaskTracker节点而言，任何一个作业都可以判

Hadoop中有一个默认的基于优先级的FIFO任务调度器JobQueueTaskScheduler，它的主要缺点就是对于在集群比较繁忙的情况，低优先级的作业将很难分配到集群的计算资源，这样对于那些低优先级同时又要求一定的响应时间的短作业来说是非常不利的。值得庆幸的是，Hadoop对作业的任务调度设计地相当灵活，即在它的任务调度器配置上开放了一个接口来允许用户根据自己的应用场景自定义一个合适的任务调

FairScheduler是由Facebook公司提出的，为了解决Facebook要处理生产型作业(数据分析、Hive)、大型批处理作业(数据挖掘、机器学习)、小型交互作业(Hive查询)的问题。同时满足不同用户提交的作业在计算时间、存储空间、数据流量和响应时间都有不同需求的情况下，使用Hadoop mapreduce框架能够应对多种类型作业并行执行，使得用户具有良好的体验，所以Facebook提

在Hadoop中为了方便集群中各个组件之间的通信，它采用了RPC，当然为了提高组件之间的通信效率以及考虑到组件自身的负载等情况，Hadoop在其内部实现了一个基于IPC模型的RPC。关于这个RPC组件的整体情况我已绍经在前面的博文中介绍过了。而在本文，我将结合源代码详细地介绍它在客户端的实现。    先来看看与RPC客户端相关联的一些类吧！1.Client类priv

Hadoop被设计用来处理海量数据，这种数据可以是结构化的，半结构化的，甚至是一些无结构化的文本数据(这些数据可能存储在HDFS文件中，也可能存放在DB中)。它处理数据的核心就是map-reduce模型，但是，无论是map还是reduce，它们的输入输出数据都是key-value对的形式，这种key-value对的形式我们可以看做是结构化的数据。同时，对于reduce的输入，当然就是map的输出，

SequenceFile文件是Hadoop用来存储二进制形式的key-value对而设计的一种平面文件(Flat File)。目前，也有不少人在该文件的基础之上提出了一些HDFS中小文件存储的解决方案，他们的基本思路就是将小文件进行合并成一个大文件，同时对这些小文件的位置信息构建索引。不过，这类解决方案还涉及到Hadoop的另一种文件格式——MapFile文件。SequenceFile文件并不保证

在前面的博文：TaskTracker节点的内部设计与实现中，我曾详细的概述了TaskTracker节点中的各个工作组件，而在本文，我将对其内部的Http服务组件展开详细的讨论。     TaskTracker节点的内部Http服务组件主要提供两个功能：1)./logtask，获取某一个Task的执行日志；2)./mapOutput，获取某一个Task的map输出数据。对于用户来说，Http

众所周知，Hadoop采用master-slave的架构设计来实现Map-Reduce框架，它的JobTracker节点作为主控节点来管理和调度用户提交的作业，TaskTracker节点作为工作节点来负责执行JobTracker节点分配的Map/Reduce任务。整个集群由一个JobTracker节点和若干个TaskTracker节点组成，当然，JobTracker节点也负责对TaskTracke

JobTracker节点在给每一个TaskTracker节点分配作业的Map/Reduce任务时，可能会根据该TaskTracker节点的实际情况分配多个Map任务，但确顶多只分配一个Reduce任务，尽管此时该TaskTracker节点还有多的Reduce Slot(也就是说TaskTracker节点每一个任务分配请求最多会得到一个Reduce类型的任务)。当然，只有当一个作业的Map任务成功完

在前面介绍Hadoop的Reduce任务执行框架的时候说过，作业的每一个Map任务被执行完之后，它们的输出结果均保存在各自执行节点的本地磁盘上，当reduce任务执行的时候，它需要自己去到所有的Map节点上取回属于自己的map输出，直到属于自己的所有map输出copy到本地，reduce任务才开始接下来的工作。那么，Reduce是如何从Map节点取回自己的输入数据呢？这就是本文即将要详细讲述的内容

在前面的一系列文章中我主要围绕Hadoop对Map任务执行框架的设计与实现展开了详细的讨论，记得在博文Hadoop中Map任务的执行框架中说过还要为大家详细地描述Hadoop对Reduce任务执行框架的设计，那么在本文，我将兑现这个承诺。     其实，Hadoop中Reduce任务执行框架跟它的Map任务执行框架大致是很相似的，唯一的不同之处就是他们的数据输入来源、数据输出目的地不一样而已。

在前面的一片博文中，我重点讲述了Task被TaskTracker调度执行的原理及过程，但是在详细的介绍执行Task的过程细节之前，我想先来认真的讨论一下Map Task和Reduce Task的执行框架。当然本文主要集中在Map Task上，至于Reduce Task的相关内容，我会在下一篇博文中谈到。在这篇文章中，我将尽量给出一个最抽象的Map模型     在Hadoop的MapRduce中

目前，海量数据处理主要存在二个问题：大规模计算(cpu+mem)、海量数据存储(disk)，而Hadoop被专门设计用来针对海量数据的处理，它通过分布式文件系统解决海量数据的存储问题，组织成千上万个计算节点来共同完成一个任务解决了大规模计算问题。Hadoop的核心是MapReduce，而不是分布式文件系统HDFS，这是因为MapRduce所依赖的存储系统并不依赖于任何一个文件系统，甚至是分布式文件

在前面的博文中，我介绍了Job的调度以及Job的任务分解，但对于Job的调度我只是从宏观的角度作了详细的说明，而关于JobInProgress具体是如何给TaskTracker分配本地Map Task和非本地MapTask的，将是本文将要讲解的重点。      先来看看JobInProgress是如何定义本地Map Task的。在前面的博文：Job的任务分解中，我自己给出了一个关于“预分配ma

在前一篇博文：Hadoop中Map任务的执行框架中，我花了大力气把Map任务在TaskTracker节点上的具体执行过程抽象出了框架，这个框架主要涉及到这些组件：map任务执行器Mapper、map任务执行上下文环境Context、任务报告器TaskReporter，而实际上，Context由两个子组件构成：记录读取器RecordReader、记录写入器RecordWriter。所以我将在接下来一

1. 目的本文描述了hadoop中的公平调度的实现算法，公平调度器是由facebook贡献的，适合于多用户共享集群的环境的调度器，其吞吐率高于FIFO，论文参见参考资料[1]。本文分析的Hadoop版本是0.20.2，在新版本（0.21.0）中，公平调度算法已经有了改进与增强。本文组织结构如下：1）目的    2）公平调度介绍  3）公平调度算法分析 4）新版hadoop中公平调度器的新特性

在JobTracker中，有这样的一个属性queueManager，它的类型是org.apache.hadoop.mapred.QueueManager，那么它被JobTracker用来干啥的呢？在上一篇博文中，我们已经大概知道了，JobTracker使用QueueManager来验证一个用户对Job是否具有某些操作权限，如提交等。所以在本文，我将集中讨论QueueManager类。   先来

很多朋友在刚开始学习Hadoop的时候，都会以类似于下面的一个例子来开始自己的hadoop学习之旅：public class MyHadoopCounter {  public static class MyHadoopMapper extends Mapper {    @Override  protected void map(LongWritable key, Tex

在前一篇博文中，我已经详细的讲解了Hadoop RPC中客户端通信组件的实现，与之对应的就会有一套服务器端通信组件的实现。Hadoop RPC的服务器端采用了多线程的设计，即服务器会开启多个处理器(后天线程)来处理所有客户端发送过来的RPC调用请求，所以在服务器端主要包括三个组件：监听器(Listener)、处理器(多个Handler)、响应发送器(Responder)。接下来我将主要围绕这三大组

Hadoop作为一个存储与服务的基础性平台，同时它的内部有采用了master/slave架构，那么其内部通信和与客户端的交互就是必不可少的了。Hadoop在实现时抛弃了JDK自带的一个RPC实现——RMI，而自己基于IPC模型实现了一个高效的轻量级RPC。整体结构    在IPC包中，最重要的3个类是ServerC，lient和RPC，它们具有层次化的结构。   1.RPC

任何一个作业在Hadoop集群中执行主要包括四个阶段：setup、map、reduce、cleanup，但在这四个阶段都出现任务实例在TaskTracker节点执行失败的情况。当一个任务实例在TaskTracker节点的JVM中执行时除了成功执行意外，还有可能出现一些异常情况：1).在JVM中执行失败；2).JVM进程被操作系统stop；3).任务实例被JobTracker节点要求kill；这些异

JobTracker节点给TaskTracker节点分配作业任务时是有优先级顺序的，JobTracker节点总是优先分配一个作业的辅助任务，然后在分配作业的正式任务。其中，作业的辅助任务包括：JobSetup、JobCleanup、TaskCleanup三种类型的任务，正式任务包括：Map、Reduce两种任务。当JobTracker节点为一个TaskTracker节点分配了辅助任务的时候就不会为

前面谈到过，每一个TaskTracker节点都要在它向JobTracker节点发送心跳包的时候顺带报告运行在其上的Task的状态信息，这些Task是指正在TaskTracker节点上运行的，或者从上一次报告到现在的时间间隔中完成的或者是失败的任务。JobTracker节点之所以需要收集这些正在执行或者刚完成的任务的状态信息，是因为它要及时掌握各个作业的执行进度，一方面将此报告给用户，一方面还调整作

在前面的一系列文章中我不断的提到了记录写入器RecordWriter，它是一个抽象类，在map任务执行中的根本作用就是向某个文件系统的文件中写入map任务的输出结果——key-value集。所以，本文将主要讨论MapTask对记录写入器RecordWriter的一个具体实现类——NewOutputCollector，来好好的看看这个NewOutputCollector对map任务的输出key-va