Hadoop與Spark之間的比較

Hadoop與Spark之間的比較

 

Hadoop框架的主要模塊包括如下：

• Hadoop Common
• Hadoop分布式文件系統(HDFS)
• Hadoop YARN
• Hadoop MapReduce

雖然上述四個模塊構成了Hadoop的核心，不過還有其他幾個模塊。這些模塊包括：Ambari、Avro、Cassandra、Hive、 Pig、Oozie、Flume和Sqoop，它們進一步增強和擴展了Hadoop的功能。

 

Spark確實速度很快(最多比Hadoop MapReduce快100倍)。Spark還可以執行批量處理，然而它真正擅長的是處理流工作負載、交互式查詢和機器學習。

相比MapReduce基於磁盤的批量處理引擎，Spark賴以成名之處是其數據實時處理功能。Spark與Hadoop及其模塊兼容。實際上，在Hadoop的項目頁面上，Spark就被列為是一個模塊。

 

Spark有自己的頁面，因為雖然它可以通過YARN(另一種資源協調者)在Hadoop集群中運行，但是它也有一種獨立模式。它可以作為 Hadoop模塊來運行，也可以作為獨立解決方案來運行。

 

MapReduce和Spark的主要區別在於，MapReduce使用持久存儲，而Spark使用彈性分布式數據集(RDDS)。

 

性能

Spark之所以如此快速，原因在於它在內存中處理一切數據。沒錯，它還可以使用磁盤來處理未全部裝入到內存中的數據。

 

Spark的內存處理為來自多個來源的數據提供了近乎實時分析的功能：營銷活動、機器學習、物聯網傳感器、日志監控、安全分析和社交媒體網站。另 外，MapReduce使用批量處理，其實從來就不是為驚人的速度設計的。它的初衷是不斷收集來自網站的信息，不需要這些數據具有實時性或近乎實時性。

 

易用性

支持Scala(原生語言)、Java、Python和Spark SQL。Spark SQL非常類似於SQL 92，所以幾乎不需要經歷一番學習，馬上可以上手。

Spark還有一種交互模式，那樣開發人員和用戶都可以獲得查詢和其他操作的即時反饋。MapReduce沒有交互模式，不過有了Hive和Pig等附加模塊，采用者使用MapReduce來得容易一點。

 

成本

“Spark已證明在數據多達PB的情況下也輕松自如。它被用於在數量只有十分之一的機器上，對100TB數據進行排序的速度比Hadoop MapReduce快3倍。”這一成績讓Spark成為2014年Daytona GraySort基准。

 

兼容性

MapReduce和Spark相互兼容;MapReduce通過JDBC和ODC兼容諸多數據源、文件格式和商業智能工具，Spark具有與MapReduce同樣的兼容性。

  

數據處理

MapReduce是一種批量處理引擎。MapReduce以順序步驟來操作，先從集群讀取數據，然后對數據執行操作，將結果寫回到集群，從集群讀 取更新后的數據，執行下一個數據操作，將那些結果寫回到結果，依次類推。Spark執行類似的操作，不過是在內存中一步執行。它從集群讀取數據后，對數據 執行操作，然后寫回到集群。

Spark還包括自己的圖形計算庫GraphX​​。GraphX讓用戶可以查看與圖形和集合同樣的數據。用戶還可以使用彈性分布式數據集(RDD)，改變和聯合圖形，容錯部分作了討論。

 

容錯

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

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

RDD擁有五個主要屬性：

• 分區列表
• 計算每個分片的函數
• 依賴其他RDD的項目列表
• 面向鍵值RDD的分區程序(比如說RDD是散列分區)，這是可選屬性
• 計算每個分片的首選位置的列表(比如HDFS文件的數據塊位置)，這是可選屬性

RDD可能具有持久性，以便將數據集緩存在內存中。這樣一來，以后的操作大大加快，最多達10倍。Spark的緩存具有容錯性，原因在於如果RDD的任何分區丟失，就會使用原始轉換，自動重新計算。

 

可擴展性

按照定義，MapReduce和Spark都可以使用HDFS來擴展。那么，Hadoop集群能變得多大呢?

