原文作者：蔡元楠

原文地址：為什么MapReduce會被硅谷一線公司淘汰？?time.geekbang.org

目錄

超大規(guī)模數(shù)據(jù)處理的技術(shù)發(fā)展

為什么MapReduce會被取代

推薦閱讀：

---

每次和來硅谷參觀的同行交流的時候，只要談起數(shù)據(jù)處理技術(shù)，他們總是試圖打探MapReduce方面的經(jīng)驗。這一點讓我頗感驚訝，因為在硅谷，MapReduced大家談的已經(jīng)很少了。今天這一講，我們就來聊聊為什么MapReduce會被硅谷一線公司淘汰。

我們先來沿著時間線看一下超大規(guī)模數(shù)據(jù)處理的重要技術(shù)以及它們產(chǎn)生的年代：

超大規(guī)模數(shù)據(jù)處理的技術(shù)發(fā)展

我認(rèn)為可以把超大規(guī)模數(shù)據(jù)處理的技術(shù)發(fā)展分為三個階段：石器時代，青銅時代，蒸汽機時代。

石器時代：

我用”石器時代“來比喻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 的依葫蘆畫瓢，我這里不再贅述。?

蒸汽機時代：

到了2014年左右，Google內(nèi)部已經(jīng)幾乎沒人寫新的MapReduce了。2016年開始，Google在新員工的培訓(xùn)中把MapReduce替換成了內(nèi)部稱為Flume（不要和Apache Flume混淆，是兩個技術(shù)）的數(shù)據(jù)處理技術(shù)，這標(biāo)志著青銅時代的終結(jié)，同時也標(biāo)志著蒸汽機時代的開始。我跳過“鐵器時代”之類的描述，是因為只有工業(yè)革命的概念才能解釋從MapReduce進(jìn)化到Flume的劃時代意義。Google 內(nèi)部的 Flume和它后來的開源版本Apache Beam所引進(jìn)的統(tǒng)一的編程模式將在后面的章節(jié)中為你深入解析。現(xiàn)在你可能有一個疑問 ：為什么MapReduce會被取代？

為什么MapReduce會被取代

1、高昂的維護(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)機（state machine）協(xié)調(diào)多個MapReduce，這大大增加了整個系統(tǒng)的復(fù)雜度。如果你搜 "MapReduce orchestration" 這樣的關(guān)鍵詞，就會發(fā)現(xiàn)有很多書整整一本都在寫怎樣協(xié)調(diào)MapReduce。你可能驚訝于MapReduce的復(fù)雜度。我經(jīng)常看到一些把MapReduce說得過度簡單的誤導(dǎo)性文章，例如“把海量的××數(shù)據(jù)通過MapReduce導(dǎo)入大數(shù)據(jù)系統(tǒng)學(xué)習(xí)，就能產(chǎn)生××人工智能”，似乎寫文的”專家“動動嘴就能點石成金。而現(xiàn)實的MapReduce系統(tǒng)的復(fù)雜度是超過了“偽專家”的認(rèn)知范圍的。下面我來舉個例子，告訴你MapReduce有多復(fù)雜。想象一下這個情景，你的公司要預(yù)測美團的股價，其中一個重要特征是活躍在街頭的美團外賣電動車數(shù)量，而你負(fù)責(zé)處理所有美團外賣電動車的圖片。在真實的商用環(huán)境下，你可能至少需要10個MapReduce任務(wù)：

首先，我們需要搜集每日的外賣電動車圖片。數(shù)據(jù)的搜集往往不全部是公司獨自完成，許多公司會選擇部分外包或者眾包。所以在數(shù)據(jù)搜集（Data collection）部分，你至少需要4個MapReduce任務(wù)：

數(shù)據(jù)導(dǎo)入（data ingestion）：用來把散落的照片（比如眾包公司上傳到網(wǎng)盤的照片）下載到你的存儲系統(tǒng)。

數(shù)據(jù)統(tǒng)一化（data normalization）：用來把不同外包公司提供過來的各式各樣的照片進(jìn)行格式統(tǒng)一。

數(shù)據(jù)壓縮（compression）：你需要在質(zhì)量可接受的范圍內(nèi)保持最小的存儲資源消耗 。

數(shù)據(jù)備份（backup）：大規(guī)模的數(shù)據(jù)處理系統(tǒng)我們都需要一定的數(shù)據(jù)冗余來降低風(fēng)險。

僅僅是做完數(shù)據(jù)搜集這一步，離真正的業(yè)務(wù)應(yīng)用還差的遠(yuǎn)。真實的世界是如此不完美，我們需要一部分數(shù)據(jù)質(zhì)量控制 （quality control）流程，比如：

數(shù)據(jù)時間有效性驗證 （date validation）：檢測上傳的圖片是否是你想要的日期的。

照片對焦檢測（focus detection）：你需要篩選掉那些因?qū)共粶?zhǔn)而無法使用的照片。

最后才到你負(fù)責(zé)的重頭戲：找到這些圖片里的外賣電動車。而這一步因為人工的介入是最難控制時間的。你需要做4步：

數(shù)據(jù)標(biāo)注問題上傳（question uploading）：上傳你的標(biāo)注工具，讓你的標(biāo)注者開始工作。

