如何看待 Google 說已經停用 Map Reduce 好多年？

01-14

報道在鏈接里 Google Replaces MapReduce With New Hyper-Scale Cloud Analytics System 。
另外像cloudera這種依賴於Hadoop的公司是不是前景不看好？

昨天我邊盯著一個 MapReduce job 邊聽 Google I/O, 聽到 Urs 說我們都不用 MapReduce 了好桑心，雖然 Google 內部系統通常只有 deprecated 和 experimental 兩種狀態，但真不帶拿 MapReduce 這麼玩兒的不是。

官方 blog[1] 有個簡單解釋，相關論文其實早就出來了。

Today at Google I/O, we are demonstrating Google Cloud Dataflow for the first time. Cloud Dataflow is a fully managed service for creating data pipelines that ingest, transform and analyze data in both batch and streaming modes. Cloud Dataflow is a successor to MapReduce, and is based on our internal technologies like Flume andMillWheel.

我感覺題主鏈接的新聞重點抓錯了，MapReduce 這套分散式計算框架實現的主要局限在於 1. 用 MapReduce 寫複雜的分析 pipeline 太麻煩；2. 它怎麼改進都還是一個基於 batch mode 的框架。

MapReduce 的計算模型特別簡單，只要分析任務稍微複雜一點，你就會發現一趟 MapReduce 是沒法把事情做完了，你就得設計多個互相依賴的 MapReduce 任務，這就是所謂 pipeline.在數據流複雜的分析任務中，設計好的 pipeline 達到最高運行效率很困難，至於給 pipeline 調錯就真是讓人想死。這時就需要用到 Flume[2] 了 —— 演示中的代碼其實就是運用 Flume 框架的 Java 代碼。Flume 提供了一個抽象層次更高的 API，然後一個 planner 把 Flume 程序轉換成若干個 MapReduce 任務去跑。Google 還有很多這種基於 MapReduce 的封裝，有一個叫 Tenzing[3] 的項目，是把複雜的 SQL 查詢轉換（編譯）成 MapReduce, 還有 Sawzall[4] 這樣的直接基於 MapReduce 模型的專用語言。所以沒錯，裸奔 MapReduce API 的時候確實少了，但數據中心裡每天仍有無數的 MapReduce job 甚至在工程師自己都不知道的情況下，默默地低調地跑著 —— 當然這個 MapReduce 經過多年改進，估計 2003 年出論文時的代碼現在已經一行不剩了。如果哪天所有人都不裸奔 MapReduce API 了（總有我這樣的頑固分子），Urs 要偷偷把 MapReduce 換成什麼別的我們可能還真都不知道。

另外插播一句 Flume 的思路沒有多獨特，它的編程模型跟微軟的 LINQ 很相象，DryadLINQ[5] 的計劃演算法也跟 Flume 異曲同工。它們所依賴的理論基礎可就老了去了。

MillWheel[6] 則是解決流計算的問題了。

我覺得必須在概念上把 MapReduce 計算模型，和 Google 內部基於這套計算模型做出的分散式計算框架實現分開。MapReduce 這個計算模型其實很古老，是函數式程序設計里的一個基本思路，它的名字就源於 LISP 類函數式語言里的 map 和 reduce 操作。Google MapReduce 論文的主要貢獻是在於它讓這個非常常用的計算模型跑在了一大堆會隨時崩潰的 PC 上，而不在計算模型本身。

把 MapReduce 看成基本的函數式編程模型而不是具體實現，理解 Flume 和 MillWheel 會簡單很多，Flume 做的工作其實就是一個編譯器，把一個複雜的分析程序編譯成一堆基本的 MapReduce 執行單元。至於 MillWheel 的所謂流計算則跟函數式編程里的懶惰求值大有淵源，比如計算

(map (fn [x] (* x 2)) (map (fn [x] (+ x 1)) data-list))

