大資料計算框架Hadoop, Spark和MPI
轉自：https://www.cnblogs.com/reed/p/7730338.html
今天做題，其中一道是
請簡要描述一下Hadoop, Spark, MPI三種計算框架的特點以及分別適用於什麼樣的場景。
一直想對這些大資料計算框架總結一下，只可惜太懶，一直拖著。今天就借這個機會好好學習一下。
一張表
| 名稱 | 發起者 | 語言 | 簡介 | 特點 | 適用場景 |
|---|---|---|---|---|---|
| Hadoop | Yahoo工程師，Apache基金會 | Java | MapReduce分散式計算框架+HDFS分散式檔案系統（GFS）+HBase資料儲存系統(BigTable) 資料分散式儲存在磁碟各個節點，計算時各個節點讀取儲存在自己節點的資料進行處理 | 高可靠（Hadoop按位儲存） 高擴充套件（在可用的計算機叢集間分配資料並完成計算任務，可以方便的擴充套件到數千個節點上） 高效（能在節點間動態的移動資料，保證節點的平衡）計算向儲存遷移 高容錯，通過資料備份應對節點失效 |
離線大批量資料處理； 不需要多次迭代 |
| Spark | UC Berkley AMP Lab，Apache基金會 | Scala | 基於記憶體計算的平行計算框架 使用記憶體來儲存資料，RDD(彈性分散式資料集) 使用者可以指定儲存策略，當記憶體不夠的時候可以放到磁碟上 |
輕量級快速處理（減少磁碟IO，用RDD在記憶體中儲存資料，需要持久化時才到磁碟） 支援多種語言 支援複雜查詢（SQL查詢、流式查詢、複雜查詢） 實時流處理（Spark Streaming） | 離線快速的處理，不能用於處理需要長期儲存的資料; 適用於多次迭代的計算模型（機器學習模型） |
| Storm | BackType團隊，Twitter，Apache基金會 | Java, clojure | 不進行資料的收集和儲存工作，直接通過網路實時的接受資料並且實時的處理資料，然後直接通過網路實時傳回結果 | 全記憶體計算，實時處理大資料流 | 線上的實時處理，基於流 |
| MPI | 基於訊息傳遞的平行計算框架 MPI從資料儲存節點讀取需要處理的資料分配給各個計算節點=>資料處理=>資料處理 | 資料儲存和資料處理是分離的 用計算換通訊 無法應對節點失效 |
各種複雜應用的平行計算。支援MPMD（多程式多資料），開發複雜度高 |
Hadoop
Hadoop就是解決了大資料的可靠儲存和處理。現在的Hadoop主要包含兩個框架
- 大規模儲存系統HDFS：在由普通PC組成的叢集上提供高可靠的檔案儲存，通過將塊儲存成多個副本的辦法來解決伺服器或硬碟壞掉的問題。以低功耗、高效能的方式儲存資料，並且能優化大資料的種類和讀取速度。
- 計算引擎YARN：可以承載任何數量的程式框架，原始的框架是MR，通過Mapper和Reduccer的抽象提供一個程式設計模型，可以在一個或上百個PC組成的不可靠叢集上併發的、分散式的處理大量資料集，而把併發、分散式和故障恢復等計算細節隱藏起來。
Hadoop的侷限和不足
抽象層次低，需要手工編寫程式碼來完成，使用上難以上手。
只提供兩個操作，Map和Reduce，表達力欠缺。
一個Job只有Map和Reduce兩個階段（Phase），複雜的計算需要大量的Job完成，Job之間的依賴關係是由開發者自己管理的。
處理邏輯隱藏在程式碼細節中，沒有整體邏輯
中間結果也放在HDFS檔案系統中
ReduceTask需要等待所有MapTask都完成後才可以開始
時延高，只適用Batch資料處理，對於互動式資料處理，實時資料處理的支援不夠
對於迭代式資料處理效能比較差
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
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的哪些問題呢？
抽象層次低，需要手工編寫程式碼來完成，使用上難以上手。
=>基於RDD的抽象，實資料處理邏輯的程式碼非常簡短。。
只提供兩個操作，Map和Reduce，表達力欠缺。
=>提供很多轉換和動作，很多基本操作如Join，GroupBy已經在RDD轉換和動作中實現。
一個Job只有Map和Reduce兩個階段（Phase），複雜的計算需要大量的Job完成，Job之間的依賴關係是由開發者自己管理的。
=>一個Job可以包含RDD的多個轉換操作，在排程時可以生成多個階段（Stage），而且如果多個map操作的RDD的分割槽不變，是可以放在同一個Task中進行。
處理邏輯隱藏在程式碼細節中，沒有整體邏輯
=>在Scala中，通過匿名函式和高階函式，RDD的轉換支援流式API，可以提供處理邏輯的整體檢視。程式碼不包含具體操作的實現細節，邏輯更清晰。
中間結果也放在HDFS檔案系統中
=>中間結果放在記憶體中，記憶體放不下了會寫入本地磁碟，而不是HDFS。
ReduceTask需要等待所有MapTask都完成後才可以開始
=> 分割槽相同的轉換構成流水線放在一個Task中執行，分割槽不同的轉換需要Shuffle，被劃分到不同的Stage中，需要等待前面的Stage完成後才可以開始。
時延高，只適用Batch資料處理，對於互動式資料處理，實時資料處理的支援不夠
=>通過將流拆成小的batch提供Discretized Stream處理流資料。
對於迭代式資料處理效能比較差
=>通過在記憶體中快取資料，提高迭代式計算的效能。