==统一资源管理与调度平台(系统)介绍--YARN/Mesos

董的博客 » 统一资源管理与调度平台(系统)介绍
http://dongxicheng.org/mapreduce-nextgen/mesos_vs_yarn/

  1. 背景
    随着互联网的高速发展,基于数据密集型应用的计算框架不断出现,从支持离线处理的MapReduce,到支持在线处理的Storm,从迭代式计算框架Spark到流式处理框架S4,…,各种框架诞生于不同的公司或者实验室,它们各有所长,各自解决了某一类应用问题。而在大部分互联网公司中,这几种框架可能都会采用,比如对于搜索引擎公司,可能的技术方案如下:网页建索引采用MapReduce框架,自然语言处理/数据挖掘采用Spark(网页PageRank计算,聚类分类算法等,【注】Spark现在不太成熟,很少有公司尝试使用),对性能要求很高的数据挖掘算法用MPI等。考虑到资源利用率,运维成本,数据共享等因素,公司一般希望将所有这些框架部署到一个公共的集群中,让它们共享集群的资源,并对资源进行统一使用,这样,便诞生了资源统一管理与调度平台,典型代表是Mesos和YARN。
    本文总结了资源统一管理与调度平台产生背景以及它们所应具有的特点,并对比了当前比较有名的资源统一管理与调度平台Mesos和YARN。
  2. 资源统一管理和调度平台具有的特点
    (1)支持多种计算框架
    资源统一管理和调度平台应该提供一个全局的资源管理器。所有接入的框架要先向该全局资源管理器申请资源,申请成功之后,再由框架自身的调度器决定资源交由哪个任务使用,也就是说,整个大的系统是个双层调度器,第一层是统一管理和调度平台提供的,另外一层是框架自身的调度器。
    资源统一管理和调度平台应该提供资源隔离。不同的框架中的不同任务往往需要的资源(内存,CPU,网络IO等)不同,它们运行在同一个集群中,会相互干扰,为此,应该提供一种资源隔离机制避免任务之间由资源争用导致效率下降。
    (2)扩展性
    现有的分布式计算框架都会将系统扩展性作为一个非常重要的设计目标,比如Hadoop,好的扩展性意味着系统能够随着业务的扩展线性扩展。资源统一管理和调度平台融入多种计算框架后,不应该破坏这种特性,也就是说,统一管理和调度平台不应该成为制约框架进行水平扩展。
    (3)容错性
    同扩展性类似,容错性也是当前分布式计算框架的一个重要设计目标,统一管理和调度平台在保持原有框架的容错特性基础上,自己本身也应具有良好的容错性。
    (4) 高资源利用率
    如果采用静态资源分配,也就是每个计算框架分配一个集群,往往由于作业自身的特点或者作业提交频率等原因,集群利用率很低。当将各种框架部署到同一个大的集群中,进行统一管理和调度后,由于各种作业交错且作业提交频率大幅度升高,则为资源利用率的提升增加了机会。
    dynamic_sharing

(5)细粒度的资源分配
细粒度的资源分配是指直接按照任务实际需求分配资源,而不是像MapReduce那样将槽位作为资源分配单位。这种分配机制可大大提高资源利用率。

