分佈式計算框架綜述

最近在寫本科的畢業論文，題目是有關於MapReduce的並行化處理，老師給出修改意見中提到了關於分佈式計算框架的的國內外研究現狀，一開始並無搞懂分佈式計算機框架，覺得是MapReduce。MapReduce只是一種並行編程模式，也能夠是一種並行框架，並非分佈式計算框架。百度得知，好比Hadoop，storm，Spark等纔是分佈式計算框架，隨後又查看了一篇博客，寫得不錯，以下：

如下是轉載內容：http://blog.csdn.net/zwan0518/article/details/17751959

---

0      引言

 

隨着互聯網的發展，web2.0時期^[1]的到來，人類正式進入了信息爆炸時期的。海量的信息在不少應用都會出現，好比一些社交網絡應用中記錄用戶行爲日誌一般都是以GB甚至是TB爲單位的。常規的單機計算模式已經不能支撐如此巨大的數據量。因此，計算必須以分佈式的把巨大的計算任務分紅小的單機能夠承受的計算任務，在這種狀況下分佈式計算框架與雲計算^[2]出現。

1      分佈式計算框架背景介紹

咱們的互聯網從Web 1.0邁入到現在的Web 2.0時期，互聯網中的信息量以指數的速度增加着。天天互聯網產生的數據量都是以TB的數據量不斷生長。相對於傳統的關係型數據的存儲和計算，這些天天產生的數據大多都是非關係性的、並且沒有固定格式的數據。這就對傳統的基於關係型的數據存儲與計算產生了挑戰^[3]。

相對於傳統的數據計算，在Web2.0時期以前，在一個機器上對數據進行計算對於機器的配置徹底是能夠支撐的。相對於常見的服務器內存是100G，把全部計算數據都緩存進內存進行科學計算是能夠實現的。可是在現在，對於一些應用的用戶日誌都是以TB爲單位的，這些數據是不可能一次性的所有緩存進內存，即便能夠對服務器的內存進行擴充，可是運算代價仍是很是大。在這個時候必須有必定的運算機制能夠把計算任務分擔到多臺機器上，讓每臺機器都承擔一部分的計算和數據存儲的任務。這就下降了對單機的配置要求，可使用普通的機器進行科學計算。

可是對於分佈計算的開發和維護中須要考慮的情形是很是複雜和多變的。在進行分佈式計算過程當中對計算過程當中的控制信息的通訊，每一個任務的數據獲取，對計算結果的合併和對錯誤計算的回滾，在分佈式計算的時候都是須要保證運行正常^[4]。若是這些任務所有都由開發人員負責，這對程序員的要求是很是高的。分佈式計算框架的出現是爲了解決這種瓶頸，經過分佈式框架封裝計算細節，完成分佈式計算程序的開發。

經過使用分佈式計算框架，程序員能夠很容易的享受到分佈式計算的帶來的高速計算的好處，並且還沒必要對分佈式計算過程當中各類問題和計算異常進行控制。這就讓程序員的開發效率成倍的提升。

本文就對當前的分佈式計算框架進行了系統的回顧與總結。

2      分佈式框架

2.1        Hadoop分佈式計算框架

2.1.1             框架介紹

Hadoop計算框架是出現比較早的一個分佈式計算框架，它主要是基於Google提出的MapReduce的開發模式^[5]下一個開源實現功能很是強大的分佈式計算框架，由Java開發完成。Hadoop分佈式計算框架包括兩個部分，計算框架MapReduce與用來存儲計算數據的存儲框架HDFS(HadoopDistributed File System)。

2.1.2             Hadoop任務執行介紹

MapReduce是一種計算架構設計，利用函數式編程思想把一個計算分紅map與reduce兩個計算過程。MapReduce把一個大的計算任務劃分爲多個小的計算任務，而後把每一個小的計算任務分配給集羣的每一個計算節點，並一直跟蹤每一個計算節點的進度決定是否從新執行該任務，最後收集每一個節點上的計算結果並輸出。

MapReduce架構是基於JobTracker與TaskTracker的主從結構設計。JobTracker負責具體的任務劃分和任務監視，並決定某個任務是否須要回滾；TaskTracker則是負責具體的任務執行，對每一個分配給本身的任務進行數據獲取，保持與JobTracker通訊報告本身狀態，輸出計算結果等計算過程。

