一、第一代hadoop组成与结构

第一代Hadoop，由分布式存储系统HDFS和分布式计算框架MapReduce组成，其中，HDFS由一个NameNode和多个DataNode组成，MapReduce由一个JobTracker和多个TaskTracker组成，对应Hadoop版本为Hadoop 1.x和0.21.X，0.22.x。  

1、MapReduce角色分配

Client ：作业提交发起者。

JobTracker: 初始化作业，分配作业，与TaskTracker通信，协调整个作业。

TaskTracker：保持JobTracker通信，在分配的数据片段上执行MapReduce任务。

2、MapReduce执行流程

（1）提交作业

在作业提交之前，需要对作业进行配置

程序代码，主要是自己书写的MapReduce程序。

输入输出路径

其他配置，如输出压缩等。

配置完成后，通过JobClinet来提交

（2）作业的初始化

客户端提交完成后，JobTracker会将作业加入队列，然后进行调度，默认的调度方法是FIFO调试方式。

（3）任务的分配

TaskTracker和JobTracker之间的通信与任务的分配是通过心跳机制完成的。

TaskTracker会主动向JobTracker询问是否有作业要做，如果自己可以做，那么就会申请到作业任务，这个任务可以使Map也可能是Reduce任务。

（4）任务的执行

申请到任务后，TaskTracker会做如下事情：

拷贝代码到本地

拷贝任务的信息到本地

启动JVM运行任务

（5）状态与任务的更新

任务在运行过程中，首先会将自己的状态汇报给TaskTracker，然后由TaskTracker汇总告之JobTracker。

任务进度是通过计数器来实现的。

（6）作业的完成

JobTracker是在接受到最后一个任务运行完成后，才会将任务标志为成功。

此时会做删除中间结果等善后处理工作。

二、第二代hadoop组成与结构

第二代Hadoop，为克服Hadoop 1.0中HDFS和MapReduce存在的各种问题而提出的。针对Hadoop 1.0中的单NameNode制约HDFS的扩展性问题，提出了HDFS Federation，它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展；针对Hadoop 1.0中的MapReduce在扩展性和多框架支持方面的不足，提出了全新的资源管理框架YARN(Yet Another Resource Negotiator)，它将JobTracker中的资源管理和作业控制功能分开，分别由组件ResourceManager和ApplicationMaster实现，其中，ResourceManager负责所有应用程序的资源分配，而ApplicationMaster仅负责管理一个应用程序。对应Hadoop版本为Hadoop 0.23.x和2.x。

1、 yarn运行架构

YARN 是下一代Hadoop计算平台，如下所示：

在 YARN 架构中，一个全局ResourceManager 以主要后台进程的形式运行，它通常在一台独立机器上运行，在各种竞争的应用程序之间仲裁可用的集群资源。

ResourceManager会追踪集群中有多少可用的活动节点和资源，协调用户提交的哪些应用程序应该在何时获取这些资源。ResourceManager是惟一拥有此信息的进程，所以它可通过某种共享的、安全的、多租户的方式制定分配（或者调度）决策（例如，依据应用程序优先级、队列容量、ACLs、数据位置等）。

在用户提交一个应用程序时，一个称为ApplicationMaster的轻量型进程实例会启动来协调应用程序内的所有任务的执行。这包括监视任务，重新启动失败的任务，推测性地运行缓慢的任务，以及计算应用程序计数器值的总和。这些职责以前是分配给单个 JobTracker来完成的。ApplicationMaster和属于它的应用程序的任务，在受NodeManager控制的资源容器中运行。

NodeManager是TaskTracker的一种更加普通和高效的版本。没有固定数量的 map 和 reduce slots，NodeManager 拥有许多动态创建的资源容器。容器的大小取决于它所包含的资源量，比如内存、CPU、磁盘和网络 IO。目前，仅支持内存和 CPU (YARN-3)。一个节点上的容器数量，由节点资源总量（比如总CPU数和总内存）共同决定。

