【Hadoop】Yarn框架学习

学习了两天，对整体框架、运行机制、组件的功能和关系有了大概了解（框架图和机制图手绘在笔记本上）。详细的通信过程通读了一遍，很细碎繁琐，一时间很难记住，日后有需要再做补充。

时间不宽裕，在此不进行完整记录阐述，仅记录部分要点。

参考文章《hadoop之yarn详解》 https://www.cnblogs.com/zsql/p/11648894.html
《Yarn框架和工作流程研究》https://www.cnblogs.com/itboys/p/9184381.html

本文仅作博主学习记录使用

每个应用程序有一个ApplicationMaster，每个任务对应一个container.

ApplicationMaster监控应用程序，ResourceManager与应用程序交互主要就是与ApplicationMaster交互

Container是Yarn框架的计算单元，是具体执行应用task（如map task、reduce task）的基本单位。Container和集群节点的关系是：一个节点会运行多个Container，但一个Container不会跨节点

在ApplicationMaster请求资源的过程中，ApplicationMaster负责计算应用程序的资源需求，并把它们转换为调度器能够理解的ResourceRequest对象

Yarn和MRv1对比
(1)扩展性对比。
MRv1中，JobTracker是个重量级组件，集中了资源管理分配、作业控制两大核心功能，随着集群规模的增大，JobTracker处理各种RPC请求负载过重，这也是系统的最大瓶颈，严重制约了Hadoop集群的扩展性。相比之下，Yarn将JobTracker功能进行了拆分，拆分为全局组件ResourceManager、应用组件ApplicationMaster和JobHistoryServer。其中，ResourceManager负载整个系统资源的管理和分配，ApplicationMaster负载单个应用程序的相关管理(job的管理),JobHistoryServer负载日志的展示和收集工作。Yarn的这种功能拆分，将减轻了master节点的负载，其处理的RPC请求的压力得到减少。其实换句话Yarn是将这种负载进行了横向转移到子节点，这个可以通过ApplicationMaster(简称APP Mstr)的机制体现，APP Mstr是运行在其中一个子节点，运行在其他各个子节点的Task只需要向App Mstr发送相关的RPC请求来汇报task运行情况就ok，而不需要直接和master节点的相关进行进行RPC通讯。这个就将MRv1的Master/slave转化为了Master/slave混杂slave/slave的这种结构。
另外，Hadoop1.x扩展性差问题不仅仅体现在MRv1框架中，提体现在HDSF中。Yarn为了解决这个问题，提出了HDFS Federation,它可以允许集群中启动多个NameNode来分管不同目录的元数据进而实现了访问隔离和横向扩展问题，同时HDFS Federation的提出也彻底解决了hadoop1.x的NameNode单点故障问题。
(2)资源利用率对比。
MRv1的资源管理分配模型是基于槽位的，槽位是一个相当粗粒度的系统资源单位，一个槽位是系统一定cpu、内存、网络、IO等资源的抽象。一个Slot只能启动一个Task，关键的是一个Task未必用完一个Slot所对应的系统资源，但是它又占着不给别的Task使用，这就造成了浪费。另外，在MRv1中Slot还被分为了Reduce Solt和Map Slot，Reudce solt只能启动Reduce Task，Map Slot只能启动Map Task，这两种Slot不允许共享，因此常常会导致一种Slot资源相当紧张而另外一种Slot资源却是空闲的。例如，当一个Job刚刚被提交的时候，只有当Map Task完成数据为总数量的5%（默认）时，Reduce Task才会启动，那么此时的Reudce Slot就是被闲置浪费了。相比之下，Yarn就克服了上面的问题，Yarn的资源抽象单位container是细粒度的，而且是动态的（目前Yarn版本中只支持cpu和内存的动态分配），他可以为不同的Task需求进行分配，而且container是部分种类的，在MRv框架中可以同时被Map Task和Reduce Task使用。
(3)安全稳定性对比。
Hadoop1.x对应的HDFS版本中NameNode是存在单点故障的，但是Yarn通过HFDS Federation的提出完美地解决了这个棘手问题。
(4)基本架构特性对比。
MRv1是单纯地为离线框架Map Reduce打造的，而这种离线计算机框架不能满足现在需求了，一些更有针对性的框架被开发出来，如Spark、storm、DAG计算机框架Tez。这些新的框架无法运行在MRv1上。相比之下，Yarn是一个独立的资源管理系统，其资源和计算机框架是被分离开来的，你可以在Yarn上同时运行MR APP、Spark APP、MPI APP等等。

Yarn工作流程

• 步骤1，用户向Yarn提交应用程序，其中包括用户程序、相关文件、启动ApplicationMaster命令、ApplicationMaster程序等。
• 步骤2，ResourceManager为该应用程序分配第一个Container，并且与Container所在的NodeManager通信，并且要求该NodeManager在这个Container中启动应用程序对应的ApplicationMaster。
• 步骤3，ApplicationMaster首先会向ResourceManager注册，这样用户才可以直接通过ResourceManager查看到应用程序的运行状态，然后它为准备为该应用程序的各个任务申请资源，并监控它们的运行状态直到运行结束，即重复后面4~7步骤。
• 步骤4，ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。
• 步骤5，一旦ApplicationMaster申请到资源后，便会与申请到的Container所对应的NodeManager进行通信，并且要求它在该Container中启动任务。
• 步骤6，任务启动。NodeManager为要启动的任务配置好运行环境，包括环境变量、JAR包、二进制程序等，并且将启动命令写在一个脚本里，通过该脚本运行任务。
• 步骤7，各个任务通过RPC协议向其对应的ApplicationMaster汇报自己的运行状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以再任务运行失败时重启任务。
• 步骤8，应用程序运行完毕后，其对应的ApplicationMaster会向ResourceManager通信，要求注销和关闭自己。