原文作者：蔡元楠

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

目錄

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

為什么MapReduce會(huì)被取代

推薦閱讀：

---

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

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

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

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

石器時(shí)代：

我用”石器時(shí)代“來(lái)比喻MapReduce誕生之前的時(shí)期。雖然數(shù)據(jù)的大規(guī)模處理問(wèn)題早已存在，早在2003年的時(shí)候，Google就已經(jīng)面對(duì)大于600億的搜索量。但是數(shù)據(jù)的大規(guī)模處理技術(shù)還處在彷徨階段。當(dāng)時(shí)每個(gè)公司或者個(gè)人可能都有自己的一套工具處理數(shù)據(jù)。卻沒(méi)有提煉抽象出一個(gè)系統(tǒng)的方法。

青銅時(shí)代：

2003年，MapReduce的誕生標(biāo)志了超大規(guī)模數(shù)據(jù)處理的第一次革命，而開(kāi)創(chuàng)這段青銅時(shí)代的就是下面這篇論文《MapReduce: Simplified Data Processing on Large Clusters》。杰夫（Jeff Dean）和桑杰（Sanjay Ghemawat）從紛繁復(fù)雜的業(yè)務(wù)邏輯中，為我們抽象出了Map和Reduce這樣足夠通用的編程模型。后面的Hadoop僅僅是對(duì)于GFS、BigTable、MapReduce 的依葫蘆畫(huà)瓢，我這里不再贅述。?

蒸汽機(jī)時(shí)代：

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

為什么MapReduce會(huì)被取代

1、高昂的維護(hù)成本

使用MapReduce，你需要嚴(yán)格地遵循分步的Map和Reduce步驟，當(dāng)你構(gòu)造更為復(fù)雜的處理架構(gòu)時(shí)，往往需要協(xié)調(diào)多個(gè)Map和多個(gè)Reduce任務(wù)。然而每一步的MapReduce都有可能出錯(cuò)。為了這些異常處理，很多人開(kāi)始設(shè)計(jì)自己的協(xié)調(diào)系統(tǒng)（orchestration）。例如做一個(gè)狀態(tài)機(jī)（state machine）協(xié)調(diào)多個(gè)MapReduce，這大大增加了整個(gè)系統(tǒng)的復(fù)雜度。如果你搜 "MapReduce orchestration" 這樣的關(guān)鍵詞，就會(huì)發(fā)現(xiàn)有很多書(shū)整整一本都在寫(xiě)怎樣協(xié)調(diào)MapReduce。你可能驚訝于MapReduce的復(fù)雜度。我經(jīng)常看到一些把MapReduce說(shuō)得過(guò)度簡(jiǎn)單的誤導(dǎo)性文章，例如“把海量的××數(shù)據(jù)通過(guò)MapReduce導(dǎo)入大數(shù)據(jù)系統(tǒng)學(xué)習(xí)，就能產(chǎn)生××人工智能”，似乎寫(xiě)文的”專(zhuān)家“動(dòng)動(dòng)嘴就能點(diǎn)石成金。而現(xiàn)實(shí)的MapReduce系統(tǒng)的復(fù)雜度是超過(guò)了“偽專(zhuān)家”的認(rèn)知范圍的。下面我來(lái)舉個(gè)例子，告訴你MapReduce有多復(fù)雜。想象一下這個(gè)情景，你的公司要預(yù)測(cè)美團(tuán)的股價(jià)，其中一個(gè)重要特征是活躍在街頭的美團(tuán)外賣(mài)電動(dòng)車(chē)數(shù)量，而你負(fù)責(zé)處理所有美團(tuán)外賣(mài)電動(dòng)車(chē)的圖片。在真實(shí)的商用環(huán)境下，你可能至少需要10個(gè)MapReduce任務(wù)：

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

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

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

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

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

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

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

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

最后才到你負(fù)責(zé)的重頭戲：找到這些圖片里的外賣(mài)電動(dòng)車(chē)。而這一步因?yàn)槿斯さ慕槿胧亲铍y控制時(shí)間的。你需要做4步：

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

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

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

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

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

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

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

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

?

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

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

圖片引用：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ū)嶒?yàn)。因?yàn)镸apReduce的分片配置異常復(fù)雜，所以在2008年以后，Google改進(jìn)了MapReduce的分片功能，引進(jìn)了動(dòng)態(tài)分片技術(shù) (dynamic sharding），大大簡(jiǎn)化了使用者對(duì)于分片的手工調(diào)整。在這之后，包括動(dòng)態(tài)分片技術(shù)在內(nèi)的各種嶄新思想被逐漸引進(jìn)，奠定了下一代大規(guī)模數(shù)據(jù)處理技術(shù)的雛型。

推薦閱讀：

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

總結(jié)

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

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