一支Facebook 團隊近期發表了一份比較報告，比較對象是他們當前的基於 Giraph的圖處理系統和更新的 GraphX （它是流行的 Spark 框架的一部分）。他們的結論是，GraphX當前無法滿足他們對擴展性和性能的需要，不足以支撐起他們圖處理的負載。
在Facebook，大規模圖處理是數據設施服務的重要組成部分。他們的社會圖有1.71十億編輯頂點和數千億的邊，如果再把人們的愛好加進來那麼該圖就會有上十億條邊了。他們還有用於圖數據分析的大量應用場景，包括通過智能數據分佈和圖壓縮的網頁和群組推薦、基礎設施優化。
該團隊基於Apache Giraph搭建了一個圖分析平臺，其在 VLDB '15 論文和一篇相應的博客文章中曾被介紹過。該團隊描述了它們尋找替代者的動機，他們是這樣寫的：
自從誕生以來，Giraph已得到了持續的演進，不僅能簡化用戶的編程，還能讓用戶可以處理Facebook級的生產負載。在這段期間，湧現出了大量的其他圖處理引擎。例如Spark框架，它是作為針對常規數據處理的平臺得以應用的，此外它還提供了一個面向圖的編程模型和執行引擎，即GraphX。
由於我們的目標是儘可能選擇最佳方式處理內部負載，所以我們決定對Giraph和GraphX進行定量、定性的比較。
由於Facebook還有一個支撐生產負載的Spark cluster，所以他們決定比較一下這些圖數據處理系統，看看這些系統處理大規模圖會怎樣。這項測試還可以看一下這兩個系統在不同的資源分配策略下是怎麼執行的，以及它們針對容錯和用戶界面提供了什麼類型的支持。他們還測試了其他的一些影響因素，包括在這兩個系統之間開始的可用性和易用性比較。
該測試方法涉及到三個在圖數據分析領域流行的算法： PageRank、Connected Components以及更多信息負載的 Triangle Counting。為了與最初的 GraphX論文形成對照，他們使用了相同的兩份公開可用的圖數據集開始的測試，它們分別是Twitter圖和英國網頁圖，前者有15億條邊，而後者有37億條邊。這項測試還包括一些人造圖數據，它是使用Darwini圖生成工具生成的。該基礎軟件配置是 Spark 1.6.1 和 Giraph 1.2.0，JDK版本為1.8 (8u60)。
他們發現在通常情況下Giraph能夠更好地處理生產級負載，而Spark GraphX提供的幾個特性，能使圖數據處理解決方案的開發更簡單。
該性能測試有如下關鍵發現：
Giraph即使在較小規模的圖數據集上執行得也更好些。
Giraph的內存使用也更加高效。
GraphX支持以SQL樣式的查詢從Hive中讀取圖，支持任意列轉換。
使用shell環境中的Scala是一種測試GraphX簡單應用的簡便方式。
最後，該團隊總結說，GraphX不足以支持他們圖處理負載的擴展性和性能需要。
基於對當前結果的推測，我們應該需要訂購更多數量級的機器去支持當前的生產負載。除此之外，即使GraphX能處理該圖規模，其機器運轉的時間也是效率方面很大的欠缺。然而，GraphX編程接口提供了許多簡化應用開發的特性，比如SQL集成。我們希望Giraph在未來也能添加上這些特性。
該團隊已經提供了重現本研究的相關細節，以及相關代碼和數據。
原文鏈接:
http://www.infoq.com/news/2016/12/graph-processing-facebook
