分布式资源管理器YARN简介（一）
@(Hadoop)
为什么会出现YARN(Yet Another Resource Negotiator, a framework for job scheduling and cluster resource management)，YARN的优秀点是什么，践行分布式框架设计和并行化开发时有什么启发。希望这能加深Hadoop理解和算法开发思路扩展，如TensorFlow的多核任务分配机制、分布式任务分配机制等。
-
- 回顾基本的MapReduce流程
- 没有YARN之前
- Hadoop2x中新方案YARNMapReduce
- YARN是通用性的分布式资源管理器框架
- YARN优势
- 概念纠正
- 复习用例Spark Driver Cluster模式和Standalone模式比对
- 参考
- 后期介绍
所谓资源调度管理器最核心是
1. 管理集群资源，原则上可以包括任何硬件资源，当前YARN管理粒度是CPU和内存——解决物理资源透明化
2. 基于资源情况和任务进行状态，调度任务队列——解决并发任务调度透明化
回顾：基本的MapReduce流程
以MR界的Hello world（WordCount）举例：
其他相关知识
- RPC原理和实践
- Master-Slave设计模式
如何完成多个这样有组织性的任务？
没有YARN之前
原 MapReduce 框架图如下：
原 MapReduce 的设计思路：
1. 首先用户程序 (JobClient) 提交了一个 job，job 的信息会发送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要做很多事情。根据如上的MR流程，我们看看他要做哪些事
- 首先，要做任务分配，那就需要知道数据分布在哪里，这意味着要和HDFS Metadata Server通讯
- 其次，要根据数据分布，分配任务给实际机器，这里又基本有两个步骤，先确定有哪些机器是存活的、资源还剩余多少；另外，根据他们和数据的分布关系，做出任务分配策略
- 然后，开始分配任务，要将MapReduce逻辑分发到各台机器上
- 然后，要监控各个机器上Mapper、Reducer实例的任务进度，如果失败要回收资源并重新分配资源，指定数据索引，重新执行
- 更细的可以参考Google MapReduce原论文，再赘述下去也是说明一件事，这个JobTracker要做很多事情。
总结下：他需要与集群中的机器定时通信 (heartbeat), 需要管理哪些程序应该跑在哪些机器上，需要管理所有 job 失败、重启等操作，还需要和数据元数据中心通讯，了解数据分布等等。
2. TaskTracker 是 Map-reduce 集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况。
3. TaskTracker 同时监视当前机器的 tasks 运行状况。TaskTracker 需要把这些信息通过 heartbeat发送给JobTracker，JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。
问题的症结
刚开始的Hadoop中的MapReduce实现是做到很多的事情，而该框架的核心Job Tracker(作业跟踪者)则是既当爹又当妈的意思，即既做资源管理又做任务调度/监控。Task Tracker资源划分过粗放，二大部分工作是可以高度一致的监控任务。
会有什么问题
1. JobTracker 是 Map-reduce 的集中处理点，存在单点故障。管理的事情太多，状态一致性不便保障，很难做到Secondary Standby，从而不便做HA。
2. JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，也增加了 JobTracker fail 的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。
3. 在 TaskTracker 端，以 map/reduce task 的数目作为资源的表示过于简单，没有考虑到 cpu/内存的占用情况，如果两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot, 如果当系统中只有 map task 或者只有 reduce task 的时候，会造成资源的浪费，也就是前面提过的集群资源利用的问题。
4. 源代码层面分析的时候，会发现代码非常的难读，常常因为一个 class 做了太多的事情，代码量达 3000 多行造成 class 的任务不清晰，增加 bug 修复和版本维护的难度。
从操作的角度来看，现在的 Hadoop MapReduce 框架在有任何重要的或者不重要的变化 ( 例如 bug 修复，性能提升和特性化 ) 时，都会强制进行系统级别的升级更新。更糟的是，它不管用户的喜好，强制让分布式集群系统的每一个用户端同时更新。这些更新会让用户为了验证他们之前的应用程序是不是适用新的 Hadoop 版本而浪费大量时间——长期以往，这就要从优秀的开源系统名单中除名了。
那怎么办？
别一个人身兼多职，能拆再拆，单独优化。
要化繁为简，化整为零，合理抽象，划分边界。
Hadoop2.x中新方案YARN+MapReduce
接下来的设计思想是：分权、分而治之
将JobTracker两个主要的功能分离成单独的组件，这两个功能是资源管理和任务调度/监控。新的资源管理器全局管理所有应用程序计算资源的分配，每一个应用的 ApplicationMaster 负责相应的调度和协调。一个应用程序无非是一个单独的传统的 MapReduce 任务或者是一个 DAG( 有向无环图 ) 任务。ResourceManager 和每一台机器的节点管理服务器能够管理用户在那台机器上的进程并能对计算进行组织。
1. 上图中，关键对象Resource Manager、Node Manager、Container都和具体任务没有关系，是资源管理者和资源的抽象封装。
- ResourceManager：Global（全局）的进程
- NodeManager：运行在每个节点上的进程
- ApplicationMaster：Application-specific（应用级别）的进程
- Scheduler：是ResourceManager的一个组件
- Container：节点上一组CPU和内存资源
2. 每一个应用的ApplicationMaster是一个详细的框架库，它结合从ResourceManager获得的资源和 NodeManagr 协同工作来运行和监控任务。
3. ResourceManager就是一个纯粹的调度器，它在执行过程中不对应用进行监控和状态跟踪。同样，它也不能重启因应用失败或者硬件错误而运行失败的任务，这些都交给Application Master管理，而Application Master的实现交由具体的任务类型自定义实现——这样就带来了扩展性。
4. ResourceManager 是基于应用程序对资源的需求进行调度的 ; 每一个应用程序需要不同类型的资源因此就需要不同的容器。资源包括：内存，CPU，磁盘，网络等等。调度方式可以单独优化或扩展——保证了资源管理的粒度和扩展性
5. 在上图中 NodeManager 是每一台机器框架的代理，是执行应用程序的容器，监控应用程序的资源使用情况 (CPU，内存，硬盘，网络 ) 并且向调度器汇报。
6. 在上图中,每一个应用的 ApplicationMaster的职责有：向调度器索要适当的资源容器，运行任务，跟踪应用程序的状态和监控它们的进程，处理任务的失败原因。
YARN是通用性的分布式资源管理器/框架
Hadoop1中mapreduce可以说是啥事都干,而Hadoop2中的MapReduce的话则是专门处理数据分析。而YARN的话则做为资源管理器存在。
Yarn的另一个目标就是拓展Hadoop，使得它不仅仅可以支持MapReduce计算，还能很方便的管理诸如Hive、Hbase、Pig、Spark/Shark等应用。这种新的架构设计能够使得各种类型的应用运行在Hadoop上面，并通过Yarn从系统层面进行统一的管理，也就是说，有了Yarn，各种应用就可以互不干扰的运行在同一个Hadoop系统中，实现整个集群资源的共享。
YARN优势
Yarn 框架相对于老的 MapReduce 框架什么优势呢？我们可以看到：
1. 这个设计大大减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。
2. 在新的 Yarn 中，ApplicationMaster 是一个可变更的部分，用户可以对不同的编程模型写自己的 AppMst，让更多类型的编程模型能够跑在 Hadoop 集群中，可以参考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。
3. 对于资源的表示以内存为单位 ( 在目前版本的 Yarn 中，没有考虑 cpu 的占用 )，比之前以剩余 slot 数目更合理。
老的框架中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况，现在，这个部分就扔给 ApplicationMaster 做了，而 ResourceManager 中有一个模块叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是监测 ApplicationMaster 的运行状况，如果出问题，会将其在其他机器上重启。
4. Container 是 Yarn 为了将来作资源隔离而提出的一个框架。这一点应该借鉴了 Mesos 的工作，目前是一个框架，仅仅提供 java 虚拟机内存的隔离 ,hadoop 团队的设计思路应该后续能支持更多的资源调度和控制 , 既然资源表示成内存量，那就没有了之前的 map slot/reduce slot 分开造成集群资源闲置的尴尬情况。
概念纠正
首先的不要被YARN给迷惑住了,它只是负责资源调度管理,而MapReduce才是负责运算的家伙,所以YARN != MapReduce2。
需要注意的是，在Yarn中job的概念换成了application，因为在新的Hadoop2.x中，运行的应用不只是MapReduce了，还有可能是其它应用如一个DAG（有向无环图Directed Acyclic Graph，例如storm应用）
跟容器技术Docker有什么差别？首先YARN是个框架，主要是整合资源，将分布式资源统一管理，统一调配任务，对应用开发者透明资源和调度。Docker是容器，用于切分和隔离资源——Docker更像是YARN的Container这个角色，kubernetes则像是YARN中的ResourceManager。
复习用例[Spark Driver Cluster模式和Standalone模式比对]
略
参考
https://my.oschina.net/codeWatching/blog/345374
https://yq.aliyun.com/articles/5896
https://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-yarn/
http://blog.csdn.net/pelick/article/details/21292119
http://blog.csdn.net/matthewei6/article/details/50520719
后期介绍
YARN内存分配管理机制和调度器Scheduler详述
RPC原理和序列化框架