據稱雅虎有一套42000個節點組成的Hadoop集群，可以說擴展無極限。最大的已知Spark集群是8000個節點，不過隨着大數據增多，預計集群規模也會隨之變大，以便繼續滿足吞吐量方面的預期。

 

安全

Hadoop支持Kerberos身份驗證，這管理起來有麻煩。然而，第三方廠商讓企業組織能夠充分利用活動目錄Kerberos和LDAP用於身份驗證。同樣那些第三方廠商還為傳輸中數據和靜態數據提供數據加密。

Hadoop分布式文件系統支持訪問控制列表(ACL)和傳統的文件權限模式。Hadoop為任務提交中的用戶控制提供了服務級授權(Service Level Authorization)，這確保客戶擁有正確的權限。

Spark的安全性弱一點，目前只支持通過共享密鑰(密碼驗證)的身份驗證。Spark在安全方面帶來的好處是，如果你在HDFS上運行Spark，它可以使用HDFS ACL和文件級權限。此外，Spark可以在YARN上運行，因而能夠使用Kerberos身份驗證。

 

總結

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

 

然后看這篇文章：Link

2009年加州大學伯克利分校團隊開始了Apache Spark項目，旨在為分布式數據處理設計一個統一的引擎。 Spark具有類似於MapReduce的編程模型，但是使用稱為“彈性分布式數據集”RDDs的數據共享抽象擴展。

Spark的通用性有幾個重要的好處。

首先，應用程序更容易開發，因為它們使用統一的API。

第二，結合處理任務更有效；而先前的系統需要將數據寫入存儲以將其傳遞給另一個引擎，Spark可以在相同的數據（通常在存儲器中）上運行不同的功能。

最后，Spark啟用了以前系統無法實現的新應用程序（如圖形上的交互式查詢和流式計算機學習）。自2010年發布以來，Spark已經發展成為最活躍的開源項目或大數據處理，擁有超過1,000名貢獻者。該項目已在超過1,000個組織中使用，從技術公司到銀行、零售、生物技術和天文學。

 

Spark中的關鍵編程抽象是RDD，它是容錯集合，可以並行處理集群中的對象。用戶通過“轉換”（例如map、filter和groupBy）操作來創建RDD。

lines = spark.textFile("hdfs://...")
 
errors = lines.filter(s => s.startsWith("ERROR"))
 
println("Total errors: "+errors.count())

Spark評估RDDs延遲，嘗試為用戶運算找到一個有效的計划。特別的是，變換返回表示計算結果的新RDD對象，但不立即計算它。當一個動作被調用時，Spark查看整個用於創建執行計划的轉換的圖。例如，如果一行中有多個過濾器或映射操作，Spark可以將它們融合到一個傳遞中，或者如果知道數據是被分區的，它可以避免通過網絡為groupBy進行數據傳遞。因此用戶可以實現程序模塊化，而不會造成性能低下。

最后，RDDs為計算之間的數據共享提供了明確的支持。默認情況下，RDD是“短暫的”，因為它們每次在動作（例如count）使用時被重新計算。但是，用戶還可以將所選的RDD保留在內存中或快速重用。（如果數據不適合內存，Spark還會將其溢出到磁盤。）例如，用戶在HDFS中搜索大量日志數據集來進行錯誤調試時，可以通過調用以下函數來載入不同集群的錯誤信息到內存中：

errors.persist()

隨后，用戶可以在該內存中數據上運行不同的查詢：

// Count errors mentioning MySQL
 
errors.filter(s => s.contains("MySQL")).count()
 
// Fetch back the time fields of errors that
 
// mention PHP, assuming time is field #3:
 
errors.filter(s => s.contains("PHP")).map(line => line.split('t')(3)).collect()

 

容錯

除了提供數據共享和各種並行操作，RDDs還可以自動從故障中恢復。 傳統上，分布式計算系統通過數據復制或檢查點提供了容錯。 Spark使用一種稱為“lineage”的新方法。每個RDD跟蹤用於構建它的轉換圖，並對基本數據重新運行這些操作，以重建任何丟失的分區。

