APACHE HADOOP YARN –背景和概述

APACHE HADOOP YARN –背景和概述

庆祝重大的里程碑，Apache Hadoop YARN 被提升为Apache Hadoop在ASF的独立子项目，我们将开始系列blog的第一篇于Apache Hadoop YARN – 一个通用的，分布式的，app管理框架，取代Hadoop集群数据处理经典的Apache Hadoop MapReduce框架。

MAPREDUCE – 经典范例

从本质上说, MapReduce model 首先由一个并行的map结构来分割输入的数据，然后进行reduce操作map输出的数据，聚合后产生希望的结果。一般的编程模型本身可以简单的，但是受限的实现高效的，大规模的数千廉价节点连接。

Apache Hadoop MapReduce 是最流行的开源MapReduce模型实现。

特别是，当MapReduce搭配上分布式文件系统比如 Apache Hadoop HDFS，就能够通过一个大集群提供一个高I/O带宽，这是一个极具吸引力的系统经济学 – 也是Hadoop变得流行的一个关键因素。

一个关键点是 减少数据移动，即移动计算到数据节点而不是通过网络移动数据到计算节点。具体来说，在集群上扩展存储层，MapReduce任务被安排在HDFS数据在同一个物理节点上。这显著降低了网络I/O，使I/O保留在本地磁盘或者同一个机架上 – 这是一个核心优势。

APACHE HADOOP MAPREDUCE, 关于 2011 – 一个概述

Apache Hadoop MapReduce 是一个开源的， Apache Software Foundation 的项目，是一个如上所MapReduce编程模型的实现。现如今，作为一些在Apache Hadoop工作超过六年的人， 我通常想指出Apache Hadoop MapReduce项目可以细分为以下几个方面：

• 终端用户的 MapReduce API ，用于编程实现自定义的MapReduce app。
• MapReduce framework, 是运行时实现各个阶段的，比如map阶段，sort/shuffle/merge 聚合和reduce阶段。
• MapReduce system, 是运行用户MapReduce app，管理集群资源，调度数千并行任务的基础。

这种隔离关注点的做法是有显著好处的，特别是对终端用户 – 他们能够完全通过API关注app，并通过MapReduce框架和MapReduce系统的组合去处理不关心的事情，比如资源管理，容错，调度等。

当前的 Apache Hadoop MapReduce System 是JobTracker，由主节点和TaskTrackers slave节点组成。

JobTracker负责资源管理（管理worker节点TaskTrackers），跟踪资源消耗/剩余，还有任务生命周期管理（调度任务的独立task，工总进度，提供task容错等）。

TaskTracker只有简单的职责 – 根据JobTracker的命令启动/关闭tasks，定期提供task状态信息给JObTracker。

已经有一段时间了，我们意识到Apache Hadoop MapReduce框架需要推倒重来了。特别是在JobTracker方面，我们需要解决以下几个方面的问题：可扩展性，集群利用率，用户控制升级堆栈的能力，即用户的灵活性，同样重要的是，提供超越MapReduce的负载均衡。

我们最近已经做了部分修复，包括最近支持JobTracker可用性和弹性HDFS问题（ Hortonworks Data Platform v1 i.e. HDP1）但是这增加了维护成本，而且并没有解决核心问题，比如支持非MapReduce和用户灵活性。

为什么需要支持非MAPREDUCE工作方式？

MapReduce对于很多app是伟大的，但是并不是全部；其他的编程模型更适合服务于图计算 (Google Pregel / Apache Giraph) 和迭代计算模型 (MPI)。当企业的所有数据都已经在Hadoop HDFS上时，有多种处理方式就变得重要了。

此外，既然MapReduce基本上是批处理的，支持实时和基本实时处理，比如流计算和CEPFresil的需求不断从我们客户中涌现。

给Hadoop提供这些可以帮助降低管理员的运营成本，降低Hadoop HDFS和其他存储系统的数据移动需求，使企业可以看到Hadoop投资的回报增长。

为什么需要改善可扩展性？

摩尔定律…从本质上讲，在相同的价格上，数据中心的处理能力是持续快速增长的。作为一个例子，请考虑以下商用服务器：

• 2009 – 8 cores, 16GB of RAM, 4x1TB disk
• 2012 – 16+ cores, 48-96GB of RAM, 12x2TB or 12x3TB of disk.

一般来说，在同一个价格上，服务器的今天的处理能力是2-3年前的两倍 – 在每一个维度上。Apache Hadoop MapReduce已知的在2009年已经在生产部署上扩展到了5000个节点。因此，持续的可扩展性需求永远存在于硬件发展趋势上。

集群利用率低的场景是什么？

在目前的系统下，JobTracker通过节点上的map slots和reduce slots，掌握着整个集群，这是不可替代的。利用率问题出现了，由于map slots可能是“满的”，而reduce slots确是空的（反之亦然）。修复这个问题对达到整体集群最大的利用率是必要的。

什么是客户敏捷性？

在现实中，Hadoop部署共享的多用户系统是很常见的需求。结果就是Hadoop软件层面的变动会对基本整个企业造成大规模的影响。所以客户热衷于可控的软件层面的升级，这将只会影响app层面。因此，允许多个，有限的，MapReduce框架版本是至关重要的。

进入 APACHE HADOOP YARN

YARN的基本思想是隔离JobTracker这两个主要的职责，即隔离资源管理和作业调度/监控到不同的进程：一个全局的ResourceManager和预先启动的ApplicationMaster(AM)。

ResourceManager， per-node slave, the NodeManager (NM) 形成了新的，通用的，系统化的以分布式的方式管理app。

ResourceManager拥有系统中所有app的资源使用决定权。实际上每个app的ApplicationMaster是一个具体的框架，负责同ResourceManager协商资源，和NodeManager一起执行和监控组件的tasks。

ResourceManager有一个插件化的 Scheduler， 根据能力制约和队列等来负责分配资源给各种正在运行的app。这个Scheduler是一个纯粹的调度，它不负责监控或者app的状态跟踪，提供并不完全保证的失败tasks，app失败或者硬件故障的重启。这个Scheduler体现他的调度功能基于app资源需求；这样基于抽象概念，整合资源元素于内存，cpu，磁盘，网络等到Resource Container。

NodeManager是一个每台机器的slave，负责启动app的containers，监控它们的资源使用（cpu，内存，磁盘，网络）并报告给ResourceManager。

每个app的ApplicationMaster负责从Scheduler协商适当的resource containers，跟踪状态，监控进度。从系统角度来看，ApplicationMaster自己也是作为一个普通container运行的。

这是YARN的架构图：

我想指出的使用新的YARN系统对于MapReduce的一个关键细节是，我们可以重用现有的MapReduce框架不用任何大的修改。这是对兼容性是非常重要的对于现有的MapReduce应用和用户来说。将来也会如此。