用Spark來替代Hadoop的觀點(diǎn)在很早以前筆者就有耳聞，其實(shí)提出這種觀點(diǎn)的原因還是在于Spark和Hadoop兩者之間存在的差異。首先，兩者都是開源的，這使得他們能夠大規(guī)模應(yīng)用在大數(shù)據(jù)分析領(lǐng)域，也能夠在其基礎(chǔ)上進(jìn)行多樣性的開發(fā)；其次，Spark立足與Scala，使得Scala擁有了高性能的計(jì)算框架；同時(shí)，Spark與Hadoop相比，不受HDFS的局限，在海量數(shù)據(jù)的計(jì)算、挖掘性能上優(yōu)于Hadoop，在當(dāng)下較為流行的機(jī)器學(xué)習(xí)上，Spark也有較好的表現(xiàn)，所以在這些因素的作用下，Spark日益受到用戶的喜愛。

但這并不能說明Hadoop不再擁有優(yōu)勢，Hadoop擁有強(qiáng)大的生態(tài)，作為一種分布式系統(tǒng)架構(gòu)，Hadoop適用于低成本、大規(guī)模的數(shù)據(jù)分析環(huán)境，能夠接受海量數(shù)據(jù)的存儲(chǔ)和運(yùn)算，雖然Spark改進(jìn)了很多MapReduce的算法，但實(shí)際上更多的是作為Hadoop的一種補(bǔ)充。

要深刻理解兩者之間的關(guān)系，首先需要對(duì)Hadoop進(jìn)行詳細(xì)了解：

Hadoop能夠解決什么問題？

Hadoop解決了大數(shù)據(jù)（大到一臺(tái)計(jì)算機(jī)無法進(jìn)行存儲(chǔ)，一臺(tái)計(jì)算機(jī)無法在要求的時(shí)間內(nèi)進(jìn)行處理）的可靠存儲(chǔ)和處理。

HDFS，在由普通PC組成的集群上提供高可靠的文件存儲(chǔ)，通過將塊保存多個(gè)副本的辦法解決服務(wù)器或硬盤壞掉的問題。

MapReduce，通過簡單的Mapper和Reducer的抽象提供一個(gè)編程模型，可以在一個(gè)由幾十臺(tái)上百臺(tái)的PC組成的不可靠集群上并發(fā)地，分布式地處理大量的數(shù)據(jù)集，而把并發(fā)、分布式（如機(jī)器間通信）和故障恢復(fù)等計(jì)算細(xì)節(jié)隱藏起來。而Mapper和Reducer的抽象，又是各種各樣的復(fù)雜數(shù)據(jù)處理都可以分解為的基本元素。尚學(xué)堂陳老師指出，復(fù)雜的數(shù)據(jù)處理可以分解為由多個(gè)Job（包含一個(gè)Mapper和一個(gè)Reducer）組成的有向無環(huán)圖（DAG）,然后每個(gè)Mapper和Reducer放到Hadoop集群上執(zhí)行，就可以得出結(jié)果。

在MapReduce中，Shuffle是一個(gè)非常重要的過程，正是有了看不見的Shuffle過程，才可以使在MapReduce之上寫數(shù)據(jù)處理的開發(fā)者完全感知不到分布式和并發(fā)的存在。

那么，Hadoop有哪些局限于不足呢？

但是，MapRecue存在以下局限，使用起來比較困難。

1.抽象層次低，需要手工編寫代碼來完成，使用上難以上手；

2.只提供兩個(gè)操作，Map和Reduce，表達(dá)力欠缺；

3.一個(gè)Job只有Map和Reduce兩個(gè)階段（Phase），復(fù)雜的計(jì)算需要大量的Job完成，Job之間的依賴關(guān)系是由開發(fā)者自己管理的；

4.處理邏輯隱藏在代碼細(xì)節(jié)中，沒有整體邏輯；

5.中間結(jié)果也放在HDFS文件系統(tǒng)中；

6.ReduceTask需要等待所有MapTask都完成后才可以開始，時(shí)延高，只適用Batch數(shù)據(jù)處理，對(duì)于交互式數(shù)據(jù)處理，實(shí)時(shí)數(shù)據(jù)處理的支持不夠；

