下一代的APACHE HADOOP MAPREDUCE : YARN

最新推荐文章于 2024-11-16 21:11:17 发布

置顶快乐程序员

最新推荐文章于 2024-11-16 21:11:17 发布

阅读量1.4k

点赞数

分类专栏： yarn 文章标签： yarn hadoop mapreduce

yarn 专栏收录该内容

13 篇文章 0 订阅

订阅专栏

本文翻译自：http://developer.yahoo.com/blogs/hadoop/posts/2011/02/mapreduce-nextgen/

原文地址：http://www.rigongyizu.com/the-next-generation-of-apache-hadoop-mapreduce/

概述

在大数据商业领域，运行少而大的集群比运行很多小的集群成本更低。大集群能处理更大的数据集，并且能支持更多的任务和用户。

Apache Hadoop MapReduce框架的扩展能力已经达到了4000台机器的瓶颈。我们正在开发下一代的MapReduce框架，首要考虑的是把框架作为一个通用的资源调度和对每个任务能用户可以自定义的组件，来管理应用的执行。由于故障恢复时间更为昂贵，因此内建的高可用性是首要考虑的，同时安全性和多租户（multi-tenancy）以支持更多的用户也是需要考虑的。新的架构也增加了一些创新，灵活性和更好的硬件利用率。

背景

当前的Hadoop MapReduce框架已经不再适用。

随着集群规模增大和工作量变大，MapReduce JobTracker需要大规模的重构来解决扩展性，内存消耗，线程模型，可靠性和性能问题。在过去的5年，我们做些一些修修补补，但是最近这些修复的成本越来越高，这表明对原框架作出改变的难度越来越大。甚至早在2007年，我们已经认识到JobTracker架构上的缺陷，并在jira上进行了记录：MAPREDUCE-278 : Proposal for redesign/refactoring of the JobTracker and TaskTracker。

从操作的角度来看，目前的Hadoop MapReduce框架关注于为任何或大或小的bug修复，性能提升和功能改进进行系统级别的升级。更糟糕的是，它不管用户是否感兴趣，强制让分布式集群的每一个用户端同时更新，这会让用户仅仅只是为了验证他们的应用程序是否能在新版本的Hadoop上运行而浪费昂贵的时间。

需求

当我们考虑如何改进Hadoop Mapreduce框架，重要的是记住从一个更高的层次考虑。对下一代MapReduce框架最迫切的需求有：

可靠性
可用性
扩展性 – 10000台机器的集群和200000万个核，甚至更多
向后（和向前）的兼容性 – 确保用户的MapReduce程序能不需要修改就能运行在下一代MapReduce框架上
演变 – 能让客户控制Haodop软件的升级
可预见的延迟 – 客户主要关心的问题

其次要考虑的需求是：

支持MapReduce外的可选的编程范式
支持短生命周期的服务

鉴于上述要求，很显然，我们需要对Hadoop之上的数据处理基础设施重新思考。事实上，在Hadoop社区有一些松散的共识：目前的MapReduce框架的架构是无法满足我们的目标并需要重构。在2008年1月的JIRA上有我们当时的建议：MAPREDUCE-279 : Map-Reduce 2.0。

下一代的MapReduce

重构MapReduce架构的基本思想是将JobTracker分离为两个独立的组件：资源管理和任务调度/监控。新的资源管理器ResourceManager管理全局计算资源的分配；每一个应用的ApplicationMaster负责其调度和协调。一个应用程序可以是传统的MapReduce任务中单个的job，也可以是由任务组成的有向无环图(DAG)。ResourceManager和每台机器上管理用户进程的NodeManager服务，一起组成了计算框架。每个应用程序都有一个ApplicationMaster，它与此框架指定的类库一起，负责与ResourceManager协商资源，并协同NodeManager执行和监控任务。

ResourceManager支持多层级应用队列，可以给这些队列指定一定百分比的资源配额。ResourceManager是一个纯粹的调度器，它不负责应用运行状态的监控和跟踪。并且，它也不负责重启因为软件或硬件原因导致失败的任务。

ResourceManager的调度功能是基于应用程序的资源请求量的；每个应用都会有多种资源请求类型，表示资源容器(container)请求的资源。请求的资源类型包括内存，CPU，硬盘，网络等。注意，这和以前的基于槽位的slot模型相比是有显著的区别，槽位的管理方式给集群的资源利用率带来了很大的负面影响。ResourceManager提供一个调度策略插件，负责将集群中的资源划分到不同的队列中。资源调度插件可以基于现有的CapacityScheduler和FairScheduler等进行设计。

NodeManager作为集群每个节点上框架的代理，它负责启动应用程序的容器(container)，监控资源的使用情况(cpu,内存，磁盘，网络)，并汇报给资源调度器。

每个应用的ApplicationMaster，负责和资源调度器协商资源，启动任务，跟踪任务运行状态并监控进度，处理任务失败的情况。

架构图

Yarn Architecture

相比目前的Hadoop MapReduce提升的地方

扩展性

将资源的管理和应用生命周期的管理分离后，系统具有更好的可扩展性，更加优雅。原来的Hadoop MapReduce框架中的JobTracker耗费了大量的资源来跟踪应用生命周期，这是造成软件失误的重要原因。将JobTracker的角色由一个应用实体（ApplicationMaster）来指定是一个重大的改进。

从当前的硬件发展趋势来看，可扩展性就显得尤为重要 – 目前已经部署Hadoop MapReduce的集群达4000台。然而，2009年的4000台机器（即8核，16G内存，4TB磁盘）的处理能力只有2011年的4000台机器（16核，48G内存，24TB磁盘）的一半。此外，运营成本迫使我们去运行一个拥有6000台机器的，比以往任何时候都大的集群。

可用性

ResourceManager – 资源管理器使用Apache Zookeeper来进行fail-over.当资源管理器挂掉后，备用的资源管理器可以从Zookeeper中保存的状集群态中快速恢复。fail-over后的备用资源管理器（通过ResourceManager中的一个模块叫做ApplicationsMasters，注意不是ApplicationMaster)）可以重启所有队列中正在运行的应用。
ApplicationMaster – 下一代的MapReduce支持应用为ApplicationMaster指定检查点的能力。ApplicationMaster可以从HDFS上保存的状态中进行失败恢复。

兼容性

下一代的MapReduce使用兼容的协议以允许不同版本的服务器和客户端通信。在未来的版本中，将支持对集群的更新进行回滚 – 在可操作性方面是一次重要提升。

创新 & 灵活性

架构方面一个重大的提议是MapReduce成为一个客户端的库。计算框架（资源管理器和节点管理器）变得很通用，完全不受MapReduce编程模型的约束。

这使得终端用户可以在一个集群上同时使用不同版本的MapReduce。这个微不足道的支持，可以让不同的应用使用不同版本的MapReduce ApplicationMaster和运行时。这为各个应用的bug修复，改进和添加新功能提供了极大的灵活性，因为不再需要升级整个集群了。它还允许终端用户能在自己的计划下升级各自应用的MapReduce版本，显著地提高了集群的可操作性。

能运行用户定义的Map-Reduce版本的能力促进了创新，而不影响集群的稳定性。将Hadoop在线原型的特点整合到用户的MapReduce版本中，而不影响其他用户，将变得异常容易。