这是我参与更文挑战的第17天，活动详情查看: 更文挑战
Yarn
Yarn简介
Yarn是Hadoop集群的资源管理系统。Hadoop2.0对MapReduce框架做了彻底的设计重构，我们称Hadoop2.0中的MapReduce为MRv2或者Yarn
Yarn的另一个目标就是拓展Hadoop，使得它不仅仅可以支持MapReduce计算，还能很方便的管理诸如Hive、Hbase、Pig、Spark/Shark等应用。这种新的架构设计能够使得各种类型的应用运行在Hadoop上面，并通过Yarn从系统层面进行统一的管理，也就是说，有了Yarn，各种应用就可以互不干扰的运行在同一个Hadoop系统中，共享整个集群资源
YARN产生背景
Yarn是在 MRv1 的基础上演化而来，解决了一些 MRv1 中的各种局限性。首先了解一下 MRv1 的一些局限性：
- 扩展性差: 在 MRv1 中，JobTracker同时兼备了资源管理和作业控制两个功能，这称为系统的一个最大瓶颈，严重制约了 Hadoop 集群扩展性
- 可靠性差: MRv1 采用了 Master/Slave 结构，Master存在单点故障的问题，一旦出现故障将导致整个集群不可用
- 资源利用率低: MRv1 采用了基于任务槽（slot）的资源分配模型，是一种粗粒度的资源划分单位。通常一个任务不会耗尽一个 slot 对应的资源，而其他任务也无法使用空闲资源。此外，slot 分为 Map slot 和 Task slot 两种，互相不能共享，会导致一种资源耗尽而另一种资源闲置。
- 无法支持多计算框架: 随着计算量增大和计算速度要求，MapReduce 这种基于磁盘的离线计算框架已经不能满足应用要求。一些新的基于内存、流式计算框架出现，MRv1 不能支持多种计算框架
为了解决以上几个缺点，MRv2 将资源管理功能抽象成了一个独立的通用系统 YARN。在以 MapReduce 为核心的软件栈中，资源管理系统 YARN 是可插拔替换的（比如选择 Mesos 替换 YARN），一旦 MapReduce 接口改变，所有的资源管理系统的实现均需要跟着改变；而以 YARN 为核心的软件栈则不同，所有框架都需要实现 YARN 定义的对外接口以运行在 YARN 之上，从而打造一个以 YARN 为核心的生态系统。
低版本的hadoop下MapReduce处理流程和问题
- 首先用户程序(JobClient)提交了一个job,job的信息会发送到Job Tracker,Job Tracker是Map-reduce框架的中心，他需要与集群中的机器定时通信heartbeat,需要管理哪些程序应该跑在哪些机器上，需要管理所有job失败、重启等操作。
- TaskTracker是Map-Reduce集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况
- TaskTracker同时监视当前机器的tasks运行状况。TaskTracker需要把这些信息通过heartbeat发送给JobTracker,JobTracker会搜集这些信息以给新提交的job分配运行在哪些机器上
随着集群规模个工作负荷的增长，原框架的问题便暴露出来了:
- JobTracker是Map-reduce的
集中处理点，存在单点故障 - JobTracker完成了
太多的任务，造成了过多的资源消耗，当map-reduce job非常多的时候，会造成很大的内存开销，潜在来说，也增加了JobTracker fail的风险，这也是业界普遍总结出老hadoop 的Map-Reduce只能支持4000节点主机的上限。 - 在TaskTracker端，以map/reduce task的数目作为资源的表示过于简单，没有考虑到cpu/内存的占用情况，如果两个大内存消耗的task被调度到了一块，很容易出现OOM
- 在TaskTracker端，把资源强制划分为map task slot和reduce task slot如果当系统中只有map task或者只有reduce task的时候，会造成资源的浪费，也就是前面提到过的集群资源利用的问题。
新hadoop yarn框架原理及运行机制
基本思想就是将JobTracker两个主要的功能分分离成单独的组件，这两个功能是资源管理和任务调度/监控。新的资源管理器全局管理所有应用程序计算资源的分配。每一个应用的ApplicationMaster负责相应的调度和协调。
一个应用程序无非是一个单独的传统的MapReduce任务或者是一个DAG(有向无环图)任务。ResourceManager和每一台机器的阶段管理服务器能够管理用户在哪台机器上的进程并能对计算进行组织
每一个应用的ApplicationMaster的职责有：向调度器索要适当的资源容器，运行任务，跟踪应用程序的状态和监控他们的进程，处理任务的失败原因。
新旧Hadoop MapReduce框架对比
- 客户端不变，其调用API及接口大部分保持兼容，这也是为了开发使用者透明化，对原码不必做大的改变，但是原框架的JobTracker和TaskTracker不见了，取而代之的是ResourceManager AppliactionMaster NodeManager三个部分。
- ResourceManager是一个中心的服务，它做的事情是调度、启动每一个Job所属的ApplicationMaster、另外监控ApplicationMaster的存在情况。Job里面所在的task的监控，重启等内容不见了，这就是ApplicationMaster存在的原因。ResourceManager负责作业与资源的调度，接收JobSubmitter提交的作业，按照作业的上下文(context)信息，以及从NodeManager收集来的状态信息，启动调度过程，分配一个Container作为Application Master
- NodeManager功能比较专一，就是负责Container状态的维护，并向RM保持心跳。
- ApplicationMaster负责一个Job生命周期内的所有工作，类似老的框架中JobTracker,但注意每一个Job(不是每一种)都有一个ApplicationMaster,他可以运行在ResourceManager以外的机器上
Hadoop yarn优势
- 大大减小了JobTracker（也就是现在的ResourceManager）的资源消耗，并且让检测每一个Job子任务（tasks）状态的程序分布式化了
- 对于资源的表示以内存为单位，比之前以剩余slot数目更合理
- 老的框架中，JobTracker一个很大的负担就是监控kob下的tasks的运行状况，现在，这个部分就扔给ApplicationMaster了，而ResourceManager中有一个模块叫做ApplicationsMaster,它是检测ApplicationMaster的运行状况，如果出问题，会将其在其他机器上重启
