Hadoop之 - 剖析 MapReduce 做業的運行機制(MapReduce 2)

在0.20版本及更早期的系列中,mapred.job.tracker 決定了執行MapReduce程序的方式。若是這個配置屬性被設置爲local(默認值),則使用本地的做業運行器。運行器在耽擱JVM上運行整個做業。它被設計用來在小的數據集上測試和運行MapReduce程序。
node


若是 mapred.job.tracker 被設置爲用冒號分開的主機和端口對(主機:端口),那麼該配置屬性就被解釋爲一個jobtracker地址,運行器則將做業提交給該地址的jobtracker。shell


Hadoop 2.x引入了一種新的執行機制。這種新機制(MapReduce 2)創建在一個名爲YARN的系統上。目前,用於執行的框架經過 mapreduce.framework.name 屬性進行設置,值local表示本地的做業運行器,「classic」表示經典的 MapReduce 框架(也稱MapReduce 1,它使用一個jobtracker和多個tasktracker),yarn表示新的框架。緩存


YARN (MapReduce 2)服務器

對於節點數超出4000的大型集羣,MapReduce 1的系統開始面領着擴展性的瓶頸。在2010年雅虎的一個團隊開始設計下一代的MapReduce.由此,YARN(Yet Another Resource Negotiator的縮寫或者爲 YARN Application Resource Neforiator的縮寫)應運而生。app


YARN 將 Jobtracker 的職能劃分爲多個獨立的實體,從而改善了「經典的」MapReduce 面臨的擴展瓶頸問題。Jobtracker負責做業調度和任務進度監視、追蹤任務、重啓失敗或過慢的任務和進行任務登記,例如維護計數器總數。框架


YARN 將這兩種角色劃分爲兩個獨立的守護進程:管理集羣上資源使用的資源管理器和管理集羣上運行任務生命週期的應用管理器。基本思路是:應用服務器與資源管理器協商集羣的計算資源:容器(每一個容器都有特定的內存上限),在這些容器上運行特定應用程序的進程容器由集羣節點上運行的節點管理器監視,以確保應用程序使用的資源不會超過度配給它的資源。分佈式

資源管理器:即resource manager,RM,負責管理全部應用程序計算資源的分配。ide

應用管理器:即application master,AM,每個應用程序的AM負責相應的調度和協調。oop

容器:即containers,YARN爲未來的資源隔離而提出的框架,每個任務對應一個Container,且只能在該container中運行。測試

節點監視器:即node manager,管理每一個節點上的資源和任務,主要有兩個做用:按期向RM彙報該節點的資源使用狀況和各個container的運行狀態;接收並處理AM的任務啓動、中止等請求。


與jobtracker不一樣,應用的每一個實例(這裏指一個MapReduce做業)有一個專用的應用master(application master),它運行在應用的運行期間。這種方式實際上和最初的Google的MapReduce論文裏介紹的方法很類似,該論文描述了master進程如何協調在一組worker上運行的map任務和reduce任務。


如前所述,YARN比MapReduce更具通常性,實際上MapReduce只是YARN應用的一種形式。有不少其餘的YARN應用(例如可以在集羣中的一組節點上運行腳本的分佈式shell)以及其餘正在開發的程序。 YARN設計的精妙之處在於不一樣的YARN應用能夠在同一個集羣上共存。例如,一個MapReduce應用能夠同時做爲MPI應用運行,這大大提升了可管理性和集羣的利用率。


此外,用戶甚至有可能在同一個YARN集羣上運行多個不一樣版本的MapReduce,這使得MapReduce升級過程更容易管理。注意,MapReduce的某些部分(好比做業歷史服務器和shuffle處理器)以及YARN自己仍然須要在整個集羣上升級。


YARN上的MapReduce比經典的MapReduce包括更多的實體:

  • 提交MapReduce做業的客戶端

  • YARN資源管理器(resource manager),負責協調集羣上計算資源的分配

  • YARN節點管理器(node manager),負責啓動和監視集羣中機器上的計算容器(container)

  • MapReduce 應用程序master,負責協調運行MapReduce做業的任務。它和MapReduce任務在容器中運行,這些容器由資源管理器分配並由節點管理器進行管理

  • 分佈式文件系統(通常爲HDFS),用來與其餘實體見共享做業文件


做業的運行過程以下圖所示,下面一一具體描述。

wKioL1gxvd7h7PJTAAEC1lT2g9Q016.png

wKioL1gx0w7iMD_0AAF4JBjvl38497.gif

