一、圖概念術語
1.1 基本概念
圖是由頂點集合(vertex)及頂點間的關系集合（邊edge）組成的一種數據結構。
這里的圖並非指代數中的圖。圖可以對事物以及事物之間的關系建模，圖可以用來表示自然發生的連接數據，如：社交網絡、互聯網web頁面
常用的應用有：在地圖應用中找到最短路徑、基於與他人的相似度圖，推薦產品、服務、人際關系或媒體
1.2 術語
1.2.1頂點和邊
一般關系圖中，事物為頂點，關系為邊
1.2.2有向圖和無向圖
在有向圖中，一條邊的兩個頂點一般扮演者不同的角色，比如父子關系、頁面A連接向頁面B；
在一個無向圖中，邊沒有方向，即關系都是對等的，比如qq中的好友。
GraphX中有一個重要概念，所有的邊都有一個方向，那么圖就是有向圖，如果忽略邊的方向，就是無向圖。
1.2.3有環圖和無環圖
有環圖是包含循環的，一系列頂點連接成一個環。無環圖沒有環。在有環圖中，如果不關心終止條件，算法可能永遠在環上執行，無法退出。
1.2.4度、出邊、入邊、出度、入度
度表示一個頂點的所有邊的數量
出邊是指從當前頂點指向其他頂點的邊
入邊表示其他頂點指向當前頂點的邊
出度是一個頂點出邊的數量
入度是一個頂點入邊的數量
1.2.5超步
圖進行迭代計算時，每一輪的迭代叫做一個超步
二、圖處理技術
圖處理技術包括圖數據庫、圖數據查詢、圖數據分析和圖數據可視化。
2.1 圖數據庫
Neo4j、Titan、OrientDB、DEX和InfiniteGraph等基於遍歷算法的、實時的圖數據庫；
2.2 圖數據查詢
對圖數據庫中的內容進行查詢
2.3 圖數據分析
Google Pregel、Spark GraphX、GraphLab等圖計算軟件。傳統的數據分析方法側重於事物本身，即實體，例如銀行交易、資產注冊等等。而圖數據不僅關注事物，還關注事物之間的聯系。例如，如果在通話記錄中發現張三曾打電話給李四，就可以將張三和李四關聯起來，這種關聯關系提供了與兩者相關的有價值的信息，這樣的信息是不可能僅從兩者單純的個體數據中獲取的。
2.4 圖數據可視化
OLTP風格的圖數據庫或者OLAP風格的圖數據分析系統（或稱為圖計算軟件），都可以應用圖數據庫可視化技術。需要注意的是，圖可視化與關系數據可視化之間有很大的差異，關系數據可視化的目標是對數據取得直觀的了解，而圖數據可視化的目標在於對數據或算法進行調試。
三、圖存儲模式
在了解GraphX之前，需要先了解關於通用的分布式圖計算框架的兩個常見問題：圖存儲模式和圖計算模式。
巨型圖的存儲總體上有邊分割和點分割兩種存儲方式。2013年，GraphLab2.0將其存儲方式由邊分割變為點分割，在性能上取得重大提升，目前基本上被業界廣泛接受並使用。
3.1 邊分割（Edge-Cut）
每個頂點都存儲一次，但有的邊會被打斷分到兩台機器上。這樣做的好處是節省存儲空間；壞處是對圖進行基於邊的計算時，對於一條兩個頂點被分到不同機器上的邊來說，要跨機器通信傳輸數據，內網通信流量大。
3.2 點分割（Vertex-Cut）
每條邊只存儲一次，都只會出現在一台機器上。鄰居多的點會被復制到多台機器上，增加了存儲開銷，同時會引發數據同步問題。好處是可以大幅減少內網通信量。
3.3 對比
雖然兩種方法互有利弊，但現在是點分割占上風，各種分布式圖計算框架都將自己底層的存儲形式變成了點分割。主要原因有以下兩個。
磁盤價格下降，存儲空間不再是問題，而內網的通信資源沒有突破性進展，集群計算時內網帶寬是寶貴的，時間比磁盤更珍貴。這點就類似於常見的空間換時間的策略。
在當前的應用場景中，絕大多數網絡都是“無尺度網絡”，遵循冪律分布，不同點的鄰居數量相差非常懸殊。而邊分割會使那些多鄰居的點所相連的邊大多數被分到不同的機器上，這樣的數據分布會使得內網帶寬更加捉襟見肘，於是邊分割存儲方式被漸漸拋棄了。
四、圖計算模式
目前的圖計算框架基本上都遵循BSP（Bulk Synchronous Parallell）計算模式。Bulk Synchronous Parallell，即整體同步並行，它將計算分成一系列的超步（superstep）的迭代（iteration）。從縱向上看，它是一個串行模型，而從橫向上看，它是一個並行的模型，每兩個superstep之間設置一個柵欄（barrier），即整體同步點，確定所有並行的計算都完成后再啟動下一輪superstep。
4.1 超步
每一個超步（superstep）包含三部分內容：
1.計算compute，每一個processor利用上一個superstep傳過來的消息和本地的數據進行本地計算；
2.消息傳遞，每一個processor計算完畢后，將消息傳遞個與之關聯的其它processors；
3.整體同步點，用於整體同步，確定所有的計算和消息傳遞都進行完畢后，進入下一個superstep。
4.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目前的計算狀態都是常駐內存的，對於規模繼續增大的圖處理可能會導致內存不足，如何解決尚待研究。
4.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相當於每個頂點對外的一個接口人，將復雜的數據通信抽象成頂點的行為。