订阅云计算RSS CSDN首页> 云计算

Facebook重做MapReduce,Corona比YARN更胜一筹?

发表于2012-11-13 12:16| 次阅读| 来源Gigaom,Facebook Github| 0 条评论| 作者康文博

摘要:Facebook最近开源了一个名叫Corona的架构,用来调度和管理Hadoop job。Corona解决了Hadoop在大规模集群运维上的问题,Facebook似乎很快就要用Corona代替以往MapReduce了。

【CSDN报道】Facebook最近在他们官方Github上发布了Corona的开源版本,声称这是下一代MapReduce,他们马上将用这一新技术替代他们的Hadoop系统中的MapReduce。

Corona是什么?

简单来讲,Corona就是一个取代MapReduce用来调度Hadoop job的新的系统。其目的是为了更好的利用集群的资源,同时能够让Hadoop的应用范围更广。

Corona和MapReduce的区别:

如今的Map-Reduce都是使用一个单一的job追踪器,不过它在Facebook上的处理能力已达到了瓶颈。Job追踪器在管理集群资源的同时追踪每一个job的状态。在Hadoop Corona上,集群资源是由一组中央集群来进行管理的。每一个job都有自己专属的Corona job追踪器进行追踪,而且每个追踪器只追踪一个job。

相比传统的MapReduce只对“map”和“reduce”进行管理,Corona最大的一个进步就是做到了基于CPU,内存和其他job处理的需求资源的管理。这就可以使得Corona可以处理非MapReduce job,使Hadoop集群的应用领域更加广泛了。

Corona的优点:

在2012年中旬的时候,测试结果达到了预期的效果,资源闲置的时间下降了17%,资源的利用率从常规的MapReduce 70%提高到了95%,资源的unfairness从14.3%下降到了3.6%,而且延迟也4分钟才发生一次。

相比传统的MapReduce只对“map”和“reduce”进行管理,Corona最大的一个进步就是做到了基于CPU,内存和其他job处理的需求资源的管理。这就可以使得Corona可以处理非MapReduce job,使Hadoop集群的应用领域更加广泛了。

- 扩展性 - 集群管理中心对每个job只需追踪少量的信息,而且每个job都由单独的Corona job追踪器进行追踪。这样就使得job的数量和规模有了更好的扩展性,也不用进行Admission控制了。

- 延迟时间 - 任务调度工作使用了推送模型。一个Corona job追踪器将资源请求推送到集群管理中心去,集群管理中心再将资源使用许可应答推回到job追踪器。收到了资源使用许可应答后,Corona的job追踪器将任务再推到task追踪器上去。这和目前的Map-Reduce形成了鲜明的对比,因为MapReduce的task调度工作每次在收到heartbeat信号时才执行。而处理一些小规模的job时,heartbeat产生的延迟就会很明显。

- 公平性 - Corona把集群分配到资源池中以保证资源的公平使用,这比MapReduce要好的多。

- 集群的利用率 - 由于减少了常规调度的开销,Corona在Task追踪器上的工作就更有效率。这样的话集群就可以负载更多的任务。

Corona的结构:

一个Corona MapReduce集群包含如下的组件:

图:Corona体系结构(图片来自Johan Swanepoel

集群管理中心:每个集群只有一个集群管理中心。它主要负责给每个job分配slots。(使用Fair Scheduler)集群管理中心只追踪集群中不同的机器的使用情况以及为不同的job分配的计算资源。它和具体job的实际运行没多大关系。集群管理中心不仅仅用于MapReduce。在将来它还会被用到各种分布式架构计算资源的分配之中。

Task追踪器:这和经典Hadoop中的一样。所有的Task追踪器向集群管理中心反馈可用的计算资源。这些Task追踪器也向job追踪器发出实际运行MapReduce的指令。

Corona Job 追踪器:用于实现job追踪功能。它可以在两种不同的模式下运行:做为执行job的客户机的一部分或者做为在Task追踪器集群中的一个task。第一种模式可以给小规模的job表现良好的延迟时间,第二种模式可以有效减少大型的job的heartbeat在集群上的输入输出的阻塞。

代理Job追踪器:job运行时的详细信息通过它来追踪。当job结束时job追踪器就关闭了,因此需要另外一个服务器去追踪job的细节。为了保证job的追踪不会被中断,job的URL通常都是指向一个代理服务器。当job开始运行时,代理就重定向到Corona job追踪器。当job运行结束时,在HDFS上就会生成一个文件,这个未见被代理Job追踪器读入,这样就获得了job运行时的详细信息。此外代理job追踪器也存储和报告集群中所有job的指标信息。

Facebook为啥要自己开发?

根据Facebook的工程师Avery Ching、Ravi Murthy、Dmytro Molkov、Ramkumar Vadali、Paul Yang近期发表的一篇关于Corona细节的微博中描述,公司最大的集群有100多Petabytes(1PB = 1000TB),其每天要处理的Hive查询有60,000个之多,并且在四年里其数据仓库增长了近2500倍。这些都已经让传统的MapReduce无法应对了。

对Hadoop领域比较熟悉的人可能会问Facebook为什么要做Corona,因为Corona的新功能和Hadoop新版本非常相似。最新版的Apache Hadoop已经把Apache YARN 项目集成了进来,将JobTracker分成了集群管理功能和job追踪功能两类不同的组件,而且也允许了非MapReduce任务在上面处理。此外,有许多商业的开源集群管理工具都有了他们自己的方法去解决Corona所要解决的问题,例如Apache Mesos。

然而,对Facebook比较了解的人都知道这个公司是一个不喜欢买别家软件的公司。另外一点就是Apache的YARN不是很支持Facebook的独特架构。他们的微博中讲到:

我们注意过Apache的YARN,然后在做过测试后发现,YARN在对我们最新的HDFS架构上的PB级的数据进行处理时的结果不是很令人满意,比如处理时间,修复的风险,而且我们也不敢保证YARN能够在我们Facebook的这个规模上正常工作。(康文博/编译 包研/审校)

11月30日-12月1日,北京新云南皇冠假日酒店,中国业内将迎来大数据领域最纯粹的技术盛会——HBTC 2012(Hadoop&BigData Technology Conference 2012)。欢迎加入!

更多精彩内容,请关注新浪微博:@CSDN云计算HBTC 2012

0
0
Facebook重做MapReduce,Corona比YARN更胜一筹?