yean体系架构介绍

YARN是Hadoop 2.0的资源管理器。它是一个通用的资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

1、从Hadoop0.23版本开始对于mapduce计算框架进行升级，引入了YARN。老的版本MRv1存在诸多问题，和YARN对比如下：

1） MRv1中Jobtracker中存在单点问题，功能比较多的问题，负责资源管理调度和job的生命周期管理(task调度，跟踪task过程状态，task处理容错)，这样当大量的任务需要处理时，单个的jobtracker无论在内存还是其他资源方面总存在瓶颈，在伸缩性、资源利用率、运行除mapreduce的其他任务等方面都会有限制；Yarn框架把资源调度和task管理监控分离开来，由资源管理器NodeManager负责资源调度，每一个application(job)由一个AppMaster负责对task进行调度管理监控，并且可以监控AppMaster的状态，有问题可以在其他节点重启。

2）MRv1只支持批量的mapreduce计算；yarn框架除了mapreduce、还支持实时流，MPI等，使得hadoop成为一个资源和数据共享的基础计算框架，减少集群运维成本，提高资源利用率。

3）MRv1 mapreduce框架使用slot做资源表示单位，并且map slot和reduce slot分离的，这样资源不能共享，资源利用率不高；yarn使用节点的cpu、内存等资源作为资源表示单位，大大提高了资源利用率。

2、YARN基本架构：

YARN的基本设计思想是将Hadoop 1.0中的JobTracker拆分成了两个独立的服务：一个全局的资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。其中ResourceManager负责整个系统的资源管理和分配，而ApplicationMaster负责单个应用程序的管理，其基本架构如下图所示：



YARN总体上仍然是Master/Slave结构。在整个资源管理框架中，ResourceManager为Master，NodeManager为Slave，并通过HA方案实现了ResourceManager的高可用。ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManger启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。

yarn架构中具体角色：

1）ResourceManager(RM)：主要接收客户端任务请求，接收和监控NodeManager(NM)的资源情况汇报，负责资源的分配与调度，启动和监控ApplicationMaster(AM)。

2）NodeManager（NM）：主要是节点上的资源管理，启动Container运行task计算，上报资源、container情况给RM和任务处理情况给AM。

3）ApplicationMaster（AM）：用户提交的每个应用程序均包含1个ApplicationMaster，主要是单个Application(Job)的task管理和调度，向RM进行资源的申请，向NM发出launch Container指令，接收NM的task处理状态信息。

4）Container：它是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当ApplicationMaster向ResourceManager申请资源时，返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。

3、提交一个job到yarn的处理过程：



1）用户向YARN中提交应用程序，其中包括用户程序、ApplicationMaster程序、ApplicationMaster启动命令等。

2）ResourceManager为应用程序分配第一个Container，并与对应的NodeManager通信，要求它在这个Container中启动应用程序的ApplicationMaster。

3）ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后ApplicationMaster为各个任务申请资源，并监控它们的运行状态，直到运行结束，即重复步骤4-7。

4）ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。

5）一旦ApplicationMaster成功申请到资源，便开始与对应的NodeManager通信，要求它启动任务。

6）NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。

7）各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，使ApplicationMaster能够随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态。

8）应用程序运行完成后，ApplicationMaster通过RPC协议向ResourceManager注销并关闭自己。

4、yarn中resourceManage的高可用：

ResourceManager（RM）负责跟踪集群中资源使用情况，调度应用程序（比如MapReduce作业）。在Hadoop 2.4之前，ResourceManager存在单点故障，需要通过其他方式实现HA。官方给出的HA方案是Active/Standby两种状态ResourceManager的冗余方式，类似于HDFS的HA方案，也就是通过冗余消除单点故障。



1）RM故障转移：

ResourceManager HA是通过Active/Standby冗余架构实现的，在任何时间点，其中一个RM处于Active状态，其他RM处于Standby状态，Standby状态的RM就等着Active扑街或被撤。通过管理员命令或自动故障转移（需要开启自动故障转移配置），Standby就会转为Active状态，对外提供服务。

A、手动转换和故障转移：当未启用自动故障转移时，就需要管理员手动转换。首先将Active状态的RM转为Standby状态，然后将一个Standby状态的转为Active状态。这些操作都需要通过yarn rmadmin命令来操作。

B、自动故障转移：RM可以通过内嵌的基于Zookeeper的Active/Standby选择器决定哪个RM应该是Active状态的。当Active性能下降或无响应时，一个Standby状态的RM就被推举出来，转为Active状态接管。这里不需要像HDFS的HA配置需要一个单独的ZKFS守护进程辅助完成切换，因为这个功能已经内嵌在RM中。

客户端、ApplicationMaster和NodeManager在故障转移时，会轮训这些RM节点，知道找到Active状态的RM。如果Active节点性能下降，他们会重新轮训查找新的Active状态的RM。默认的轮训扩展是org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider。可以通过实现org.apache.hadoop.yarn.client.RMFailoverProxyProvider，并配置yarn.client.failover-proxy-provider来实现自己的逻辑。

2）RM状态恢复：

当启用ResourceManger重启状态恢复之后，新的Active状态的RM会加载上一个RM状态，并根据状态尽可能的恢复之前的操作。应用程序会定期检查，以避免丢失数据。状态存储需要对Active状态和Standby状态的RM都可见。目前，RMStateStore有两个持久化实现，FileSystemRMStateStore和ZKRMStateStore。ZKRMStateStore隐式的只允许一个RM写入操作，可以没有单独的防护机制就能够避免脑裂问题，所以是HA集群推荐的状态存储方式。使用ZKRMStateStore时，建议不要在zookeeper集群上设置zookeeper.DigestAuthenticationProvider.superDigest配置，以确保zk管理员无法访问YARN的信息。

参考：
http://blog.leanote.com/post/lh1649896772@163.com/HDFS%E4%BB%8B%E7%BB%8D%E5%92%8CYARN%E5%8E%9F%E7%90%86%E4%BB%8B%E7%BB%8D http://www.howardliu.cn/hadoop/rm-ha/