首先，我們要思考Hadoop為什麼會流行起來？Hadoop之所以流行是因為它解決了網際網路，移動網際網路快速資料積累與原有傳統資料分析方案無法適應的痛點。

我在《領域修煉方法-論軟體架構設計的思想及其適應性》一文中曾論述過，隨著資訊科技的不斷髮展，很多解決軟體架構設計的具體技術已經過時或者消亡，但是，軟體架構設計的模式、思想是不會過時的。Hadoop作為解決大資料分析痛點的一種具體技術同樣逃脫不了這一命運。Hadoop什麼時候出現的？時間要追溯到2016年1月。Spark什麼時候出現的？時間是2009年。顯而易見，Spark是建立在Hadoop這一巨人的肩膀之上的開拓創新，其在解決Hadoop能夠解決的問題同時，肯定還能夠彌補Hadoop的不足。因此，從這一點上來說，Hadoop相比於Spark不存在優勢。

Hadoop與Spark相比完全沒有任何優勢了嗎？答案是否定的。這是由於網際網路特別是移動網際網路、物聯網快速發展起來以後，資料規模成幾何級的增長而且這一趨勢還在持續，這一現實需求使得大資料分析仍處於上升期，因此Hadoop的發展同樣處於上升期。既然Hadoop和Spark同處於上升期，那麼作為首先出現的Hadoop就具有先發優勢，其實際行業應用更廣，體系發展的更快更完善，不足之處不斷的有新的補充方案加入進來。這一點從Apache的頂級專案就可以看出來，Hadoop生態體系相關的頂級專案有近20個，而Spark相關的只有三四個。

企業的技術選型是以解決當前的業務痛點為前提的，因此，選擇一個成熟完善的體系解決當前業務痛點，還是選擇一個相對不夠完善的方案，投入更多的資源？答案顯而易見，這就是Hadoop相比於Spark的優勢。

至於這一優勢能否彌補Saprk架構能夠解決更多資料分析場景的優勢，在於企業當前端所面臨的實際需求。其實大多數時候，兩者相互配合是一種更完善的方案。

Hadoop

Hadoop就是解決了大資料的可靠儲存和處理。現在的Hadoop主要包含兩個框架:

大規模儲存系統HDFS：在由普通PC組成的叢集上提供高可靠的檔案儲存，透過將塊儲存成多個副本的辦法來解決伺服器或硬碟壞掉的問題。以低功耗、高效能的方式儲存資料，並且能最佳化大資料的種類和讀取速度。計算引擎YARN：可以承載任何數量的程式框架，原始的框架是MR，透過Mapper和Reducer的抽象提供一個程式設計模型，可以在一個或上百個PC組成的不可靠叢集上併發的、分散式的處理大量資料集，而把併發、分散式和故障恢復等計算細節隱藏起來。

Hadoop的侷限和不足

抽象層次低，需要手工編寫程式碼來完成，使用上難以上手。只提供兩個操作，Map和Reduce，表達力欠缺。一個Job只有Map和Reduce兩個階段(Phase)，複雜的計算需要大量的Job完成，Job之間的依賴關係是由開發者自己管理的。處理邏輯隱藏在程式碼細節中，沒有整體邏輯中間結果也放在HDFS檔案系統中ReduceTask需要等待所有MapTask都完成後才可以開始時延高，只適用Batch資料處理，對於互動式資料處理，實時資料處理的支援不夠對於迭代式資料處理效能比較差

Spark

Apache Spark是一個新興的大資料處理的引擎，主要特點是提供了一個叢集的分散式記憶體抽象，以支援需要工作集的應用。

這個抽象就是RDD(Resilient Distributed Dataset)，RDD就是一個不可變的帶分割槽的記錄集合，RDD也是Spark中的程式設計模型。Spark提供了RDD上的兩類操作，轉換和動作。轉換是用來定義一個新的RDD，包括map, flatMap, filter, union, sample, join, groupByKey, cogroup,ReduceByKey, cros, sortByKey, mapValues等，動作是返回一個結果，包括collect, reduce,count, save, lookupKey。

在Spark中，所有RDD的轉換都是是惰性求值的。RDD的轉換操作會生成新的RDD，新的RDD的資料依賴於原來的RDD的資料，每個RDD又包含多個分割槽。那麼一段程式實際上就構造了一個由相互依賴的多個RDD組成的有向無環圖(DAG)。並透過在RDD上執行動作將這個有向無環圖作為一個Job提交給Spark執行。

Spark對於有向無環圖Job進行排程，確定階段(Stage)，分割槽(Partition)，流水線(Pipeline)，任務(Task)和快取(Cache)，進行最佳化，並在Spark叢集上執行Job。RDD之間的依賴分為寬依賴(依賴多個分割槽)和窄依賴(只依賴一個分割槽)，在確定階段時，需要根據寬依賴劃分階段。根據分區劃分任務。

