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

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

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的这个规模上正常工作。

责任编辑:王程程 来源: Gigaom
相关推荐

2010-05-28 11:21:17

2020-03-06 09:21:28

PWA原生应用Web

2020-02-02 15:42:22

PythonC++编程语言

2018-06-12 10:09:41

编程语言PythonJava

2014-03-06 15:07:41

青橙小米

2022-07-20 08:16:54

Lombokjava工具

2023-08-23 15:14:13

Web开发Javascript编程语言

2018-03-26 14:09:00

缓存Redis分布式缓存

2017-01-11 14:38:39

编程语言Java

2017-04-15 18:58:31

PythonRuby编程语言

2014-05-22 11:26:26

航班app体验

2020-01-18 14:55:03

架构运维技术

2022-08-24 08:00:00

Node.isJavaScriptDeno

2018-10-12 13:54:26

2010-05-02 14:43:43

Meego开发

2019-01-04 09:59:14

KafkaRabbitMQMQ

2017-11-13 15:38:03

VMwareOpenStack混合云

2023-08-09 18:08:35

ChatGPTStackOverflow

2010-07-27 14:36:31

Flex Array

2010-05-21 16:36:09

GoogleCode
点赞
收藏

51CTO技术栈公众号