Spark可以完全替代hadoop嗎？

01-02

hadoop在那些方面優於Spark？

不可以。

Spark只是分散式計算平台，而hadoop已經是分散式計算、存儲、管理的生態系統。

與Spark相對應的是Hadoop MapReduce。我認為Spark是可以取代MapReduce的，從而成為Hadoop系統中不可或缺的一部分。

至於Spark相對於Hadoop的優勢，我已經說了，分散式計算僅僅是hadoop的一部分。所以以下比較內容實際上是Spark和MapReduce的對比：

具體可以參考Spark的官網，我感覺已經說的很清楚了：

Apache Spark?

1、更快

2、更加容易使用

編程的時候沒有蛋疼的map+reduce函數，而且配置起來超級方便。除支持JAVA外，支持scala、python、R。特別是scala，簡直是太適合寫數據分析的程序了，mapreduce用JAVA實在是太蛋疼了。而且RDD自帶的函數超級好用，真心比mapreduce方便太多

3、巨好用的庫

能解決90%問題的四大組件，無論是SQL、還是流數據處理、機器學習庫、圖計算，相當好用。當然，hadoop相關的庫也不少，不過spark是原生包含，用起來方便點。

4、運行方便

Spark是可以脫離hadoop運行的，比如數據可以從資料庫或者本地文件裡面抽取。不過畢竟大數據時代，大家都習慣於將Spark和hadoop通過mesos或者yarn結合起來用；主要用Hadoop的HDFS，當然HBASE或者HIVE這種HDFS之上的組件，Spark也支持。

Is Apache Spark going to replace Hadoop?

Spark And Hadoop Are Friends, Not Foes

基本觀點都在這裡了，請享用：）

兩個工具focus的層面不一樣

我個人認為不可能完成替代，兩者的應用場景初衷應該是不同的。

spark最大優勢在於是基於內存的分散式計算框架，在計算速度方面可甩hadoop好幾條街。天生就適合於多迭代的業務場景，在機器學習演算法上能夠充分體現。另外，spark還支持准實時流式框架spark streaming，分散式查詢spark SQL、圖計算graph、機器學習ML、R語言等，能夠滿足整條業務線的需求，從獲取、處理、分析等提供支持，而不需再加入其它框架，這應該就是spark最大的野心：大一統。

在我看來，雖然基於內存是spark最大的優勢，但是也會造成有些業務場景無法滿足，如超大數據量的ETL。相反在這方面hadoop的mapreduce能夠很好地hold，所以spark可能不斷掠奪hadoop的領地，但是不可能完成替代hadoop。

不可以，特別是那你的數據量增長的某個量級以後

Spark自有其特點，這是mr框架無法解決的，但這並不能使其替代hadoop

hdfs 是不可代替的。

其他的可以。

先從狹義上說，Hadoop應該包括分散式文件系統HDFS、列式資料庫系統Hbase、計算引擎MapReduce，從2.x開始單獨分離出資源調度管理系統YARN。而Spark僅僅是一個計算引擎，和Hadoop MapReduce功能上平行，在計算性能上由於使用內存迭代避免了多次磁碟讀寫，相對Hadoop Mapreduce肯定要高，加上和Hadoop Mapreduce一樣也支持離線計算，開發效率高，因此存在取代的可能。Spark目前使用的最主流的數據源依然是HDFS，頂多算上Alluxio，其它外部數據源比如S3、Openstack Swift佔少數。根據數據結構依然會把某些數據存入Hbase。資源管理方面雖然一開始是主推Mesos，不過由於很多企業都是從Hadoop集群升級過來的，因此使用YARN的相對比較多，至少國內是如此。因此，Spark完全取代Hadoop是不準確的。

廣義上說Hadoop是一個生態圈，幾乎涵蓋了所有的大數據技術（Google 搜圖，侵刪）：

更具體的列表可參考The Hadoop Ecosystem Table。