shared-framework

  1. 当前比较有名的开源资源统一管理和调度平台
    当前比较有名的开源资源统一管理和调度平台有两个,一个是Mesos,另外一个是YARN,下面依次对这两个系统进行介绍。
    3.1 Mesos
    Mesos诞生于UC Berkeley的一个研究项目,现已成为Apache Incubator中的项目,当前有一些公司使用Mesos管理集群资源,比如Twitter。


    mesos

    总体上看,Mesos是一个master/slave结构,其中,master是非常轻量级的,仅保存了framework(各种计算框架称为framework)和mesos slave的一些状态,而这些状态很容易通过framework和slave重新注册而重构,因而很容易使用了zookeeper解决mesos master的单点故障问题。
    Mesos master实际上是一个全局资源调度器,采用某种策略将某个slave上的空闲资源分配给某一个framework,各种framework通过自己的调度器向Mesos master注册,以接入到Mesos中;而Mesos slave主要功能是汇报任务的状态和启动各个framework的executor(比如Hadoop的excutor就是TaskTracker)。
    3.2 YARN
    YARN是下一代MapReduce,即MRv2,是在第一代MapReduce基础上演变而来的,主要是为了解决原始Hadoop扩展性较差,不支持多计算框架而提出的。它完全不同于Hadoop MapReduce,所有代码全部重写而成。整个平台由Resource Manager(master,功能是资源分配)和Node Manager组成(slave,功能是节点管理)。较于HadoopMapReduce,其最大特点是将JobTracker拆分成Resource Manager和Application Master,其中Resource Manager是全局的资源管理器,仅负责资源分配(由于Resource Manager功能简单,所以不会严重制约系统的扩展性),而Application Master对应一个具体的application(如Hadoop job, Spark Job等),主要负责application的资源申请,启动各个任务和运行状态监控(没有调度功能)。


    yarn
  2. Mesos与YARN比较
    Mesos与YARN主要在以下几方面有明显不同:
    (1)框架担任的角色
    在Mesos中,各种计算框架是完全融入Mesos中的,也就是说,如果你想在Mesos中添加一个新的计算框架,首先需要在Mesos中部署一套该框架;而在YARN中,各种框架作为client端的library使用,仅仅是你编写的程序的一个库,不需要事先部署一套该框架。从这点上说,YARN运行和使用起来更加方便。
    (2)调度机制
    两种系统都采用了双层调度机制,即,第一层是源管理系统(mesos/YARN)将资源分配给应用程序(或框架),第二层,应用程序将收到的资源进一步分配给内部的任务。但是资源分配器智能化程度不同,mesos是基于resource offer的调度机制,包含非常少的调度语义,他只是简单的将资源推给各个应用程序,由应用程序选择是否接受资源,而mesos本身并不知道各个应用程序资源需求;YARN则不同,应用程序的ApplicationMaster会把各个任务的资源要求汇报给YARN,YARN则根据需要为应用程序分配资源。
    其他各个特性对比如下表:
    mesos_vs_yarn

  1. Mesos与YARN发展情况
    个人认为Mesos和YARN均不成熟,很多承诺的功能还未实现或者实现得不全,但总体看,它们发展很快,尤其是YARN,在去年年末推出Hadoop-0.23.0后,近期又推出Hadoop-0.23.1。随着各种计算框架(如Spark,S4,Storm等)的日趋成熟,一个统一的资源管理和调度平台将不可或缺。
    另一个与Mesos和YARN类似的系统是Facebook开源的Hadoop Coroca,具体可参考:“Hadoop Corona介绍”
  2. 参考资料
    (1)Mesos论文:Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center. B. Hindman, A. Konwinski, M. Zaharia, A. Ghodsi, A.D. Joseph, R. Katz, S. Shenker and I. Stoica, NSDI 2011, March 2011.
    (2) Mesos官网:http://incubator.apache.org/mesos/index.html
    (3)YARN官网:http://hadoop.apache.org/common/docs/r0.23.0/index.html
    (4)下一代Apache Hadoop MapReduce框架的架构:
    http://dongxicheng.org/mapreduce-nextgen/nextgen-mapreduce-introduction/
    原创文章,转载请注明: 转载自董的博客
    本文链接地址: http://dongxicheng.org/mapreduce-nextgen/mesos_vs_yarn/

作者:Dong,作者介绍:http://dongxicheng.org/about/
本博客的文章集合:http://dongxicheng.org/recommend/

Hadoop, MapReduce NextGen, Mesos, MRv2, yarn, 下一代MapReduce

评论 (9)
引用通告 (0)

发表评论


1楼ye
回复
Post: 2012-06-08 07:21
我疯了,老大分布式计算的新技术层出不穷,刚看完mapreduce源码又看到spark 现在又是这些 神啊
[回复]
Dong
回复:六月 8th, 2012 at 下午 11:55

Hadoop,Spark,Storm,S4,……
[回复]


ye
回复:六月 21st, 2012 at 上午 8:24

经常看你的博客,以后请多多指教啊
[回复]


2楼yexiaojiang
回复
Post: 2012-06-29 08:20
能写篇介绍下各种分布式计算框架安装于同一组机器的文章吗?我想把各种框架都自己手动安装一下!
[回复]


3楼wangfeng
回复
Post: 2012-09-27 03:36
每个架构师为了解决一种业务问题,还是大同小异,解决问题的根本思路是一致的,只是宏观表现上不同,因为关注点不同
[回复]


4楼pinopino
回复
Post: 2012-10-22 03:15
我是一名.net下的普通程序员, 看过很多你博客上关于分布式技术的文章. 让我很奇怪, 也让我很纳闷的一点就是为嘛.net就没有这些生机勃勃的东西呢? 为嘛全都是java的全都是linux的? .net程序员干嘛去了呢?(额…好吧,我在写该死的CRUD)
[回复]
domain
回复:十一月 18th, 2013 at 上午 11:26

微软内部是有这样一套东西的,叫cosmos,我只能说,很有特色,主要是用来支撑bing的,虽然人家确实不开源吧,但做的也确实挺好的。上面的框架式scope,可以关注一下,这个上面发的paper很多。微软对Hadoop也有贡献呀,比如说REEF
[回复]