Spark支援故障恢復的方式也不同，提供兩種方式，Linage，透過資料的血緣關係，再執行一遍前面的處理，Checkpoint，將資料集儲存到持久儲存中。

Spark為迭代式資料處理提供更好的支援。每次迭代的資料可以儲存在記憶體中，而不是寫入檔案。

Spark解決了Hadoop的那些不足

1、HadoopSpark抽象層次低，需要手工編寫程式碼來完成，使用上難以上手=>基於RDD的抽象，實資料處理邏輯的程式碼非常簡短。

2、只提供兩個操作，Map和Reduce，表達力欠缺=>提供很多轉換和動作，很多基本操作如Join，GroupBy已經在RDD轉換和動作中實現。

3、一個Job只有Map和Reduce兩個階段(Phase)，複雜的計算需要大量的Job完成，Job之間的依賴關係是由開發者自己管理的=>一個Job可以包含RDD的多個轉換操作，在排程時可以生成多個階段(Stage)，而且如果多個map操作的RDD的分割槽不變，是可以放在同一個Task中進行。

4、處理邏輯隱藏在程式碼細節中，沒有整體邏輯=>在Scala中，透過匿名函式和高階函式，RDD的轉換支援流式API，可以提供處理邏輯的整體檢視。程式碼不包含具體操作的實現細節，邏輯更清晰。

5、中間結果也放在HDFS檔案系統中=>中間結果放在記憶體中，記憶體放不下了會寫入本地磁碟，而不是HDFS。

6、ReduceTask需要等待所有MapTask都完成後才可以開始=> 分割槽相同的轉換構成流水線放在一個Task中執行，分割槽不同的轉換需要Shuffle，被劃分到不同的Stage中，需要等待前面的Stage完成後才可以開始。

7、時延高，只適用Batch資料處理，對於互動式資料處理，實時資料處理的支援不夠=>透過將流拆成小的batch提供Discretized Stream處理流資料。

8、對於迭代式資料處理效能比較差=>透過在記憶體中快取資料，提高迭代式計算的效能。

　　Hadoop和Spark均是大資料框架，都提供了一些執行常見大資料任務的工具。但確切地說，它們所執行的任務並不相同，彼此也並不排斥。雖然在特定的情況下，Spark據稱要比Hadoop快100倍，但它本身沒有一個分散式儲存系統。而分散式儲存是如今許多大資料專案的基礎。它可以將PB級的資料集儲存在幾乎無限數量的普通計算機的硬碟上，並提供了良好的可擴充套件性，只需要隨著資料集的增大增加硬碟。因此，Spark需要一個第三方的分散式儲存。也正是因為這個原因，許多大資料專案都將Spark安裝在Hadoop之上。這樣，Spark的高階分析應用程式就可以使用儲存在HDFS中的資料了。

　　與Hadoop相比，Spark真正的優勢在於速度。Spark的大部分操作都是在記憶體中，而Hadoop的MapReduce系統會在每次操作之後將所有資料寫回到物理儲存介質上。這是為了確保在出現問題時能夠完全恢復，但Spark的彈性分散式資料儲存也能實現這一點。

　　另外，在高階資料處理（如實時流處理和機器學習）方面，Spark的功能要勝過Hadoop。在Bernard看來，這一點連同其速度優勢是Spark越來越受歡迎的真正原因。實時處理意味著可以在資料捕獲的瞬間將其提交給分析型應用程式，並立即獲得反饋。在各種各樣的大資料應用程式中，這種處理的用途越來越多，比如，零售商使用的推薦引擎、製造業中的工業機械效能監控。Spark平臺的速度和流資料處理能力也非常適合機器學習演算法。這類演算法可以自我學習和改進，直到找到問題的理想解決方案。這種技術是最先進製造系統（如預測零件何時損壞）和無人駕駛汽車的核心。Spark有自己的機器學習庫MLib，而Hadoop系統則需要藉助第三方機器學習庫，如Apache Mahout。

　　實際上，雖然Spark和Hadoop存在一些功能上的重疊，但它們都不是商業產品，並不存在真正的競爭關係，而透過為這類免費系統提供技術支援贏利的公司往往同時提供兩種服務。例如，Cloudera就既提供Spark服務也提供Hadoop服務，並會根據客戶的需要提供最合適的建議。

　　Bernard認為，雖然Spark發展迅速，但它尚處於起步階段，安全和技術支援基礎設施方還不發達。在他看來，Spark在開源社群活躍度的上升，表明企業使用者正在尋找已儲存資料的創新用法。