一、引言

　　在了解GraphX之前，需要先了解關於通用的分布式圖計算框架的兩個常見問題：圖存儲模式和圖計算模式。

二、圖存儲模式

　　巨型圖的存儲總體上有邊分割和點分割兩種存儲方式。2013年，GraphLab2.0將其存儲方式由邊分割變為點分割，在性能上取得重大提升，目前基本上被業界廣泛接受並使用。

2.1　邊分割（Edge-Cut）

　　每個頂點都存儲一次，但有的邊會被打斷分到兩臺機器上。這樣做的好處是節省存儲空間；壞處是對圖進行基於邊的計算時，對於一條兩個頂點被分到不同機器上的邊來說，要跨機器通信傳輸數據，內網通信流量大。

2.2　點分割（Vertex-Cut）

　　每條邊只存儲一次，都只會出現在一臺機器上。鄰居多的點會被復制到多臺機器上，增加了存儲開銷，同時會引發數據同步問題。好處是可以大幅減少內網通信量。

2.3　對比

　　雖然兩種方法互有利弊，但現在是點分割占上風，各種分布式圖計算框架都將自己底層的存儲形式變成了點分割。主要原因有以下兩個。

　　磁盤價格下降，存儲空間不再是問題，而內網的通信資源沒有突破性進展，集群計算時內網帶寬是寶貴的，時間比磁盤更珍貴。這點就類似於常見的空間換時間的策略。

　　在當前的應用場景中，絕大多數網絡都是“無尺度網絡”，遵循冪律分布，不同點的鄰居數量相差非常懸殊。而邊分割會使那些多鄰居的點所相連的邊大多數被分到不同的機器上，這樣的數據分布會使得內網帶寬更加捉襟見肘，於是邊分割存儲方式被漸漸拋棄了。

三、圖計算模式

　　目前的圖計算框架基本上都遵循BSP（Bulk Synchronous Parallell）計算模式。Bulk Synchronous Parallell，即整體同步並行，它將計算分成一系列的超步（superstep）的叠代（iteration）。從縱向上看，它是一個串行模型，而從橫向上看，它是一個並行的模型，每兩個superstep之間設置一個柵欄（barrier），即整體同步點，確定所有並行的計算都完成後再啟動下一輪superstep。

3.1　超步

　　每一個超步（superstep）包含三部分內容：

1.計算compute，每一個processor利用上一個superstep傳過來的消息和本地的數據進行本地計算；

2.消息傳遞，每一個processor計算完畢後，將消息傳遞個與之關聯的其它processors；

3.整體同步點，用於整體同步，確定所有的計算和消息傳遞都進行完畢後，進入下一個superstep。

3.2　Pregel模型——像頂點一樣思考

　　Pregel借鑒MapReduce的思想，采用消息在點之間傳遞數據的方式，提出了“像頂點一樣思考”（Think Like A Vertex）的圖計算模式，采用消息在點之間傳遞數據的方式，讓用戶無需考慮並行分布式計算的細節，只需要實現一個頂點更新函數，讓框架在遍歷頂點時進行調用即可。

常見的代碼模板如下：

上圖簡要地描述了Pregel的計算模型：

1.master將圖進行分區，然後將一個或多個partition分給worker；

2.worker為每一個partition啟動一個線程，該線程輪詢partition中的頂點，為每一個active狀態的頂點調用compute方法；

3.compute完成後，按照edge的信息將計算結果通過消息傳遞方式傳給其它頂點；

4.完成同步後，重復執行2,3操作，直到沒有active狀態頂點或者叠代次數到達指定數目。

這個模型雖然簡潔，但很容易發現它的缺陷。對於鄰居數很多的頂點，它需要處理的消息非常龐大，而且在這個模式下，它們是無法被並發處理的。所以對於符合冪律分布的自然圖，這種計算模型下很容易發生假死或者崩潰。

作為第一個通用的大規模圖處理系統，pregel已經為分布式圖處理邁進了不小的一步，這點不容置疑，但是pregel在一些地方也不盡如人意：

1.在圖的劃分上，采用的是簡單的hash方式，這樣固然能夠滿足負載均衡，但是hash方式並不能根據圖的連通特性進行劃分，導致超步之間的消息傳遞開銷可能會是影響性能的最大隱患。

2.簡單的checkpoint機制只能向後式地將狀態恢復到當前S超步的幾個超步之前，要到達S還需要重復計算，這其實也浪費了很多時間，因此如何設計checkpoint，使得只需重復計算故障worker的partition的計算節省計算甚至可以通過checkpoint直接到達故障發生前一超步S，也是一個很需要研究的地方。

3.BSP模型本身有其局限性，整體同步並行對於計算快的worker長期等待的問題無法解決。

4.由於pregel目前的計算狀態都是常駐內存的，對於規模繼續增大的圖處理可能會導致內存不足，如何解決尚待研究。

3.3　GAS模型——鄰居更新模型

相比Pregel模型的消息通信範式，GraphLab的GAS模型更偏向共享內存風格。它允許用戶的自定義函數訪問當前頂點的整個鄰域，可抽象成Gather、Apply和Scatter三個階段，簡稱為GAS。相對應，用戶需要實現三個獨立的函數gather、apply和scatter。常見的代碼模板如下所示：

由於gather/scatter函數是以單條邊為操作粒度，所以對於一個頂點的眾多鄰邊，可以分別由相應的worker獨立調用gather/scatter函數。這一設計主要是為了適應點分割的圖存儲模式，從而避免Pregel模型會遇到的問題。

1.Gather階段

工作頂點的邊(可能是所有邊，也有可能是入邊或者出邊)從領接頂點和自身收集數據，記為gather_data_i，各個邊的數據graphlab會求和，記為sum_data。這一階段對工作頂點、邊都是只讀的。

2.Apply階段

Mirror將gather計算的結果sum_data發送給master頂點，master進行匯總為total。Master利用total和上一步的頂點數據，按照業務需求進行進一步的計算，然後更新master的頂點數據，並同步mirror。Apply階段中，工作頂點可修改，邊不可修改。

3.Scatter階段

工作頂點更新完成之後，更新邊上的數據，並通知對其有依賴的鄰結頂點更新狀態。這scatter過程中，工作頂點只讀，邊上數據可寫。

在執行模型中，graphlab通過控制三個階段的讀寫權限來達到互斥的目的。在gather階段只讀，apply對頂點只寫，scatter對邊只寫。並行計算的同步通過master和mirror來實現，mirror相當於每個頂點對外的一個接口人，將復雜的數據通信抽象成頂點的行為。

Spark學習之路 （二十八）分布式圖計算系統