hadoop vs spark

http://www.zhihu.com/question/26568496#answer-12035815

Hadoop
首先看一下Hadoop解決了什麼問題，Hadoop就是解決了大數據（大到一臺計算機沒法進行存儲，一臺計算機沒法在要求的時間內進行處理）的可靠存儲和處理。

• HDFS，在由普通PC組成的集羣上提供高可靠的文件存儲，經過將塊保存多個副本的辦法解決服務器或硬盤壞掉的問題。
• MapReduce，經過簡單的Mapper和Reducer的抽象，將併發、分佈式（如機器間通訊）和故障恢復等計算細節隱藏起來，並在一個由幾十臺上百太的PC組成的不可靠集羣上，提供可靠的數據處理。而Mapper和Reducer的抽象，又是各類各樣的複雜數據處理均可以分解爲的基本元素。這樣，複雜的數據處理能夠分解爲由多個Mapper和Reducer組成的有向無環圖（DAG）,而後每一個Mapper和Reducer放到Hadoop集羣上執行，就能夠得出結果。

用MapReduce統計一個文本文件中單詞出現的頻率的示例WordCount請參見： WordCount - Hadoop Wiki

在MapReduce中，Shuffle是一個很是重要的過程，有了看不見的Shuffle過程，纔可使在MapReduce之上寫數據處理的開發者徹底感知不到分佈式和併發的存在。
（圖片來源： Hadoop Definitive Guide By Tom White）

可是MapRecue存在如下侷限，使用起來比較困難

• 抽象層次低，須要手工編寫代碼來完成，使用上難以上手。
• 只提供兩個操做，Map和Reduce，表達力欠缺。
• 一個Job只有Map和Reduce兩個階段，複雜的計算須要大量的Job完成。
• 處理邏輯隱藏在代碼細節中，沒有總體邏輯
• 中間結果也放在文件系統中
• ReduceTask須要等待全部MapTask都完成後才能夠開始
• 時延高，只適用Batch數據處理，對於交互式數據處理，實時數據處理的支持不夠
• 對於迭代式數據處理性能比較差

所以出現了不少相關的技術對其中的侷限進行改進。

Apache Pig
Apache Pig也是Hadoop框架中的一部分，Pig提供類SQL語言（Pig Latin）經過MapReduce來處理大規模半結構化數據。而Pig Latin是更高級的過程語言，經過將MapReduce中的設計模式抽象爲操做，如Filter，GroupBy，Join，OrderBy，由這些操做組成數據處理流程。例如以下程序：

visits             = load ‘/data/visits’ as (user, url, time);
gVisits          = group visits by url;
visitCounts  = foreach gVisits generate url, count(visits);

urlInfo          = load ‘/data/urlInfo’ as (url, category, pRank);
visitCounts  = join visitCounts by url, urlInfo by url;

gCategories = group visitCounts by category;
topUrls = foreach gCategories generate top(visitCounts,10);

store topUrls into ‘/data/topUrls’;

描述了數據處理的整個過程。

而Pig Latin又是經過編譯爲MapReduce，在Hadoop集羣上執行的。上述程序被編譯成MapReduce時，會產生以下圖所示的Map和Reduce：

（圖片來源： http://cs.nyu.edu/courses/Fall12/CSCI-GA.2434-001/sigmod08-pig-latin.ppt ）

Apache Pig解決了MapReduce存在的大量手寫代碼，語義隱藏，提供操做種類少的問題。相似的項目還有Cascading，JAQL等。

Apache Tez
Apache Tez，Tez是HortonWorks的Stinger Initiative的的一部分。做爲執行引擎，Tez也提供了有向無環圖（DAG），DAG由頂點（Vertex）和邊（Edge）組成，Edge是對數據的移動的抽象，提供了One-To-One，BroadCast，和Scatter-Gather三種類型，只有Scatter-Gather才須要進行Shuffle。

Tez的優化主要體如今：

（圖片來源： http://www.slideshare.net/hortonworks/apache-tez-accelerating-hadoop-query-processing ）

1. 去除了連續兩個任務之間的寫操做
2. 去除了每一個工做流中多餘的Map階段

