资源管理与调度系统YARN(YARN基本架构及原理)

hadoop 2.0引入了数据操作系统YARN，YARN能够将资源按需分配给各个应用程序，大大提高了资源利用率，其次，YARN将短作业和长作业混合部署到一个集群中，并提供了容错、自愿隔离及负载均衡等方面的支持，大大简化了作业和服务的部署和管理成本。

why YARN

MRv1 局限性

1. 可靠性差：MRv1采用了master/slave结构，master存在单点故障问题，一旦出现问题可能导致整个集群不可用。
2. 扩展性差：MRv1中JobTracker(master)同时兼备了资源管理和作业控制两个功能，严重制约了Hadoop集群的扩展性。
3. 资源利用率低：MRv1采用了基于槽位的资源分配模型，通常一个任务不用全部用完槽位对应的所有的资源，其他任务也无法使用这些没有使用的资源。另外，Hadoop将槽位划分为Map Slot和Reduce Slot两种，且不允许它们之间共享，常常会导致一种槽位资源紧张而另一种槽位闲置的状态(例如一个作业刚刚提交时，只会运行Map Task，此时Reduce Slot闲置)。
4. 无法支持多种计算框架：MRv1不能支持多种计算框架并存(例如内存计算框架、流式计算框架和迭代计算框架)。
   MRv2将资源管理功能抽象成了一个独立的通用系统YARN，使得下一代MapReduce的核心从单一的计算框架MapReduce转移为通用的资源管理系统YARN。下图展示了MRv1和MRv2的对比：
   
   以MapReduce为核心的协议栈中，资源管理系统是可以替换的，但一旦MapReduce接口发生改变，所有的资源管理系统的实现都需要改变；以YARN为核心的协议栈中，所有框架都需要实现YARN定义的对外接口以运行在YARN之上。

YARN设计动机

YARN作为一个通用的资源管理系统，其目标是将短作业和长任务混合部署到一个集群中，并为他们提供统一的资源管理和调度功能。YARN的设计需要解决以下两类问题。

1. 提高集群资源利用率
   为了存储和处理海量数据，需要规模较大的服务器集群或者数据中心，一般这些集群上运行着数量众多的应用程序和服务，传统的做法是让这些不同类型的作业或任务对应一个单独的集群以避免互相干扰。这样集群被分成若干个小集群，由于不同类型的任务需要的资源不同，所以这些小集群的利用率通常很不均衡，并且集群间的资源无法共享，有些集群资源紧张而有些集群处于闲置状态。为了提高资源整体的利用率，一种解决方式是让这些小集群合并成一个大的集群，让任务可以共享大集群的资源，并由一个资源管理系统统一进行资源管理和分配。
2. 服务自动化部署
   YARN需要提供服务统一管理系统，包括服务资源申请、服务自动化部署、服务容错等功能。

YARN 设计思想

Hadoop1.0中，JobTracker同时负责资源管理和作业控制两部分，如下图所示。这种设计使得JobTracker的功能过多负载过重，未能将资源管理与程序相关的功能分开，造成第一代Hadoop难以支持多种计算框架