下圖顯示了我們以前的查詢中的RDD，其中我們通過應用兩個過濾器和一個映射來獲取錯誤的時間字段。 如果RDD的任何分區丟失（例如保存內存分區的錯誤的節點失敗），Spark將通過在HDFS文件的相應塊上的應用過濾器來重建它。 對於將數據從所有節點發送到所有其他節點（例如reduceByKey）的“shuffle”操作，發送方在本地保留其輸出數據，以防接收器出現錯誤。

基於沿襲的恢復比數據密集型工作負載中的復制效率高得多。 它節省了時間，因為寫入RAM要比通過網絡寫入數據快。 恢復通常比簡單地重新運行程序快得多，因為故障節點通常包含多個RDD分區，這些分區可以在其他節點上並行重建。

另外一個復雜些的例子:

Spark中邏輯回歸的實現。 它使用批量梯度下降，一個簡單的迭代算法，重復計算數據上的梯度函數作為並行求和。 Spark可以方便地將數據加載到RAM中，並運行多個求和。 因此，它運行速度比傳統的MapReduce快。 例如，在100GB作業中，MapReduce每次迭代需要110秒，因為每次迭代需從磁盤加載數據，而Spark在第一次加載后每次迭代只需要一秒。

 

與存儲系統的整合

與Google的MapReduce非常相似，Spark旨在與多個外部系統一起使用持久存儲。Spark最常用於集群文件系統，如HDFS和鍵值存儲，如S3和Cassandra。 它還可以作為數據目錄與Apache Hive連接。 RDD通常僅在應用程序中存儲臨時數據，但某些應用程序（例如Spark SQL JDBC服務器）也在多個用戶之間共享RDD。Spark作為存儲系統無關引擎的設計，使用戶可以輕松地對現有數據進行運算和連接各種數據源。

 

 

庫

Spark SQL中尚未實現的一種技術是索引，盡管Spark上的其他庫（如IndexedRDDs）確實使用它。

 

Spark Streaming(流)。 Spark Streaming使用稱為“離散流”的模型實現增量流處理。為了通過Spark實現流式傳輸，我們將輸入數據分成小批量（例如每200毫秒），我們定期與RDD中存儲的狀態組合以產生新結果。以這種方式運行流計算比傳統的分布式流系統有幾個好處。例如，由於使用沿襲，故障恢復更便宜，並且可以將流與批處理和交互式查詢組合。

 

GraphX。 GraphX提供了類似於Pregel和GraphLab的圖形計算接口，1通過為其構建的RDD選擇分區函數來實現與這些系統相同的布局優化（例如頂點分區方案）。

 

MLlib。 MLlib，Spark的機器學習庫，實現了50多種常見的分布式模型訓練算法。例如，它包括決策樹（PLANET），Latent Dirichlet分布和交替最小二乘矩陣分解的常見分布式算法。

 

Spark的庫都對RDD進行操作，作為數據抽象，使得它們在應用程序中易於組合。例如，下圖顯示了一個程序，它使用Spark SQL讀取一些歷史Twitter數據，使用MLlib訓練一個K-means聚類模型，然后將該模型應用於一個新的tweet流。每個庫返回的數據任務（這里是歷史性的tweet RDD和K-means模型）很容易傳遞給其他庫。

 

 

性能

比較了Spark對三個簡單任務（SQL查詢，流字計數和交替最小二乘矩陣分解）與其他引擎的性能。雖然結果隨着工作負載的不同而不同，但Spark通常與Storm，GraphLab和Impala等專用系統相當。對於流處理，雖然我們顯示了Storm上分布式實現的結果，但是每個節點的吞吐量也可以與商業流引擎如Oracle CEP相媲美。

 

交互式查詢

互動使用Spark分為三個主要類別。首先，組織通常通過商業智能工具（如Tableau）使用Spark SQL進行關系查詢。例子包括eBay和百度。第二，開發人員和數據科學家可以通過shell或可視化筆記本環境以交互方式使用Spark的Scala，Python和R接口。這種交互式使用對於提出更高級的問題和設計最終導致生產應用程序的模型至關重要，並且在所有部署中都很常見。第三，一些供應商已經開發了在Spark上運行的特定領域的交互式應用程序。示例包括Tresata（反洗錢），Trifacta（數據清理）和PanTera。

 

 

使用的Spark組件

