大数据入门(四) - 分布式资源调度——YARN框架
1 YARN产生背景
YARN是Hadoop2.x才有的，所以在介绍YARN之前，我们先看一下MapReduce1.x时所存在的问题：
- 单点故障
- 节点压力大
- 不易扩展
1.1 MapReduce1.x时的架构
可以看到，1.x时,即 Master/Slave 主从结构，在集群上的表现就是一个JobTracker带多个TaskTracker
- JobTracker
负责资源管理和作业调度 - TaskTracker
- 定期向JobTracker汇报本节点的健康状况、资源使用情况以及作业执行情况
- 接收来自JobTracker的命令，例如启动任务或结束任务等。
1.2 该架构存在的问题
- 整个集群中只有一个
JobTracker，就代表着会存在单点故障的情况 -
JobTracker节点的压力很大，不仅要接收来自客户端的请求，还要接收大量TaskTracker节点的请求 - 由于
JobTracker是单节点，所以容易成为集群中的瓶颈，而且也不易域扩展 -
JobTracker承载的职责过多，基本整个集群中的事情都是JobTracker来管理 - 1.x版本的整个集群只支持
MapReduce作业，其他例如Spark的作业就不支持了
由于1.x版本不支持其他框架的作业，所以导致我们需要根据不同的框架去搭建多个集群。这样就会导致资源利用率比较低以及运维成本过高，因为多个集群会导致服务环境比较复杂
在上图中我们可以看到，不同的框架不仅需要搭建不同的集群
而且这些集群很多时候并不是总是在工作，如上图可以看到，Hadoop集群在忙的时候Spark就比较闲，Spark集群比较忙的时候Hadoop集群就比较闲，而MPI集群则是整体并不是很忙
这样就无法高效的利用资源，因为这些不同的集群无法互相使用资源
除此之外，我们还得运维这些个不同的集群，而且文件系统是无法共享的
如果当需要将Hadoop集群上的HDFS里存储的数据传输到Spark集群上进行计算时，还会耗费相当大的网络IO流量
所以我们就想着要把这些集群都合并在一起，让这些不同的框架能够运行在同一个集群上，这样就能解决这各种各样的问题了.如下
正是因为在1.x中，有各种各样的问题，才使得YARN得以诞生，而YARN就可以令这些不同的框架运行在同一个集群上，并为它们调度资源。我们来看看Hadoop2.x的架构图：
在上图中，我们可以看到，集群最底层的是HDFS，在其之上的就是YARN层，而在YARN层上则是各种不同的计算框架。所以不同计算框架可以共享同一个HDFS集群上的数据，享受整体的资源调度，进而提高集群资源的利用率，这也就是所谓的 xxx on YARN
2 YARN 架构
YARN概述：
YARN是资源调度框架
通用的资源管理系统
为上层应用提供统一的资源管理和调度
3 YARN 执行流程
1.client向yarn提交job，首先找ResourceManager分配资源，
2.ResourceManager开启一个Container,在Container中运行一个Application manager
3.Application manager找一台nodemanager启动Application master，计算任务所需的计算
4.Application master向Application manager（Yarn）申请运行任务所需的资源
5.Resource scheduler将资源封装发给Application master
6.Application master将获取到的资源分配给各个nodemanager
7.各个nodemanager得到任务和资源开始执行map task
8.map task执行结束后，开始执行reduce task
9.map task和 reduce task将执行结果反馈给Application master
10.Application master将任务执行的结果反馈pplication manager。
4 YARN 环境搭建
5 提交 PI 的 MapReduce 作业到 TARN 上执行
