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

Corona是什么?

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

Corona和MapReduce的區(qū)別：

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

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

Corona的優(yōu)點：

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

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

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

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

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

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

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

一個Corona MapReduce集群包含如下的組件：

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

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

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

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

代理Job追蹤器：job運行時的詳細(xì)信息通過它來追蹤。當(dāng)job結(jié)束時job追蹤器就關(guān)閉了，因此需要另外一個服務(wù)器去追蹤job的細(xì)節(jié)。為了保證job的追蹤不會被中斷，job的URL通常都是指向一個代理服務(wù)器。當(dāng)job開始運行時，代理就重定向到Corona job追蹤器。當(dāng)job運行結(jié)束時，在HDFS上就會生成一個文件，這個未見被代理Job追蹤器讀入，這樣就獲得了job運行時的詳細(xì)信息。此外代理job追蹤器也存儲和報告集群中所有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個之多，并且在四年里其數(shù)據(jù)倉庫增長了近2500倍。這些都已經(jīng)讓傳統(tǒng)的MapReduce無法應(yīng)對了。

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

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

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