我們先來沿著時間線看一下超大規(guī)模數(shù)據(jù)處理的重要技術(shù)以及它們產(chǎn)生的年代。
我認(rèn)為可以把超大規(guī)模數(shù)據(jù)處理的技術(shù)發(fā)展分為三個階段：石器時代，青銅時代，蒸汽機(jī)時代。
石器時代
我用“石器時代”來比喻 MapReduce 誕生之前的時期。
數(shù)據(jù)的大規(guī)模處理問題早已存在。早在 2003 年的時候，Google 就已經(jīng)面對大于 600 億的搜索量。
但是數(shù)據(jù)的大規(guī)模處理技術(shù)還處在彷徨階段。當(dāng)時每個公司或者個人可能都有自己的一套工具處理數(shù)據(jù)。卻沒有提煉抽象出一個系統(tǒng)的方法。
青銅時代
2003 年，MapReduce 的誕生標(biāo)志了超大規(guī)模數(shù)據(jù)處理的第一次革命，而開創(chuàng)這段青銅時代的就是下面這篇論文《MapReduce: Simplified Data Processing on Large Clusters》。
杰夫（Jeff Dean）和桑杰（Sanjay Ghemawat）從紛繁復(fù)雜的業(yè)務(wù)邏輯中，為我們抽象出了 Map 和 Reduce 這樣足夠通用的編程模型。后面的 Hadoop 僅僅是對于 GFS、BigTable、MapReduce 的依葫蘆畫瓢。
蒸汽機(jī)時代
到了 2014 年左右，Google 內(nèi)部已經(jīng)幾乎沒人寫新的 MapReduce 了。
2016 年開始，Google 在新員工的培訓(xùn)中把 MapReduce 替換成了內(nèi)部稱為 FlumeJava（不要和 Apache Flume 混淆，是兩個技術(shù)）的數(shù)據(jù)處理技術(shù)。
這標(biāo)志著青銅時代的終結(jié)，同時也標(biāo)志著蒸汽機(jī)時代的開始。
Google 內(nèi)部的 FlumeJava 和它后來的開源版本 Apache Beam 所引進(jìn)的統(tǒng)一的編程模式，將在后面的章節(jié)中為你深入解析。
現(xiàn)在你可能有一個疑問 ：為什么 MapReduce 會被取代？今天我將重點(diǎn)為你解答。
高昂的維護(hù)成本
使用 MapReduce，你需要嚴(yán)格地遵循分步的 Map 和 Reduce 步驟。當(dāng)你構(gòu)造更為復(fù)雜的處理架構(gòu)時，往往需要協(xié)調(diào)多個 Map 和多個 Reduce 任務(wù)。
然而，每一步的 MapReduce 都有可能出錯。
為了這些異常處理，很多人開始設(shè)計自己的協(xié)調(diào)系統(tǒng)（orchestration）。例如，做一個狀態(tài)機(jī)（state machine）協(xié)調(diào)多個 MapReduce，這大大增加了整個系統(tǒng)的復(fù)雜度。
在應(yīng)用過程中，每一個 MapReduce 任務(wù)都有可能出錯，都需要重試和異常處理的機(jī)制。所以，協(xié)調(diào)這些子 MapReduce 的任務(wù)往往需要和業(yè)務(wù)邏輯緊密耦合的狀態(tài)機(jī)。
這樣過于復(fù)雜的維護(hù)讓系統(tǒng)開發(fā)者苦不堪言。
時間性能“達(dá)不到”用戶的期待
除了高昂的維護(hù)成本，MapReduce 的時間性能也是個棘手的問題。
MapReduce 是一套如此精巧復(fù)雜的系統(tǒng)，如果使用得當(dāng)，它是青龍偃月刀，如果使用不當(dāng)，它就是一堆廢鐵。不幸的是并不是每個人都是關(guān)羽。
在實(shí)際的工作中，不是每個人都對 MapReduce 細(xì)微的配置細(xì)節(jié)了如指掌。
在現(xiàn)實(shí)中，業(yè)務(wù)往往需求一個剛畢業(yè)的新手在 3 個月內(nèi)上線一套數(shù)據(jù)處理系統(tǒng)，而他很可能從來沒有用過 MapReduce。這種情況下開發(fā)的系統(tǒng)是很難發(fā)揮好 MapReduce 的性能的。
你一定想問，MapReduce 的性能優(yōu)化配置究竟復(fù)雜在哪里呢？
我想 Google500 多頁的 MapReduce 性能優(yōu)化手冊足夠說明它的復(fù)雜度了。這里我舉例講講 MapReduce 的分片（sharding）難題，希望能窺斑見豹，引發(fā)大家的思考。
Google 曾經(jīng)在 2007 年到 2012 年間做過一個對于 1PB 數(shù)據(jù)的大規(guī)模排序?qū)嶒?，來測試 MapReduce 的性能。
從 2007 年的排序時間 12 小時，到 2012 年的排序時間縮短至 0.5 小時。即使是 Google，也花了 5 年的時間才不斷優(yōu)化了一個 MapReduce 流程的效率。
其中有一個重要的發(fā)現(xiàn)，就是他們在 MapReduce 的性能配置上花了非常多的時間。包括了緩沖大小 (buffer size），分片多少（number of shards），預(yù)抓取策略（prefetch），緩存大?。╟ache size）等等。
所謂的分片，是指把大規(guī)模的的數(shù)據(jù)分配給不同的機(jī)器 / 工人，流程如下圖所示。
選擇一個好的分片函數(shù)（sharding function）為何格外重要？讓我們來看一個例子。
假如你在處理 Facebook 的所有用戶數(shù)據(jù)，你選擇了按照用戶的年齡作為分片函數(shù)（sharding function）。我們來看看這時候會發(fā)生什么。
因為用戶的年齡分布不均衡（假如在 20~30 這個年齡段的 Facebook 用戶最多），導(dǎo)致我們在下圖中 worker C 上分配到的任務(wù)遠(yuǎn)大于別的機(jī)器上的任務(wù)量。
這時候就會發(fā)生掉隊者問題（stragglers）。別的機(jī)器都完成了 Reduce 階段，只有 worker C 還在工作。
