Hadoop2.x的yarn

hadoop mapreduce 1.x中的问题

原理

在1.x中主要使用的是JobTracker和TaskTracker这两个组件管理系统中的资源

step1：客户端提交任务
step2：JobTracker从namenode获取输入文件的数据块的列表信息
step3：JobTracker会根据第二步中获取到的数据块的列表信息将任务提交到离数据块尽可能近的位置上运行
step4：TaskTracker跟踪监控该节点上的任务的运行情况
step5：TaskTracker隔一段时间将运行的信息发送到JobTracker（包括task的运行状态和本节点上的资源的使用情况），如果JobTracker在一定时间内没有收到来自于TaskTracker的信息，那么就认为分配在这个上面的任务失败了，就会将任务分配到另一个节点上去运行。一旦所有的任务都成功了，JobTracker就会更新作业状态为成功，如果任务反复失败达到一定的数量，那么JobTracker就会宣布任务失败

除此以外，客户端也会轮询JobTracker用来获取Job的运行情况

问题

1. 在图中我们能发现，JobTracker过于繁重，其需要进行task的调度，还需要实施监控着各个节点上的资源信息，为下一个任务分配好准备。这就造成了JobTracker容易出现故障
2. JobTracker存在单点故障
3. 使用这种方式只支持mapreduce只一种计算模型，不能支持比如map，reduce，reduce这种运算模型，需要改变JobTracker

hadoop mr2中引入yarn

yarn中的主要组件：

1. ResourceManager（全局只有一个）
   处理客户端的请求
   启动ApplicationMaster，并负责对他的监控
   管理和分配集群上的所有的资源（这里涉及到对nodemanager的监控）
2. ApplicationMaster（每一个应用都会有一个）
   向ResourceManager请求资源，包含的要求有对容器的要求，CPU数量和内存大小
   监控任务的执行情况
3. NodeManager
   接收ResourceManager的请求，为作业分配Container
   向RM汇报自己节点的资源信息
   管理自己运行的Container

mr程序使用yarn的运行机制

step1：Client提交任务到ResourceManager
step2：ResourceManager接收到作业后，根据其的一些调度策略（因为RM可能不止接收了一个作业）调度作业，在一个节点上获取一个运行ApplicationManager实例的Container
step3：AM启动后，向RM注册，客户端就可以通过RM查询AM的详细信息了
step4：AM对任务进行相应的分析后，向RM申请用于执行task（map或者reduce）的Container
step5：RM将分配好的信息(包括容器所在的节点和容器所持有的CPU的数量和内存的大小)告知AM，AM去寻找相应的NodeManager
step6：NodeManager分配Container
step7：每个任务向AM汇报执行进度

与mr1.x的比较

1. JobTracker的任务被分成了两个部分，分别由ResourceManager进行资源的分配和ApplicationMaster管理监控task的运行
2. yarn支持多种计算模型，只要实现相应的ApplicationMaster即可

yarn的容错机制

1. ResourceManager
   使用Zookeeper的实现HA
2. NodeManager
   失败后，RM将失败任务告诉对应的AM；
   AM决定如何处理失败的任务。
3. ApplicationMaster
   失败后，由RM负责重启；
   AM需处理内部任务的容错问题；
   RMAppMaster会保存已经运行完成的Task，重启后无需重新运行。