&#160學習MapReduce的原理(https://blog.csdn.net/Chris_MZJ/article/details/83099262)之後，我們來看看MapReduce是如何在HDFS叢集上實現的。分散式計算框架的思想一般都是計算找資料，這樣能減少資料傳輸中的網路IO開銷，可以將一個計算執行緒比作一個伐木工人，資料就是山上的樹木，工人工作肯定是攜帶工具上山伐木的，而不能把山搬到工人的家中來。 先來介紹Hadoop1.x版本的MapReduce實現：

首先程式設計師自己寫好MapReduce計算框架的map部分和reduce部分程式碼，shuffle過程由MapReduce框架實現。現在有一個MapReduce程式，我們將它打包成一個Application jar包，光有這個jar包肯定是不能執行的，首先我們得向資源排程器申請點資源(CPU,記憶體，磁碟空間),得到執行Application的資源後還得進行任務排程，因為一個MapReduce程式有多個map task和reduce task，然後再進行分散式平行計算。

          如上圖所示，首先客戶端將MapReduce程式打包成Application jar包，傳送給JobTracker，JobTracker拿到jar包後分析MapReduce程式要操作哪些資料，並彙報給NameNode節點，NameNode返回要操作的資料都是哪些DataNode上，接著，JobTrakcer將appllication中的map task和reduce task 分發給對應的TaskTracker(哪個DataNode有資料哪個節點就是一個TaskTracker，當由資料的節點資源不足時，TaskTracker也會是其他節點)，TaskTracker收到JobTracker的訊息後分配一部分資源用來執行map task任務，map task任務輸出資料後reduce tracker把資料拿走，進行Reude task任務，輸出結果。在這整個過程中，JobTracker既是任務排程的主節點，又是資源排程的主節點，負荷大，任務量多時容易崩，JobTracker一旦崩了整個計算框架就不能用了。還有一個潛在的問題是：當有另外一個計算框架也要在HDFS叢集在工作時，可能會造成資源搶奪問題，詳見上圖。由此，Hadoop1.x版本是不穩定的。由此我們引出Hadoop的2.x版本:

          同樣地，首先客戶端將MapReduce程式打包成Application jar包，向NameNode彙報，然後生成一個數據報表，這個報表的意義是：我們假設要處理的檔案在HDFS上只有兩個block，對於block1：資料在node01~node3上面，那麼最好是在這三個節點的任意一個啟動map task計算，如果這三個節點資源不足，那麼就在同機架的一個節點啟動map task，如果同機架的節點資源不足，隨機找一個節點啟動。

         與NameNode通訊生成資料報表後，client會向資源排程器發起請求，請求啟動一個application master，RM收到client的請求後在NodeManager啟動一個Application Master程序，接著，Application Master會從client拿到資料報表，根據資料報表向RM申請資源，RM收到請求後開始分配資源，拿到資源的NodeManager節點建立一個container容器，容器包括cpu，記憶體，磁碟空間等資源，接著Application Master向各個獲得資源的NodeManager派發任務執行，這就是整個計算框架的運算過程。其中啟動RM,Application Master,NodeManager等工作都是由hadoop的yarn框架完成的，當有其他的計算框架如sparks想執行在HDFS叢集上時，只需要繼承yarn的介面就行，因為這兩個框架都是繼承yarn的介面執行的，資源排程均有yarn完成，所以就不會存在Hadoop1.x版本的資源搶奪問題。而且，在執行過程中，如果Application Master掛掉，RM會重新啟動一個Application Master來執行任務，如果RM掛掉，zookeeper會切換到備用的RM來進行資源排程管理，這就比Hadoop1.x版本強大穩定得多了。