需要说明的是：ApplicationMaster可在容器内运行任何类型的任务。例如，MapReduce ApplicationMaster请求一个容器来启动map或reduce 任务，而 Giraph ApplicationMaster请求一个容器来运行Giraph任务。

我们还可以实现一个自定义的 ApplicationMaster 来运行特定的任务，进而发明出一种全新的分布式应用程序框架，改变大数据格局。

在YARN中，MapReduce降级为一个分布式应用程序的一个角色（但仍是一个非常流行且有用的角色），现在称为 MRv2。MRv2 是经典MapReduce引擎（称为 MRv1）的重现，运行在YARN之上。

2、YARN可运行任何分布式应用程序

ResourceManager、NodeManager 和容器都不关心应用程序或任务的类型。所有特定于应用程序框架的代码都会转移到ApplicationMaster，以便任何分布式框架都可以受 YARN 支持。

得益于这个一般性的方法，Hadoop YARN集群可以运行许多不同分布式计算模型，例如：MapReduce、Giraph、Storm、Spark、Tez/Impala、MPI等。

3、YARN中提交应用程序

下面讨论在应用程序提交到YARN集群时，ResourceManager、ApplicationMaster、NodeManagers和容器如何相互交互。下图显示了一个例子。

假设用户采用与MRv1中相同的方式键入hadoop jar命令，将应用程序提交到 ResourceManager。ResourceManager维护在集群上运行的应用程序列表，以及每个活动的 NodeManager上的可用资源列表。

ResourceManager 需要确定哪个应用程序接下来应该获得一部分集群资源。该决策受到许多限制，比如队列容量、ACL 和公平性。ResourceManager 使用一个可插拔的 Scheduler。Scheduler 仅执行调度；它管理谁在何时获取集群资源（以容器的形式），但不会对应用程序内的任务执行任何监视，所以它不会尝试重新启动失败的任务。

在 ResourceManager接受一个新应用程序提交时，Scheduler制定的第一个决策是选择将用来运行ApplicationMaster的容器。在 ApplicationMaster启动后，它将负责此应用程序的整个生命周期。首先也是最重要的是，它将资源请求发送到 ResourceManager，请求运行应用程序的任务所需的容器。

资源请求是对一些容器的请求，用以满足一些资源需求，比如：

• 一定量的资源，目前使用MB内存和CPU份额来表示

• 一个首选的位置，由主机名、机架名称指定

• 此应用程序中的一个优先级，而不是跨多个应用程序

如果可能的话，ResourceManager 会分配一个满足ApplicationMaster在资源请求中所请求的容器（表达为容器 ID和主机名）。该容器允许应用程序使用特定主机上给定的资源量。分配一个容器后，ApplicationMaster会要求NodeManager（管理分配容器的主机）使用这些资源来启动一个特定于应用程序的任务。此任务可以是在任何框架中编写的任何进程（比如一个 MapReduce 任务或一个Giraph任务）。

NodeManager 不会监视任务；它仅监视容器中的资源使用情况，例如，如果一个容器消耗的内存比最初分配的更多，它会结束该容器。

ApplicationMaster会竭尽全力协调容器，启动所有需要的任务来完成它的应用程序。它还监视应用程序及其任务的进度，在新请求的容器中重新启动失败的任务，以及向提交应用程序的客户端报告进度。

应用程序完成后，ApplicationMaster 会关闭自己并释放自己的容器。

尽管ResourceManager不会对应用程序内的任务执行任何监视，但它会检查 ApplicationMaster的健康状况。如果 ApplicationMaster失败，ResourceManager 可在一个新容器中重新启动它。我们可以认为ResourceManager负责管理ApplicationMaster，而 ApplicationMasters负责管理任务。

本文出自 “爱维Linux” 博客，请务必保留此出处http://ixdba.blog.51cto.com/2895551/1870189

分布式计算 MapReduce与yarn工作机制