原 Hadoop MapReduce 框架的問題
原h(huán)adoop的MapReduce框架圖
從上圖中可以清楚的看出原 MapReduce 程序的流程及設(shè)計思路：
- 首先用戶程序 (JobClient) 提交了一個 job，job 的信息會發(fā)送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要與集群中的機器定時通信 (heartbeat), 需要管理哪些程序應(yīng)該跑在哪些機器上，需要管理所有 job 失敗、重啟等操作。
- TaskTracker 是 Map-reduce 集群中每臺機器都有的一個部分，他做的事情主要是監(jiān)視自己所在機器的資源情況。
- TaskTracker 同時監(jiān)視當(dāng)前機器的 tasks 運行狀況。TaskTracker 需要把這些信息通過 heartbeat 發(fā)送給 JobTracker，JobTracker 會搜集這些信息以給新提交的 job 分配運行在哪些機器上。上圖虛線箭頭就是表示消息的發(fā)送 - 接收的過程。
可以看得出原來的 map-reduce 架構(gòu)是簡單明了的，在最初推出的幾年，也得到了眾多的成功案例，獲得業(yè)界廣泛的支持和肯定，但隨著分布式系統(tǒng)集群的規(guī)模和其工作負(fù)荷的增長，原框架的問題逐漸浮出水面，主要的問題集中如下：
- JobTracker 是 Map-reduce 的集中處理點，存在單點故障。
- JobTracker 完成了太多的任務(wù)，造成了過多的資源消耗，當(dāng) map-reduce job 非常多的時候，會造成很大的內(nèi)存開銷，潛在來說，也增加了 JobTracker fail 的風(fēng)險，這也是業(yè)界普遍總結(jié)出老 Hadoop 的 Map-Reduce 只能支持 4000 節(jié)點主機的上限。
- 在 TaskTracker 端，以 map/reduce task 的數(shù)目作為資源的表示過于簡單，沒有考慮到 cpu/ 內(nèi)存的占用情況，如果兩個大內(nèi)存消耗的 task 被調(diào)度到了一塊，很容易出現(xiàn) OOM。
- 在 TaskTracker 端，把資源強制劃分為 map task slot 和 reduce task slot, 如果當(dāng)系統(tǒng)中只有 map task 或者只有 reduce task 的時候，會造成資源的浪費，也就是前面提過的集群資源利用的問題。
