[轉]分散式運算架構綜述

標籤：

本來是發表到科技論線上的，誰知道被退稿了，那就發到這裡來吧。

 

 

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介紹

Distributed File SystemHDFS，它是一個基於分布式的對大檔案進行儲存的檔案系統。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      結論

本文對當前互連網中現有的比較流行的分散式運算架構進行了系統的回顧，詳細對不同計算架構的架構和計算過程和進行了詳細的介紹。然後又對不同的分散式運算架構從計算資料的儲存到計算過程中的資料通訊進行了詳細的對比，又從效能上對不同架構的展開比較，得出不同架構的優缺點，並給出不同的計算架構在不同的適用場合。最後本文展望了分散式運算架構在未來的發展方向。

參考連結：分散式運算架構綜述

[轉]分散式運算架構綜述