簡單介紹 HDFS，MapReduce，Yarn 的 架構思想和原理

大家好，我是 夢想家Alex ，之前實際上我也寫了不少關于大資料技術組件的文章，例如：

前方高能 | HDFS 的架構，你吃透了嗎？

MapReduce 的核心知識點，你都 get 到了嗎 ?

從 0 到 1 學習 Presto，這一篇就夠了

…

但感徑訓本上都是在描述一些理論層面的內容，缺少一些架構的思想精髓 ，而且大資料技術其實是分布式技術在資料處理領域的創新型應用，其本質就是利用更多的計算機組成一個集群，提供更多的計算資源，從而滿足更大的計算壓力要求，說的通俗易懂一些，就是大資料技術的誕生解決的就是資料存盤和計算的問題，正好最近在刷李智慧老師的書和極客專欄，想輸出一些干貨，那本篇文章，我想先通過一個引子，為大家帶來 Hadoop 三大組件，例如 HDFS，MapReduce，Yarn 的架構分析和梳理，希望對大家學習成長有所幫助 ，

引子

大資料就是將各種資料統一收集起來進行計算，發掘其中的價值，這些資料，既包括資料庫的資料，也包括日志資料，還包括專門采集的用戶行為資料；既包括企業內部自己產生的資料，也包括從第三方采購的資料，還包括使用網路爬蟲獲取的各種互聯網公開資料 …

面對如此龐大的資料，如何存盤、如何有效利用大規模的服務器集群處理計算才是大資料技術的核心，

HDFS 分布式檔案存盤架構

我們知道，Google 大資料“三駕馬車”的第一駕是 GFS（Google 檔案系統），而 Hadoop 的第一個產品是 HDFS，可以說分布式檔案存盤是分布式計算的基礎，也可見分布式檔案存盤的重要性，如果我們將大資料計算比作烹飪，那么資料就是食材，而 Hadoop 分布式檔案系統 HDFS 就是燒菜的那口大鍋，

廚師來來往往，食材進進出出，各種菜肴層出不窮，而不變的則是那口大鍋，大資料也是如此，這些年來，各種計算框架、各種演算法、各種應用場景不斷推陳出新，讓人眼花繚亂，但是大資料存盤的王者依然是 HDFS，

為什么 HDFS 的地位如此穩固呢？在整個大資料體系里面，最寶貴、最難以代替的資產就是資料，大資料所有的一切都要圍繞資料展開，HDFS 作為最早的大資料存盤系統，存盤著寶貴的資料資產，各種新的演算法、框架要想得到人們的廣泛使用，必須支持 HDFS 才能獲取已經存盤在里面的資料，所以大資料技術越發展，新技術越多，HDFS 得到的支持越多，我們越離不開 HDFS，HDFS 也許不是最好的大資料存盤技術，但依然最重要的大資料存盤技術，

之前在 前方高能 | HDFS 的架構，你吃透了嗎？這篇文章中，我們就已經談到了 HDFS 的架構 ，如下圖所示：

HDFS 可以將數千臺服務器組成一個統一的檔案存盤系統，其中 NameNode 服務器充當檔案控制塊的角色，進行檔案元資料管理，即記錄檔案名、訪問權限、資料存盤地址等資訊，而真正的檔案資料則存盤在 DataNode 服務器上，

DataNode 以塊為單位存盤資料，所有的塊資訊，比如 塊 ID、塊所在的服務器 IP 地址等，都記錄在 NameNode 服務器上，而具體的塊資料存盤在 DataNode 服務器上，理論上，NameNode 可以將所有 DataNode 服務器上的所有資料塊都分配給一個檔案，也就是說，一個檔案可以使用所有服務器的硬碟存盤空間 ，

此外，HDFS 為了保證不會因為磁盤或者服務器損壞而導致檔案損壞，還會對資料塊進行復制，每個資料塊都會存盤在多臺服務器上，甚至多個機架上，

關于 HDFS是怎么做檔案管理和容錯，可以看下這篇文章：干貨 | HDFS是怎么做檔案管理和容錯的？