最笨的做法就是先把 data-list 每項加 1，輸出一個列表作為每項乘 2 的 map 任務的輸入，然後再輸出另一個列表，這就是傳統 MapReduce 實現乾的事情。Clojure 利用 LazySeq 實現了對 map 的懶惰求值，可以做到「要一個算一個」：當要取上述結果的第一項時，它才去取 data-list 中的第一項，作加 1 和乘 2 操作然後輸出，如此類推，就不是做完一個 map 再做另一個 map 了。MillWheel 做的則是方向正好反過來的「來一個算一個」，data-list 里來一個輸入就輸出一個結果，每一步都不需要等上一步全部完成（數據流往往是無限的，沒有「全部完成」的概念）。例如計算：

(reduce + 0 (map (fn [x] (* x 2)) data-stream))

（注意這不是一個典型的 MapReduce，雖然裡面有 map 和 reduce）在 MillWheel 里，就可以隨著 data-stream 數據的湧入，實時顯示當前的數據總和，而不是到 data-stream 結束時才輸出一個結果，而且這樣 x * 2 的中間結果也壓根用不著存儲下來。

可以看到，具體怎麼實現上述運算，是個具體實現的底層優化的問題，在概念上計算模型還是基本的 map 和 reduce，就好比同一條 SQL 查詢語句可用於不同的執行引擎 —— 在 I/O 上工程師也演示了一段分析代碼是怎麼可以不加修改同時適應 batch 模式和流模式的。作為常用計算模型的 MapReduce 並沒有什麼被淘汰的可能。

再補充一句，MapReduce 當然不是唯一可用的計算模型，MillWheel 可以很方便的實現其他計算模型，Google 還有基於圖的計算框架 Pregel[7] 等。另外其實自從有了 Dremel[8], 很多分析任務都可以直接用互動式查詢來完成，寫分析 pipeline 的時候也少了很多。

1. http://googlecloudplatform.blogspot.com/2014/06/reimagining-developer-productivity-and-data-analytics-in-the-cloud-news-from-google-io.html

2. http://pages.cs.wisc.edu/~akella/CS838/F12/838-CloudPapers/FlumeJava.pdf

3. Tenzing A SQL Implementation On The MapReduce Framework

4. Google Research Publication: Sawzall

5. DryadLINQ - Microsoft Research

6. MillWheel: Fault-Tolerant Stream Processing at Internet Scale

7. http://googleresearch.blogspot.com/2009/06/large-scale-graph-computing-at-google.html

8. Dremel: Interactive Analysis of Web-Scale Datasets

恕我直言，那些把MapReduce噴的一無是處的人真正讀過MR的原始論文么？google 發布 mr 從來都不是為了強調 high performance 和 expressive , 而是scalability. 更重要的是，給我們普及了工業屆對真正意義上的「大數據」的理解。屌絲們知足吧，在04年論文出來之前，搞並行計算的人壓根連「容錯」的概念都沒有。站在今天這個時代去批判一個歷史技術，無異於耍流氓。除此之外，大部分人都是通過 Hadoop 這個系統了解 MapReduce 的，但是hadoop 在現在看來無疑是一個非常糟糕的系統，無論是系統的設計還是編程語言的選擇。hadoop中充滿了各種 over engineering，比如說你一個計算框架搞什麼資源調度？！搞什麼job tracker？！這難道不是集群管理系統應該做的么？直到現在，hadoop社區才意識到這個問題，然後再去搞了一個Yarn. 可是人家 Mesos 幾年前早就搞出來了。我親自參與開發過 c++ 版本 mapreduce 的實現，我們的系統甚至可以比 spark 更快。而google 現在內部使用的 mapreduce，也早就不知道演變成了什麼樣子。

每個系統都有自己的歷史地位，一篇論文，一個系統帶給我們更多的是一種思路，以及更深層次的，philosophy 層面的東西。而不是一個具體的系統實現。

