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

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]

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

3.2        框架效能比較

三種分散式框架在不同的領域行業都在大規模的使用，不同的框架會有自己最適用的計算場景^[11]，三種計算框架的效能上的比較如下表所示：

表2  效能比較

Tab. 2  Performance Comparation

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      結論

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