Hadoop——JobTracker和TaskTracker，以及如何演变成Yarn架构详解编程语言

MapReduce计算框架是如何实现计算向数据移动的呢？

计算向数据移动面临着诸多问题，如：怎么让机器自动移动，面对block的许多副本，怎么判别移动到的是最合适的Datanode

这个问题牵扯到两个概念：资源管理，任务调度

资源管理：掌握各机器当前可用内存，可用CPU等情况
任务调度：根据可用资源，进行计算任务的分配（也就是向哪个Datanode移动）

MapReduce想要完成资源管理和任务调度，需要引进两个新的角色：JobTracker和TaskTracker

JobTracker：负责资源管理，任务调度
TaskTracker：管理被分到Datandoe的计算任务，资源汇报（TaskTracker与JobTracker之间维持心跳，实时汇报当前Datanode资源所剩情况）

JobTracker与TaskTracker之间也是主从结构。

然而推动计算向数据移动的角色是client

下面具体阐述client到底做了什么

1. 根据每次需要计算的数据，咨询NN元数据，得到block信息，算出所需的split数，得到一个split清单，这样map的并行度就得到了。且由于咨询过了元数据，所以得到的split清单还带有block location信息，这样就知道各split的map应该移动到哪些Datanode了。
2. 生成计算程序未来运行时需要的配置文件(xml)
3. 移动过程应是可靠安全的，所以client会将计算程序上传到HDFS（这就是移动过程），未来TaskTracker只需要去HDFS下载就行
4. 调用JobTracker，通知JobTracker需要启动计算了，并告诉JobTracker计算程序放在了HDFS的哪些地方

用大白话说就是：计算向数据移动 -> 那么哪些节点可以移动（需要对整体资源有把控，需要资源管理） -> 确定了节点后怎么通知对方（任务调度）

然而JobTracker还存在三个问题，这也是Hadoop非HA模式遇到的问题

JobTracker是单点的，必存在单点故障问题，存在压力过大问题，且因为JobTracker集成了资源管理和任务调度，所以未来若有新的非MapReduce计算框架，则不能复用资源管理，故而必将各自实现自己的资源管理，但又因为它们部署在同一批硬件上，所以肯定会造成资源争抢。

上述JobTracker为Hadoop 1.x 采用的方案，后面为解决该问题，放弃了这种资源调度方案，在Hadoop 2.x 中引入了全新的资源调度方案，也就是Yarn

Yarn就是把资源管理和任务调度分开，也就是解耦了JobTracker的功能

Yarn与MapReduce无关，Yarn是独立的资源层，除了支持MapReduce计算框架，还支持Spark等其他计算模型。

下面是从官方摘过来的Yarn的架构图

• 黄色框代表了一个节点，可以看出Yarn也是主从架构的
• Yarn取消了JobTracker和TaskTracker，将资源管理放在了Resource Manager，将任务调度放在了Application Master，图中Container代表资源

下面具体阐述一下图中的流程：

1. Client首先完成上文1.x方案中阐述的1.2.3.步
2. Client通知Resource Manager（RM），RM挑一个不繁忙的节点通知对应的Node Manager（NM）启动一个Application Manager（AM），AM去HDFS下载split清单，反向从RM申请生成Container
3. RM根据自己掌握的资源情况，找到合适的节点通知NM启动一批Container（注意Container由NM启动，NM与RM之间保持心跳）。Container在逻辑上是一个对象，里面定义了未来在这个节点中要消耗多少内存，多少CPU等属性；物理上是一个进程，占用定义好的内存等资源
4. Container启动之后会反向注册回AM，这时AM才知道在集群中有多少资源，也就是有多少Container供自己调度
5. AM将需要下载xml和计算程序的消息发给各Container，各Container自行去HDFS下载，最后执行

总结：RM用于调配资源，与NM保持联系，NM负责启动AM和Container（AM本质上也是一个Container），最终计算任务由AM调度给Container，Container自行下载执行

RM ————资源管理； NM————Container启动器；AM————任务调度；Container————任务执行者

Yarn的方案成功将JobTracker解耦，不发生资源争抢，即使有一组AM与Container挂了，也不妨碍其他组AM和Container运行。由于有多个AM了，也不会出现单点故障和压力过大的问题。

Yarn架构有完善的消息通信，AM与Container挂机，RM都会重新调度，让NM重启

同样RM也存在单点故障问题，所以Yarn也有对应的HA模式解决该问题，Yarn的主备切换同样由Zookeeper协调

我将在下一篇博客中介绍如何搭建Yarn，实现MapReduce On Yarn