對任務輸入，框架會首先經過JobTracker進行任務的切分，劃分結束就發送到每一個TaskTracker進行執行Map任務，Map結束以後爲了讓性能更加均衡會執行洗牌Shuffle操做，最後執行Reduce操做，輸出結果。具體的任務執行以下圖所示：

 

2.1.3             HDFS介紹

分佈式文件系統HDFS，它是一個基於分佈式的對大文件進行存儲的文件系統。HDFS具備高容錯性^[6]和對機器設備要求比較低等特色。HDFS對每一個大文件分紅固定大小的數據塊，均衡的存儲在不一樣的機器上，而後對每一個數據文件進行備份存儲，保證數據不會出現丟失。

HDFS集羣也是基於名稱節點NameNode與數據節點DataNode展開的主從架構設計。主節點名稱節點負責整個集羣的數據存儲信息的存儲，一個集羣中只有一個名稱節點，而從節點數據節點負責具體的數據存儲，通常會有多個在集羣中。以下圖所示：

 

 

 

2.2        Storm框架

2.2.1             框架介紹

Storm分佈式計算框架是由Twitter提出由類Lisp語言開發推出的一個用來處理實時的大數據的基於流式計算的分佈式框架。它的出如今必定程度上結局了Hadoop框架中的延遲比較大，後期程序運維複雜等特色，並且它還有Hadoop所不能支持的實時性、流式計算等特色。對一些實時性的數據分析，Storm具備很是高的效率。

Storm相比較於Hadoop，Storm擁有更多的功能組件，可是其主要功能是基於Nimbus和Supervisor兩個功能組件展開，經過Zookeeper對組件進行生命週期的監視。Nimbus相似於Hadoop的JobTracker負責任務的分配與監視每一個任務的狀態；Supervisor是在每一個工做機器上都部署，它負責監視這臺機器並負責這臺機器上工做進程啓動。

2.2.2             Storm任務執行介紹

相比Hadoop的執行是以任務（Job）展開，Storm任務則是以提交拓撲（Topology）的方式開始。和Hadoop任務執行不一樣的是除非你手動干預中止任務流，不然該拓撲會在框架中一直循環計算。每一個拓撲會在具體的工做進程Worker上執行，Worker之間是採用了ZeroMQ^[7]消息隊列進行通訊，提升通訊性能。

Storm具體的任務過程經過客戶端提交一個聲明好的拓撲，Nimbus經過與Zookeeper交互獲取適合的運行機器，而後把任務分配到具體的機器，機器上的Supervisor根據分配到的任務開始啓動相應的工做進程開始執行任務。在執行過程當中，不管是Supervisor仍是每一個Worker都會與Zookeeper保持心跳聯繫。具體執行過程以下圖所示：

 

 

 

2.3Spark分佈式計算框架

2.3.1             框架介紹

Spark^[8]是最近很是流行、使用Scala編寫、基於RDD^[9]（Resilient Distributed Datasets）彈性分佈式內存數據集的分佈式計算框架。該框架解決了在Hadoop計算框架中，在執行迭代性質的任務效率比較低的弊端，除此以外該框架還提供了任務執行期間的任務的交互查詢，增長了任務的可控性。相比Hadoop，Spark除了提供計算的方法調用以外，還提供了更多的操做。

Spark和Hadoop的通用性相比，Spark框架對一些特殊的算法必定的針對性。由於Spark會對輸入數據進行緩存，因此對每次計算就沒必要對數據重複加載，這對計算的加速有很是大的促進做用。對於一些須要迭代的計算，經過中間數據的緩存能夠快速完成整個計算。在使用Spark指揮，對於一些迭代的工做，好比Kmeans算法，則會提升20倍左右的速度。除此以外，Spark對於緩存到內存中的數據仍是可控制的，當沒有足夠可以使用的內存，能夠選擇緩存必定百分比的數據。這就讓框架有更大的自助性。

2.3.2             任務執行介紹

Spark的任務執行框架也是以主從模式對任務調度，其任務執行框架由主結構Master和從屬結構Workers組成，具體的任務執行是以Driver的方式。用戶本身開發的程序以Driver的方式鏈接Master，並指定數據集RDD的生成與轉換，而後把RDD的操做發送到任務執行節點Workers上。Workers即執行具體任務也存儲計算所需數據，當收到對於RDD的操做以後，Workers經過收到的操做定義對本地化數據進行操做生成預期結果，最後把結果返回或者存儲。

