Yarn
MapReduce
MapReduce的架构
MapReduce是一个用于大规模数据处理的分布式计算模型
MapReduce模型主要有Mapper和Reducer两个抽象类.
Mapper端主要负责对数据的分析处理,最终转化为Key-value的数据结构
Reducer端主要是获取Mapper出来的结果，对结果进行统计
MapReduce实现存储的均衡，未实现计算的均衡
MapReduce的问题
- JobTracker存在单点故障的隐患。在Yarn中RM实现了HA。
- JobTracker的职责多样，且消耗的资源随着集群和作业的数量增加而增加，更加剧了JobTracker挂掉的风险。
- 代码复杂，bug修复和新增功能难度较大。
- 无法支持更多的计算模型。
- 资源划分粒度过大：在 TaskTracker 端，以 map/reduce task 的数目作为资源的表示过于简单，没有考虑到 cpu/ 内存的占用情况，这种基于无类别slot的资源划分方法的划分粒度仍过于粗糙，往往会造成节点资源利用率过高或者过低 ，比如，管理员事先规划好一个slot代表2GB内存和1个CPU，如果一个应用程序的任务只需要1GB内存，则会产生“资源碎片”，从而降低集群资源的利用率，同样，如果一个应用程序的任务需要3GB内存，则会隐式地抢占其他任务的资源，从而产生资源抢占现象，可能导致集群利用率过高。如果两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。
- 资源无法共享：在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot，且不允许共享。对于一个作业，刚开始运行时，Map slot资源紧缺而Reduce slot空闲，当Map Task全部运行完成后，Reduce slot紧缺而Map slot空闲。很明显，这种区分slot类别的资源管理方案在一定程度上降低了slot的利用率。在Yarn中是分阶段获取资源的，且这个阶段是可以配置的。
- 资源没有有效的隔离：CPU无法进行隔离，应用之间产生资源竞争，相互干扰影响执行效果。
Yarn MapReduce2
Apache Yarn(Yet Another Resource Negotiator) 是Hadoop的新一代集群资源管理系统。最初，Yarn的出现是为了改善之前版本中MapReduce中的缺陷，但是Yarn被设计的有足够的抽象与通用，现在，MapReduce任务只是Yarn 应用中的一种，它还支持Tez、Spark等分布式计算模式。我们比较熟悉的hive、pig与Yarn并没有直接的协作关系，他们都是运行在MapReduce、spark或Tez之上的。
Yarn应用
Yarn的架构
Yarn架构
我们仍然可以认为它是采用了master/slave的架构，主要由以下几个部分组成：
- ResourceManager：负责Yarn集群的资源管理，任务的调度和监控。整个系统只有一个是live状态的（HA的时候另外一个是stand状态的），它支持可插拔的资源调度器，自带了FIFO、Fair Scheduler和Capacity Scheduler三种调度器；
- ApplicationMaster：负责管理单个应用程序，它想RM申请资源，并用这些资源启动内部的任务，同时负责任务的运行监控和容错等。
- NodeManager：集群中计算节点上的节点管理器，负责单个节点上的资源管理和监控，它定期将资源的使用情况报告给RM。并接收ApplicationMaster的命令以启动和回收Container等。
- Container：对资源的抽象封装，它按照配置封装了某个节点上的CPU、内存等资源，一个Container既可以是一个Linux进程也可以是一个cGroup，这取决于具体的配置。
Yarn和MapReduce1的组件比较
| MapReduce1 | Yarn |
|---|---|
| JobTracker | ResourceManager、application master、时间轴服务器 |
| TaskTracker | NodeManager |
| Slot | Container |
ResourceManager
它同事包含两个组件NodeManagers (NMs) 和 ApplicationMasters (AMs)。
- NodeManagers从RM接收指令并管理单个节点上的可用资源。
- ApplicationMasters 与ResourceManager协调资源，并与NodeManagers一起启动容器。
- Scheduler: 支持插件，以实现不同的资源调度方案。
ResourceManager
Yarn的资源管理方案
Yarn丢弃了在MapReduce1中的slot的概念，而是让ApplicationMaster向RM申请自己需要的资源（比如某个任务可申请1.5GB 内存和1个CPU），而调度器则按照任务实际需求为其精细地分配对应的资源量，不再简单的将一个Slot分配给它，Hadoop 2.0正式采用了这种基于真实资源量的资源分配方案。
http://dongxicheng.org/mapreduce-nextgen/hadoop-1-and-2-resource-manage/
提交Yarn应用程序的过程
- 步骤1：用户（客户端）将应用程序提交到ResourceManager上，请求允许application master；
-
步骤2：RM找到一个可以在容器里启动这个application master的节点。
- 这里如果能够完成计算的话就计算并返回结果到客户端。
- 步骤3：还可以从RM请求更多的容器（资源）。
- 步骤4a和4b：从第步骤3开始，运行一个分布式计算。
yarn应用的启动
多种计算框架部署在Yarn上
随着yarn和各个计算框架的发展，慢慢形成了一种以Yarn为核心的生态系统，Yarn负责管理和监控整个集群的的资源，好处是显而易见的。
- 应用程序的部署将变的简单，管理员只需要部署Yarn服务即可，各类应用不需要自带的服务，它们在某些意义上变成了编程库。Spark集群不需要单独部署，直接是Spark-On-Yarn。甚至，我们可以自己写一些应用跑在Yarn上，后面我们会有spring-yarn的例子。
- 服务之间是隔离的。Yarn提供的服务很专业也很纯粹，只是提供资源的管理和监控，Yarn上面运行什么服务是由用户自己决定的。
- 资源的弹性利用，对提高资源的利用效率有很大帮助，比如离线计算、实时计算、DAG计算等。Yarn可以根据不同类型的应用程序压力情况，调整对应的资源使用量。
运行在Yarn上的计算框架
下面举几个例子。
- MapReduce-On-YARN：YARN上的离线计算，YARN发行版中自带该实现；
- Spark-On-YARN：YARN上的内存计算；
- Storm-On-YARN：YARN上的实时/流式计算；
- Tez-On-YARN：YARN上的DAG计算，我们目前的Hive底层就是用到了这个计算框架。
Yarn调度器
- FIFO调度器：hadoop默认的调度器，它按照作业的优先级高低先排序，再按照作业的先来后到排序执行作业。
- 计算能力调度器Capacity Scheduler：它配置了多个队列，每个队列占用集群的一定百分比的资源量，在每个队列内部采用FIFO调度策略，它的缺点在于牺牲了部分资源利用率。
调度器的一些配置
应用允许的占用最大资源率
- 弹性队列，单个作业的资源一般不会超过队列的总量。如果多个资源运行且当前队列的资源不够用了，是可以弹性的使用其他队列的资源的；另外，如果下面的选项yarn.scheduler.capacity.<queue-path>.user-limit-factor > 1 则y一个作业可以使用超过队列总量的资源。
- 队列的等待与抢占，自己的队列之前是空闲的，然后被被别的队列占用了，那么只能是等待占用了这个资源的应用释放容器资源。还可以是抢占的，但是这样会影响作业的执行效率。
- 其他配置，可以配置用户或者应用最多能占用集群资源的多少，以及队列的ACL认证等。
用户限制
-
公平调度器Fair Scheduler
公平调度器也可以有多队列的组合，并且可以给每个队列配置一个权重。在队列中允许以FIFO的策略执行作业。
公平调度器与多队列
Yarn上最常见的三种调度器
reference:
https://www.jianshu.com/p/b3afeb1daf3a
http://hadoop.apache.org/docs/r2.4.1/hadoop-yarn/hadoop-yarn-site/YARN.html
http://dongxicheng.org/mapreduce-nextgen/apache-hadoop-yarn-paper-on-socc2013/
