最近在寫本科的畢業論文，題目是有關於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 結論
本文對當前互聯網中現有的比較流行的分布式計算框架進行了系統的回顧，詳細對不同計算框架的架構和計算過程和進行了詳細的介紹。然后又對不同的分布式計算框架從計算數據的存儲到計算過程中的數據通信進行了詳細的對比，又從性能上對不同框架的展開比較，得出不同框架的優缺點，並給出不同的計算框架在不同的適用場合。最后本文展望了分布式計算框架在未來的發展方向。