從中看出，Spark也是屬於Hadoop生態圈的一員，它支持更豐富的API高層介面（如filter、map、group等）以及面向函數編程模式，這可以取代傳統的Pig。集成的機器學習庫，可以取代之前的Mahout。以前的Hive會把HQL轉化成底層的Hadoop MapReduce，因此查詢性能非常差，可以考慮替換計算引擎為Spark，當然目前用的比較多的方式還是使用Spark SQL讀取Hive數據。因此，Spark完全取代Hadoop是不準確的，只能說Spark可能會取代Hadoop的部分功能組件。

大數據的浪潮風靡全球的時候，Spark火了。在國外 Yahoo!、Twitter、Intel、Amazon、Cloudera 等公司率先應用並推廣 Spark 技術，在國內阿里巴巴、百度、淘寶、騰訊、網易、星環等公司敢為人先，並樂於分享。在隨後的發展中，IBM、Hortonworks、微策略等公司紛紛將 Spark 融進現有解決方案，並加入 Spark 陣營。Spark 在IT業界的應用可謂星火燎原之勢。

。Hadoop並不是一個單獨的產品而是一個生態系統，而spark也是一樣的。下面讓我們來一個一個解釋。目前hadoop生態系統主要包括：

HDFS—Hadoop分散式文件系統。它是一個分散式的、面向塊的、不可更新的、高度伸縮性的、可運行在集群中普通硬碟上的文件系統。此外，HDFS還是一個獨立的工具，它可以獨立於Hadoop生態系統中其他組件而運行(但是如果我們想要使HDFS高可用時，還需要依賴zookeeper和日誌管理器，但這又是另外一碼事了)。
MapReduce框架—這是一個基本的在集群中一組標準硬體上執行的分散式計算框架。我們沒必要一定在HDFS張使用它—因為文件系統是可插拔的；同樣的，我們也沒必要一定在yarn中使用它，因為資源管理器是可插拔的：例如我們可以用Mesos來替換它。
YARN—Hadoop集群中默認的資源管理器。但是我們可以在集群中不使用yarn，而是將我們的mr(譯註:map/reduce)任務運行在Mesos之上；或者僅僅在集群中運行不需要依賴yarn的hbase。
Hive—Hive是一個構建在MapReduce框架之上的類sql查詢引擎，它可以將hiveQL語句轉換為一系列運行在集群中的mapReduce任務。此外，hdfs也不是唯一的存儲系統，也不一定非得使用MapReduce框架，比如在這裡我么可以替換為Tez。
Hbase—基於HDFS的鍵值對存儲系統，為Hadoop提供了聯機事務處理(OLTP)能力。Hbase僅僅依賴HDFS和zookeeper;但是Hbase只能依賴於HDFS嗎？不是的，Hbase除了可以運行在HDFS上之外，還可以運行在Tachyon(內存文件系統)、MapRFS、IBM GPFS以及其他一些框架之上。

下面我們來說說spark，它主要包含以下幾個方面：

Spark Core – 用於通用分散式數據處理的引擎。它不不依賴於任何其他組件，可以運行在任何商用伺服器集群上。
Spark Sql – 運行在Spark上的SQL查詢語句，支持一系列SQL函數和HiveQL。但是還不是很成熟，所以不要在生產系統中使用；而HiveQL集成了需要的hive元數據和Hive相關的jar包。
Spark Streaming – 基於spark的微批處理引擎，支持各種各樣數據源的導入。唯一依賴的是Spark Core引擎。
MLib – 構建在spark之上的機器學習庫，支持一系列數據挖掘演算法。

此外我們這裡還要講到的是一個關於spark的重要誤區—「spark是基於內存的技術」。它不是基於內存的技術；spark是一個管道式的執行引擎，而且在shuffle的過程中會將數據寫入磁碟(比如說，如果我們想針對某個欄位做聚合操作)、如果內存不夠的話也一樣會內存溢出(但是內存可以調整)。因此，spark之所以比MapReduce快主要是因為它是管道式處理方式而不是有些人說的「基於內存的優化」。當然，spark在內存中做了緩存來提高性能，但這不是spark真正工作快的原因。

現在，我們再來完整比對一下：

