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的架构，主要由以下几个部分组成：

1. ResourceManager：负责Yarn集群的资源管理，任务的调度和监控。整个系统只有一个是live状态的（HA的时候另外一个是stand状态的），它支持可插拔的资源调度器，自带了FIFO、Fair Scheduler和Capacity Scheduler三种调度器；
2. ApplicationMaster：负责管理单个应用程序，它想RM申请资源，并用这些资源启动内部的任务，同时负责任务的运行监控和容错等。
3. NodeManager：集群中计算节点上的节点管理器，负责单个节点上的资源管理和监控，它定期将资源的使用情况报告给RM。并接收ApplicationMaster的命令以启动和回收Container等。
4. Container：对资源的抽象封装，它按照配置封装了某个节点上的CPU、内存等资源，一个Container既可以是一个Linux进程也可以是一个cGroup，这取决于具体的配置。

Yarn和MapReduce1的组件比较

ResourceManager

它同事包含两个组件NodeManagers (NMs) 和 ApplicationMasters (AMs)。

1. NodeManagers从RM接收指令并管理单个节点上的可用资源。
2. ApplicationMasters 与ResourceManager协调资源，并与NodeManagers一起启动容器。
3. 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负责管理和监控整个集群的的资源，好处是显而易见的。

1. 应用程序的部署将变的简单，管理员只需要部署Yarn服务即可，各类应用不需要自带的服务，它们在某些意义上变成了编程库。Spark集群不需要单独部署，直接是Spark-On-Yarn。甚至，我们可以自己写一些应用跑在Yarn上，后面我们会有spring-yarn的例子。
2. 服务之间是隔离的。Yarn提供的服务很专业也很纯粹，只是提供资源的管理和监控，Yarn上面运行什么服务是由用户自己决定的。
3. 资源的弹性利用，对提高资源的利用效率有很大帮助，比如离线计算、实时计算、DAG计算等。Yarn可以根据不同类型的应用程序压力情况，调整对应的资源使用量。

运行在Yarn上的计算框架

下面举几个例子。

1. MapReduce-On-YARN：YARN上的离线计算，YARN发行版中自带该实现；
2. Spark-On-YARN：YARN上的内存计算；
3. Storm-On-YARN：YARN上的实时/流式计算；
4. Tez-On-YARN：YARN上的DAG计算，我们目前的Hive底层就是用到了这个计算框架。

Yarn调度器

1. FIFO调度器：hadoop默认的调度器，它按照作业的优先级高低先排序，再按照作业的先来后到排序执行作业。
2. 计算能力调度器Capacity Scheduler：它配置了多个队列，每个队列占用集群的一定百分比的资源量，在每个队列内部采用FIFO调度策略，它的缺点在于牺牲了部分资源利用率。

调度器的一些配置

应用允许的占用最大资源率

• 弹性队列，单个作业的资源一般不会超过队列的总量。如果多个资源运行且当前队列的资源不够用了，是可以弹性的使用其他队列的资源的；另外，如果下面的选项yarn.scheduler.capacity.<queue-path>.user-limit-factor > 1 则y一个作业可以使用超过队列总量的资源。
• 队列的等待与抢占，自己的队列之前是空闲的，然后被被别的队列占用了，那么只能是等待占用了这个资源的应用释放容器资源。还可以是抢占的，但是这样会影响作业的执行效率。
• 其他配置，可以配置用户或者应用最多能占用集群资源的多少，以及队列的ACL认证等。

用户限制

3. 公平调度器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/

http://blog.csdn.net/suifeng3051/article/details/49508261