經過提供DAG語義和操做，提供了總體的邏輯，經過減小沒必要要的操做，Tez提高了執行性能。

Apache Spark
Apache Spark也是一個大數據處理的引擎，主要特色是提供了一個集羣的分佈式內存抽象，以支持須要工做集的應用。

這個抽象就是RDD（Resilient Distributed Dataset），RDD就是一個不可變的帶分區的記錄集合。Spark提供了RDD上的兩類操做，轉換和動做。轉換是用來定義一個新的RDD，包括map, flatMap, filter, union, sample, join, groupByKey, cogroup, ReduceByKey, cros, sortByKey, mapValues等，動做是返回一個結果，包括collect, reduce, count, save, lookupKey。

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

Spark的API很是簡單易用，使用Spark，WordCount的示例以下所示：

val spark = new SparkContext(master, appName, [sparkHome], [jars])
val file = spark.textFile("hdfs://...")
val counts = file.flatMap(line => line.split(" "))
                 .map(word => (word, 1))
                 .reduceByKey(_ + _)
counts.saveAsTextFile("hdfs://...")

其中的file是根據HDFS上的文件建立的RDD，後面的flatMap，map，reduceByKe都建立出一個新的RDD，一個簡短的程序就可以執行不少個轉換和動做。在Spark中，全部RDD的轉換都是是惰性求值的。Spark的任務是由相互依賴的多個RDD組成的有向無環圖，每一個RDD又包含多個分區，當在RDD上執行動做時，Spark纔對任務進行調度。 

Spark對於有向無環圖對任務進行調度，肯定階段，分區，流水線，任務和緩存，進行優化，並在Spark集羣上運行任務。RDD之間的依賴分爲寬依賴（依賴多個分區）和窄依賴（只依賴一個分區），在肯定階段時，須要根據寬依賴劃分階段。根據分區劃分任務。

（圖片來源： https://databricks-training.s3.amazonaws.com/slides/advanced-spark-training.pdf ）

Spark爲迭代式數據處理提供更好的支持。每次迭代的數據能夠保存在內存中，而不是寫入文件。

Spark的性能相比Hadoop有很大提高，2014年1月，Spark完成了一個Daytona Gray類別的Sort Benchmark測試，排序徹底是在磁盤上進行的，與Hadoop以前的測試的對比結果如表格所示：
（表格來源：  Spark officially sets a new record in large-scale sorting ）
從表格中能夠看出排序100TB的數據（1萬億條數據）， Spark只用了Hadoop所用1/10的計算資源，耗時只有Hadoop的1/3 。


Spakr的優點不只體如今性能提高上的，Spark框架爲批處理（Spark Core），交互式（Spark SQL），流式（Spark Streaming），機器學習（MLlib），圖計算（GraphX）提供一個統一的平臺，這相對於使用Hadoop有很大優點。

（圖片來源： https://gigaom.com/2014/06/28/4-reasons-why-spark-could-jolt-hadoop-into-hyperdrive/ ）

那麼Spark解決了Hadoop的哪些問題呢？

• 抽象層次低，須要手工編寫代碼來完成，使用上難以上手。
• =>基於RDD的抽象，不少代碼已經在RDD轉換和動做中實現。
• 只提供兩個操做，Map和Reduce，表達力欠缺。
• =>提供不少轉換和動做，如Join，GroupBy這種經常使用的操做
• 一個Job只有Map和Reduce兩個階段，複雜的計算須要大量的Job完成。
• =>邏輯上的多個RDD的轉換，在調度式能夠生成多個階段。
• 處理邏輯隱藏在代碼細節中，沒有總體邏輯
• =>在Scala中，經過匿名函數和高階函數，RDD的轉換支持流式API，能夠提供處理邏輯的總體視圖。
• 中間結果也放在文件系統中
• =>中間結果放在內存中。
• ReduceTask須要等待全部MapTask都完成後才能夠開始
• =>待定
• 時延高，只適用Batch數據處理，對於交互式數據處理，實時數據處理的支持不夠
• =>經過將流拆成小的batch提供Discretized Stream處理流數據。
• 對於迭代式數據處理性能比較差
• =>經過在內存中緩存數據，提升迭代式計算的性能。