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应用和用户来说。将来也会如此。