论文阅读笔记《Apache Hadoop YARN: Yet Another Resource Negotiator》

---

Introduction：

这是一篇偏工程性的paper，主要由Hortonworks公司的人写成，共有16位作者，是阐述第二代Hadoop的计算平台Yarn的发展驱动，设计理念和基本框架等，并将两代hadoop做比较分析，凸显YARN的优势，同时将其与类似Mesos等系统做对比分析。这篇paper是SOCC2013年的best paper，是学习YARN的一篇必读论文吧。

Keyword

motivation

在Hadoop1.x中MapReduce是Master/Slave结构，在集群中的表现形式为：1个JobTracker带多个TaskTracker。JobTracker：负责资源管理和作业调度；TaskTracker：定期向JobTracker汇报本节点的健康状况、资源使用情况以及任务的执行情况；接收来自JobTracker的命令（启动/杀死任务等）并执行接收到的命令。如此，JobTracker负责接收处理来自各个TastTracker节点的RPC请求，压力很大，这就大大限制了集群的扩展，节点规模要扩大，它就将成为一个瓶颈。同时存在单点故障问题，而对于第一代hadoop来说它不能支持除MR之外的计算框架也是一个问题。为此要对其进行大的修整。

Contribution

YARN是Yet Another Resource Negotiator的简称，是由社区多人贡献实现的，本文总结了其设计/发展和目前的一个部署情况。Yarn的设计一个main idea在于它解耦了编程模型和资源管理，打破了原先的一种紧耦合的状态，将两者分开，同时从master中分离出部分调度功能给每一个应用组件，即AppMaster.一句话概括就是，它在原先的版本基础上，加了一层抽象Yarn,相当于hadoop的操作系统，负责集群资源管理，使得mapreduce成为一个跑在Yarn上的一个应用，突破了原先MR计算框架的性能瓶颈。hadoop成为一个多应用程序平台，其他诸如spark，storm等计算框架稍作修改也可运行在Yarn上。

Content

---

History and rationale

    在一节中，主要是总结了从实际应用中得到的YARN的需求，回顾了hadoop的一个发展历史，每一阶段都对前面的结果有改进，解决一些迫切的问题，但是仍存在未能很好解决的状况，在原先框架基础上的小修小改已不能满足需求，这也促使了第二代hadoop的发展。论文中总结了十个需求，下面列出并简要说明。

requirements introduction Scalability 可扩展性：前文提过，由于jobtracker负载过大，造成单点性能瓶颈，影响系统给的可扩展性,这也是要考虑的主要标准 Multi-tenancy 多租户：为了解决这个问题，第一代hadoop引入HOD(Hadoop On Demand),它通过资源管理系统Torque将一个物理Hadoop集群隔离出若干个虚拟Hadoop集群，以应对不同类型的应用程序相互干扰的问题.Torque分配节点时不考虑本地性；资源调整粒度过粗，job之间无法共享资源。调度延迟过高，利用率过低。因此，在HoD之后，Hadoop还需要新的集群调度机制 Serviceability 可服务性：HoD是存在问题的，它为每一个job建立一个新的集群，而新和旧版本的hadoop同时存在，hadoop的更新发布周期非常短 Locality Awareness 位置感知：jobtrack尽量将任务部署到离输入的近的节点上，但是node allocator是不能感知到位置 High Cluster Utilization 高集群利用率：一个集群一个计算框架，造成各个集群管理复杂，资源的利用率低，例如某个时间段，hadoop集群忙而Spark集群闲着。 Reliability/Availability 可靠性/可用性：主要是考虑到单点故障的问题，大型分享集群处理过多jobs时的overhead问题。 Secure and auditable operation 安全和可审计的操作：系统在安全方面依然是重要的需求，主要集中在Authentication方面 Support for Programming Model Diversity 支持多样的编程模型：由于第一代hadoop与MR的紧耦合，无法支持其他的编程模型。目前诸如Spark,Storm等越来越多的编程模型出现也非常的流行，这也是促使了Yarn诞生的主要原因。 Flexible Resource Model 灵活的资源模型：map和reduce的slot是由cluster operator设定，这容易造成资源利用瓶颈，闲置的map资源不能用于reduce，反之亦然，造成很大的延迟和资源紧缺与浪费。 Backward Compatibility 向后兼容：新的系统保证兼容原先的系统，做越少的更改越好。

---

Architecture