hadoop 2.0--YARN

從2012年8月開始Apache Hadoop YARN（YARN = Yet Another Resource Negotiator）成了Apache Hadoop的一項子工程。自此Apache Hadoop由下面四個子工程組成：

• Hadoop Comon：核心庫，爲其餘部分服務
• Hadoop HDFS：分佈式存儲系統
• Hadoop MapReduce：MapReduce模型的開源實現
• Hadoop YARN：新一代Hadoop數據處理框架

      歸納來講，Hadoop YARN的目的是使得Hadoop數據處理能力超越MapReduce。衆所周知，Hadoop HDFS是Hadoop的數據存儲層，Hadoop MapReduce是數據處理層。然而，MapReduce已經不能知足今天普遍的數據處理需求，如實時/準實時計算，圖計算等。而Hadoop YARN提供了一個更加通用的資源管理和分佈式應用框架。在這個框架上，用戶能夠根據本身需求，實現定製化的數據處理應用。而Hadoop MapReduce也是YARN上的一個應用。咱們將會看到MPI，圖處理，在線服務等（例如Spark，Storm，HBase）都會和Hadoop MapReduce同樣成爲YARN上的應用。下面將分別介紹傳統的Hadoop MapReduce以及新一代Hadoop YARN架構。
　　因而可知，hadoop2.0吸取目前工業界整個生態圈的現有成就，而且但願可以支持更多的運算模型。可是生態系統老是有演化的過程，隨着各類新物種的出現，總會有一天打破現有的生態平衡的。hadoop雖然提供了MPI但願可以支持更多的計算類型，可是從目前看，HBase等都是自稱一系的。

原 MapReduce 程序的流程及設計思路：

1. 首先用戶程序 (JobClient) 提交了一個 job，job 的信息會發送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他須要與集羣中的機器定時通訊 (heartbeat), 須要管理哪些程序應該跑在哪些機器上，須要管理全部 job 失敗、重啓等操做。
2. TaskTracker 是 Map-reduce 集羣中每臺機器都有的一個部分，他作的事情主要是監視本身所在機器的資源狀況。
3. TaskTracker 同時監視當前機器的 tasks 運行情況。TaskTracker 須要把這些信息經過 heartbeat 發送給 JobTracker，JobTracker 會蒐集這些信息以給新提交的 job 分配運行在哪些機器上。上圖虛線箭頭就是表示消息的發送 - 接收的過程。

能夠看得出原來的 map-reduce 架構是簡單明瞭的，在最初推出的幾年，也獲得了衆多的成功案例，得到業界普遍的支持和確定，但隨着分佈式系統集羣的規模和其工做負荷的增加，原框架的問題逐漸浮出水面，主要的問題集中以下：

1. JobTracker 是 Map-reduce 的集中處理點，存在單點故障。
2. JobTracker 完成了太多的任務，形成了過多的資源消耗，當 map-reduce job 很是多的時候，會形成很大的內存開銷，潛在來講，也增長了 JobTracker fail 的風險，這也是業界廣泛總結出老 Hadoop 的 Map-Reduce 只能支持 4000 節點主機的上限。
3. 在 TaskTracker 端，以 map/reduce task 的數目做爲資源的表示過於簡單，沒有考慮到 cpu/ 內存的佔用狀況，若是兩個大內存消耗的 task 被調度到了一塊，很容易出現 OOM。
4. 在 TaskTracker 端，把資源強制劃分爲 map task slot 和 reduce task slot, 若是當系統中只有 map task 或者只有 reduce task 的時候，會形成資源的浪費，也就是前面提過的集羣資源利用的問題。
5. 源代碼層面分析的時候，會發現代碼很是的難讀，經常由於一個 class 作了太多的事情，代碼量達 3000 多行，，形成 class 的任務不清晰，增長 bug 修復和版本維護的難度。
6. 從操做的角度來看，如今的 Hadoop MapReduce 框架在有任何重要的或者不重要的變化 ( 例如 bug 修復，性能提高和特性化 ) 時，都會強制進行系統級別的升級更新。更糟的是，它無論用戶的喜愛，強制讓分佈式集羣系統的每個用戶端同時更新。這些更新會讓用戶爲了驗證他們以前的應用程序是否是適用新的 Hadoop 版本而浪費大量時間。

　　整個hadoop2.0中，namenode上jobtracker的功能被拆分紅resourceManager和ApplicationMaster以及客戶端上面的NodeManager來統一負責。而AppMst又可有有多個，一個AppMst對應一種計算框架的類型，由AppMst來監控任務的運行狀態，以及失敗重啓。NameNode是YARN每一個節點上面運行的agent，負責集羣中每一個計算節點，看看hortonworks的官方描述：The NodeManager (NM) is YARN’s per-node agent, and takes care of the individual compute nodes in a Hadoop cluster. 

 

　　從上面介紹能夠看得出，YARN最大的特性就是jobtracker被切分紅resourceManager和appMst，而appMst這一層至關於對整個hadoop作了切分跟抽象，在文件系統之上增長了一個應用程序層，從而可以支持擴展。本質上看，appMst實現的邏輯其實用戶的代碼，不該當與系統代碼的nodeManger和resourceManager混在一塊兒，有了AppMst後繼hadoop就能夠支持各類流式運算和各類非MR的運算了。這個看起來貌似很簡單的改變，可以極大減輕MASTER節點的壓力和運算邏輯，目前業界hadoop系統有三千臺的集羣的，有五千臺集羣的，再高的沒有誰詳細的介紹過，聽說YARN能支持的節點數目是遠遠超過hadoop1.0的。resourceManager相似於jt，而nodeManager相似於tt，而appMst則是新生事物。

　　YARN還支持webHDFS，經過restfull api訪問和操做hdfs，這也算是遇上了時代的步伐，將大大方便跨語言對hadoop的調用。

　　悲催的是，沒有看到關於MASTER單節點的解決方案，整個YARN對resourceManager的依賴像對jt和nn同樣強烈，當resourceManager失效的時候，對整個系統來講是災難。這已經被工業界多次實踐的一個缺陷了，不少實時切換的方案，可是未見到YARN官方的介紹。

 

　　最後YY一下，號稱是HADOOP2.0的產品開發來自這家公司http://hortonworks.com/，完美的商業與技術結合的產品。