Facebook最近在他們官方Github上發(fā)布了Corona的開源版本，聲稱這是下一代MapReduce，他們馬上將用這一新技術(shù)替代他們的Hadoop系統(tǒng)中的MapReduce。

Corona是什么?

簡(jiǎn)單來講，Corona就是一個(gè)取代MapReduce用來調(diào)度Hadoop job的新的系統(tǒng)。其目的是為了更好的利用集群的資源，同時(shí)能夠讓Hadoop的應(yīng)用范圍更廣。

Corona和MapReduce的區(qū)別：

如今的Map-Reduce都是使用一個(gè)單一的job追蹤器，不過它在Facebook上的處理能力已達(dá)到了瓶頸。Job追蹤器在管理集群資源的同時(shí)追蹤每一個(gè)job的狀態(tài)。在Hadoop Corona上，集群資源是由一組中央集群來進(jìn)行管理的。每一個(gè)job都有自己專屬的Corona job追蹤器進(jìn)行追蹤，而且每個(gè)追蹤器只追蹤一個(gè)job。

相比傳統(tǒng)的MapReduce只對(duì)“map”和“reduce”進(jìn)行管理，Corona最大的一個(gè)進(jìn)步就是做到了基于CPU，內(nèi)存和其他job處理的需求資源的管理。這就可以使得Corona可以處理非MapReduce job，使Hadoop集群的應(yīng)用領(lǐng)域更加廣泛了。

Corona的優(yōu)點(diǎn)：

在2012年中旬的時(shí)候，測(cè)試結(jié)果達(dá)到了預(yù)期的效果，資源閑置的時(shí)間下降了17%，資源的利用率從常規(guī)的MapReduce 70%提高到了95%，資源的unfairness從14.3%下降到了3.6%，而且延遲也4分鐘才發(fā)生一次。

相比傳統(tǒng)的MapReduce只對(duì)“map”和“reduce”進(jìn)行管理，Corona最大的一個(gè)進(jìn)步就是做到了基于CPU，內(nèi)存和其他job處理的需求資源的管理。這就可以使得Corona可以處理非MapReduce job，使Hadoop集群的應(yīng)用領(lǐng)域更加廣泛了。

- 擴(kuò)展性 - 集群管理中心對(duì)每個(gè)job只需追蹤少量的信息，而且每個(gè)job都由單獨(dú)的Corona job追蹤器進(jìn)行追蹤。這樣就使得job的數(shù)量和規(guī)模有了更好的擴(kuò)展性，也不用進(jìn)行Admission控制了。

- 延遲時(shí)間 - 任務(wù)調(diào)度工作使用了推送模型。一個(gè)Corona job追蹤器將資源請(qǐng)求推送到集群管理中心去，集群管理中心再將資源使用許可應(yīng)答推回到j(luò)ob追蹤器。收到了資源使用許可應(yīng)答后，Corona的job追蹤器將任務(wù)再推到task追蹤器上去。這和目前的Map-Reduce形成了鮮明的對(duì)比，因?yàn)镸apReduce的task調(diào)度工作每次在收到heartbeat信號(hào)時(shí)才執(zhí)行。而處理一些小規(guī)模的job時(shí)，heartbeat產(chǎn)生的延遲就會(huì)很明顯。

- 公平性 - Corona把集群分配到資源池中以保證資源的公平使用，這比MapReduce要好的多。

- 集群的利用率 - 由于減少了常規(guī)調(diào)度的開銷，Corona在Task追蹤器上的工作就更有效率。這樣的話集群就可以負(fù)載更多的任務(wù)。

Corona的結(jié)構(gòu)：

一個(gè)Corona MapReduce集群包含如下的組件：

圖：Corona體系結(jié)構(gòu)(圖片來自Johan Swanepoel)