MapReduce 大資料計算架構

大資料計算的核心思路是移動計算比移動資料更劃算，既然計算方法跟傳統計算方法不一樣，移動計算而不是移動資料，那么用傳統的編程模型進行大資料計算就會遇到很多困難，因此 Hadoop 大資料計算使用了一種叫作 MapReduce 的編程模型，

其實 MapReduce 編程模型并不是 Hadoop 原創，甚至也不是 Google 原創，但是 Google 和 Hadoop 創造性地將 MapReduce 編程模型用到大資料計算上，立刻產生了神奇的效果，看似復雜的各種各樣的機器學習、資料挖掘、SQL 處理等大資料計算變得簡單清晰起來，

就好比資料存盤在 HDFS 上的最終目的還是為了計算，通過資料分析或者機器學習獲得有益的結果，但是如果像傳統的應用程式那樣，把 HDFS 當做普通檔案，從檔案中讀取資料后進行計算，那么對于需要一次計算數百 TB 資料的大資料計算場景，就不知道要算到什么時候了，

大資料處理的經典計算框架是 MapReduce ，MapReduce 的核心思想是對資料進行分片計算，既然資料是以塊為單位分布存盤在很多服務器組成的集群上，那么能不能就在這些服務器上針對每個資料塊進行分布式計算呢 ？

事實上，MapReduce 可以在分布式集群的多臺服務器上啟動同一個計算程式，每個服務器上的程式行程都可以讀取本服務器上要處理的資料塊進行計算，因此，大量的資料就可以同時進行計算了，但是這樣一來，每個資料塊的資料都是獨立的，如果這些資料塊需要進行關聯計算怎么辦？

MapReduce 將計算程序分成了兩個部分：一部分是 map 程序，每個服務器上會啟動多個 map 行程，map 優先讀取本地資料進行計算，計算后輸出一個 <key，value> 集合；另一部分是 reduce 部分，MapReduce 在每個服務器上都會啟動多個 reduce 行程，然后對所有 map 輸出的 <key，value> 集合進行 shuffle 操作，所謂的 shuffle 就是將相同的 key 發送到同一個 reduce 行程中，在 reduce 中完成資料關聯計算 ，

為了更直觀的展示這個程序，下面以經典的 WordCount ，即統計所有資料中相同單詞的詞頻資料為例，來認識 map 和 reduce 的處理程序 ，

假設原始資料有兩個資料塊，MapReduce 框架啟動了兩個 map 行程進行處理，它們分別讀入資料 ， map 函式會對輸入資料進行分詞處理，然后針對每個單詞輸出 < 單詞，1 > 這樣的 < key，value > 結果 ， 然后 MapReduce 框架進行 shuffle 操作，相同的 key 發送給同一個 reduce 行程，reduce 的輸入就是 < key ，value 的串列>這樣的結構，即相同 key 的 value 合并成了一個串列，

在這個示例中，這個 value 串列就是由很多個 1 組成的串列，reduce 對這些 1 進行求和操作，就得到了每個單詞的詞頻結果了，

示例代碼如下：

上面的源代碼描述的是 map 和 reduce 行程合作完成資料處理的程序，那么這些行程是如何在分布式的服務器集群上啟動的呢？資料是如何流動并最終完成計算的呢？

我們以 Hadoop 1 為例，帶領大家一起看下這個程序，

MapReduce1 主要有 JobTracker 和 TaskTracker 這兩種角色，JobTracker 在 MapReduce 的集群只有一個，而 TaskTracker 則和 DataNode 一起啟動在集群的所有服務器上，

MapReduce 應用程式 JobClient 啟動后，會向 JobTracker 提交作業，JobTracker 根據作業中輸入的檔案路徑分析需要在哪些服務器上啟動 map 行程，然后就在這些服務器上的 TaskTracker 發送任務命令，

