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個國家超過一百個貢獻者，社區非?；钴S，實際上已經沒有必要去創建一個全新項目。
從長遠來看，我們期望減少在MapReduce上的投入，相應增加在新框架上的投入，比如：Impala和Spark，理所當然，運行在該平臺上的負載將逐漸轉移到新的框架上。Google已經開始將負載從MapReduce轉移到Pregel和Dremel上，而FaceBook則將負載轉移到Presto上。
京公網安備 11010502049343號