董的博客 ? 統一資源管理與調度平臺（系統）介紹
http://dongxicheng.org/mapreduce-nextgen/mesos_vs_yarn/

1. 背景
   隨著互聯網的高速發展，基于數據密集型應用的計算框架不斷出現，從支持離線處理的MapReduce，到支持在線處理的Storm，從迭代式計算框架Spark到流式處理框架S4，…，各種框架誕生于不同的公司或者實驗室，它們各有所長，各自解決了某一類應用問題。而在大部分互聯網公司中，這幾種框架可能都會采用，比如對于搜索引擎公司，可能的技術方案如下：網頁建索引采用MapReduce框架，自然語言處理/數據挖掘采用Spark（網頁PageRank計算，聚類分類算法等，【注】Spark現在不太成熟，很少有公司嘗試使用），對性能要求很高的數據挖掘算法用MPI等。考慮到資源利用率，運維成本，數據共享等因素，公司一般希望將所有這些框架部署到一個公共的集群中，讓它們共享集群的資源，并對資源進行統一使用，這樣，便誕生了資源統一管理與調度平臺，典型代表是Mesos和YARN。
   本文總結了資源統一管理與調度平臺產生背景以及它們所應具有的特點，并對比了當前比較有名的資源統一管理與調度平臺Mesos和YARN。
2. 資源統一管理和調度平臺具有的特點
   （1）支持多種計算框架
   資源統一管理和調度平臺應該提供一個全局的資源管理器。所有接入的框架要先向該全局資源管理器申請資源，申請成功之后，再由框架自身的調度器決定資源交由哪個任務使用，也就是說，整個大的系統是個雙層調度器，第一層是統一管理和調度平臺提供的，另外一層是框架自身的調度器。
   資源統一管理和調度平臺應該提供資源隔離。不同的框架中的不同任務往往需要的資源（內存，CPU，網絡IO等）不同，它們運行在同一個集群中，會相互干擾，為此，應該提供一種資源隔離機制避免任務之間由資源爭用導致效率下降。
   （2）擴展性
   現有的分布式計算框架都會將系統擴展性作為一個非常重要的設計目標，比如Hadoop，好的擴展性意味著系統能夠隨著業務的擴展線性擴展。資源統一管理和調度平臺融入多種計算框架后，不應該破壞這種特性，也就是說，統一管理和調度平臺不應該成為制約框架進行水平擴展。
   （3）容錯性
   同擴展性類似，容錯性也是當前分布式計算框架的一個重要設計目標，統一管理和調度平臺在保持原有框架的容錯特性基礎上，自己本身也應具有良好的容錯性。
   （4） 高資源利用率
   如果采用靜態資源分配，也就是每個計算框架分配一個集群，往往由于作業自身的特點或者作業提交頻率等原因，集群利用率很低。當將各種框架部署到同一個大的集群中，進行統一管理和調度后，由于各種作業交錯且作業提交頻率大幅度升高，則為資源利用率的提升增加了機會。
   
   dynamic_sharing

（5）細粒度的資源分配
細粒度的資源分配是指直接按照任務實際需求分配資源，而不是像MapReduce那樣將槽位作為資源分配單位。這種分配機制可大大提高資源利用率。

shared-framework

3. 當前比較有名的開源資源統一管理和調度平臺
   當前比較有名的開源資源統一管理和調度平臺有兩個，一個是Mesos，另外一個是YARN，下面依次對這兩個系統進行介紹。
   3.1 Mesos
   Mesos誕生于UC Berkeley的一個研究項目，現已成為Apache Incubator中的項目，當前有一些公司使用Mesos管理集群資源，比如Twitter。

   
   
   mesos
   
   

   總體上看，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的資源申請，啟動各個任務和運行狀態監控（沒有調度功能）。

   
   
   yarn