TaskTracker 收到任務后，啟動一個TaskRunner 行程下載任務對應的程式，然后反射加載程式中的 map 函式，讀取任務中分配的資料塊，并進行map計算，map計算結束后，TaskTracker會對 map 輸出進行shuffle 操作，然后 TaskRunner 加載 reduce 函式進行后續計算 ，

Yarn 資源調度框架

在 MapReduce 應用程式的啟動程序中，最重要的就是要把 MapReduce 程式分發到大資料集群的服務器上，在上文介紹的 Hadoop 1 中，這個程序主要是通過 TaskTracker 和 JobTracker 通信來完成，

但是這種架構方案有什么缺點呢？

服務器集群資源調度管理和 MapReduce 執行程序耦合在一起，如果想在當前集群中運行其他計算任務，比如 Spark 或者 Storm，就無法統一使用集群中的資源了，

在 Hadoop 早期的時候，大資料技術就只有 Hadoop 一家，這個缺點并不明顯，但隨著大資料技術的發展，各種新的計算框架不斷出現，我們不可能為每一種計算框架部署一個服務器集群，而且就算能部署新集群，資料還是在原來集群的 HDFS 上，所以我們需要把 MapReduce 的資源管理和計算框架分開，這也是 Hadoop 2 最主要的變化，就是將 Yarn 從 MapReduce 中分離出來，成為一個獨立的資源調度框架，

Yarn 的設計思路也非常有趣

首先，為了避免功能的高度耦合，你得將原 JobTracker 的功能進行拆分

其次，一個集群多個框架，即在一個集群上部署一個統一的資源調度框架YARN，在YARN之上可以部署各種計算框架，

最終形成 Yarn 的整體架構如下所示：

從圖上看，Yarn 包括兩個部分：一個是資源管理器（Resource Manager），一個是節點管理器（Node Manager），這也是 Yarn 的兩種主要行程：ResourceManager 行程負責整個集群的資源調度管理，通常部署在獨立的服務器上；NodeManager 行程負責具體服務器上的資源和任務管理，在集群的每一臺計算服務器上都會啟動，基本上跟 HDFS 的 DataNode 行程一起出現，

具體說來，資源管理器又包括兩個主要組件：調度器和應用程式管理器，調度器其實就是一個資源分配演算法，根據應用程式（Client）提交的資源申請和當前服務器集群的資源狀況進行資源分配，

Yarn 內置了幾種資源調度演算法，包括 Fair Scheduler、Capacity Scheduler 等，你也可以開發自己的資源調度演算法供 Yarn 呼叫，Yarn 進行資源分配的單位是容器（Container），每個容器包含了一定量的記憶體、CPU 等計算資源，默認配置下，每個容器包含一個 CPU 核心，容器由 NodeManager 行程啟動和管理，NodeManger 行程會監控本節點上容器的運行狀況并向 ResourceManger 行程匯報，

應用程式管理器負責應用程式的提交、監控應用程式運行狀態等，應用程式啟動后需要在集群中運行一個 ApplicationMaster，ApplicationMaster 也需要運行在容器里面，每個應用程式啟動后都會先啟動自己的 ApplicationMaster，由 ApplicationMaster 根據應用程式的資源需求進一步向 ResourceManager 行程申請容器資源，得到容器以后就會分發自己的應用程式代碼到容器上啟動，進而開始分布式計算，

巨人的肩膀

1、《從零開始學大資料》
2、《架構師的自我修煉》
3、 https://www.cnblogs.com/yszd/p/10885222.htm
4、 http://hadoop.apache.org/

小結

本期內容簡單為大家介紹了 Hadoop 三大組件的架構思想和原理，對于一些非重點的內容并未詳細展開介紹，大家可以自行了解或者添加我的 wx:zwj_bigdataer 找我交流學習，如果本期內容對你有點幫助，記得來發三連支持一下 ~

更多精彩內容關注 👇「大資料夢想家」🔥：

一枚喜歡閱讀，輸出，復盤的大資料愛好者，熱衷于分享大資料基礎原理，技術實戰，架構設計與原型實作之外，還喜歡輸出一些有趣實用的編程干貨內容，與閱讀心得 …