1. 背景
隨着互聯網的高速發展，基於數據密集型應用的計算框架不斷出現，從支持離線處理的MapReduce，到支持在線處理的Storm，從迭代式計算框架Spark到流式處理框架S4，…，各種框架誕生於不同的公司或者實驗室，它們各有所長，各自解決了某一類應用問題。而在大部分互聯網公司中，這幾種框架可能都會採用，比如對於搜索引擎公司，可能的技術方案如下：網頁建索引採用MapReduce框架，自然語言處理/數據挖掘採用Spark（網頁PageRank計算，聚類分類算法等，【注】Spark現在不太成熟，很少有公司嘗試使用），對性能要求很高的數據挖掘算法用MPI等。考慮到資源利用率，運維成本，數據共享等因素，公司一般希望將所有這些框架部署到一個公共的集羣中，讓它們共享集羣的資源，並對資源進行統一使用，這樣，便誕生了資源統一管理與調度平臺，典型代表是Mesos和YARN。
本文總結了資源統一管理與調度平臺產生背景以及它們所應具有的特點，並對比了當前比較有名的資源統一管理與調度平臺Mesos和YARN。
2. 資源統一管理和調度平臺具有的特點
（1）支持多種計算框架
資源統一管理和調度平臺應該提供一個全局的資源管理器。所有接入的框架要先向該全局資源管理器申請資源，申請成功之後，再由框架自身的調度器決定資源交由哪個任務使用，也就是說，整個大的系統是個雙層調度器，第一層是統一管理和調度平臺提供的，另外一層是框架自身的調度器。
資源統一管理和調度平臺應該提供資源隔離。不同的框架中的不同任務往往需要的資源（內存，CPU，網絡IO等）不同，它們運行在同一個集羣中，會相互干擾，爲此，應該提供一種資源隔離機制避免任務之間由資源爭用導致效率下降。
（2）擴展性
現有的分佈式計算框架都會將系統擴展性作爲一個非常重要的設計目標，比如Hadoop，好的擴展性意味着系統能夠隨着業務的擴展線性擴展。資源統一管理和調度平臺融入多種計算框架後，不應該破壞這種特性，也就是說，統一管理和調度平臺不應該成爲制約框架進行水平擴展。
（3）容錯性
同擴展性類似，容錯性也是當前分佈式計算框架的一個重要設計目標，統一管理和調度平臺在保持原有框架的容錯特性基礎上，自己本身也應具有良好的容錯性。
（4） 高資源利用率
如果採用靜態資源分配，也就是每個計算框架分配一個集羣，往往由於作業自身的特點或者作業提交頻率等原因，集羣利用率很低。當將各種框架部署到同一個大的集羣中，進行統一管理和調度後，由於各種作業交錯且作業提交頻率大幅度升高，則爲資源利用率的提升增加了機會。
（5）細粒度的資源分配
細粒度的資源分配是指直接按照任務實際需求分配資源，而不是像MapReduce那樣將槽位作爲資源分配單位。這種分配機制可大大提高資源利用率。
3. 當前比較有名的開源資源統一管理和調度平臺
當前比較有名的開源資源統一管理和調度平臺有兩個，一個是Mesos，另外一個是YARN，下面依次對這兩個系統進行介紹。
3.1 Mesos
Mesos誕生於UC Berkeley的一個研究項目，現已成爲Apache Incubator中的項目，當前有一些公司使用Mesos管理集羣資源，比如Twitter。
總體上看，Mesos是一個master/slave結構，其中，master是非常輕量級的，僅保存了framework（各種計算框架稱爲framework）和mesos slave的一些狀態，而這些狀態很容易通過framework和slave重新註冊而重構，因而很容易使用了zookeeper解決mesos master的單點故障問題。
Mesos master實際上是一個全局資源調度器，採用某種策略將某個slave上的空閒資源分配給某一個framework，各種framework通過自己的調度器向Mesos master註冊，以接入到Mesos中；而Mesos slave主要功能是彙報任務的狀態和啓動各個framework的executor（比如Hadoop的excutor就是TaskTracker）。
3.2 YARN
YARN是下一代MapReduce，即MRv2，是在第一代MapReduce基礎上演變而來的，主要是爲了解決原始Hadoop擴展性較差，不支持多計算框架而提出的。它完全不同於Hadoop MapReduce，所有代碼全部重寫而成。整個平臺由Resource Manager（master，功能是資源分配）和Node Manager組成（slave，功能是節點管理）。較於HadoopMapReduce，其最大特點是將JobTracker拆分成Resource Manager和Application Master，其中Resource Manager是全局的資源管理器，僅負責資源分配（由於Resource Manager功能簡單，所以不會嚴重製約系統的擴展性），而Application Master對應一個具體的application（如Hadoop job， Spark Job等），主要負責application的資源申請，啓動各個任務和運行狀態監控（沒有調度功能）。
4. Mesos與YARN比較
Mesos與YARN主要在以下幾方面有明顯不同：
（1）框架擔任的角色
在Mesos中，各種計算框架是完全融入Mesos中的，也就是說，如果你想在Mesos中添加一個新的計算框架，首先需要在Mesos中部署一套該框架；而在YARN中，各種框架作爲client端的library使用，僅僅是你編寫的程序的一個庫，不需要事先部署一套該框架。從這點上說，YARN運行和使用起來更加方便。
（2）調度機制
Mesos採用了雙層調度策略，第一層是Mesos master將空閒資源分配給某個框架，而第二層是計算框架自帶的調度器對分配到的空閒資源進行分配，也就是說，Mesos將大部分調度任務授權給了計算框架；而YARN是一個單層調度架構，各種框架的任務一視同仁，全由Resource Manager進行統一調度。總結來說，Mesos master首先完成粗粒度的資源分配，即：將資源分配給框架，然後由框架進行細粒度的資源分配；而Resource manager直接進行細粒度的分配，即:直接將資源分配給某個任務（Task）。
其他各個特性對比如下表：
5. Mesos與YARN發展情況
個人認爲Mesos和YARN均不成熟，很多承諾的功能還未實現或者實現得不全，但總體看，它們發展很快，尤其是YARN，在去年年末推出Hadoop-0.23.0後，近期又推出Hadoop-0.23.1。隨着各種計算框架（如Spark，S4，Storm等）的日趨成熟，一個統一的資源管理和調度平臺將不可或缺。
另一個與Mesos和YARN類似的系統是Facebook開源的Hadoop Coroca，具體可參考：“Hadoop Corona介紹”。
6. 參考資料
（1）Mesos論文：Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center. B. Hindman, A. Konwinski, M. Zaharia, A. Ghodsi, A.D. Joseph, R. Katz, S. Shenker and I. Stoica, NSDI 2011, March 2011.
（2） Mesos官網：http://incubator.apache.org/mesos/index.html
（3）YARN官網：http://hadoop.apache.org/common/docs/r0.23.0/index.html
（4）下一代Apache Hadoop MapReduce框架的架構：
http://dongxicheng.org/mapreduce-nextgen/nextgen-mapreduce-introduction/
原創文章，轉載請註明： 轉載自董的博客
本文鏈接地址: http://dongxicheng.org/mapreduce-nextgen/mesos_vs_yarn/
作者：Dong，作者介紹：http://dongxicheng.org/about/
本博客的文章集合:http://dongxicheng.org/recommend/