原 Hadoop MapReduce 框架的問題

原h(huán)adoop的MapReduce框架圖

從上圖中可以清楚的看出原 MapReduce 程序的流程及設(shè)計(jì)思路:

  1. 首先用戶程序 (JobClient) 提交了一個(gè) job,job 的信息會(huì)發(fā)送到 Job Tracker 中,Job Tracker 是 Map-reduce 框架的中心,他需要與集群中的機(jī)器定時(shí)通信 (heartbeat), 需要管理哪些程序應(yīng)該跑在哪些機(jī)器上,需要管理所有 job 失敗、重啟等操作。
  2. TaskTracker 是 Map-reduce 集群中每臺(tái)機(jī)器都有的一個(gè)部分,他做的事情主要是監(jiān)視自己所在機(jī)器的資源情況。
  3. TaskTracker 同時(shí)監(jiān)視當(dāng)前機(jī)器的 tasks 運(yùn)行狀況。TaskTracker 需要把這些信息通過 heartbeat 發(fā)送給 JobTracker,JobTracker 會(huì)搜集這些信息以給新提交的 job 分配運(yùn)行在哪些機(jī)器上。上圖虛線箭頭就是表示消息的發(fā)送 - 接收的過程。

   可以看得出原來的 map-reduce 架構(gòu)是簡(jiǎn)單明了的,在最初推出的幾年,也得到了眾多的成功案例,獲得業(yè)界廣泛的支持和肯定,但隨著分布式系統(tǒng)集群的規(guī)模和其工作負(fù)荷的增長(zhǎng),原框架的問題逐漸浮出水面,主要的問題集中如下:

  1. JobTracker 是 Map-reduce 的集中處理點(diǎn),存在單點(diǎn)故障
  2. JobTracker 完成了太多的任務(wù),造成了過多的資源消耗,當(dāng) map-reduce job 非常多的時(shí)候,會(huì)造成很大的內(nèi)存開銷,潛在來說,也增加了 JobTracker fail 的風(fēng)險(xiǎn),這也是業(yè)界普遍總結(jié)出老 Hadoop 的 Map-Reduce 只能支持 4000 節(jié)點(diǎn)主機(jī)的上限。
  3. 在 TaskTracker 端,以 map/reduce task 的數(shù)目作為資源的表示過于簡(jiǎn)單,沒有考慮到 cpu/ 內(nèi)存的占用情況,如果兩個(gè)大內(nèi)存消耗的 task 被調(diào)度到了一塊,很容易出現(xiàn) OOM。
  4. 在 TaskTracker 端,把資源強(qiáng)制劃分為 map task slot 和 reduce task slot, 如果當(dāng)系統(tǒng)中只有 map task 或者只有 reduce task 的時(shí)候,會(huì)造成資源的浪費(fèi),也就是前面提過的集群資源利用的問題。
  5. 延伸閱讀

    學(xué)習(xí)是年輕人改變自己的最好方式-Java培訓(xùn),做最負(fù)責(zé)任的教育,學(xué)習(xí)改變命運(yùn),軟件學(xué)習(xí),再就業(yè),大學(xué)生如何就業(yè),幫大學(xué)生找到好工作,lphotoshop培訓(xùn),電腦培訓(xùn),電腦維修培訓(xùn),移動(dòng)軟件開發(fā)培訓(xùn),網(wǎng)站設(shè)計(jì)培訓(xùn),網(wǎng)站建設(shè)培訓(xùn)學(xué)習(xí)是年輕人改變自己的最好方式