大數據計算框架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處理流數據。
對於迭代式數據處理性能比較差
    =>經過在內存中緩存數據，提升迭代式計算的性能。