共計 4311 個字符，預計需要花費 11 分鐘才能閱讀完成。
這篇文章跟大家分析一下“如何實現 MRv1 和 Yarn 對比”。內容詳細易懂，對“如何實現 MRv1 和 Yarn 對比”感興趣的朋友可以跟著丸趣 TV 小編的思路慢慢深入來閱讀一下，希望閱讀后能夠對大家有所幫助。下面跟著丸趣 TV 小編一起深入學習“如何實現 MRv1 和 Yarn 對比”的知識吧。
YARN 并不是下一代 MapReduce（MRv2），下一代 MapReduce 與第一代 MapReduce（MRv1）在編程接口、數據處理引擎（MapTask 和 ReduceTask）是完全一樣的， 可認為 MRv2 重用了 MRv1 的這些模塊，不同的是資源管理和作業管理系統，MRv1 中資源 管理和作業管理均是由 JobTracker 實現的，集兩個功能于一身，而在 MRv2 中，將這兩部分分開了， 其中，作業管理由 ApplicationMaster 實現，而資源管理由新增系統 YARN 完成，由于 YARN 具有通用性，因此 YARN 也可以作為其他計算框架的資源管理系 統，不僅限于 MapReduce，也是其他計算框架，比如 Spark、Storm 等， 通常而言，我們一般將運行在 YARN 上的計算框架稱為“X on YARN”，比如“MapReduce On YARN”, Spark On YARN，“Storm On YARN”等。
這在官網上描述的很清楚：
Hadoop Common: The common utilities that support the other Hadoop modules.
Hadoop Distributed File System (HDFS?): A distributed file system that provides high-throughput access to application data.
Hadoop YARN: A framework for job scheduling and cluster resource management.
Hadoop MapReduce: A YARN-based system for parallel processing of large data sets.
原 Hadoop MapReduce 框架的問題
對于業界的大數據存儲及分布式處理系統來說，Hadoop 是耳熟能詳的卓越開源分布式文件存儲及處理框架，對于 Hadoop 框架的介紹在此不再累述，讀者可參考 Hadoop 官方簡介。使用和學習過老 Hadoop 框架（0.20.0 及之前版本）的同仁應該很熟悉如下的原 MapReduce 框架圖：
圖 1.Hadoop 原 MapReduce 架構
從上圖中可以清楚的看出原 MapReduce 程序的流程及設計思路：
首先用戶程序 (JobClient) 提交了一個 job，job 的信息會發送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要與集群中的機器定時通信 (heartbeat), 需要管理哪些程序應該跑在哪些機器上，需要管理所有 job 失敗、重啟等操作。
TaskTracker 是 Map-reduce 集群中每臺機器都有的一個部分，他做的事情主要是監視自己所在機器的資源情況。
TaskTracker 同時監視當前機器的 tasks 運行狀況。TaskTracker 需要把這些信息通過 heartbeat 發送給 JobTracker，JobTracker 會搜集這些信息以給新提交的 job 分配運行在哪些機器上。上圖虛線箭頭就是表示消息的發送 – 接收的過程。
可以看得出原來的 map-reduce 架構是簡單明了的，在最初推出的幾年，也得到了眾多的成功案例，獲得業界廣泛的支持和肯定，但隨著分布式系統集群的規模和其工作負荷的增長，原框架的問題逐漸浮出水面，主要的問題集中如下：
JobTracker 是 Map-reduce 的集中處理點，存在單點故障。
JobTracker 完成了太多的任務，造成了過多的資源消耗，當 map-reduce job 非常多的時候，會造成很大的內存開銷，潛在來說，也增加了 JobTracker fail 的風險，這也是業界普遍總結出老 Hadoop 的 Map-Reduce 只能支持 4000 節點主機的上限。
在 TaskTracker 端，以 map/reduce task 的數目作為資源的表示過于簡單，沒有考慮到 cpu/ 內存的占用情況，如果兩個大內存消耗的 task 被調度到了一塊，很容易出現 OOM。
在 TaskTracker 端，把資源強制劃分為 map task slot 和 reduce task slot, 如果當系統中只有 map task 或者只有 reduce task 的時候，會造成資源的浪費，也就是前面提過的集群資源利用的問題。
源代碼層面分析的時候，會發現代碼非常的難讀，常常因為一個 class 做了太多的事情，代碼量達 3000 多行，，造成 class 的任務不清晰，增加 bug 修復和版本維護的難度。
從操作的角度來看，現在的 Hadoop MapReduce 框架在有任何重要的或者不重要的變化 (例如 bug 修復，性能提升和特性化) 時，都會強制進行系統級別的升級更新。更糟的是，它不管用戶的喜好，強制讓分布式集群系統的每一個用戶端同時更新。這些更新會讓用戶為了驗證他們之前的應 用程序是不是適用新的 Hadoop 版本而浪費大量時間。
新 Hadoop Yarn 框架原理及運作機制
從業界使用分布式系統的變化趨勢和 hadoop 框架的長遠發展來看，MapReduce 的 JobTracker/TaskTracker 機制需要大規模的調整來修復它在可擴展性，內存消耗，線程模型，可靠性和性能上的缺陷。在過去的幾年中，hadoop 開發團隊做了一些 bug 的修復，但是最近這些修復的成本越來越高，這表明對原框架做出改變的難度越來越大。
為從根本上解決舊 MapReduce 框架的性能瓶頸，促進 Hadoop 框架的更長遠發展，從 0.23.0 版本開始，Hadoop 的 MapReduce 框架完全重構，發生了根本的變化。新的 Hadoop MapReduce 框架命名為 MapReduceV2 或者叫 Yarn，其架構圖如下圖所示：
圖 2. 新的 Hadoop MapReduce 框架（Yarn）架構
重構根本的思想是將 JobTracker 兩個主要的功能分離成單獨的組件，這兩個功能是資源管理和任務調度 / 監控。新的資源管理器全局管理所有應用程序計算資源的分配，每一個應用的 ApplicationMaster 負責相應的調度和協調。一個應用程序無非是一個單獨的傳統的 MapReduce 任務或者是一個 DAG(有向無環圖) 任務。ResourceManager 和每一臺機器的節點管理服務器能夠管理用戶在那臺機器上的進程并能對計算進行組織。
事實上，每一個應用的 ApplicationMaster 是一個詳細的框架庫，它結合從 ResourceManager 獲得的資源和 NodeManager 協同工作來運行和監控任務。
上圖中 ResourceManager 支持分層級的應用隊列，這些隊列享有集群一定比例的資源。從某種意義上講它就是一個純粹的調度器，它在執行過程中不對應用進行監控和狀態跟蹤。同樣，它也不能重啟因應用失敗或者硬件錯誤而運行失敗的任務。
ResourceManager 是基于應用程序對資源的需求進行調度的 ; 每一個應用程序需要不同類型的資源因此就需要不同的容器。資源包括：內存，CPU，磁盤，網絡等等。可以看出，這同現 Mapreduce 固定類型的資源使用模型有顯著區別，它給集群的使用帶來負面的影響。資源管理器提供一個調度策略的插件，它負責將集群資源分配給多個隊列和應用程序。調度 插件可以基于現有的能力調度和公平調度模型。
上圖中 NodeManager 是每一臺機器框架的代理，是執行應用程序的容器，監控應用程序的資源使用情況 (CPU，內存，硬盤，網絡) 并且向調度器匯報。
每一個應用的 ApplicationMaster 的職責有：向調度器索要適當的資源容器，運行任務，跟蹤應用程序的狀態和監控它們的進程，處理任務的失敗原因。
Yarn 執行任務流程
它的基本設計思想是將 MapReduce 中的 JobTracker 拆分成了兩個獨立的服務：一個全局的資源管理器 ResourceManager 和每個應 用程序特有的 ApplicationMaster。其中 ResourceManager 負責整個系統的資源管理和分配，而 ApplicationMaster 則負責單個應用程序的管理。
當用戶向 YARN 中提交一個應用程序后，YARN 將分兩個階段運行該應用程序：第一個階段是啟動 ApplicationMaster；第二個階段是 由 ApplicationMaster 創建應用程序，為它申請資源，并監控它的整個運行過程，直到運行成功。如圖 2 - 7 所示，YARN 的工作流程分為以下 幾個步驟：
步驟 1 用戶向 YARN 中提交應用程序，其中包括 ApplicationMaster 程序、啟動 ApplicationMaster 的命令、用戶程序等。
步驟 2 ResourceManager 為該應用程序分配第一個 Container，并與對應的 NodeManager 通信，要求它在這個 Container 中啟動應用程序的 ApplicationMaster。
步驟 3 ApplicationMaster 首先向 ResourceManager 注冊，這樣，用戶可以直接通過 ResourceManage 查看應用程序的運行狀態，然后，它將為各個任務申請資源，并監控它的運行狀態，直到運行結束，即重復步驟 4~7。
步驟 4 ApplicationMaster 采用輪詢的方式通過 RPC 協議向 ResourceManager 申請和領取資源。
步驟 5 一旦 ApplicationMaster 申請到資源后，則與對應的 NodeManager 通信，要求其啟動任務。
步驟 6 NodeManager 為任務設置好運行環境（包括環境變量、jar 包、二進制程序等）后，將任務啟動命令寫到一個腳本中，并通過運行該腳本啟動任務。
步驟 7 各個任務通過某個 RPC 協議向 ApplicationMaster 匯報自己的狀態和進度，以讓 ApplicationMaster 隨時掌握各個任務的運行 狀態，從而可以在任務失敗時重新啟動任務。在應用程序運行過程中，用戶可隨時通過 RPC 向 ApplicationMaster 查詢應用程序的當前運行狀 態。
步驟 8 應用程序運行完成后，ApplicationMaster 向 ResourceManager 注銷，并關閉自己。
關于如何實現 MRv1 和 Yarn 對比就分享到這里啦，希望上述內容能夠讓大家有所提升。如果想要學習更多知識，請大家多多留意丸趣 TV 小編的更新。謝謝大家關注一下丸趣 TV 網站！