5楼Dong
回复
Post: 2012-10-23 01:09
.net是微软的, 光凭这个,就不可能收到开源届青睐,怎么可能生机勃勃, .net只能是个封闭的技术, 永不可能生机勃勃。以后的发展趋势是,一个技术,走封闭路线,不开源,则不可能流行起来, 就跟symbian之与andriod一样
[回复]
.V
回复:四月 11th, 2013 at 下午 1:12

Microsoft有Dryad (类似MR parallel computing), Daytona (类似迭代MR计算), Windows Azure (PaaS Clud), .NET Hadoop,开源的分布式引擎和框架都会支持多种接口的,.NET一样可以用的,其实作为一名程序架构师,还是应该全面了解,各网络公司为着自己的业务提出各类计算模型和框架,并不奇怪,并极力开源以获取更多.
我倒是希望Google能开源更多新的计算框架和系统,类似Pregel, BigQuery, Spanner,省的那帮Google跳出去的人叽叽喳喳的参考开发出这许多Hadoop/MR/Mesos/S4/…
[回复]


Dong
回复:四月 11th, 2013 at 下午 11:46

这些开源系统的架构是google提出来的,但是开源届做的时候可能最终将这个系统做的面目全非了,甚至可能google会反过来借鉴很多开源的idea丰富到自己的系统上。另外,有些系统并不是google首先提出来的(至少出现前google并没有透露任何消息),比如Hive(09年,google关于tenzing、dremel的论文发表于11和10年),mesos(这个就更早了)。随着开源概念的深入人心,很多新颖的系统会出现,这些系统,google并不一定有,相反,google可能会反过来学习。 google当初开源的MapReduce,GFS等论文推动了开源的飞速发展,但一旦发展到一定程度,各种创造性的系统就会出现。毕竟,开源实际上是一种“群体智慧”的体现,这里的群体是全世界范围内的hacker。
[回复]


6楼封神
回复
Post: 2013-01-08 09:11
其实都是双层的,只是粒度的问题。我感觉两者都差不多,做到最后会很相似的。
[回复]


7楼weirorange7
回复
Post: 2014-03-11 07:42
您好,本篇文章中在与mesos的对比中说yarn是单层调度,但是在您的书中,第161页说yarn是双层资源调度模型,正确的应该是哪一个呢?还有就是yarn分配任务的时候,是只分配到应用程序这一层,还是到具体的任务呢?谢谢您啦
[回复]
Dong
回复:三月 11th, 2014 at 上午 9:44

之前理解有误,现在已经修改了,看现在的内容。
[回复]


8楼modeyangg
回复
Post: 2014-03-17 01:20
您好,很喜欢您的博客和微信,看完这篇文章有几个问题想请教一下。1. 本文中对于YARN的框架图里面的Container是做什么用的?我你文章中写到YARN的隔离性是进程级别,不存在像mesos那样利用linux container将每个任务隔离起来。2. YARN对于容灾性的处理还能不能详细一点介绍,我看您说的定时将任务保存在磁盘,那如果宕机了怎么办呢? 这点Mesos如果在slave宕机后,Framework/master就会监听到slave的状态,将在这个slave中的任务重新分配,以保证任务的成功执行。这两个框架对于容灾性处理优劣能分析下吗?3. 如你本文中讲到,Mesos和YARN在任务资源分配中存在很大不同,Mesos是不能够感知到任务的资源要求的,而由Framework内部的二次调度完成,而YARN里面,应用程序ApplicationMaster会把各个任务的资源要求汇报给YARN,YARN则根据需要为应用程序分配资源。我想问的是,在YARN中如何确定每个任务的资源要求呢? 经验值还是?可能对于YARN还不怎么了解,望回复,谢谢。
[回复]
Dong
回复:三月 18th, 2014 at 上午 12:42

  1. Container就是一个抽象概念,封转了任务执行所需的环境、资源等信息, 这篇文章比较早了,现在YARN已经像Mesos一样,提供了cgroups隔离机制。2. YARN目前也不太适合运行长服务,应以像map task或者reduce task这样的短任务为主,这主要是因为yarn直接从mapreduce过渡来的,而mesos不同,他先天就考虑到了部署长服务。 不过yarn正在朝着方面发展。3. 用户提交应用程序时,需指定你的task需要的资源量,这个值是用户自己确定的(默认值),一般是经验值,或者估算值。目前这方面还难以做到智能推测。
    [回复]


    modeyangg
    回复:三月 18th, 2014 at 上午 1:45

谢谢回复,正在拜读您的别的文章,希望能多多指教。
[回复]


9楼SelfMedicated
回复
Post: 2014-06-19 03:22
董大哥,能否把你写的文章加上一个文章发表时间,因为文章的内容(比如“该开源软件目前还很不稳定”),是基于时间的,当然从评论也能粗略看出时间,但不准确….
[回复]

推荐阅读更多精彩内容