原文連結：https://www.cnblogs.com/yjd_hycf_space/p/7681535.html

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棧”而是叫它“大資料棧”或者類似的稱呼。因為在大資料棧中我們有很廣泛的選擇可以選出不同的開源產品來組合在一起形成一個單獨的技術棧使用。

 

人一定要靠自己 轉載本文，只是為了本人記錄一下，如有侵權，請及時聯絡本人刪除。