Cloudera CTO：取代MapReduce 未來會加大Spark等框架投入

過去兩年，Hadoop社區對MapReduce做了很多改進，但關鍵的改進只停留在了代碼層，HTTP://www.aliyun.com/zixun/aggregation/13383.html"> Spark作為MapReduce的替代品，發展很快，其擁有來自25個國家超過一百個貢獻者，社區非常活躍，未來可能取代MapReduce。

MapReduce的高延遲已經成為Hadoop發展的瓶頸，為當前的MapReduce尋找性能更高的替代品已成為Hadoop社區的一個共識。

MapReduce

有關MapReduce框架，最早要追溯到Google，Google將這個框架與靈活、可擴充性存儲結合到一起，用以解決各類資料處理和分析任務。 後來Doug Cutting和Mike Cafarella在2005年聯合創立了Apache Hadoop時，採用的就是這個架構。

類似的專案，比如Apache Pig和Apache Hive，它們將專門的查詢轉化成可以運行在多功能MapReduce框架上的任務，同時也繼承了MapReduce的可擴充性、容錯能力、良好的吞吐能力還有糟糕的延遲， 特別是Hive，延遲使其無力應付互動式應用。

關於MapReduce的抱怨使人們對企業資料中心和Hadoop專案的熱情漸漸減少，MapReduce延遲太高，批次處理模式回應也難以應對大量需要處理分析資料的應用。

Hadoop生態圈需要的是一個比MapReduce更加強大、更加靈活、更具即時性的系統。

Spark

如今MapReduce的主要替代者是Apache Spark。 和MapReduce一樣，它也是一個多功能引擎，但是Spark設計之初就考慮到運行更多的負載，而且速度更快。

最初的MapReduce通過簡單的方式執行任務，但是本身結構嚴格：處理或者轉化（map）；同步（shuffle）；以及在集群中將所有結點的結果整合到一起（reduce）。 你必須將問題變成一系列MapReduce任務，然後按照循序執行這些任務，延遲很高。 在前一個任務執行完成之前，任何一個任務都無法開始，運行複雜、多階段的應用程式很讓人頭疼。

一種替代方案是讓開發者構建有關任務的複雜、多步有向非循環圖表（DAG），一次執行所有這些圖，而不需要一個一個按照順序來。 這個方案避免了MapReduce中麻煩的同步問題，也使得應用程式的構建更加簡單。 對於DAG引擎的研究，微軟在早些時候已經開始了，比如：Dryad，Dryad一直在微軟內部使用，針對Bing搜索和其他託管服務。

在Spark中既包含了上述一些思想，也有一些重要的創新，比如：Spark支援跨DAG的記憶體資料分享，使不同任務可以以非常高的速度處理相同資料。 Spark甚至支援迴圈資料流程，這使得它能很好地處理反覆運算圖演算法（社交網路分析中常用）、機器學習和流處理，這是通過MapReduce或者其他DAG引擎是很難做到的。

Spark包含了流處理、快速故障還原、語言集成API、優化調度和傳輸資料等許多高級的功能。 記憶體使用是Spark最引人注目的地方，MapReduce需要經常處理存儲在磁片上的資料，相比之下，Spark可以利用分散在集群中所有節點的大量RAM，它能夠智慧利用磁片，解決溢出資料和持久性問題， 這使Spark在應對負載時有了巨大的性能優勢。

為什麼不改進MapReduce，而要取代它？

在過去兩年，Hadoop社區對MapReduce做了很多改進，但這些改進大多隻是停留在了代碼層，軟體發展者把這稱為原有代碼基礎上的「技術債務」，這些負債導致在原有基礎上的改進只能解決一時的問題，從這個意義上講， MapReduce實在是已經負債累累。

創建全新的代碼庫（無技術負債），針對當前和未來可預見的負載進行設計，這個過程相對還比較簡單、風險較小。 需要考慮的問題是：我們是不是真的有必要創建一個全新的專案？

作為MapReduce的替代品，Spark已經比較發展得比較成熟，擁有來自25個國家超過一百個貢獻者，社區非常活躍，實際上已經沒有必要去創建一個全新專案。

從長遠來看，我們期望減少在MapReduce上的投入，相應增加在新框架上的投入，比如：Impala和Spark，理所當然，運行在該平臺上的負載將逐漸轉移到新的框架上。 Google已經開始將負載從MapReduce轉移到Pregel和Dremel上，而FaceBook則將負載轉移到Presto上。

原文連結：HTTP://www.csdn.net/article/2014-05-05/2819604-BigData-MapReduce-Spark