MapReduce可以被Spark Core替換？是的，它會隨著時間的推移被替代，而且這種替代是合理的。但是spark目前還不是特別成熟能完全替代MapReduce。此外，也沒有人會完全放棄MapReduce,除非所有依賴MapReduce的工具都有可替代方案。比如說，想要在pig上運行的腳本能在spark上執行還是有些工作要做的。
Hive可以被Spark SQL替換？是的，這又是對的。但是我們需要理解的是Spark SQL對於spark本身來說還是比較年輕的，大概要年輕1.5倍。相對於比較成熟的Hive來說它只能算是玩具了吧，我將在一年半到兩年之內再回頭來看Spark SQL.。如果我們還記得的話，兩到三年前Impala就號稱要終結Hive,但是截止到目前兩種技術也還是共存狀態，Impala並沒有終結Hive。在這裡對於Spark SQL來說也是一樣的。
Storm可以被Spark Streaming替換？ 是的，可以替換。只不過平心而論storm並不是Hadoop生態系統中的一員，因為它是完全獨立的工具。他們的計算模型並不太形同，所以我不認為storm會消失，反而仍會作為一個商業產品。
Mahout可以被MLib替換？公平的講，Machout已經失去了市場，而且從過去的幾年來看它正在快速失去市場。對於這個工具，我們可以說這裡是Spark真正可以替換Hadoop生態系統中的地方。

因此，總的來說，這篇文章的結論是：

不要被大數據供應商的包裝所愚弄。他們大量推進的是市場而不是最終的真理。Hadoop最開始是被設計為可擴展的框架，而且其中很多部分是可替換的：可以將HDFS替換為Tachyon，可以將YARN替換為Mesos，可以將MapReduce替換為Tez並且在Tez之上可以運行Hive。這將會是Hadoop技術棧的可選方案或者完全替代方案？倘若我們放棄的MR（MapReduce）而使用Tez,那麼它還會是Hadoop嗎？

Spark不能為我們提供完整的技術棧。它允許我們將它的功能集成到我們的Hadoop集群中並且從中獲益，而不用完全脫離我們老的集群方案。
Spark還不夠成熟。我認為在過三到四年我們就不會再叫「Hadoop棧」而是叫它「大數據棧」或者類似的稱呼。因為在大數據棧中我們有很廣泛的選擇可以選出不同的開源產品來組合在一起形成一個單獨的技術棧使用。

答：肯定是不可以的

一. hodoop是大數據啟蒙者，藉助Hadoop的幫助讓企業步入了大數據時代。

Apache Spark是最近幾年，人氣似乎超越了hadoop.有種取代hodoop成為大數據的統治者。

下面介紹下hodoop和spark各自的特點

1.Hadoop是http://Apache.org的一個項目，其實是一種軟體庫和框架，以便使用簡單的編程模型，跨計算器集群對龐大數據集（大數據）進行分散式處理。Hadoop可靈活擴展，從單一計算機系統，到提供本地存儲和計算能力的數千個商用系統，它都能輕鬆支持。實際上，Hadoop就是大數據分析領域的重量級大數據平台。

2.Apache Spark開發人員聲稱它是「一種用於數據大規模處理的快速通用引擎」。相比之下，如果說Hadoop的大數據框架好比是800磅重的大猩猩，Spark就好比是130磅重的獵豹。

其實，Hadoop與Spark不存在衝突，因為Spark是運行於Hadoop頂層的內存處理方案，也就是說目前部署Spark的企業，其實都在現有的Hadoop集群中運行Spark。主流的Hadoop發行版本提供商比如Cloudera和Hortonworks將Spark列為他們Hadoop發行的一部分。

我們可以說Hadoop和Spark均是大數據框架，都提供了執行常見大數據任務的工具。雖然Spark在某些應用場景下比Hadoop，但是Spark本身沒有一個分散式存儲系統，而是依賴於Hadoop的HDFS。Spark的高級分析應用也是依賴於HDFS存儲數據。

Hadoop和Spark不存在競爭關係

1. 在前面的論述中，不斷強調是某些計算類型和應用場景，Spark比Hadoop快。其實Hadoop和Spark是針對不同的應用場景。Hadoop將巨大的數據集分派到一個由普通計算機組成的集群中的多個節點進行存儲。同時，Hadoop還會索引和跟蹤這些數據，讓大數據處理和分析效率達到前所未有的高度。

