MapReduce的高延遲已經(jīng)成為Hadoop發(fā)展的瓶頸，為當(dāng)前的MapReduce尋找性能更高的替代品已成為Hadoop社區(qū)的一個共識。

MapReduce

有關(guān)MapReduce框架，最早要追溯到Google，Google將這個框架與靈活、可擴展性存儲結(jié)合到一起，用以解決各類數(shù)據(jù)處理和分析任務(wù)。后來Doug Cutting和Mike Cafarella在2005年聯(lián)合創(chuàng)立了Apache Hadoop時，采用的就是這個架構(gòu)。

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

關(guān)于MapReduce的抱怨使人們對企業(yè)數(shù)據(jù)中心和Hadoop項目的熱情漸漸減少，MapReduce延遲太高，批處理模式響應(yīng)也難以應(yīng)對大量需要處理分析數(shù)據(jù)的應(yīng)用。

Hadoop生態(tài)圈需要的是一個比MapReduce更加強大、更加靈活、更具實時性的系統(tǒng)。

Spark

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

最初的MapReduce通過簡單的方式執(zhí)行任務(wù)，但是本身結(jié)構(gòu)嚴(yán)格：處理或者轉(zhuǎn)化（map）；同步（shuffle）；以及在集群中將所有結(jié)點的結(jié)果整合到一起（reduce）。你必須將問題變成一系列MapReduce任務(wù)，然后按照順序執(zhí)行這些任務(wù)，延遲很高。在前一個任務(wù)執(zhí)行完成之前，任何一個任務(wù)都無法開始，運行復(fù)雜、多階段的應(yīng)用程序很讓人頭疼。

一種替代方案是讓開發(fā)者構(gòu)建有關(guān)任務(wù)的復(fù)雜、多步有向非循環(huán)圖（DAG），一次執(zhí)行所有這些圖，而不需要一個一個按照順序來。這個方案避免了MapReduce中麻煩的同步問題，也使得應(yīng)用程序的構(gòu)建更加簡單。對于DAG引擎的研究，微軟在早些時候已經(jīng)開始了，比如：Dryad，Dryad一直在微軟內(nèi)部使用，針對Bing搜索和其他托管服務(wù)。

在Spark中既包含了上述一些思想，也有一些重要的創(chuàng)新，比如：Spark支持跨DAG的內(nèi)存數(shù)據(jù)分享，使不同任務(wù)可以以非常高的速度處理相同數(shù)據(jù)。Spark甚至支持循環(huán)數(shù)據(jù)流，這使得它能很好地處理迭代圖算法（社交網(wǎng)絡(luò)分析中常用）、機器學(xué)習(xí)和流處理，這是通過MapReduce或者其他DAG引擎是很難做到的。

Spark包含了流處理、快速故障還原、語言集成API、優(yōu)化調(diào)度和傳輸數(shù)據(jù)等許多高級的功能。內(nèi)存使用是Spark最引人注目的地方，MapReduce需要經(jīng)常處理存儲在磁盤上的數(shù)據(jù)，相比之下，Spark可以利用分散在集群中所有節(jié)點的大量RAM，它能夠智能利用磁盤，解決溢出數(shù)據(jù)和持久性問題，這使Spark在應(yīng)對負(fù)載時有了巨大的性能優(yōu)勢。

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

在過去兩年，Hadoop社區(qū)對MapReduce做了很多改進，但這些改進大多只是停留在了代碼層，軟件開發(fā)者把這稱為原有代碼基礎(chǔ)上的“技術(shù)債務(wù)”，這些負(fù)債導(dǎo)致在原有基礎(chǔ)上的改進只能解決一時的問題，從這個意義上講，MapReduce實在是已經(jīng)負(fù)債累累。

創(chuàng)建全新的代碼庫（無技術(shù)負(fù)債），針對當(dāng)前和未來可預(yù)見的負(fù)載進行設(shè)計，這個過程相對還比較簡單、風(fēng)險較小。需要考慮的問題是：我們是不是真的有必要創(chuàng)建一個全新的項目？

作為MapReduce的替代品，Spark已經(jīng)比較發(fā)展得比較成熟，擁有來自25個國家超過一百個貢獻者，社區(qū)非?；钴S，實際上已經(jīng)沒有必要去創(chuàng)建一個全新項目。

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