MapReduce:job在Job Tracker上的初始化

[size=medium]
這篇來說道說道job在到達Job Tracker後會有哪些動作，涉及上篇job生命週期的第五步和第六步。因爲job在初始化後緊接着需要應付Job Tracker對Task Tracker的task分發響應，所以我們從Job Tracker的分發過程倒着來看job初始化。

Task Tracker在運行時會週期性地向Job Tracker發送心跳請求，彙報Task Tracker的狀態數據、本Task Tracker上task執行狀態及希望從Job Tracker得到可以執行的task來做。在這裏再得明確下task的概念。Task是job的基本單元，由Job Tracker分發到Task Tracker來執行。task分爲兩類: map task與reduce task。map task處理輸入數據，它就應該是輸入數據、job相關信息等組成的對象；reduce task彙總map task的輸出結果，最後生成job的輸出，它也應是由job相關信息組成。task是在Task Tracker上執行，所以task需要的信息須與Job Tracker的狀態信息有關，以便task執行時需要。

在前一節[url=http://langyu.iteye.com/blog/909170]Job提交過程[/url]中說到，job將所有輸入數據組裝成了邏輯分片，這些邏輯分片只是HDFS上物理數據block的索引及存儲信息。map task依賴於這些信息來決定將task分發到哪些Task Tracker上。Job Tracker可以取到job相關的metadata信息，然後由這些信息來決定如何分發task。因此，上一節的這些分片的相關信息就存放在特定的目錄下，Job Tracker通過jobId可以訪問到。

Reduce task不管在哪個Task Tracker上執行，都得從其它那些執行map task的Task Tracker上拉取數據，所以對它的分發Job Tracker不需要準備什麼，只要在合適的時候放到某臺Task Tracker上執行即可。Job Tracker主要還是關注map task的準備工作(Reduce task並不是從所有map task拉取臨時數據。如果有多個reduce task的話，每個reduce task只拉取一部分map task的臨時數據。關於partition等相關的細節以後會說到)。

這裏介紹Job Tracker分發task過程中比較重要的一步：data locality級別。map task的執行效率依賴於讀取輸入數據的效率。輸入數據越靠近執行task的Task Tracker，map task就執行的越快。根據數據所處的位置與Task Tracker的距離，有如下幾種data locality級別：[/size]
[quote]
0 node-local 輸入分片就在Task Tracker本地
1 rack-local 輸入分片在Task Tracker所在的rack內其它Task Tracker上
2 off-switch 輸入分片在其它的rack內
[/quote]
[size=medium]
Job Tracker在task分發時應充分考慮data locality級別。分發策略對job執行效率的影響很大程度是如何優化map task的locality。[/size]


[img]http://dl.iteye.com/upload/attachment/429530/8ea55ed6-bf4f-3740-9821-6c2b90edb767.jpg[/img]
[size=medium]
Job Tracker可以從job的metadata中得到並維護這樣一種映射關係：job split ----> HDFS block && slave node。這種映射關係就是生成map task的基礎。有多少個split，就會有map task。如上所述，響應心跳而選擇map task的處理就像這樣：
1. 根據Task Tracker的機器，查看Job Tracker中是否存在一個map task，它關聯的block(假設一個block劃分爲一個split)存儲在Task Tracker的本地磁盤上，那麼就優先執行這個map task。
2. 如果沒有1可選的map task，那麼查看是否有map關聯的block在Task Tracker所在的rack內。
3. 如果上面兩步都沒有選到某個map task，那麼就根據情況看是否執行跨rack的task或其它推測式執行task。

初始化的基本工作就很少一些，主要的選擇邏輯還是task scheduler應該做的事情。既然提到Scheduler，還得說MapReduce默認的JobQueue scheduler在理論上有個嚴重的問題。如果它沒有從1或2中選取到map task，那麼它就會執行某個跨rack的map task。理想情況下應該儘量避免這樣做，當前的Task Tracker本地或rack內不存在task所需的split，但其它rack內的Task Tracker上肯定會存在那個split的，那個有split存在的Task Tracker之後也會從Job Tracker取task，把這種map task放到有數據的Task Tracker上做肯定比跨rack取數據快。所以如果可能的話，儘量按照實際情況選取合適的scheduler(以上之所以是理論，也是因爲大部分的執行環境都沒有與rack有關物理拓撲結構)。

Scheduler還得注意的一點是，當用戶開啓task推測式執行，那推測式執行就會發生在Job Tracker意識到某個task執行效率低的時候，儘量要讓推測式task是node local級別的。如果推測式task要跨rack取數據，比原來的task執行還慢，就沒有現實意義了。

Job初始化過程主要是在Job Tracker建立一個slave node對task的映射模型，其它都是附屬工作。我會把job生命週期的重點放在task執行的過程，也就是那個“奇蹟發生的地方”。To be continued...

[/size]