2. Hadoop包括兩個最重要的組件。第一個是大規模儲存系統，叫做Hadoop Distributed File System(HDFS)。第二個是一個計算引擎，叫做MapReduce，它能在儲存在HDFS上的數據頂層運行大規模並行程序。

3.所以我們看到Hadoop包含了存儲和計算兩個組件，而這個MapReduce計算組件其實可以被Spark替換的。Spark是一個基於內存計算的開源的集群計算系統，目的是讓數據分析更加快速。

所以看明白了吧，Spark相當於是對Hadoop計算組件的改進。實際上它是對Hadoop的補充，可以在Hadoop文件系統中並行運行。因為Spark充分利用內存進行緩存，所以比較合適做迭代式的運算。

Hadoop vs Spark

對任何大數據應用而言，使用Spark似乎是默認選擇。然而，事實並非如此。MapReduce已在大數據市場取得了進展，尤其受到這種公司企業的追捧：需要由商用系統對龐大數據集加以控制。Spark的速度、靈活性和相對易用性對MapReduce的低操作成本來說是絕對補充。

實際上，Spark與MapReduce是一種相互共生的關係。Hadoop提供了Spark所沒有的功能特性，比如分散式文件系統，而Spark為需要它的那些數據集提供了實時內存處理。完美的大數據場景正是設計人員當初預想的那樣：讓Hadoop和Spark在同一個團隊裡面協同運行。

大家可以看下哦

馬士兵2017最新hodoop2.7視頻教程

現在一些公司用Hadoop這套然後和hbase,hive這一整套搞起來為了離線數據分析。如果你沒有強烈的實時數據分析需求，也不會上sprak。我覺得最大的區別就是，你是不是要實時數據分析。一般不會是誰代替誰，一起使用更多，利用hdfs,hbase存儲數據，sprak分析。錯了請更正我，謝謝。

spark可能會取代mapreduce,但是不會取代hdfs

Spark是一種計算框架，hadoop是一個生態圈，主要部件有MR/HDFS/HBASE等，Spark可以集成在hadoop裡面，可以通過HDFS與Hbase獲取數據，然後進行計算。Spark可以將數據扔進內存進行迭代計算，所以一般情況下，它的速度會比MR快很多，很適合迭代計算。

所以說呢，hadoop是一個生態環境，Spark只是裡面的一個計算框架。

個人見解，有錯煩請指出。

1.可以替代hadoop套件中的mapreduce，這點毫無疑問

2.無論從任何角度看mapreduce在spark面前都沒有優勢

hadoop有狹義與廣義兩種概念，spark可以替代mapreduce，而mapreduce只是hadoop的一部分

偶認為不可以…spark雖然速度快各種性能優於hadoop，但是沒有自己的存儲系統，像我們做的項目，很多都是spark和hadoop一起搭配來用，目的就是為了用hadoop的hdfs文件存儲系統。

spark是一個計算引擎，是hadoop裡面的一個部件，不能替代。

。Hadoop並不是一個單獨的產品而是一個生態系統，而spark也是一樣的。下面讓我們來一個一個解釋。目前hadoop生態系統主要包括：

HDFS—Hadoop分散式文件系統。它是一個分散式的、面向塊的、不可更新的、高度伸縮性的、可運行在集群中普通硬碟上的文件系統。此外，HDFS還是一個獨立的工具，它可以獨立於Hadoop生態系統中其他組件而運行(但是如果我們想要使HDFS高可用時，還需要依賴zookeeper和日誌管理器，但這又是另外一碼事了)。

MapReduce框架—這是一個基本的在集群中一組標準硬體上執行的分散式計算框架。我們沒必要一定在HDFS張使用它—因為文件系統是可插拔的；同樣的，我們也沒必要一定在yarn中使用它，因為資源管理器是可插拔的：例如我們可以用Mesos來替換它。

YARN—Hadoop集群中默認的資源管理器。但是我們可以在集群中不使用yarn，而是將我們的mr(譯註:map/reduce)任務運行在Mesos之上；或者僅僅在集群中運行不需要依賴yarn的hbase。

