[TOC] ## 舊的MapReduce架構  - **JobTracker:** 負責資源管理，跟蹤資源消耗和可用性，作業生命周期管理（調度作業任務，跟蹤進度，為任務提供容錯） - **TaskTracker:** 加載或關閉任務，定時報告認為狀態 此架構會有以下問題： 1. JobTracker是MapReduce的集中處理點，存在單點故障 1. JobTracker完成了太多的任務，造成了過多的資源消耗，當MapReduce job 非常多的時候，會造成很大的內存開銷。這也是業界普遍總結出老Hadoop的MapReduce只能支持4000 節點主機的上限 1. 在TaskTracker端，以map/reduce task的數目作為資&##x6E90;的表示過于簡單，沒有考慮到cpu/ 內存的占用情況，如果兩個大內存消耗的task被調度到了一塊，很容易出現OOM 1. 在TaskTracker端，把資源強制劃分為map task slot和reduce task slot, 如果當系統中只有map task或者只有reduce task的時候，會造成資源的浪費，也就集群資源利用的問題 總的來說就是**單點問題**和**資源利用率問題** ## YARN架構   YARN就是將JobTracker的職責進行拆分，將資源管理和任務調度監控拆分成獨立#x7ACB;的進程：一個全局的資源管理和一個每個作業的管理（ApplicationMaster） ResourceManager和NodeManager提供了計算資源的分配和管理，而ApplicationMaster則完成應用程序的運行 - **ResourceManager:** 全局資源管理和任務調度 - **NodeManager:** 單個節點的資源管理和監控 - **ApplicationMaster:** 單個作業的資源管理和任務監控 - **Container:** 資源申請的單位和任務運行的容器 ## 架構對比  YARN架構下形成了一個通用的資源管理平臺和一個通用的應用計算^#x5E73;臺，避免了舊架構的單點問題和資源利用率問題，同時也讓在其上運行的應用不再局限于MapReduce形式 ## YARN基本流程   **1. Job submission** 從ResourceManager中獲取一個Application ID檢查作業輸出配置，計算輸入分片拷貝作業資源（job jar、配置文件、分片信息）到HDFS，以便后面任務的執行 **2. Job initialization** ResourceManager將作業遞交給Scheduler（有很多調度算法，一般是根據優先級）Scheduler為作業分配一個Container，ResourceManager就加載一個application master process并交給NodeManager管理ApplicationMaster主要是創建一系列的監控進程來跟蹤作業的進度，同時獲取輸入分片，為每一個分片創建一個Map task和相應的reduce taskApplication Master還決定如何運行作業，如果作業很小（可配置），則直接在同一個JVM下運行 **3. Task assignment** ApplicationMaster向Resource Manager申請資源（一個個的Container，指定任務分配的資源要求）一般是根據data locality來分配資源 **4. Task execution** ApplicationMaster根據ResourceManager的分配情況，在對應的NodeManager中啟動Container從HDFSN#x4E2D;讀取任務所需資源（job jar，配置文件等），然后執行該任務 **5. Progress and status update** 定時將任務的進度和狀態報告給ApplicationMasterClient定時向ApplicationMaster獲取整個任務的進度和狀態 **6. Job completion** Client定時檢查整個作業是否完成作業完成后，會清空臨時文件、目錄等