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的這個規模上正常工作。