強答, 大家用詞其實都挺有意思的, Michael Stonebraker 在最近的演講里用的是abandon, 詳情請看: https://www.youtube.com/watch?v=Fxbiw2EMpOg

簡而言之, 現在直接要求程序員去寫map reduce, 確實是不合適的, 我手上管理著三份很大的map/reduce, 差不多有5k行, 要調, 要改, 那酸爽, 你連debug都沒可能. 半年前遇到一個系統bug, B Tree index會因為emit value大小不合適而導致無限分割, log你都找不到. 總結一下程序員"不應該"寫MR的原因

1) 一個task, 到實際的map/reduce, 有無數種寫法, 每種寫法效率都不一樣

2) 主流就是玩抽象, 總體還是要往SQL上走的, 好比現在老闆說彙編牛逼, 你丫給我寫一個, 體會一下. 你知道你的伺服器有幾個register么? 這些本應該是compiler + runtime做的事情.

上面的幾位說得都挺到位, 我還是重複一下MS說的話, Stack就三層

1) HDFS (集群/文件管理系統)

2) 計算框架 (map/reduce或者其他, 應該會被編譯器搞定)

3) SQL (以後程序員應該只要玩這層)

這年頭技術發展那麼快, 有沒有前途不好說, 個人覺得如果一個公司還是在鼓吹大家來寫map reduce, 那悲劇的可能性相當大

谷歌在10年的時候就已經在google web index這一塊放棄使用mapreduce了。

現在應該是新技術全面成熟，所以開始替換老技術了。除此之外，還可以通過這個來宣傳一下它的數據服務。

因為mapreduce還是有一些缺陷的，例如它在實時性上面特別差，在當前操作完成以前，你無法進行下次的操作。

google說它這個新技術優化，部署，管理都是自動化的，能夠更加容易的創建複雜的多線程任務。

但再具體的就不了解了，畢竟它還沒有開源，我們也就就只能聽它講講是怎麼回事了。

根據上面的話，個人猜測，核心思路沒變，大的框架變了。

當然，也說不定google又整出來一個耳目一新的技術，然後又再次養活了大批的程序員～～想當年，谷歌的三篇論文給我們提供了多少工作機會呀～～

應該是google的mapreduce 進化成 cloud dataflow 了。

mapreduce這麼多年，用戶需求和軟硬體技術都在發展，mapreduce也在演化發展，意料之中。

開源社區mapreduce的熱度也在下降，替代產品正在激烈競爭，全球最大的大數據公司某工程總監的話『Mapreduce is dead』

這應該是好久以前的問題了，就最近大數據計算的現狀來看，著重猜一猜谷歌究竟當時做了什麼。

根據谷歌dataflow的論文，我猜想mr的替換路線是類似hadoop的產品-》類似flink的產品 -》類似dataflow的產品（現在開源為apache beam）

為何要替換mr，最主要的原因根據論文所述就是兩個：1. 批處理碰到迭代好幾次的情況速度太慢，2. 編程模型導致多層次的批處理太難調試和開發

那麼是否完全把mr去乾淨了，我是持懷疑態度的，否則也不會有apache beam這種流，批抽象層的中間件產品存在了，我認為mr的基礎設施都在的，只是谷歌開發工程師已經不用手寫mr程序了，用流批一致的apache beam工具，可以淡化下面掛載實際計算平台的區別了。

當年他們發表那三篇著名論文的時候，應該都已經有更牛逼的技術研發成功了吧

1、Mapreduce是一個web1.0時代的框架。現在，碎片化越來越嚴重，實時性要求更高，Mapreduce失寵也是情理之中。

2、Google的基因決定了他不會一直依賴一門技術，總會自己革自己的命，於是才能保持創新，才能造福國內民政局，促進就業相關工作；

3、Jeff Dean是神，不管Mapreduce存不存在。

看文章內容，基本原因是 MapReduce 不能滿足 Google 近期的需求了（處理 PB 級的數據），而 Cloud Dataflow 的的擴展性和性能更好。