7.對(duì)于迭代式數(shù)據(jù)處理性能比較差。

于是，針對(duì)以上內(nèi)容，Spark做了一定程度上的改進(jìn)：

從性能方面來比較，Spark在于運(yùn)算速度快。Spark還可以執(zhí)行批量處理，然而它真正擅長的是處理流工作負(fù)載、交互式查詢和機(jī)器學(xué)習(xí)。

相比MapReduce基于磁盤的批量處理引擎，Spark賴以成名之處是其數(shù)據(jù)實(shí)時(shí)處理功能。Spark與Hadoop及其模塊兼容。實(shí)際上，在Hadoop的項(xiàng)目頁面上，Spark就被列為是一個(gè)模塊。Spark有自己的頁面，因?yàn)殡m然它可以通過YARN(另一種資源協(xié)調(diào)者)在Hadoop集群中運(yùn)行，但是它也有一種獨(dú)立模式。它可以作為 Hadoop模塊來運(yùn)行，也可以作為獨(dú)立解決方案來運(yùn)行。MapReduce和Spark的主要區(qū)別在于，MapReduce使用持久存儲(chǔ)，而Spark使用彈性分布式數(shù)據(jù)集(RDDS)。

Spark之所以如此快速，原因在于它在內(nèi)存中處理一切數(shù)據(jù)。沒錯(cuò)，它還可以使用磁盤來處理未全部裝入到內(nèi)存中的數(shù)據(jù)。

Spark的內(nèi)存處理為來自多個(gè)來源的數(shù)據(jù)提供了近乎實(shí)時(shí)分析的功能：營銷活動(dòng)、機(jī)器學(xué)習(xí)、物聯(lián)網(wǎng)傳感器、日志監(jiān)控、安全分析和社交媒體網(wǎng)站。另外，MapReduce使用批量處理，其實(shí)從來就不是為驚人的速度設(shè)計(jì)的。它的初衷是不斷收集來自網(wǎng)站的信息，不需要這些數(shù)據(jù)具有實(shí)時(shí)性或近乎實(shí)時(shí)性。

從簡單易用角度來說，Spark支持Scala(原生語言)、Java、Python和Spark SQL。Spark SQL非常類似于SQL 92，所以幾乎不需要經(jīng)歷一番學(xué)習(xí)，馬上可以上手。Spark還有一種交互模式，那樣開發(fā)人員和用戶都可以獲得查詢和其他操作的即時(shí)反饋。MapReduce沒有交互模式，不過有了Hive和Pig等附加模塊，采用者使用MapReduce來得容易一點(diǎn)。

在容錯(cuò)性方面，MapReduce和Spark從兩個(gè)不同的方向來解決問題。MapReduce使用TaskTracker節(jié)點(diǎn)，它為 JobTracker節(jié)點(diǎn)提供了心跳(heartbeat)。如果沒有心跳，那么JobTracker節(jié)點(diǎn)重新調(diào)度所有將執(zhí)行的操作和正在進(jìn)行的操作，交給另一個(gè)TaskTracker節(jié)點(diǎn)。這種方法在提供容錯(cuò)性方面很有效，可是會(huì)大大延長某些操作(即便只有一個(gè)故障)的完成時(shí)間。

Spark使用彈性分布式數(shù)據(jù)集(RDD)，它們是容錯(cuò)集合，里面的數(shù)據(jù)元素可執(zhí)行并行操作。RDD可以引用外部存儲(chǔ)系統(tǒng)中的數(shù)據(jù)集，比如共享式文件系統(tǒng)、HDFS、HBase，或者提供Hadoop InputFormat的任何數(shù)據(jù)源。Spark可以用Hadoop支持的任何存儲(chǔ)源創(chuàng)建RDD，包括本地文件系統(tǒng)，或前面所列的其中一種文件系統(tǒng)。

所以，通過上面內(nèi)容的論述，筆者認(rèn)為，Spark可以對(duì)Hadoop起到一個(gè)很好的補(bǔ)充作用，而且在某種程度上，兩者可以并行。Hadoop建立分布式文件系，而Spark負(fù)責(zé)進(jìn)行高效地?cái)?shù)據(jù)運(yùn)算，從而搭建一個(gè)理想的大數(shù)據(jù)處理平臺(tái)。