集群管理中心：每個(gè)集群只有一個(gè)集群管理中心。它主要負(fù)責(zé)給每個(gè)job分配slots。(使用Fair Scheduler)集群管理中心只追蹤集群中不同的機(jī)器的使用情況以及為不同的job分配的計(jì)算資源。它和具體job的實(shí)際運(yùn)行沒多大關(guān)系。集群管理中心不僅僅用于MapReduce。在將來它還會(huì)被用到各種分布式架構(gòu)計(jì)算資源的分配之中。

Task追蹤器：這和經(jīng)典Hadoop中的一樣。所有的Task追蹤器向集群管理中心反饋可用的計(jì)算資源。這些Task追蹤器也向job追蹤器發(fā)出實(shí)際運(yùn)行MapReduce的指令。

Corona Job 追蹤器：用于實(shí)現(xiàn)job追蹤功能。它可以在兩種不同的模式下運(yùn)行：做為執(zhí)行job的客戶機(jī)的一部分或者做為在Task追蹤器集群中的一個(gè)task。第一種模式可以給小規(guī)模的job表現(xiàn)良好的延遲時(shí)間，第二種模式可以有效減少大型的job的heartbeat在集群上的輸入輸出的阻塞。

代理Job追蹤器：job運(yùn)行時(shí)的詳細(xì)信息通過它來追蹤。當(dāng)job結(jié)束時(shí)job追蹤器就關(guān)閉了，因此需要另外一個(gè)服務(wù)器去追蹤job的細(xì)節(jié)。為了保證job的追蹤不會(huì)被中斷，job的URL通常都是指向一個(gè)代理服務(wù)器。當(dāng)job開始運(yùn)行時(shí)，代理就重定向到Corona job追蹤器。當(dāng)job運(yùn)行結(jié)束時(shí)，在HDFS上就會(huì)生成一個(gè)文件，這個(gè)未見被代理Job追蹤器讀入，這樣就獲得了job運(yùn)行時(shí)的詳細(xì)信息。此外代理job追蹤器也存儲(chǔ)和報(bào)告集群中所有job的指標(biāo)信息。

Facebook為什么要自己開發(fā)?

根據(jù)Facebook的工程師Avery Ching、Ravi Murthy、Dmytro Molkov、Ramkumar Vadali、Paul Yang近期發(fā)表的一篇關(guān)于Corona細(xì)節(jié)的微博中描述，公司最大的集群有100多Petabytes(1PB = 1000TB)，其每天要處理的Hive查詢有60,000個(gè)之多，并且在四年里其數(shù)據(jù)倉庫增長(zhǎng)了近2500倍。這些都已經(jīng)讓傳統(tǒng)的MapReduce無法應(yīng)對(duì)了。

對(duì)Hadoop領(lǐng)域比較熟悉的人可能會(huì)問Facebook為什么要做Corona，因?yàn)镃orona的新功能和Hadoop新版本非常相似。最新版的Apache Hadoop已經(jīng)把Apache YARN 項(xiàng)目集成了進(jìn)來，將JobTracker分成了集群管理功能和job追蹤功能兩類不同的組件，而且也允許了非MapReduce任務(wù)在上面處理。此外，有許多商業(yè)的開源集群管理工具都有了他們自己的方法去解決Corona所要解決的問題，例如Apache Mesos。

然而，對(duì)Facebook比較了解的人都知道這個(gè)公司是一個(gè)不喜歡買別家軟件的公司。另外一點(diǎn)就是Apache的YARN不是很支持Facebook的獨(dú)特架構(gòu)。他們的微博中講到：

我們注意過Apache的YARN，然后在做過測(cè)試后發(fā)現(xiàn)，YARN在對(duì)我們最新的HDFS架構(gòu)上的PB級(jí)的數(shù)據(jù)進(jìn)行處理時(shí)的結(jié)果不是很令人滿意，比如處理時(shí)間，修復(fù)的風(fēng)險(xiǎn)，而且我們也不敢保證YARN能夠在我們Facebook的這個(gè)規(guī)模上正常工作。