3      框架比較

3.1        框架架構比較

對於三種分佈式框架，雖然都是基於主從結構對框架展開的，可是在細節上不一樣分佈式計算框架的結構還有不一樣的。一個好的架構設計不只會讓框架後期更好維護，並且對於開發者來講也更容易對框架的運行機理更容易掌握，能夠在性能上進行優化^[10]。三種分佈式計算框架的架構比較以下表就所示：

表1  架構比較

Tab. 1  Architectures Comparation

框架名稱	架構設計	存儲	通訊
Hadoop	JobTracker/TraskTacker	HDFS	RPC/HTTP
Storm	Nimbus/Supervisor	實時的輸入流	zeroMQ消息隊列
Spark	Master/Workers	內存、磁盤	共享、廣播變量

3.2        框架性能比較

三種分佈式框架在不一樣的領域行業都在大規模的使用，不一樣的框架會有本身最適用的計算場景^[11]，三種計算框架的性能上的比較以下表所示：

表2  性能比較

Tab. 2  Performance Comparation

框架名稱	優點	弊端	使用場合
Hadoop	Java編寫性能高	時延高； 處理流程固定	批處理； 對延遲不敏感； 離線的數據處理
Storm	實時接收數據流； 更高的容錯能力； 開發簡單；	依賴其餘組件較多； 內存控制很差； 多語言支持補好	實時性； 流數據處理； 分佈式RPC計算
Spark	算法實現簡單； 數據緩衝內存； 計算方法更通用； 任務執行時能夠交互	須要較大內存； 增量更新效率差	批處理； 迭代性質的任務； 大部分大數據處理任務

4      其餘框架

除了這幾個經常使用的框架以外，還有不少分佈式計算框架在各個領域中發揮着很大的做用。在Hadoop框架出現的時候，微軟公司推出了分佈式計算框架Dryad^[12]與DryadLINQ^[13]。和Storm相似的基於實時數據流進行處理的分佈式計算框架也有不少，好比Yahoo公司推出的S4計算框架與伯克利大學D-Streams^[14]計算框架，Hadoop也提出了基於數據流的實現是HStreaming的概念。

文獻[15]給出了在將來的雲計算框架的一些發展前景，文獻[16]給出了分佈式計算框架對當今的項目維護的影響並預測將來分佈式計算框架對軟件維護的預測，文獻[17]對當前的雲計算進展給出了總結與將來雲計算的進一步的發展方向。在將來的框架發展中，數據量確定會比如今的量級更加龐大^[18]，對計算框架的可擴展性有較大的考驗，要求計算的時間消耗有必定的限制；數據的複雜性會更加難以控制^[19]，對框架的架構^[20]和計算模式會提出更高的要求。針對一些特殊的應用場景，不一樣的分佈式框架也須要對相應的不一樣應用展開優化和升級^[21]。

在將來的發展中，結合當今研究方向，分佈式框架的發展方向會在如下幾種展開：

1)       分佈式計算框架會在架構上進行更近一步的優化，在架構上更加清晰，Hadoop在第二代推出分佈式計算框架YARN則是對Hadoop的架構進行優化。經過良好的架構設計讓框架更加容易維護，計算過程更加清晰。

2)       在將來的分佈式計算架構中，計算模式也會更加優化，從當今分佈式計算框架能夠看出從批量計算的Hadoop到流式計算Storm而後到函數式編程的Spark。經過一個良好的計算模式，讓開發框架上的應用程序更加容易、便利。

3)       分佈式計算框架的基礎架構也會必定程度上展開研究，用來支撐上層的分佈式計算過框架。在大數據計算中，分佈在不一樣機器上的數據的傳輸花費較大的代價，因此基礎架構的發展也會促進分佈式計算框架性能上的提高。

5      結論

本文對當前互聯網中現有的比較流行的分佈式計算框架進行了系統的回顧，詳細對不一樣計算框架的架構和計算過程和進行了詳細的介紹。而後又對不一樣的分佈式計算框架從計算數據的存儲到計算過程當中的數據通訊進行了詳細的對比，又從性能上對不一樣框架的展開比較，得出不一樣框架的優缺點，並給出不一樣的計算框架在不一樣的適用場合。最後本文展望了分佈式計算框架在將來的發展方向。