MapReduce精髓

雖然Google的MapReduce論文很老了（十多年），但只要還沒看，就值得一看。

概要

MapReduce是一種重視容錯性的分佈式並行計算模式，它把分佈式並行計算分爲map和reduce兩個階段：

• map: 把輸入數據集切分紅不少份（1份可包含不少records），傳給map函數作轉換處理（每次處理1條record，得出1條結果），結果集被輸出到文件
• reduce: 讀取map的結果集，傳給reduce函數作歸約處理（每次處理1條record，更新一條共享的結果），結果集被輸出到文件

數據一般是key-value格式的，像HashMap，key關聯着value。key是鏈接map和reduce的紐帶，reduce經過key來拉取相關的map結果，把關聯某個key的一批values歸約成一個收斂的結果。

每臺機器是一個node。map和reduce均可以在不少worker node上運行。1個任務=1個函數+1組輸入數據，任務被分配到worker node上運行。有一箇中央的調度器，叫作master node，來進行全局調度，給worker node分配任務。

示意圖就不貼了，處處可見的WordCount例子也不寫了，別人寫過的我通常不寫。請參考網絡資料。例如這篇就挺好：https://mr-dai.github.io/mapr...

參考好了嗎？繼續吧！

優化

論文指出它是爲大量廉價機器組成的環境而設計的，環境特色是：機器特別多，機器性能良莠不齊，有的機器會忽然壞掉。論文的不少優化都是在解決這種環境所特有的問題，這在當時是開創性的，由於通常的分佈式並行技術都還在研究一組性能均等的高性能機器，不能容忍某臺機器變慢或故障。如今工業界都是用MapReduce的方式在搞，由於多數企業的環境都是論文裏說的這種。

Google推出MapReduce論文時已經考慮周密了，給出了不少優化點：
Map階段:

1. 一開始先把輸入數據集切分紅M片，每片通常16~64MB
2. map完成時通知master，master記錄全部map的完成狀況和文件位置
3. map tasks要切得小而多，建議遠大於機器數，容易負載均衡（3個task分給2個node，均衡度確定不如13個task分給2個node）
4. map tasks儘可能分配到靠近數據的node，以節省帶寬
5. 用combine函數作本地預合併，以減少map的輸出結果集

Reduce階段：

1. reducer從mapper node下載輸入文件
2. reduce先寫臨時文件，完成時用原子的文件重命名操做
3. reduce用lazy iterator讀取輸入，以節省內存

全階段：

1. map輸出到本地文件，reduce輸出到全局文件
2. map和reduce均可有多個副本同時重複執行，誰快就用誰的結果（即便有個副本忽然變慢，也有別的副本在跑）
3. 總有一些落後進程，增長百分之幾的備用資源，就能加速掃除長尾，節省百分之幾十的時間
4. 調度器儘可能把任務分配給空閒的worker，所以速度快的worker天然會處理更多tasks
5. 遇到錯誤的record，寫標記到master，再有task遇到時跳過它

註釋：這種「總有一些落後進程」的現象叫作尾部延遲放大(tail delay amplification)，分佈式數據庫執行查詢的scatter/gatter模式也有此問題。Google的解法至關於task rebalance，來個比喻：讓先進員工幫助落後員工完成積壓的任務，以保證全團隊的項目按時完成。咱們要知道，「計算易移動，數據難移動」，咱們老是傾向於把計算移動到另外一處，而不是把數據移過去。MapReduce就是移動了計算，而且把計算儘量移動到數據附近。task rebalance只移動計算，無需移動數據，因此才管用。而分佈式數據庫在執行查詢時，把計算分發到data node上，若是有的data node反應慢，就沒有辦法，由於數據很差移。