標(biāo)注結(jié)果下載（answer downloading）：抓取標(biāo)注完的數(shù)據(jù)。

標(biāo)注異議整合（adjudication）：標(biāo)注異議經(jīng)常發(fā)生，比如一個標(biāo)注者認(rèn)為是美團外賣電動車，另一個標(biāo)注者認(rèn)為是京東快遞電動車。

標(biāo)注結(jié)果結(jié)構(gòu)化（structuralization）: 要讓標(biāo)注結(jié)果可用，你需要把可能非結(jié)構(gòu)化的標(biāo)注結(jié)果轉(zhuǎn)化成你的存儲系統(tǒng)接受的結(jié)構(gòu)。

我不再深入每個MapReduce任務(wù)的技術(shù)細(xì)節(jié)，因為本章的重點僅僅是理解MapReduce的復(fù)雜度。通過這個案例，我想要闡述的觀點是，因為真實的商業(yè)MapReduce場景極端復(fù)雜，上面這樣10個子任務(wù)的MapReduce系統(tǒng)在硅谷一線公司司空見慣。在應(yīng)用過程中，每一個MapReduce任務(wù)都有可能出錯，都需要重試和異常處理的機制。協(xié)調(diào)這些子MapReduce的任務(wù)往往需要和業(yè)務(wù)邏輯緊密耦合的狀態(tài)機，過于復(fù)雜的維護(hù)讓系統(tǒng)開發(fā)者苦不堪言。

2、時間性能“達(dá)不到”用戶的期待

除了高昂的維護(hù)成本，MapReduce的時間性能也是個棘手的問題。MapReduce是一套如此精巧復(fù)雜的系統(tǒng)，如果使用得當(dāng)，它是青龍偃月刀，如果使用不當(dāng)它就是一堆廢鐵，不幸的是并不是每個人都是關(guān)羽。實際的工作中，不是每個人都對MapReduce細(xì)微的配置細(xì)節(jié)了如指掌。在現(xiàn)實工作中，業(yè)務(wù)往往需求一個剛畢業(yè)的新手在3個月內(nèi)上線一套數(shù)據(jù)處理系統(tǒng)，而他很可能從來沒有用過MapReduce。這種情況下開發(fā)的系統(tǒng)是很難發(fā)揮好MapReduce的性能的。你一定想問，MapReduce的性能優(yōu)化配置究竟復(fù)雜在哪里呢？

事實上，Google的MapReduce性能優(yōu)化手冊有500多頁。這里我舉例講講MapReduce的分片（sharding）難題，希望能窺斑見豹，引發(fā)大家的思考。Google曾經(jīng)在2007年到2012年做過一個對于1PB數(shù)據(jù)的大規(guī)模排序?qū)嶒?#xff0c;來測試MapReduce的性能。從2007年的排序時間12小時，到2012年的排序時間0.5小時，即使是Google，也花了5年的時間才不斷優(yōu)化了一個MapReduce流程的效率。2011年，他們在Google Research的博客上公布了初步的成果（http://googleresearch.blogspot.com/2011/09/sorting-petabytes-with-mapreduce-next.html）。其中有一個重要的發(fā)現(xiàn)，就是他們在MapReduce的性能配置上花了非常多的時間。包括了緩沖大小(buffer size），分片多少（number of shards），預(yù)抓取策略（prefetch），緩存大小（cache size）等等。所謂的分片，是指把大規(guī)模的的數(shù)據(jù)分配給不同的機器/工人，流程如下圖所示。?

?

選擇一個好的分片函數(shù)（sharding function）為何格外重要？讓我們來看一個例子。假如你在處理Facebook的所有用戶數(shù)據(jù)，你選擇了按照用戶的年齡作為分片函數(shù)（sharding function）。我們來看看這時候會發(fā)生什么。因為用戶的年齡分布不均衡，假如在20-30這個年齡段的Facebook用戶最多，導(dǎo)致我們在下圖中worker C上分配到的任務(wù)遠(yuǎn)大于別的機器上的任務(wù)量。

這時候就會發(fā)生掉隊者問題（stragglers）。別的機器都完成了Reduce階段，它還在工作。掉隊者問題可以通過MapReduce的性能剖析（profiling）發(fā)現(xiàn)。 如下圖所示，箭頭處就是掉隊的機器。

圖片引用：Chen, Qi, Cheng Liu, and Zhen Xiao. "Improving MapReduce performance using smart speculative execution strategy." IEEE Transactions on Computers 63.4 (2014): 954-967.

回到剛剛的Google大規(guī)模排序?qū)嶒灐Ｒ驗镸apReduce的分片配置異常復(fù)雜，所以在2008年以后，Google改進(jìn)了MapReduce的分片功能，引進(jìn)了動態(tài)分片技術(shù) (dynamic sharding），大大簡化了使用者對于分片的手工調(diào)整。在這之后，包括動態(tài)分片技術(shù)在內(nèi)的各種嶄新思想被逐漸引進(jìn)，奠定了下一代大規(guī)模數(shù)據(jù)處理技術(shù)的雛型。

推薦閱讀：

《大規(guī)模數(shù)據(jù)處理實戰(zhàn)》?time.geekbang.org

總結(jié)

以上是生活随笔為你收集整理的分布式离线计算—MapReduce—为什么被淘汰了？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。