Facebookチームは、既存のGiraphベースのグラフ処理システムと、人気のSparkフレームワークの一部である新しいGraphXとのパフォーマンス比較を先日公開した。彼らの結論はGraphXは現在、彼らのグラフ処理ワークロードをサポートするために十分なスケーラビリティやパフォーマンスを備えていないということだ。
大規模なグラフ処理は、Facebookのデータインフラストラクチャサービスの重要な部分である。彼らのソーシャルグラフは数千億のエッジを持つ17億1000万の頂点を持ち、人気のあるページを追加する場合、グラフは1兆を超えるエッジをも持ち得る。また、ページやグループのレコメンド、インテリジェントなデータ配置によるインフラストラクチャの最適化、グラフの圧縮など、グラフデータ分析のユースケースも幅広くある。
チームは、VLDB '15の論文と、該当するブログ記事で説明しているようにApache Giraphフレームワークをベースにしたグラフ分析プラットフォームを構築している。代替案を探す動機の説明を、チームは次のように書いている。
その誕生以来、Giraphは進化を続けており、Facebook規模のプロダクションワークロードを処理できるようになりましたが、ユーザのプログラミングもまた簡単になりました。その間に、他の多くのグラフ処理エンジンが登場しました。たとえば、一般的なデータ処理のプラットフォームとして採用されたSparkフレームワークは、グラフ指向のプログラミングモデルと実行エンジン、さらにGraphXを提供しています。
最良の方法で内部のワークロードを提供することが私たちの目標であるため、GiraphとGraphXの定量的および定性的な比較を行うことにしました。
FacebookはプロダクションワークロードをサポートするSparkクラスタも保持しており、これらのグラフデータ処理システムの比較を行って、両者のシステムが巨大なグラフをどのように処理するかを確認することにした。テストでは、異なるリソース割り当てポリシーの下で2つのシステムがどのように実行されたか、さらにフォールトトレランスやユーザインタフェースなどの側面でどのようなサポートが提供されるかについても調査した。彼らはまた、2つのシステム間の使いやすさと開発の容易さを含む他の要因についてもテストした。
テスト方法には、グラフデータ分析によく使われる3つのアルゴリズム、ページランク（PageRank）、連結成分（Connected Components）、さらに重い三角形構造数計算（Triangle Counting）が含まれていた。オリジナルのGraphX論文との比較を可能にするために、公開されている同じ2つのグラフデータセット、すなわち15億のエッジを持つTwitterグラフと37億のエッジを持つ英国のウェブグラフを使用してテストを開始した。このテストには、Darwiniグラフ生成ツールを使用して生成された合成グラフデータセットも含まれていた。基本的なソフトウェア構成は、JDK 1.8（8u60）のSpark 1.6.1とGiraph 1.2.0であった。
一般的に、Giraphはプロダクション規模のワークロードを処理することに適しており、Spark GraphXはグラフデータ処理ソリューションの開発を容易にするいくつかの機能を提供していた。
パフォーマンステストの主な結果は次のとおりだ。
- Giraphは小さなグラフのデータセットであっても優れたパフォーマンスを示した。
- Giraphはメモリ効率も高かった。
- GraphXでは、SQLのようなクエリを使用してHiveからグラフを読み取ることができ、任意の列変換が可能である。
- シェル環境からScalaを使用すると、簡単なGraphXアプリケーションをテストするのに便利である。
最後に、チームは、GraphXは彼らのグラフ処理ワークロードをサポートするのに十分なスケーラビリティやパフォーマンスを備えていないと結論づけた。
今の結果の予測に基づいて、既存のプロダクションワークロードをサポートするためには十倍のマシンが必要になります。これとは別に、GraphXが処理できるグラフサイズであっても、必要とする機械時間の効率に大きな差があり、そのパフォーマンスは安定していませんでした。ただし、GraphXのプログラミングインタフェースには、SQLの統合などアプリケーション開発を簡素化する多くの機能が用意されています。これらは今後Giraphに追加したい機能です。
チームは調査の再現方法の詳細を提供しており、コードとデータも利用可能である。
Rate this Article
- Editor Review
- Chief Editor Action