擴展MapReduce架構的一種嘗試

[size=medium]
假設有這樣一個遊戲，一個人來出加減乘除的題目給很多小朋友來做，對每一個小朋友，給他出一道題目，然後讓他算好後給你報告答案，你再給他出一道題目，週而復始如此。如果有十個小朋友在算，還可以欣賞小朋友抓耳撓腮的樣子；如果有一百個小朋友，每個人都在爭着表現，叫嚷着讓出題，這個人肯定不堪重負；如果有成千上萬個小朋友呢？這個人瘋了。

面對這樣的場景，學生時的經驗是不斷地改進和優化算法；而工作以後的經驗是再拽的算法也難以抵擋海量的數據或任務，主要還是增加資源，其次纔是優化算法，兩者可並行。小朋友越多，相應地增加出題人的數量，也可以緩解每個人的壓力。

與這種場景類似，MapReduce框架也面臨類似的問題。如下圖：


[img]http://dl.iteye.com/upload/attachment/426807/e1ebd8cd-b47d-3fc5-a14a-4c3f3e17a7d4.jpg[/img]


越來越多的task tracker會讓job tracker很有壓力，以至於task tracker有很多時，job tracker不能及時響應請求，很多task tracker就空閒着資源，等待job tracker的response。Job tracker的壓力與task tracker的資源浪費問題導致整個集羣難於擴展，對外提供服務的能力也相當下降很多。當前Yahoo也受此困擾，正醞釀[url=http://developer.yahoo.com/blogs/hadoop/posts/2011/02/mapreduce-nextgen/]重構MapReduce架構[/url]。我沒從這個架構看出對現有問題的改善之處，所以自己來試着分析下解決方法。

回頭來看模擬場景，如果把小朋友按班分，每個班都有一位老師。每位老師從出題人那裏得到很多題目，然後讓自己班的小朋友來做。這樣，出題人的壓力在於老師的數量，老師的壓力在於班裏小朋友的數量。以前小朋友數量增加帶給出題人的壓力，現在分攤到老師就會成倍地減少。與之前相比，不同處在於引入了老師這個角色。

如果以同樣方式解決MapReduce問題，那“老師”的角色應該由誰來扮演呢？MapReduce的初衷之一是“儘量移動計算而不是數據”。假如數據存放於HDFS這樣的文件系統上，移動數據的成本在於機器之間的帶寬限制，由此HDFS網絡拓撲結構表示機器之間數據移動的等級。MapReduce的map task會去訪問HDFS的存儲block，如果block在機器本地或是與task tracker 在同一rack內，對執行沒有太大影響，否則集羣帶寬會嚴重影響task執行效率。

從上述描述來看，影響task執行的最大網絡拓撲範圍是rack。一般來說，Rack間的網絡帶寬肯定要比rack內的帶寬小。那我們就以rack來作爲“老師”的角色。以此假設，我們在每個rack內將某臺機器設爲secondary job tracker，負責rack內task資源的調度與分發單位。結構圖如下：


[img]http://dl.iteye.com/upload/attachment/426805/f634450d-9135-361a-8854-bb7cd22adc5e.jpg[/img]


這個結構有兩種job tracker：Global job tracker與Secondary job tracker。Global JT負責跨rack的task分發與調度。基本task分配策略是根據job輸入數據的block存儲情況，只分配block在當前rack內的map task到rack上，分配reduce task 到 map task多的rack上。Secondary JT與Global JT保持着心跳，它管理的map task操作數據要麼是node-local，要麼是rack-local cache 級別，不會再有map task跨rack取數據的場景，所以分發策略就很簡單了。

在這個結構下，client提交job的流程就變成：1. Client上傳job相關的輸入數據到HDFS上，HDFS會將block幅本存放與不同的data node上，這些data node有在同一個rack內，也有跨rack存在的。2. job提交到Global JT後，根據block存儲情況(在哪些rack上存在block就往哪些rack的Secondary JT發送map task，且根據rack上map task的多少來分發reduce task)。3. Secondary JT向Global JT彙報當前rack內的資源情況，得到那些自己rack內的task。4. Secondary JT響應本rack內的TT 心跳，然後分配適合的task來執行。

以rack劃分MapReduce架構，也是考慮到HDFS與網絡帶寬情況的結果。如果每個rack內有15到20臺機器，10000臺機器差不多可以分佈到七八百rack內。Global JT與Secondary JT的併發壓力都不大。這樣的垂直擴展只是暫時解決了部分問題，但沒有從根本上解決job分配程序的壓力。

上述只是我的個人想法，希望得到各位的指正及建議，謝謝！

[/size]