这是我参与11月更文挑战的第10天，活动详情查看：2021最后一次更文挑战」
hadoop1.x的体现
- 根据每次需要计算的数据，咨询NN元数据，得到block信息，算出所需的split数，得到一个split清单，这样map的并行度就得到了。且由于咨询过了元数据，所以得到的split清单还带有
block location信息，这样就知道各split的map应该移动到哪些DataNode了。 - 生成计算程序未来运行时需要的配置文件(xml)
- 移动过程应是可靠安全的，所以client会将计算程序上传到HDFS（这就是移动过程），未来TaskTracker只需要去HDFS下载就行
- 调用JobTracker，通知JobTracker需要启动计算了，并告诉JobTracker计算程序放在了HDFS的哪些地方
存在的问题
JobTracker是单点的，必存在单点故障问题，存在压力过大问题，且因为JobTracker集成了资源管理和任务调度，所以未来若有新的非MapReduce计算框架，则不能复用资源管理，故而必将各自实现自己的资源管理，但又因为它们部署在同一批硬件上，所以肯定会造成资源争抢。
hadoop2.x的体现
yarn的引入
RM(ResoucesManager) ————资源管理
ResourceManager 通常在独立的机器上以后台进程的形式运行，它是整个集群资源的主要协调者和管理者。ResourceManager 负责给用户提交的所有应用程序分配资源，它根据应用程序优先级、队列容量、ACLs、数据位置等信息，做出决策，然后以共享的、安全的、多租户的方式制定分配策略，调度集群资源。
NM(NodeManger)————Container启动器
NodeManager 是 YARN 集群中的每个具体节点的管理者。主要负责该节点内所有容器的生命周期的管理，监视资源和跟踪节点健康。具体如下：
启动时向 ResourceManager 注册并定时发送心跳消息，等待 ResourceManager 的指令；
维护 Container 的生命周期，监控 Container 的资源使用情况；
管理任务运行时的相关依赖，根据 ApplicationMaster 的需要，在启动 Container 之前将需要的程序及其依赖拷贝到本地。
AM(ApplicationMaster )————任务调度
在用户提交一个应用程序时，YARN 会启动一个轻量级的进程 ApplicationMaster 。
ApplicationMaster 负责协调来自 ResourceManager 的资源，并通过 NodeManager 监视容器内资源的使用情况，同时还负责任务的监控与容错。具体如下：
- 根据应用的运行状态来决定动态计算资源需求
- 向
ResourceManager申请资源，监控申请的资源的使用情况 - 跟踪任务状态和进度，报告资源的使用情况和应用的进度信息
- 负责任务的容错。
Container————任务执行者
Container 是 YARN 中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等。当 AM 向 RM 申请资源时，RM 为 AM 返回的资源是用 Container 表示的。YARN 会为每个任务分配一个 Container ，该任务只能使用该 Container 中描述的资源。ApplicationMaster 可在Container 内运行任何类型的任务。例如: MapReduce ApplicationMaster 请求一个容器来启动map 或 reduce 任务，而 Giraph ApplicationMaster 请求一个容器来运行 Giraph 任务。
- 可以看出Yarn也是主从架构
- Yarn取消了JobTracker和TaskTracker,将资源管理放在了
Resource Manager，将任务调度放在了Application Master，图中Container代表资源
下面具体阐述一下图中的流程：
- Client首先完成上文hadoop 1.x方案中阐述的1.2.3.步
- Client通知Resource Manager（RM），RM挑一个不繁忙的节点通知对应的Node Manager（NM）启动一个Application Manager（AM），AM去HDFS下载split清单，反向从RM申请生成Container
- RM根据自己掌握的资源情况，找到合适的节点通知NM启动一批Container（注意Container由NM启动，NM与RM之间保持心跳）。Container在逻辑上时一个对象，里面定义了未来在这个节点中要消耗多少内存，多少CPU等属性；物理上时一个进程，占用定义好的内存等资源
- Container启动之后会反向注册回AM，这时AM才知道在集群中有多少资源，也就是有多少Container供自己调度
- AM将需要下载xml和计算程序的消息发给各Container，各Container自行去HDFS下载，最后执行
总结：
RM用于调配资源，与NM保持联系
NM负责启动AM和Container（AM本质上也是一个Container）
最终计算任务由AM调度给Container，Container自行下载执行
Yarn的方案成功将JobTracker解耦，不发生资源争抢，即使有一组AM与Container挂了，也不妨碍其他组AM和Container运行。由于有多个AM了，也不会出现单点故障和压力过大的问题。
Yarn架构有完善的消息监听机制，AM与Container挂机，RM都会重新调度，让NM重启
同样RM也存在单点故障问题，所以Yarn也有对应的HA模式解决该问题，Yarn的主备切换同样由Zookeeper协调
