Hadoop和Spark

Spark 基於記憶體進行資料處理，適合資料量大，對實時性要求不高的場合。

Hadoop 要求每個步驟的資料序列化到磁碟，I/O成本高，導致互動分析迭代演算法開銷很大。

Hadoop 的MapReduce 表達能力有限，所有計算都要轉換成 Map和Reduce兩個操作，不能適用於所有場景，對於複雜的資料處理過程難以描述。

Spark 的計算模式也屬於MapReduce型別，但Spark不僅提供了 Map 和 Reduce操作，還包括了 Filter、FlatMap、Sample、GroupByKey、ReduceByKey、Union、Join、Cogroup、MapValues、Sort、PartionBy 等多種轉換操作，以及 Count、Collect、Reduce、Lookup、Save 等行為操作

Spark基於DAG(有向無環圖)的任務排程執行機制比Hadoop Mapreduce 的迭代執行機制更優越！

Spark 各個處理結點之間的通訊模型不再像 Hadoop 一樣只有 Shuffle 一種模式，程式開發者可以使用 DAG 開發複雜的多步資料管道，控制中間結果的儲存、分割槽等。

二者執行流程對比

從中可以看出，Hadoop 不適合於做迭代計算，因為每次迭代都需要從磁碟中讀入資料，向磁碟寫中間結果，而且每個任務都需要從磁碟中讀入資料，處理的結果也要寫入磁碟，磁碟 I/O 開銷很大。而 Spark 將資料載入記憶體後，後面的迭代都可以直接使用記憶體中的中間結果做計算，從而避免了從磁碟中頻繁讀取資料。

對於多維度隨機查詢也是一樣。在對 HDFS 同一批資料做成百或上千維度查詢時，Hadoop 每做一個獨立的查詢，都要從磁碟中讀取這個資料，而 Spark 只需要從磁碟中讀取一次後，就可以針對保留在記憶體中的中間結果進行反覆查詢。

Spark 在 2014 年打破了 Hadoop 保持的基準排序（SortBenchmark）記錄，使用 206 個結點在 23 分鐘的時間裡完成了 100TB 資料的排序，而 Hadoop 則是使用了 2000 個結點在 72 分鐘才完成相同資料的排序。也就是說，Spark 只使用了百分之十的計算資源，就獲得了 Hadoop 3 倍的速度。

儘管與 Hadoop 相比，Spark 有較大優勢，但是並不能夠取代 Hadoop。

因為 Spark 是基於記憶體進行資料處理的，所以不適合於資料量特別大、對實時性要求不高的場合。另外，Hadoop 可以使用廉價的通用伺服器來搭建叢集，而 Spark 對硬體要求比較高，特別是對記憶體和 CPU 有更高的要求。

總結

總而言之，大資料處理場景有以下幾個型別。

1）複雜的批量處理

偏重點是處理海量資料的能力，對處理速度可忍受，通常的時間可能是在數十分鐘到數小時。

2）基於歷史資料的互動式查詢

通常的時間在數十秒到數十分鐘之間。

3）基於實時資料流的資料處理

通常在數百毫秒到數秒之間。

目前對以上三種場景需求都有比較成熟的處理框架：：

用 Hadoop 的 MapReduce 技術來進行批量海量資料處理。
用 Impala 進行互動式查詢。
用 Storm 分散式處理框架處理實時流式資料。

以上三者都是比較獨立的，所以維護成本比較高，而 Spark 能夠一站式滿足以上需求。

通過以上分析，可以總結 Spark 的適應場景有以下幾種：

1）Spark 是基於記憶體的迭代計算框架，適用於需要多次操作特定資料集的應用場合。需要反覆操作的次數越多，所需讀取的資料量越大，受益越大；資料量小但是計算密集度較大的場合，受益就相對較小。

2）Spark 適用於資料量不是特別大，但是要求實時統計分析的場景。

3）由於 RDD 的特性，Spark 不適用於那種非同步細粒度更新狀態的應用，例如，Web 服務的儲存，或增量的 Web 爬蟲和索引，也就是不適合增量修改的應用模型。