前言：
有一段時間沒有寫博客了(發現這是我博客最常見的開頭，不過這次間隔真的好長），前段時間事情比較多，所以耽擱得也很多。
現在准備計划寫一個新的專題，叫做《hadoop雜記》，里面的文章有深有淺，文章不是按入門-中級-高級的順序組織的，如果想看看從入門到深入的書，比較推薦《the definitive guide of hadoop》。
今天主要想寫寫關於map-reduce v2(或者叫map-reduce next generation，或者叫YARN)與之前的map-reduce有什么不同。最近在學習Yarn的過程中，也參考了很多人的博客，里面的介紹都各有所長。不過一個很重要的問題是，為什么需要一個Yarn，初看之后，也不覺得Yarn有什么特別的，就是把之前設計中的一塊拆成了幾塊，仔細想想，方才明白其中的奧妙。
理解本文需要對老的Map-reduce框架有一定的了解。有朋友如果對hadoop以及大數據處理的架構、應用的咨詢、討論等等可以按下一段的聯系方式與我聯系。
版權聲明：本文由leftnoteasy發布於http://leftnoteasy.cnblogs.com，本文可以部分或者全部的被引用，但請注明出處，可以聯系wheeleast (at) gmail.com, 也可以加我weibo: http://weibo.com/leftnoteasy
Why Yarn：
Map-reduce老矣，尚能飯否?
第一次看到Yarn的問題，就需要問問，為什么要重新設計之前這樣一個成熟的架構。
“The Apache Hadoop Map-reduce framework is showing it’s age, clearly”, 社區的Yarn設計文檔 ”MapReduce_NextGen-Architecture”如是說。
目前的Map-reduce framework碰到了很多的問題，比如說過於大的內存消耗、不合理的線程模型設計、當集群規模增大后，擴展性/穩定性/性能的不足。這是目前hadoop的集群一直停留在Yahoo公布出來的3000台這個數量級上。
為了克服之前說道的問題，就需要對目前架構上進行重新思考，之后我會對新老Map-reduce架構上進行比較。
Yarn的設計需求
這里放上設計需求不是為了湊字數的，最近越來越發現設計需求是軟件開發的靈魂，雖然需求常常變化可以喚醒植物人，不過一份好的設計需求可以讓之后怎么走變得非常清晰。參考自Yarn設計文檔：
最優先的需求：
· Reliability
· Availability
· Scalability - Clusters of 10000 nodes and 200,000 cores
· Backward Compatibility - Ensure customers’ Map-Reduce applications can run unchanged in the nextversion of the framework. Also implies forward compatibility. （向前兼容）
· Evolution – Ability for customers to control upgrades to the grid software stack.
· Predictable Latency – A major customer concern.
· Cluster utilization
The second tier of requirements is（優先級低一點的需求）:
· Support for alternate programming paradigms to Map-Reduce
· Support for limited, short-lived services
這里解釋一下這份需求，首先是可以支持非常大的集群規模，200k cores這個數字的確很驚人。
然后是向前兼容，之前大家都寫了很多在map-reduce上面的程序，如果不能支持這些老的程序，老的用戶怎么都不願意切換到新版本上去。
另外集群資源最大化利用，這個之后會提一下
然后值得一提的是，支持增加除了Map-Reduce之外的計算模型，這個彰顯了Hadoop想做領域霸主的決心，之前的Hadoop基本上就與Map-Reduce划上了等號，Map-Reduce干不了的事情，Hadoop基本上就干不了。Map-Reduce能做的事情有限（可以參考一下我之前的一篇文章,在”hadoop的劣勢”部分），簡單的說就是，數據多，但是計算簡單的時候，hadoop威力強大。如果計算邏輯復雜，需要搞個迭代至收斂之類的算法之類的，hadoop就玩不動了。如果能夠在Hadoop上加入其他的計算模型，支持這種數據量不那么大，但是計算量大的場景，就防止一些挑剔的客戶在這個問題上jjyy了。
最后說的支持limited, short-lived services還沒有看到過更詳細的說明，如果有人明白歡迎補充
老的Map-reduce設計
下面給出一個設計圖，
簡單的介紹一下
1. 首先用戶程序(Client Program)提交了一個job，job的信息會發送到Job Tracker中，Job Tracker是Map-reduce框架的中心，他需要與集群中的機器定時通信(heartbeat), 需要管理哪些程序應該跑在哪些機器上，需要管理所有job失敗、重啟等操作。
2. TaskTracker是Map-reduce集群中每台機器都有的一個部分，他做的事情主要是監視自己所在機器的資源情況（資源的表示是“本機還能起多少個map-task，多少個reduce-task”，每台機器起map/reduce task的上限是在建立集群的時候配置的），另外TaskTracker也會監視當前機器的tasks運行狀況。
TaskTracker需要把這些信息通過heartbeat發送給JobTracker，JobTracker會搜集這些信息以給新提交的job分配運行在哪些機器上。上圖回形針一樣的箭頭就是表示消息的發送-接收的過程。
夠簡單吧？當前的架構這么兩句話就概括出來了，不過當你去看代碼的時候，發現代碼非常的難讀，因為常常一個類3000多行，因為一個class做了太多的事情，這樣會造成class的任務不清楚。另外，從我的理解來說，上面的設計至少有下面的幾個問題，
1. JobTracker是Map-reduce的單點，看起來多多少少讓人不爽
2. JobTracker完成了太多的任務，造成了過多的資源消耗，當map-reduce job非常多的時候，會造成很大的內存開銷，潛在來說，也增加了很多JobTracker fail的風險
3. 在TaskTracker端，以map/reduce task的數目作為資源的表示過於簡單，沒有考慮到cpu/內存的占用情況，如果兩個大內存消耗的task被調度到了一塊，很容易出現OOM
4. 在TaskTracker端，把資源強制划分為map task slot和reduce task slot, 如果當系統中只有map task或者只有reduce task的時候，會造成資源的浪費，也就是前面提過的集群資源利用的問題
上面提到的4個問題，在Yarn中，除了第一個屬於“部分完成”以外，其他的幾個問題都已經解決掉了
看看Map-reduce v2的設計:
首先User還是User，JobTracker和TaskTracker不見了，取而代之的是ResourceManager, Application Master與Node Manager三個部分。我詳細的說一下。
首先Resource Manager是一個中心的服務，它做的事情是調度、啟動每一個Job所屬的ApplicationMaster、另外監控ApplicationMaster的存在情況。
細心的朋友已經發現少了點什么，對！Job里面所在的task的監控、重啟等等內容不見了。這就是ApplicationMaster存在的原因。
上圖中的MPI Mast(er)與MR Master就是某一個MPI Job或者MR Job的ApplicationMaster，一定要記住，ApplicationMaster是每一個Job（不是每一種）都有的一個部分，ApplicationMaster可以運行在ResourceManager以外的機器上。老的框架中，JobTracker一個很大的負擔就是監控job下的tasks的運行狀況，現在，這個部分就扔給ApplicationMaster做了，而ResourceManager中有一個模塊叫做ApplicationsMaster，它是監測ApplicationMaster的運行狀況，如果出問題，會將其在其他機器上重啟。
設計優點一：這個設計大大減小了JobTracker（也就是現在的ResourceManager）的資源消耗，並且讓監測每一個Job子任務(tasks)狀態的程序分布式化了，更安全、更優美
另外，在新版中，ApplicationMaster是一個可變更的部分，用戶可以對不同的編程模型寫自己的ApplicationMaster，讓更多類型的編程模型能夠跑在Hadoop集群中。
設計優點二：能夠支持不同的編程模型
設計優點三：對於資源的表示以內存為單位(在目前版本的Yarn中，沒有考慮cpu的占用)，比之前以剩余slot數目更合理
設計優點四：既然資源表示成內存量，那就沒有了之前的map slot/reduce slot分開造成集群資源閑置的尷尬情況了
其實在Yarn中還有很多優美的設計，之后慢慢再給大家說一下
總結：
在Hadoop 0.23版中，就已經加入了Yarn，這個改變讓Hadoop從單一的“黑虎掏心”變成了少林七十二絕學，學習了解Yarn也將是一個合格的hadooper的基本素質
參考資料：
主要就是官方設計文檔：https://issues.apache.org/jira/secure/attachment/12486023/MapReduce_NextGen_Architecture.pdf