所以沒啥要看待的，不能滿足需求，就弄個新的，很正常啊……

IT行業就是這樣迅速升級換代的行業，這一點毋庸置疑，至於說如何看待，我的感覺是「擁抱變化」。用了很久的東西不再繼續打補丁而是推倒重來這也是很需要勇氣的。有一點不解的倒是，谷歌如此絕絕的說MR有嚴重的擴放性問題之類的，所有參與在HADOOP之類里的人難道沒有有同感的么？ MR， HADOOP升級換代也是放上時間表的事情了

接著就有人提交了個 CL 把 MapReduce 的源代碼全刪乾淨了。 R=urs 哦。

Googler 可以去 me***en 里翻一翻。

先問是不是，再問為什麼。首先：

Google並沒有停用MapReduce，事實上現在還在大量使用MapReduce。

新聞的意思是，工程師直接使用MapReduce的介面已經不被推薦了（當然寫experimental的代碼依然會有很多直接用的）。因為公司內部已經推出了一系列更高層級的替代方案。

比如日誌分析用Dremel(powerdrill)，只需要寫一個sql-like的語句，引擎自動幫你轉換成MapReduce的任務運行，比原來方便無數倍。

代碼方面，現在大多用Flume，只需要定義好pipeline的邏輯（join aggregate union project），也是程序幫你轉換成MapReduce任務。

而很多內部的系統也提供了類似的介面例如tenzing, s**sta batch什麼的。

其實就是裸寫MapReduce變少了而已，MapReduce這麼好用的東西哪那麼容易替代。

現在直接寫Hadoop的也少了啊。

不是Pig就是Hive，時髦點兒的上Cascade，都是提供一層更高級的API，底層再轉換成一連串Hadoop Job。

冒昧插樓

作為一名Java轉大數據的大數據開發人員，我不理解為什麼那麼多人覺得Spark可以完全替代Mapreduce，甚至可以說將來程序員會寫sql就可以這樣的話。

真正複雜的需求，絕對不是一句sql可以解決的，甚至不是進入演算法包改改演算法或者修改幾行源碼就能解決的。我不知道別人會如何選擇，但至少到目前而言，無論是否在使用Spark，深入研究Mapreduce都是有必要的。

恕我直言，一個有半年Mapreduce經驗的人要玩好Spark只要半個月，有半年Spark經驗的人要玩好Mapreduce，那就真的只能呵呵了……

如果樓主想做一名大數據開發人員，計算框架從mapreduce開始，才是真正的成長。

當然，我還是那句話，如果需求是調包、BI的話，那請無視上述發言。因為隨著時代的發展，這部分人像用Hue一樣，知道怎麼頁面管理就可以了，連寫sql可能都省了……

Hadoop大得很，又不是只有一個mapreduce，而且cloudera已經沒在跟著谷歌了，明顯已經上道自己玩了。而且玩的還不錯的

我覺得google說出這話也沒什麼好奇的吧,當我們自己以為GFS,MR在處理大數據相當牛B,並且開始大規模應用的時候,google早已進入下一個新時代;

其實直接操低級API的活兒，基本已經沒有。

有能力搞出hadoop的組織，給他一篇論文同樣能用差不多的時間搞出一個pohaad。有能力搞出cdh或cloudera manager的組織，給他一點時間分析源碼，也依然能搞出hdc和相應的manager。

只要有理論依據和模型，大神工程師們總是能把東西搞出來的。

MapReduce就是用很多台電腦一起遍歷很多台電腦上的數據的笨辦法。

以前谷歌用MapReduce來生成索引。因為遍歷一次要很長時間，所以不能夠實時更新索引，所以以前一個新站上線，谷歌可能會多達要幾個月以後才能收錄。

對於搜索引擎來說，更聰明的辦法是增量更新索引，這也是谷歌現在的做法。

MapReducer這麼笨的辦法，怎麼國人們沒想出來了，整天站在旁邊說風涼話