4. Mesos與YARN比較
   Mesos與YARN主要在以下幾方面有明顯不同：
   （1）框架擔任的角色
   在Mesos中，各種計算框架是完全融入Mesos中的，也就是說，如果你想在Mesos中添加一個新的計算框架，首先需要在Mesos中部署一套該框架；而在YARN中，各種框架作為client端的library使用，僅僅是你編寫的程序的一個庫，不需要事先部署一套該框架。從這點上說，YARN運行和使用起來更加方便。
   （2）調度機制
   兩種系統都采用了雙層調度機制，即，第一層是源管理系統（mesos/YARN）將資源分配給應用程序（或框架），第二層，應用程序將收到的資源進一步分配給內部的任務。但是資源分配器智能化程度不同，mesos是基于resource offer的調度機制，包含非常少的調度語義，他只是簡單的將資源推給各個應用程序，由應用程序選擇是否接受資源，而mesos本身并不知道各個應用程序資源需求；YARN則不同，應用程序的ApplicationMaster會把各個任務的資源要求匯報給YARN，YARN則根據需要為應用程序分配資源。
   其他各個特性對比如下表：
   
   mesos_vs_yarn

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/

Hadoop, MapReduce NextGen, Mesos, MRv2, yarn, 下一代MapReduce

評論 (9)
引用通告 (0)

發表評論

Hadoop，Spark，Storm，S4，……
[回復]

ye
回復:六月 21st, 2012 at 上午 8:24

經常看你的博客，以后請多多指教啊
[回復]

微軟內部是有這樣一套東西的，叫cosmos，我只能說，很有特色，主要是用來支撐bing的，雖然人家確實不開源吧，但做的也確實挺好的。上面的框架式scope，可以關注一下，這個上面發的paper很多。微軟對Hadoop也有貢獻呀，比如說REEF
[回復]

Microsoft有Dryad (類似MR parallel computing), Daytona (類似迭代MR計算), Windows Azure (PaaS Clud), .NET Hadoop,開源的分布式引擎和框架都會支持多種接口的,.NET一樣可以用的,其實作為一名程序架構師,還是應該全面了解,各網絡公司為著自己的業務提出各類計算模型和框架,并不奇怪,并極力開源以獲取更多.
我倒是希望Google能開源更多新的計算框架和系統,類似Pregel, BigQuery, Spanner,省的那幫Google跳出去的人嘰嘰喳喳的參考開發出這許多Hadoop/MR/Mesos/S4/…
[回復]

Dong
回復:四月 11th, 2013 at 下午 11:46

這些開源系統的架構是google提出來的，但是開源屆做的時候可能最終將這個系統做的面目全非了，甚至可能google會反過來借鑒很多開源的idea豐富到自己的系統上。另外，有些系統并不是google首先提出來的（至少出現前google并沒有透露任何消息），比如Hive（09年，google關于tenzing、dremel的論文發表于11和10年），mesos（這個就更早了）。隨著開源概念的深入人心，很多新穎的系統會出現，這些系統，google并不一定有，相反，google可能會反過來學習。 google當初開源的MapReduce，GFS等論文推動了開源的飛速發展，但一旦發展到一定程度，各種創造性的系統就會出現。畢竟，開源實際上是一種“群體智慧”的體現，這里的群體是全世界范圍內的hacker。
[回復]

之前理解有誤，現在已經修改了，看現在的內容。
[回復]

1. Container就是一個抽象概念，封轉了任務執行所需的環境、資源等信息， 這篇文章比較早了，現在YARN已經像Mesos一樣，提供了cgroups隔離機制。2. YARN目前也不太適合運行長服務，應以像map task或者reduce task這樣的短任務為主，這主要是因為yarn直接從mapreduce過渡來的，而mesos不同，他先天就考慮到了部署長服務。 不過yarn正在朝著方面發展。3. 用戶提交應用程序時，需指定你的task需要的資源量，這個值是用戶自己確定的（默認值），一般是經驗值，或者估算值。目前這方面還難以做到智能推測。
   [回復]

   
   

   modeyangg
   回復:三月 18th, 2014 at 上午 1:45

謝謝回復，正在拜讀您的別的文章，希望能多多指教。
[回復]