我們看到許多組件被廣泛使用，Spark Core和SQL最受歡迎。 Streaming在46％的組織中使用，機器學習在54％中使用。雖然在圖9中未直接示出，但大多數組織使用多個組件; 88％使用其中至少兩個，60％使用至少三個（如Spark Core和兩個庫），27％使用至少四個組件。

 

 

 

部署環境

雖然第一個Spark部署通常在Hadoop環境中，在2015年7月Spark調查中，僅有40％的部署在Hadoop YARN集群管理器上。此外，52％的受訪者在公共雲上運行Spark。

 

 

模型能力

MapReduce在跨時間段共享數據方面效率低下，因為它依賴於復制的外部存儲系統來實現此目的。

RDDs建立在Map-Reduce模擬任何分布式計算的能力之上，但更有效率。它們的主要限制是由於每個通信步驟中的同步而增加的等待時間，但是該等待時間的損失與所得相比是可以忽略的。

 

典型的Hadoop集群可能具有以下特性：

 

本地存儲。每個節點具有本地存儲器，大約50GB/s的帶寬，以及10到20個本地磁盤，大約1GB/s到2GB/ s的磁盤帶寬。

 

鏈接。每個節點具有10Gbps（1.3GB/s）鏈路，或者比其存儲器帶寬小約40x，並且比其總的磁盤帶寬小2倍。

 

機架。節點被組織成20到40台機器的機架，每個機架的帶寬為40Gbps-80Gbps，或者機架內網絡性能的2-5倍。

 

給定這些屬性，在許多應用中最重要的性能問題是在網絡中放置數據和計算。幸運的是，RDD提供了控制這種放置的設施;該接口允許應用程序在輸入數據附近放置計算（通過用於輸入源25的“優選位置”的API），並且RDD提供對數據分區和共置（例如指定數據被給定密鑰散列）的控制。

 

除了網絡和I / O帶寬，最常見的瓶頸往往是CPU時間，特別是如果數據在內存中。在這種情況下，Spark可以運行在每個節點上的專用系統中使用的相同的算法和庫。例如，它使用Spark SQL中的列存儲和處理，MLlib中的本機BLAS庫等。正如我們之前討論的，RDD明顯增加成本的唯一區域是網絡延遲。

 

Spark在shuffle階段實現了一個障礙，所以reduce任務不會開始，直到所有的Map已經完成。這避免了故障恢復所需的一些復雜性。雖然刪除一些這些功能將加快系統。但默認情況下，我們在Spark中會保持開啟容錯，以便於對應用程序進行容錯處理。

 

 

結語

可擴展數據處理對於下一代計算機應用是必不可少的，但通常涉及不同的計算系統。為了簡化這個任務，Spark項目為大數據應用程序引入了統一的編程模型和引擎。實踐證明，這樣的模型可以有效地支持當前的工作負荷，並為用戶帶來實質性的好處。

 

 

然后看這一篇(我覺得這幾篇的水平，這一篇>第一篇>第二篇)：

http://blog.csdn.net/archleaner/article/details/50988258

 

目前Hadoop生態系統主要包括：

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

此外你可能還會想到storm可以處理數據流，但是它完全獨立於hadoop，可以獨立運行；你可能還會想到運行於MapReduce之上的機器學習框架Mahout,但它在之前被社區關注的越來越少。下圖為Mahout被反饋的問題(紅色)和被解決的問題(綠色)趨勢圖： 

 

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

 

注：對下面這一段持保留意見：

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

 

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

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

（注：Pig是一種數據流語言，用來快速輕松的處理巨大的數據，雅虎推出的，現在正在走下坡路。Pig可以非常方便的處理HDFS和HBase的數據，和Hive一樣,Pig可以非常高效的處理其需要做的，通過直接操作Pig查詢可以節省大量的勞動和時間。當你想在你的數據上做一些轉換，並且不想編寫MapReduce jobs就可以用Pig.）

 

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

 

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

 

4. Mahout可以被MLib替換？公平的講，Machout已經失去了市場，而且從過去的幾年來看它正在快速失去市場。對於這個工具，我們可以說這里是Spark真正可以替換Hadoop生態系統中的地方。 (注：同意！Spark的ML非常好用！要好好學！)

 

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

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

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

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