分布式离线计算—MapReduce—为什么被淘汰了？
原文作者：蔡元楠
原文地址：為什么MapReduce會被硅谷一線公司淘汰？?time.geekbang.org
目錄
超大規模數據處理的技術發展
為什么MapReduce會被取代
推薦閱讀：
每次和來硅谷參觀的同行交流的時候，只要談起數據處理技術，他們總是試圖打探MapReduce方面的經驗。這一點讓我頗感驚訝，因為在硅谷，MapReduced大家談的已經很少了。今天這一講，我們就來聊聊為什么MapReduce會被硅谷一線公司淘汰。
我們先來沿著時間線看一下超大規模數據處理的重要技術以及它們產生的年代：
超大規模數據處理的技術發展
我認為可以把超大規模數據處理的技術發展分為三個階段：石器時代，青銅時代，蒸汽機時代。
石器時代：
我用”石器時代“來比喻MapReduce誕生之前的時期。雖然數據的大規模處理問題早已存在，早在2003年的時候，Google就已經面對大于600億的搜索量。但是數據的大規模處理技術還處在彷徨階段。當時每個公司或者個人可能都有自己的一套工具處理數據。卻沒有提煉抽象出一個系統的方法。
青銅時代：
2003年，MapReduce的誕生標志了超大規模數據處理的第一次革命，而開創這段青銅時代的就是下面這篇論文《MapReduce: Simplified Data Processing on Large Clusters》。杰夫（Jeff Dean）和桑杰（Sanjay Ghemawat）從紛繁復雜的業務邏輯中，為我們抽象出了Map和Reduce這樣足夠通用的編程模型。后面的Hadoop僅僅是對于GFS、BigTable、MapReduce 的依葫蘆畫瓢，我這里不再贅述。?
蒸汽機時代：
到了2014年左右，Google內部已經幾乎沒人寫新的MapReduce了。2016年開始，Google在新員工的培訓中把MapReduce替換成了內部稱為Flume（不要和Apache Flume混淆，是兩個技術）的數據處理技術，這標志著青銅時代的終結，同時也標志著蒸汽機時代的開始。我跳過“鐵器時代”之類的描述，是因為只有工業革命的概念才能解釋從MapReduce進化到Flume的劃時代意義。Google 內部的 Flume和它后來的開源版本Apache Beam所引進的統一的編程模式將在后面的章節中為你深入解析。現在你可能有一個疑問 ：為什么MapReduce會被取代？
為什么MapReduce會被取代
1、高昂的維護成本
使用MapReduce，你需要嚴格地遵循分步的Map和Reduce步驟，當你構造更為復雜的處理架構時，往往需要協調多個Map和多個Reduce任務。然而每一步的MapReduce都有可能出錯。為了這些異常處理，很多人開始設計自己的協調系統（orchestration）。例如做一個狀態機（state machine）協調多個MapReduce，這大大增加了整個系統的復雜度。如果你搜 "MapReduce orchestration" 這樣的關鍵詞，就會發現有很多書整整一本都在寫怎樣協調MapReduce。你可能驚訝于MapReduce的復雜度。我經常看到一些把MapReduce說得過度簡單的誤導性文章，例如“把海量的××數據通過MapReduce導入大數據系統學習，就能產生××人工智能”，似乎寫文的”專家“動動嘴就能點石成金。而現實的MapReduce系統的復雜度是超過了“偽專家”的認知范圍的。下面我來舉個例子，告訴你MapReduce有多復雜。想象一下這個情景，你的公司要預測美團的股價，其中一個重要特征是活躍在街頭的美團外賣電動車數量，而你負責處理所有美團外賣電動車的圖片。在真實的商用環境下，你可能至少需要10個MapReduce任務：
首先，我們需要搜集每日的外賣電動車圖片。數據的搜集往往不全部是公司獨自完成，許多公司會選擇部分外包或者眾包。所以在數據搜集（Data collection）部分，你至少需要4個MapReduce任務：
僅僅是做完數據搜集這一步，離真正的業務應用還差的遠。真實的世界是如此不完美，我們需要一部分數據質量控制 （quality control）流程，比如：
最后才到你負責的重頭戲：找到這些圖片里的外賣電動車。而這一步因為人工的介入是最難控制時間的。你需要做4步：
我不再深入每個MapReduce任務的技術細節，因為本章的重點僅僅是理解MapReduce的復雜度。通過這個案例，我想要闡述的觀點是，因為真實的商業MapReduce場景極端復雜，上面這樣10個子任務的MapReduce系統在硅谷一線公司司空見慣。在應用過程中，每一個MapReduce任務都有可能出錯，都需要重試和異常處理的機制。協調這些子MapReduce的任務往往需要和業務邏輯緊密耦合的狀態機，過于復雜的維護讓系統開發者苦不堪言。
2、時間性能“達不到”用戶的期待
除了高昂的維護成本，MapReduce的時間性能也是個棘手的問題。MapReduce是一套如此精巧復雜的系統，如果使用得當，它是青龍偃月刀，如果使用不當它就是一堆廢鐵，不幸的是并不是每個人都是關羽。實際的工作中，不是每個人都對MapReduce細微的配置細節了如指掌。在現實工作中，業務往往需求一個剛畢業的新手在3個月內上線一套數據處理系統，而他很可能從來沒有用過MapReduce。這種情況下開發的系統是很難發揮好MapReduce的性能的。你一定想問，MapReduce的性能優化配置究竟復雜在哪里呢？
事實上，Google的MapReduce性能優化手冊有500多頁。這里我舉例講講MapReduce的分片（sharding）難題，希望能窺斑見豹，引發大家的思考。Google曾經在2007年到2012年做過一個對于1PB數據的大規模排序實驗，來測試MapReduce的性能。從2007年的排序時間12小時，到2012年的排序時間0.5小時，即使是Google，也花了5年的時間才不斷優化了一個MapReduce流程的效率。2011年，他們在Google Research的博客上公布了初步的成果（http://googleresearch.blogspot.com/2011/09/sorting-petabytes-with-mapreduce-next.html）。其中有一個重要的發現，就是他們在MapReduce的性能配置上花了非常多的時間。包括了緩沖大小(buffer size），分片多少（number of shards），預抓取策略（prefetch），緩存大小（cache size）等等。所謂的分片，是指把大規模的的數據分配給不同的機器/工人，流程如下圖所示。?
?
選擇一個好的分片函數（sharding function）為何格外重要？讓我們來看一個例子。假如你在處理Facebook的所有用戶數據，你選擇了按照用戶的年齡作為分片函數（sharding function）。我們來看看這時候會發生什么。因為用戶的年齡分布不均衡，假如在20-30這個年齡段的Facebook用戶最多，導致我們在下圖中worker C上分配到的任務遠大于別的機器上的任務量。
這時候就會發生掉隊者問題（stragglers）。別的機器都完成了Reduce階段，它還在工作。掉隊者問題可以通過MapReduce的性能剖析（profiling）發現。 如下圖所示，箭頭處就是掉隊的機器。
圖片引用：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大規模排序實驗。因為MapReduce的分片配置異常復雜，所以在2008年以后，Google改進了MapReduce的分片功能，引進了動態分片技術 (dynamic sharding），大大簡化了使用者對于分片的手工調整。在這之后，包括動態分片技術在內的各種嶄新思想被逐漸引進，奠定了下一代大規模數據處理技術的雛型。
推薦閱讀：
《大規模數據處理實戰》?time.geekbang.org
總結
以上是生活随笔為你收集整理的分布式离线计算—MapReduce—为什么被淘汰了？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 分布式离线计算—MapReduce—基础
- 下一篇： 分布式离线计算—MapReduce—基本