Hive—Hive是一個構建在MapReduce框架之上的類sql查詢引擎，它可以將hiveQL語句轉換為一系列運行在集群中的mapReduce任務。此外，hdfs也不是唯一的存儲系統，也不一定非得使用MapReduce框架，比如在這裡我么可以替換為Tez。

Hbase—基於HDFS的鍵值對存儲系統，為Hadoop提供了聯機事務處理(OLTP)能力。Hbase僅僅依賴HDFS和zookeeper;但是Hbase只能依賴於HDFS嗎？不是的，Hbase除了可以運行在HDFS上之外，還可以運行在Tachyon(內存文件系統)、MapRFS、IBM GPFS以及其他一些框架之上。

下面我們來說說spark，它主要包含以下幾個方面：

Spark Core– 用於通用分散式數據處理的引擎。它不不依賴於任何其他組件，可以運行在任何商用伺服器集群上。

Spark Sql– 運行在Spark上的SQL查詢語句，支持一系列SQL函數和HiveQL。但是還不是很成熟，所以不要在生產系統中使用；而HiveQL集成了需要的hive元數據和Hive相關的jar包。

Spark Streaming– 基於spark的微批處理引擎，支持各種各樣數據源的導入。唯一依賴的是Spark Core引擎。

MLib– 構建在spark之上的機器學習庫，支持一系列數據挖掘演算法。

現在，我們再來完整比對一下：

MapReduce可以被Spark Core替換？是的，它會隨著時間的推移被替代，而且這種替代是合理的。但是spark目前還不是特別成熟能完全替代MapReduce。此外，也沒有人會完全放棄MapReduce,除非所有依賴MapReduce的工具都有可替代方案。比如說，想要在pig上運行的腳本能在spark上執行還是有些工作要做的。

Hive可以被Spark SQL替換？是的，這又是對的。但是我們需要理解的是Spark SQL對於spark本身來說還是比較年輕的，大概要年輕1.5倍。相對於比較成熟的Hive來說它只能算是玩具了吧，我將在一年半到兩年之內再回頭來看Spark SQL.。如果我們還記得的話，兩到三年前Impala就號稱要終結Hive,但是截止到目前兩種技術也還是共存狀態，Impala並沒有終結Hive。在這裡對於Spark SQL來說也是一樣的。

Storm可以被Spark Streaming替換？是的，可以替換。只不過平心而論storm並不是Hadoop生態系統中的一員，因為它是完全獨立的工具。他們的計算模型並不太形同，所以我不認為storm會消失，反而仍會作為一個商業產品。

Mahout可以被MLib替換？公平的講，Machout已經失去了市場，而且從過去的幾年來看它正在快速失去市場。對於這個工具，我們可以說這裡是Spark真正可以替換Hadoop生態系統中的地方。

因此，總的來說，這篇文章的結論是：

不要被大數據供應商的包裝所愚弄。他們大量推進的是市場而不是最終的真理。Hadoop最開始是被設計為可擴展的框架，而且其中很多部分是可替換的：可以將HDFS替換為Tachyon，可以將YARN替換為Mesos，可以將MapReduce替換為Tez並且在Tez之上可以運行Hive。這將會是Hadoop技術棧的可選方案或者完全替代方案？倘若我們放棄的MR（MapReduce）而使用Tez,那麼它還會是Hadoop嗎？

Spark不能為我們提供完整的技術棧。它允許我們將它的功能集成到我們的Hadoop集群中並且從中獲益，而不用完全脫離我們老的集群方案。

Spark還不夠成熟。我認為在過三到四年我們就不會再叫「Hadoop棧」而是叫它「大數據棧」或者類似的稱呼。因為在大數據棧中我們有很廣泛的選擇可以選出不同的開源產品來組合在一起形成一個單獨的技術棧使用。

這兩個不是同性質的東西吧

不能，即使題主指的是map reduce也不能完全替代。

一個原因是內存大小可能成為瓶頸，

另一個原因是，並不是所有的map reduce任務都是純計算類的任務。

當然不可以，spark是hadoop的擴展應用的類似的存在。