動圖展現流程

  1. 做業提交

    MapReduce 2中的做業提交時使用與MapReduce 1相同的用戶API(步驟1)。MapReduce 2實現了ClientProtocol,當 mapreduce.framework.name 設置爲yarn時啓動。提交的過程與經典的很是類似。從資源管理器(而不是jobtracker)獲取新的做業ID,在YARN命名法中它是一個應用程序ID(步驟2)。做業客戶端檢查做業的輸出說明,計算輸入分片(雖然有選項yarn.app.mapreduce.am.compute-splits-in-cluster在集羣上來產生分片,這可使具備多個分片的做業從中受益)並將做業資源(包括做業JAR、配置和分片信息)複製到HDFS(步驟3)。最後,經過調用資源管理器上的submitApplication()方法提交做業(步驟4)。          


  2. 做業初始化

    資源管理器收到調用它的 submitApplication() 消息後,便將請求傳遞給調度器(scheduler)。調度器分配一個容器,而後資源管理器在節點管理器的管理下在容器中啓動應用程序的master進程(步驟5a 和 5b)


    MapReduce做業的application master 是一個Java應用程序,它的主類是MRAppMaster。它對做業進行初始化:經過建立多個簿記對象以保持對做業進度的跟蹤,由於它將接受來自任務的進度和完成報告(步驟6)。接下來,它接受來自共享文件系統的在客戶端計算的輸入分片(步驟7)。對每個分片建立一個map任務對象以及由 mapreduce.job.reduces 屬性肯定的多個reduce任務對象。


    接下來,application master 決定如何運行構成MapReduce做業的各個任務。若是做業很小,就選擇在與它同一個JVM上運行任務。


    相對於在一個節點上順序運行它們,判斷在新的容器中分配和運行任務的開銷大於並行運行它們的開銷時,就會發生這一狀況。這不一樣於MapReduce 1,MapReduce 1 從不在單個tasktracker上運行小做業。這樣的做業稱爲uberized,或者做爲uber任務運行。


    uber運行默認對小做業進行優化,不會給每一個任務分別神器分配Contianer資源,這些小任務將統一在一個container中按照先執行map任務後執行reduce任務的順序串執行。


    哪些任務是小任務呢? 默認狀況下,小任務就是小魚10個mapper且只有1個reducer且輸入大小小於一個HDFS塊的任務。(經過設置mapreduce.job.ubertask.maxmapsmapreduce.job.ubertask.maxreducesmapreduce.job.ubertask.maxbytes 能夠改變一個做業的上述值。)將 mapreduce.job.ubertask.enable 設置爲 false 也能夠徹底使uber任務不可用。


    在任何任務運行以前,做業的setup方法爲了設置做業的 OutputCommitter 被調用來創建做業的輸出目錄。在MapReduce 1中,它在一個由 tasktracker 運行的特殊任務中被調用,而在YARN執行框架中,該方法由應用程序master直接調用。


  3. 任務分配

    若是做業不適合做爲uber任務運行,那麼 application master 就會爲該做業中的全部map任務和reduce任務向資源管理器請求容器(步驟8)。附着心跳信息的請求包括每一個map任務的數據本地化信息,特別是輸入分片所在的主機和相應機架信息。調度器使用這些信息來作調度策略(像jobtracker的調度器同樣)。理想狀況下,它將任務分配到數據本地化的節點,但若是不可能這樣作,調度器就會相對於非本地化的分配有限使用機架本地化的分配。


    請求也爲任務指定了內存需求。在默認狀況下,map任務和reduce任務都分配到1024MB的內存,但這能夠經過 mapreduce.map.memory.mb 和 mapreduce.reduce.memory.mb 來設置。


    內存的分配方式不一樣於MapReduce 1,後者中tasktrackers 有在集羣配置時設置的固定數量的槽,每一個任務在一個槽上運行。槽有最大內存分配限制,這對集羣是固定的,致使當任務使用較少內存時沒法充分利用內存(由於其餘等待的任務不能使用這些未使用的內存)以及因爲任務不能獲取足夠內存而致使做業失敗。


    在YARN中,資源分爲更細的粒度,因此能夠避免上述問題。具體而言,應用程序能夠請求最小到最大限制範圍內的任意最小值倍數的內存容量。默認的內存分配容量是調度器特定的,對於容量調度器,它的默認值最小值是1024MB(由 yarn.sheduler.capacity.minimum-allocation-mb 設置),默認的最大值是10240MB(由 yarn.sheduler.capacity.maximum-allocation-mb 設置)。所以,任務能夠經過適當設置 mapreduce.map.memory.mb 和 mapreduce.reduce.memory.mb 來請求1GB到10GB間的任務1GB倍數的內存容量(調度器在須要的時候使用最接近的倍數)。


  4. 任務執行

    一旦資源管理器的調度器爲任務分配了容器,application master 就經過與節點管理器通訊來啓動容器(步驟9a 和 9b)。該任務由主類 YarnChild 的Java應用程序執行,在它運行任務以前,首先將任務須要的資源本地化,包括做業的配置、JAR文件 和 全部來自分佈式緩存的文件(步驟10)。最後,運行map任務或reduce任務(步驟11)。


    Streaming 和 Pipes程序以MapReduce 1的方式運行。YarnChild 啓動Streaming 或 Pipes進行,並經過分別使用標準的輸入/輸出或套接字與它們通訊,child和子進程在節點管理器上運行,而非tasktracker。


  5. 進度和狀態更新

    在 YARN 下運行時,任務每3瞄準經過umbilical接口向 application master 彙報進度和狀態(包含計數器),做爲做業的匯聚視圖(aggregate view)。這個過程以下圖所示。相比之下,MapReduce 1 經過tasktracker 到 jobtracker 來實現進度更新。

    wKioL1gxvfTSMdibAACtowdXTLY205.png


    客戶端每秒鐘(經過 mapreduce.client.progressmonitor.pollinterval 設置)查詢一次 application master 以接收進度更新,一般都會向用戶顯示。


    在MapReduce 1中,做業跟蹤器的Web UI展現運行做業列表及進度。在 YARN 中個,資源管理器的 Web UI(默認8088端口)展現了正在運行的應用以及鏈接到的對應 application master,每一個 application master 展現MapReduce做業的進度等進一步的細節


  6. 做業完成

    除了向 application master 查詢進度外,客戶端每5秒鐘還經過調用Job的 waitForCompletion() 來檢查做業是否完成。查詢的間隔能夠經過 mapreduce.client.completion.pollinterval 屬性進行設置。


    注意,經過 HTTP 回調 (callback)來完成做業也是支持的,就像在 MapReduce 1中同樣,然而在MapReduce 2中,回調是由 application master 初始化。


    做業完成後,application master 和任務容器清理其工做狀態,OutputCommiter 的做業清理方法會被調用。做業歷史服務器保存做業的信息供用戶須要時查詢。

相關文章
相關標籤/搜索