解決問題的層面不一樣
首先，Hadoop和Apache Spark兩者都是大數(shù)據(jù)框架，但是各自存在的目的不盡相同。Hadoop實質(zhì)上更多是一個分布式數(shù)據(jù)基礎(chǔ)設(shè)施: 它將巨大的數(shù)據(jù)集分派到一個由普通計算機組成的集群中的多個節(jié)點進行存儲，意味著您不需要購買和維護昂貴的服務(wù)器硬件。
同時，Hadoop還會索引和跟蹤這些數(shù)據(jù)，讓大數(shù)據(jù)處理和分析效率達到前所未有的高度。Spark，則是那么一個專門用來對那些分布式存儲的大數(shù)據(jù)進行處理的工具，它并不會進行分布式數(shù)據(jù)的存儲。
兩者可合可分
Hadoop除了提供為大家所共識的HDFS分布式數(shù)據(jù)存儲功能之外，還提供了叫做MapReduce的數(shù)據(jù)處理功能。所以這里我們完全可以拋開Spark，使用Hadoop自身的MapReduce來完成數(shù)據(jù)的處理。
相反，Spark也不是非要依附在Hadoop身上才能生存。但如上所述，畢竟它沒有提供文件管理系統(tǒng)，所以，它必須和其他的分布式文件系統(tǒng)進行集成才能運作。這里我們可以選擇Hadoop的HDFS,也可以選擇其他的基于云的數(shù)據(jù)系統(tǒng)平臺。但Spark默認(rèn)來說還是被用在Hadoop上面的，畢竟，大家都認(rèn)為它們的結(jié)合是最好的。
希望能幫到你。

Hadoop這項大數(shù)據(jù)處理技術(shù)大概已有十年歷史，而且被看做是首選的大數(shù)據(jù)集合處理的解決方案。MapReduce是一路計算的優(yōu)秀解決方案，不過對于需要多路計算和算法的用例來說，并非十分高效。數(shù)據(jù)處理流程中的每一步都需要一個Map階段和一個Reduce階段，而且如果要利用這一解決方案，需要將所有用例都轉(zhuǎn)換成MapReduce模式。
在下一步開始之前，上一步的作業(yè)輸出數(shù)據(jù)必須要存儲到分布式文件系統(tǒng)中。因此，復(fù)制和磁盤存儲會導(dǎo)致這種方式速度變慢。另外Hadoop解決方案中通常會包含難以安裝和管理的集群。而且為了處理不同的大數(shù)據(jù)用例，還需要集成多種不同的工具（如用于機器學(xué)習(xí)的Mahout和流數(shù)據(jù)處理的Storm）。
如果想要完成比較復(fù)雜的工作，就必須將一系列的MapReduce作業(yè)串聯(lián)起來然后順序執(zhí)行這些作業(yè)。每一個作業(yè)都是高時延的，而且只有在前一個作業(yè)完成之后下一個作業(yè)才能開始啟動。
而Spark則允許程序開發(fā)者使用有向無環(huán)圖（DAG）開發(fā)復(fù)雜的多步數(shù)據(jù)管道。而且還支持跨有向無環(huán)圖的內(nèi)存數(shù)據(jù)共享，以便不同的作業(yè)可以共同處理同一個數(shù)據(jù)。
Spark運行在現(xiàn)有的Hadoop分布式文件系統(tǒng)基礎(chǔ)之上（HDFS）提供額外的增強功能。它支持將Spark應(yīng)用部署到現(xiàn)存的Hadoop v1集群（with SIMR – Spark-Inside-MapReduce）或Hadoop v2 YARN集群甚至是Apache Mesos之中。
我們應(yīng)該將Spark看作是Hadoop MapReduce的一個替代品而不是Hadoop的替代品。其意圖并非是替代Hadoop，而是為了提供一個管理不同的大數(shù)據(jù)用例和需求的全面且統(tǒng)一的解決方案。