大規模グラフデータ処理

大規模グラフデータ処理

@maruyama097
丸山不二夫

今日のウェブは、さまざまページの間に張ら
れた無構造でランダムなリンクによって成り
たっています。 Open Graph(オープンググ
ラフ)は人々の間の関係を構造化します。
Zuckerberg 2010年4月 f8コンファレンス

GoogleのKnowledge Graphは、単に
FreebaseやWikipedia、そしてCIA World
Factbookといった、パブリックなリソースに

基づいているだけではない。それは、もっと
巨大なスケールで、拡張されている。なぜな
ら、我々は、包括的な広さと深さにフォーカ
スしてきたからだ。
我々は、あなたが聞こうと思いもしなかった
質問に答え、あなたの発見をさらに助ける為
に、Knowledge Graphを、利用することが
出来る。

はじめに
 巨大なクラウドと無数のデバイス達がネット
ワークでつながる世界では、我々がリーチ出
来る範囲にも、驚くほど大量の「情報」があ
ふれている。
 「Webスケール」と呼ばれる、これらの情報
の量的特徴付けは、それ自身、現代のITが挑
戦を続けている課題の質的特徴をよく表して
いる。
 一方、我々人間が直接知りうる事には、自然
な限界がある。Webスケールの情報に、我々
が関心を持つのは、そこに我々が理解しうる

はじめに
 文書間の参照グラフを利用したPageRankは
、Webスケールの情報から、我々の関心にそ
う情報を我々が理解出来る範囲で抽出する、
もっとも成功した手法である。
 SNSの爆発的成長は、人間と人間の関係グラ
フ、いわゆる「ソーシャル・グラフ」をネッ
トワーク上に作り上げた。それは、現代の
Webスケールデータの代表的な存在になった
。

はじめに
 現在のグラフに対する関心は、直接的には、
モバイルと個人に対して最適の広告を配布す
るというビジネス上の動機でドライブされて
いる。それは、現代のIT企業間の競争のもっ
とも中心的な分野である。
 モバイルと個人に対する「最適の広告」を「
最適の情報」と読み替えると、現在進行中の
技術的変化の特質がよく理解出来ると思う。
それは、無理な読み替えではない。両者は、
同じ技術を共有しているからだ。

はじめに
 「知識グラフ」に対する関心の高まりは、人
間の認知能力とりわけ意味理解の能力を解明
し、機械に学習能力を与え、機械と人間の将
来の関係のあり方を考えるという、ITの最も
重要で長期的な諸課題に我々が近づいている
事を意味しているのかもしれない。
 問題を立てる事と、問題を解くのは別の事で
ある。ただ、問題を立てるだけの条件がそろ
ってきていることは、大事な変化である。そ
して、こうした変化の下で、次世代のイノベ
ーションが起きるのは確実である。

はじめに
 講演では、現時点での代表的なWebスケール
の大規模グラフデータ処理技術として、次の
三つの技術を取り上げる。

 Google Pregel
 Apache Giraph
 Microsoft Trinity

Agenda
 Part I グラフとグラフデータ処理
 Part II 検索の進化と
 Part III Google Pregel
 Part IV Apache Giraph
 Part V
MS Trinity

Part I
グラフとグラフデータ処理

様々なグラフ
グラフは、頂点とそれを結ぶ辺だけからな
る単純な図形である。それは、基本的には
２つのものの関係を表現したものだと解釈
出来る。我々は、複雑な現実の様々な対象
の背後に、グラフ構造を見つけ出す。

Euler
ケーニヒスベルク
の7つの橋巡り

頂点
辺

様々な対象・様々なグラフ

生物学的ネットワーク

プログラムの流れ図

ソーシャル・ネットワーク

輸送ネットワーク

タンパク質のネットワーク

http://www.cse.unsw.edu.au/~iwgdm/2013/Slides/Haixun.pdf

Deep learning

Google DistBelief

http://stanford.edu/~acoates/papers/
CoatesHuvalWangWuNgCatanzaro_icml2013.pdf

物理学のグラフ

http://arxiv.org/pdf/0711.0770.pdf

グラフのタイプ
グラフには、辺の向きやラベルの有無によ
って、幾つかのタイプにわけられる。現在
のグラフ・データベースの多くは、「プロ
パティー・グラフ・モデル」を採用してい
る。


無向グラフ


有向グラフ

ＵＭＬダイアグラム

http://en.wikipedia.org/wiki/Unified_Modeling_Language


TwitterのFollow

有向グラフ

Webぺージのリンク

全ての辺が同じ意味を持つ
単一関係グラフ
 辺を区別する方法がなく、全ての辺が同じ意
味・型を持っている。こうした構造は、「単
一関係グラフ(single-relational graphs)」
と呼ばれる。
 単一関係グラフは、グラフ理論やネットワー
ク科学で、おそらくは、もっともよく使われ
ているグラフの型である。

The Graph Traversal Programming Pattern

http://www.slideshare.net/slidarko/graph-windycitydb2010

複数関係グラフ
 複数関係グラフは、辺に、例えば、「フォロ
ーする」とか「引用する」といった、明確な
型付けを許す。
 辺にラベルを付ける事によって、辺は異なっ
た意味を持ち、頂点も異なった型を持つよう
になる。
 例
 follows : user → user
 created : user → webpage
 cites : webpage → webpage

複数関係グラフによって、
グラフの表現力は拡大される
引用する

引用する

生成する

生成する

生成する
フォローする

引用する
フォローする
生成する

フォローする
フォローする

生成する

フォローする

プロパティー・グラフの柔軟性
 プロパティー・グラフは、複数関係グラフを、頂点・
辺の両方とも Key/Valueのプロパティー・マップを
保持出来るように拡張したものである。この事によっ
て、辺の意味は、もっと洗練されたものに出来る。
 次のグラフは、以下の文章を表現している。

Peter Neubauer created the Neo4j webpage on 2007/10.

プロパティー・グラフを利用した
グラフ・データベースのデータ構造の例

http://en.wikipedia.org/wiki/Graph_database

グラフ処理のスタイル

グラフ・データベースと
リレーショナル・データベース
 リレーショナル・データベースでも、グラフ
の表現は可能である。ただし、例えば、「友
達の友達の友達」「友達の友達が引用してい
る文書が引用している文書」といった検索を
実現しようとすれば分かるように、グラフ上
では単純にノードを横断するだけの処理が、
リレーショナル・データベースでのグラフ表
現では、ノードを移動する度に、テーブルの
ジョインが必要になる。これでは、効率的な
検索は望めない。

グラフ・データベースと
大規模グラフデータ処理システム
 グラフ・データを処理するのに、グラフ・デ
ータベースは極めて強力なツールである。そ
の利用は、エンタープライズでの利用を含め
て、今後、ますます拡大して行くだろう。
 ただ、小論は、グラフ・データベースを対象
とはしていない。それは、現状ではWebスケ
ールの大規模なグラフ・データを処理するス
ケーラビリティをまだ持っていないからであ
る。
 一方で、BSPモデルに基づく大規模グラフデ
ータ処理システムは、基本的にはバッチ型の

Part II

検索の進化と

He who controls the graph,
controls the world.

2000年代
大規模データ処理の第一世代の開始
 現代のITの中核的な技術の一つは、大規模分
散システムによる大規模データの処理技術で
ある。「世界中の情報を検索可能にする」と
いうミッションを掲げたGoogleの、Webス
ケールの検索技術の実現がこうした時代の幕
を開いた。21世紀の始まりとその時期は、ほ
ぼ等しい。
 クローリングで収集した膨大なページへのイ
ンデックス付けとPageRankの計算が、
Webスケールのデータ処理の中心だったのだ
が、そうした処理は、MapReduceを用いた

2010年代
大規模データ処理の第二世代への転化
 モバイル・デバイスSNSの爆発的な普及を背
景として、2010年ごろ、バッチ処理からリア
ルタイム処理への大規模データ処理の大きな
転換が始まる。
 Googleのシステムの転換については、昨年７月の丸
山の「大規模分散システムの現在--- GFS,
MapReduce, BigTableは、どう進化したか」を参照
されたい。
https://drive.google.com/file/d/0B04ol8GVySU
ueWQ2dkZUSFFETlk/edit?usp=sharing

ソーシャル・グラフと
 こうした変化の口火を切ったのは、個人とモ
バイルをターゲットとして、「世界をもっと
つながったものに」を会社のミッションとす
るFacebookの躍進だった。2010年4月に公
開されたFacebookのOpen Graphは、「ソ
ーシャル・グラフ＝大規模グラフデータ」処
理の重要性に多くの人の目を向けさせた。
 Googleの対応も興味深い。2010年６月、前
述の検索インデキシングのリアルタイム化を
実現したCaffeinの投入と同じ日に、大規模
グラフデータ処理のエンジンPregelを発表す

検索と大規模グラフデータ
 2010年に行われた技術的転換は、バッチから
リアルタイムへの進化だけではなく、データ
の量への注目からデータの質的なグラフ構造
への注目を特質とする大規模データ処理の第
二世代の開始を意味するものである。
 ただ、この技術的転換の意味を、検索の分野
で「知識グラフ」の探索として、明確に定式
化したのは、2012年のGoogleの
Knowledge Graphである。この動きに、
FacebookはSearch Graphで、Microsoft
は Satori/Trinityで、ただちに追走を開始

グラフデータと「知識」の探求の始ま
り
 GoogleのKnowledge Graphについては、
2012/07/12 の丸山の講演「Google の新しい検索
技術 Knowledge Graph について」を参照されたい
。
https://docs.google.com/file/d/0B04ol8GVySUu
UFUtbWcxNFlHY3c/edit?usp=sharing

 ただ、大規模なグラフデータから、我々にと
って有用な「知識」「意味」を抽出しようと
いう取り組みは、まだ始まったばかりである
。

「知識グラフ」と開かれた課題
 「知識グラフ」に対する関心は、次のようなよ
り長期的な課題の実現と結びついている。






自然言語を用いたインターフェース
知識とそれをハンドルする能力の機械への移転
生物の多様な認知能力と学習能力の理解
人間の言語能力の理解
学習する機械

 楽観的に語るならば、我々は、こうした課題を
解決する時代の入り口に、さしかかっているの
かもしれない。

Facebook Open Graph
「人々の関係を構造化する」
2010年4月21日
f8 Conference Keynote
http://www.livestream.com/f8conference/vi
deo?clipId=pla_e7a096b4-3ef9-466d-9a37d920c31040aa

Open Graph
 「今日のウェブは、さまざまページの間に張
られた無構造でランダムなリンクによって成
りたっています。Open Graph(オープンググ
ラフ)は人々の間の関係を構造化します。」
Zuckerberg
 Facebookは、2010年に、ソーシャル・グラ
フの拡張であるオープングラフの初期バージ
ョンを導入した。このオープングラフ・プロ
トコルを通じて、Web中の人々が好きなウェ
ブサイトやページを含めることが出来る。
Open Graph

https://developers.facebook.com/docs/opengraph/

Google‘s Schmidt: ‗I Screwed
Up‘ on Social Networking
「SNSでは、私はへまをした」
2010年6月1日
Wired誌へのインタビュー
http://www.wired.com/business/2011/06/g
oogles-schmidt-social/

Our new search index:
Caffeine
検索インデックス付けのリアルタイム化
2010年6月8日
Google Webmaster Central Blog
http://googlewebmastercentral.blogspot.jp/
2010/06/our-new-search-indexcaffeine.html

Pregel: A System for LargeScale Graph Processing
Googleの大規模グラフデータ処理エンジン
2010年6月8日
SIGMOD 2010
http://kowshik.github.io/JPregel/pregel_paper
.pdf

Google+

一般公開

GoogleのSNSへの参入
2011年9月21日
試験サービスの開始は、2011年6月２８日
http://ja.wikipedia.org/wiki/Google+#cite_
note-1

Apache Giraph 0.1 incubating
Release
Pregelのオープンソース・クローン
2012年2月6日
https://giraph.apache.org/
http://archive.apache.org/dist/incubator/gir
aph/

Google Knowledge Graph
Googleの知識ベース検索サービス
2012年5月16日
―Introducing the Knowledge Graph:
things, not strings‖
http://googleblog.blogspot.co.uk/2012/05/i
ntroducing-knowledge-graph-thingsnot.html

新しい検索の三つの特徴
 正しい「もの」を見つける。（Find the
right thing）
 最良の要約を得る。（Get the best
summary）
 さらに深く、さらに広く。（Go deeper
and broader）
GoogleのKnowledge Graphについては、2012年7月12日の
クラウド研究会での丸山の資料「Googleの新しい検索技術
Knowledge Graphについて」を参照されたい。
https://drive.google.com/file/d/
0B04ol8GVySUuUFUtbWcxNFlHY3c/edit?usp=sharing

The Knowledge Graph

http://www.google.com/insidesearch/features/search/knowledge.html

Facebook Graph Search
Facebookの知識ベースの検索サービス
2013年1月15日
―Introducing Graph Search Beta‖
http://newsroom.fb.com/News/562/Introdu
cing-Graph-Search-Beta

―Graph Search‖ は、Googleがして
いるようなリンクではなく、答えを与
える
 「Facebookが現在行っているこれら全ての
ことより、ずっ面白いのは、人々に彼らが望
むグラフのどんな断片でも得ることが出来る
パワーとツールを与える事である。」
 「Graph Searchは、正確な検索をすれば、
ある一つの答えを与えるようにデザインされ
ている。答えを与えるかもしれない複数のリ
ンクではない。... 例えば、Grah Searchに
「サンフランシスコに住んでいる私の友達は
誰？」と質問出来る。」
http://techcrunch.com/2013/01/15/
facebook-announces-its-third-pillar-graph-search/

Facebook Graph Search

「カリフォルニア州サンフランシスコに住んでいる人」

 ザッカーバーグは、Graph Searchは「非常
に初期のベータ段階にある」と語った。「製
品の最初の取り組みでは、友達・写真・場所
・興味にフォーカスする。」
 FacebookのGraph Searchは完全にパーソナ
ライズされている。「スター・ウォーズとハ
リー・ポッターが好きな友達は？」という検
索は、質問する人によって全く違う答えを返
す。
http://techcrunch.com/2013/01/15/
facebook-announces-its-third-pillar-graph-search/

Microsoft Satori
MSの知識ベースの検索サービス
2013年3月21日
―Understand Your World with Bing‖
http://www.bing.com/blogs/site_blogs/b/se
arch/archive/2013/03/21/satorii.aspx

Bing Snapshot
 Bingでは、我々は検索はwebのページを指す
青いリンク以上のものであるべきだと信じて
いる。我々はまた検索は現実の世界の反映で
あるべきだと信じている。それが、我々が昨
年6月に検索結果ページの中央のコラムに答え
を一目で見る事の出来るSnapshotという特
徴を導入した理由である。この検索結果は、
現実世界をよりよく理解し開拓する、豊かな
検索である。我々は、まず、映画、レストラ
ン、ホテルから始めた。

Bing Satori
 Snapshotのの基礎にある技術は、我々を取
り巻く世界を、単に「人、場所、物」といっ
たものの集まりとしてだけではなく、これら
のものの関係として、深く理解することを目
的にデザインされた。Bingのエンジニアリン
グ・チームの中では、この技術は、理解を意
味する日本語の「悟り(Satori)」と呼ばれて
いた。Satoriは、繰り返し成長を続け、検索
者にディジタルとフィジカルな世界のより有
用なモデルを提供する、数十億のエンティテ
ィと関係をカバーするまでになった。

Microsoft
Trinity: A Distributed Graph
Engine on a Memory Cloud
MSの新しいアーキテクチャのグラフエン
ジン
2013年6月26日
ACM SIGMOD 2013
http://research.microsoft.com/pubs/183710
/Trinity.pdf
http://research.microsoft.com/apps/pubs/d

Facebook Scaling Apache
Giraph to a trillion edges
FacebookのGiraph拡張の試み
2013年8月15日
Avery Ching
Northern Western University
https://www.facebook.com/avery.ching

Google Hammingbird
Googleの最新の検索エンジン
2013年9月26日
―Fifteen years on—and we‘re just
getting started‖
http://insidesearch.blogspot.jp/2013/09/fift
een-years-onand-were-just-getting.html

Google: Moonshot Changes !
検索の現状と未来について
2013年10月23日
Pubcon Las Vegas 2013
Keynote Talk With Matt Cutts
http://www.youtube.com/watch?v=K7JhnW
HbwnE
http://www.bruceclay.com/blog/2013/10/m
att-cutts-pubcon-las-vegas-keynote/

Moonshot Changes
 Knowledge Graph: 文字列ではなく物事。
質問の背後に実際にあるものを知る
 Voice search: ますます改良されている
 Conversational search: 代名詞を考える
 Google Now: 質問をしなくても、次のステ
ップを先読みする
 Deep learning: 神経回路網を学習する為に
、数千のコンピュータが利用されている

Hummingbird
 質問を行っているのなら、それは、自然言語
での質問かもしれないし、そこには必要では
ない言葉が含まれているかもしれない。
「愛しのテキサスの首府は？」
Hummingbirdは、重要な言葉を切り出して
、その言葉にもっと知的に点数を加えるとい
う方向への一つのステップである。

検索の未来
未来の大きな流れ
 機械学習：検索をする人に、如何にしたらもっと大
きな価値を与えられるかを解き明かす試みを、続けて
いこうとしている
 モバイル: 2011年のYouTubeの携帯電話からのトラ
フィックは6%だった。2012年には、それは25%に
なり、2014年にはYouTubeのトラフィックの40%
を占めると予想されている。もし、モバイルについて
の戦略を明確に持っていないのなら、それについて考
えた方がいい。
 社会性/主体性/著作権：自分が何者であるかを知る
こと。主体性は大きな違いを生み出しうる。人々が耳
を傾ける人物であるという事は、長期間続くシグナル
である。

Facebook
next 10-year plans
「Graph Searchは、ほとんど動かない
」
2013年1月30日
Interview with Business Week
http://www.businessweek.com/articles/201
4-01-30/facebook-turns-10-the-markzuckerberg-interview#p4

Facebookの10年計画
1. 高度にパーソナライズ化されたターゲット広
告をニュースフィードに配信し、ユーザーあ
たりの平均の収入と利益幅を大幅に増加させ
る
2. ユニークな経験を配信し、巨大なFacebook
のデータハブに接続する主要なスポークとし
て、スタンドアロンのアプリを確立する
3. 多様な人工知能サービスを可能とするSearch
Graphで、伝統的な検索を凌駕する
4. たえず安価になり、より機能的なデバイスと
http://www.dnaindia.com/scitech/report-mark-zuckerberg-unveilsデータセンターをインターネットにもたらす
facebook-s-next-10-year-plans-1958538

Part II まとめ
検索とグラフをめぐる主要な出来事
2010/04/21 Facebook Open Graph公開
2010/06/01 Schmidt 自己批判
2010/06/08 Google Caffeine投入
2010/06/08 Google Pregel Paper
SIGMOD 2010
 2011/09/21 Google Google+スタート
 2012/02/06 Apache Giraph 0.1
incubating
 2012/06/16 Google Knowledge Graph





Part II まとめ
検索とグラフをめぐる主要な出来事
2012/06/16
2013/01/15
2013/03/21
2013/06/26
2013/08/15
Giraph
 2013/09/26






Facebook Search Graph
Microsoft Satori
Microsoft Trnity
Facebook Trillon Edges
Google Hammingbird

2010年6月8日
SIGMOD 2010
http://kowshik.github.io/JPregel/preg
el_paper.pdf

SIGMOD 2010
Grzegorz Malewicz, Matthew Austern,
Aart Bik, James Dehnert, Ilan Horn,
Naty Leiser, Grzegorz Czajkowski
(Google, Inc.)
http://www.cse.iitb.ac.in/dbms/Data/
Courses/CS632/Talks/pregel.pptx

Pregel開発の背景と動機

グラフ処理の必要性
 実践的な計算問題の多くがグラフに関係して
いる。（Webグラフ、ソーシャル・ネットワ
ーク、輸送ネットワーク）

例:






最小経路
クラスタリング
ページランク
最大フロー・最小カット
連結要素

グラフのスケール
 ソーシャル・ネットワークは、人々の間の関
係を表すグラフである。輸送ルートは、地理
的な位置の物理的なつながりを表現するグラ
フである。伝染病の伝播もグラフを形成する
。サッカーチーム間の試合もコンピュータ・
ネットワークのトポロジーもそうである。お
そらく、もっとも広がっているグラフは、
webそのものだろう。そこでは、ドキュメン
トが頂点で、リンクが辺である。
 これらのグラフのスケールは、ある場合には
数十億の頂点、数兆の辺を持ち、その効率的

グラフ・アルゴリズム
挑戦その1
 頂点毎には、ほんの尐しの計算しか必要とされな
い。
 実行の途中で、並列計算の程度が変わる。
 Munagala and Ranadeは、グラフ・アルゴリズ
ムの IO の複雑さの下限を示した。
http://www.daimi.au.dk/~large/ioS06/MR.p
df

グラフ処理の他のアプローチ
 新しいアルゴリズム全てに対して、分散インフラ環境
を構築する
 Map Reduce
 ステージ間のコミュニケーションのオーバーヘッ
ド
 コンピュータ上のグラフ・ライブラリー
 スケールしない
 その他の並行グラフ処理システム
 fault-toleranceでない

スケーラブルな分散処理のソリューションが求
められている

グラフの規模拡大と
グラフ処理に対する要求の変化
 先に述べたグラフの多くは、その構造や起源がそれぞ
れ異なるにもかかわらず、二つの共通点を持つ。その
一つは、それらのグラフのサイズが膨張し続けている
事であり、もう一つは、人々がお互いに知りたいと思
っている事実や細部は、無限に存在するように見える
事である。
 例えば、地理的な位置情報を考えてみよう。普通の地
図（これもグラフだ）の比較的単純な分析で、二つの
都市の最小経路を与える事が出来る。しかし、もっと
進んで分析を洗練させれば、もっと豊かな情報、スピ
ード制限とか予想される交通渋滞とか道路工事や天候
の状態まで、応用出来る。

グラフの規模拡大と
グラフ処理に対する要求の変化
 実距離を計測した最短ルートに加えて、最も
景色のいいルートや最も燃料効率のいいルー
ト、一番休憩場所の多いルートといったもの
の情報を得る事も出来る。こうしたオプショ
ンやそれ以上のものを、もしも適切なツール
と入力情報があれば、グラフから引き出し、
便利に利用出来る。Webグラフも同様である
。Webは、数十億の文書を含み、かつ、毎日
のようにその数は増え続けている。

検索とグラフ処理
 巨大な量の情報から、必要とする情報を見つ
け出すのを助ける為に、Googleは、ウェブペ
ージの言語からそのページを参照しているペ
ージの数と質にいたるまで、Webグラフから
200以上の情報を抽出している。それを成し
遂げる為に、広い範囲のグラフのデータをマ
イニングするスケールするインフラを必要と
している。

Pregel
 Pregelという名前は、レオナルド・オイラー
にちなんだものである。彼の有名な定理をイ
ンスパイアしたケーニヒスベルクの橋は、プ
レゲル川にかかっていた。
 ScalableでFault-tolerantなプラットフォー
ム
 任意のアルゴリズムを表現出来る柔軟なAPI
 ValiantのBulk Synchronous Parallelモデル
にインスパイアされている
 頂点中心の計算 (頂点のように考える)

Bulk Synchronous Parallel
の計算モデル
Bulk Synchronous Parallel（BSP）モデ
ルは、ハーバード大のLeslie Valiant によ
って，1980年代に提案された。
http://web.mit.edu/6.976/www/hand
out/valiant2.pdf

MapReduceの原論文でも、BSPモデルは
引用されている。
http://static.googleusercontent.com/media/
research.google.com/ja//archive/
mapreduce-osdi04.pdf

BSPの計算モデル
 BSPコンピュータは、コミュニケーション・
ネットワークで結合された複数のプロセッサ
から構成される。
 それぞれのプロセッサは、高速のローカル・
メモリーをもち、それぞれ異なる計算スレッ
ドを走らせる事がある。
 BSP計算は、一連のグローバルなスーパース
テップを繰り返し実行する。

BSPの計算モデル
全体の流れ
入力

スーパーステップ
(一連の繰り返し)

出力

http://en.wikipedia.org/wiki/Bulk_synchronous_parallel

スーパーステップを構成するもの
 BSPのスーパーステップは、以下の三つ
の要素から構成される
1. 並行計算
2. コミュニケーション
3. バリア同期

一つのスーパーステップの構造
複数のプロセッサー

ローカルな計算

ノード間の
コミュニケーション
バリア同期
http://en.wikipedia.org/wiki/Bulk_synchronous_parallel

スーパーステップの構成要素
並行計算
 いくつかの計算は、参加している全てのプロ
セッサで並行に実行される。
 それぞれのプロセスは、プロセッサのローカ
ル・メモリーに格納された値のみを使う。
 この計算は、それが他の全ての計算とは非同
期であるという意味で、独立である。

 スーパーステップの中で、プロセスは、ノー
ド間でデータを交換する。
 この交換は、双方向のsend, receiveではな
く、一方向のput, getである。
 コミュニケーションは、メッセージ・パッシ
ングで行われる。

バリア同期
 プロセスはこの地点（バリア）に到達すると
、他の全てのプロセスがコミュニケーション
動作を終了するまで待つ。
 計算とコミュニケーションの動作は、各プロ
セッサ毎に独立に行われるので、時間が合っ
ている必要はない。
 バリア同期がスーパーステップを締めくくる
。

Pregelの計算モデル
Pregelの計算モデルは、BSPモデルである
。
基本的には、グラフの頂点が、一つの計算
ノードに対応していると考えるといい。
グラフの計算は、主要に、頂点上で行われ
る。

MapReduceでの
アルゴリズムとの違い
グラフ・アルゴリズムは、一連のMapReduceの
連続的な呼び出しとしても記述出来る
 MapReduce
 一つのステージから次のステージに、グラ
フ全体の状態を渡す
 MapReduceの連鎖のステップでは協調が
必要となる
 Pregel
 計算を行うマシン上に、頂点と辺を保持す
る
 ネットワーク転送はメッセージのみ

「頂点」上での計算
1. 直前のスーパーステップで送られたメッセージを
受け取る
2. ユーザーが定義した同一の関数を実行する
3. 自分の値、あるいは、外向けの辺の値を変更する
4. 他の頂点にメッセージを送る（次のスーパーステ
ップで受け取られる）
5. グラフのトポロジーを変化させる
6. 他に仕事がなければ、停止の投票をする

「頂点」の状態遷移と終了条件
State 頂点の状態マシン
machine for a vertex
停止の投票

メッセージの受け取り

スーパーステップの終了条件
 全ての頂点が同時にInactiveになった時
 メッセージが無くなった時

Pregelの計算サンプル
最小経路を見つける
ここでは、ある始点から、全てのノードへ
の最小経路を見つける「単一始点最小経路
SSSP （Single Source Shortest Path）
」を求める問題を、BSPに基づくPregelが
、どのように解くのかを見てみよう。
http://zhenxiao.com/read/Pregel.ppt

グラフ処理の流れグラフ情報入力
スーパーステップ
１

並行計算
バリア同期

スーパーステップ2

並行計算
バリア同期

並行計算
バリア同期


並行計算
バリア同期


結果出力

単一始点最小経路実行サンプル
スーパーステップ： 0
D

B

1

10

A

2

0

9

3

5

4

6

7

C

2

E

次のようなグラフが
あったとしよう。
辺の数字は、ノード
間の距離、ノードの
数字は、最終的に
は始点からの最小
の距離が入る。
始点には0を、各ノ
ードには、無限大を
入れておく。

スーパーステップ： 1 並行計算
・全てのノードを
Activeにする

D

B

1

・並行計算1

10

A

2

0

9

3

5

4

6

7

C

送られたメッセージ
で最小なものをm
とする。このステップ
では、メッセージは
ない。A以外は、
m=無限大として処理

・並行計算1

2

E

mと自分の値をくら
べて小さな方を自
分の値とする。変化なし

スーパーステップ： 1 コミュニケー
ション
D

B

・コミュニケーション

1

10
10

A

2

0

9

3

5

4

6

7
5

C

2

E

自分の値と外向き
の辺の数字を足し
て、隣りの頂点にメ
ッセージを送る

スーパーステップ： 1 バリア同期
D

B

・バリア同期1

1

10
10

A

2

0

9

3

5

4

6

7
5

C

2

E

メッセージを受け取
ったノードだけを
Activeにする
A, B, C, D, E

D

B

・並行計算2

1

10

とする

10

A

2

0

9

3

5

4

6

7
5

C

2

E

無限大＋nも無限大
である。

D

B 10
10

・並行計算2

1

分の値に変更する

10

A

2

0

9

3

5

4

6

7
5

C

5

2

E

変更出来なければ
スキップして
Inactiveに

ション
D

B

8

10

A

2

0

5

11

1

10

14
9

3

12

C

4

6

7
5


7
2

E

自分の値を変更し
たノードは、自分の
値と外向きの辺の
数字を足して、隣り
の頂点にメッセージ
を送る

D

B

8

10

A

2

0

5

11

1

10

14
9

3

12

C

4

6

7
5

・バリア同期2

7
2

E

Activeにする
B, C, D, E

D

B

8

10

A

2

0

5

11

1

10

とする

14
9

3

12

C

4

6

7
5

・並行計算3

7
2

E

D

B

1

8

・並行計算3

11


10

A

2

0

9

3

5

4

6

7

C

5

2

7

E

スキップして
Inactiveに

ション
D

B

11

9

1

8


たノードは。自分の
を送る

10

A

0

13

14

5

2

9

3

10

C

4

7
5

2

6

15
7

E

D

B

9

1

8

11

10

A

0

13

14

5

・バリア同期3

2

9

3

10

C

4

7
5

2

6

15
7

E

Activeにする
A, C, D, E

D

B

9

1

8

11

10

A

0

13

14

5

・並行計算4

2

9

3

10

C

4

7
5

2

6

15
7

E

とする

D

B

1

8

・並行計算4

9


10

A

2

0

9

3

5

4

6

7

C

5

2

7

E

スキップして
Inactiveに

ション
D

B

9

1

8


たノードは。自分の
を送る

10

A

2

0

9

3

5

4

7

C

5

2

6

13
7

E

D

B

1

8

・バリア同期4

9

10

A

2

0

9

3

5

4

7

C

5

2

6

13
7

E

Activeにする
E

D

B

1

8

・並行計算5

9

とする

10

A

2

0

9

3

5

4

7

C

5

2

6

13
7

E

D

B

1

8

・並行計算5

9


10

A

2

0

9

3

5

4

7

C

5

2

6

13
7

E

スキップして
Inactiveに

・バリア同期
全てのノードが
inactiveになった
ので、スーパース
テップは終了する

D

8

B

1

9

10

A

2

0

9

3

5

4

6

7

C

5

2

7
E

・これで、始点から
の最小経路が求ま
った
B: 8
C: 5
D: 9
E: 7

Pregelでプログラムを書く API
 定義されている Vertex classを継承する

Compute関数を書き換える
受け取った
メッセージ
変更された
達
Modify vertex
頂点の値送り出す
value
out msg
メッセージ

先のサンプルのPregelプログラム

並行計算
並行計算


バリア同期

Pregel
システム・アーキテクチャー

Pregelの
システム・アーキテクチャー
Pregelのシステムも、 master/workerモデル
 Master
 workerを協調動作させる
 workerの失敗を回復する

 Worker
 タスクを処理する
 他のworkerと通信する

 永続するデータは、GFSあるいはBigTableと
いったシステムの分散ストレージを使う
 一時的なデータは、ローカル・ディスクに格
納する

Pregelの実行グラフの分割
1. プログラムの多くのコピーが、マシンのク
ラスター上で実行を始める
2. Masterはグラフを分割し、一つあるいは
それ以上の分割グラフをそれぞれの
workerに割り当てる
worker 2

worker 1

Master

グラフ分割
worker 3

Pregelの実行
頂点への入力データの割り当て
3. Masterは、それぞれのworkerに、分割さ
れた入力情報を割り当てる
 workerは、頂点をロードし、activeのマーク
をつける
worker 2

worker 1

Master

入力データ
の

worker 3

Pregelの実行
スーパーステップの実行
4. Masterは、それぞれのworkerにスーパー
ステップを実行するように指示する
 それぞれのworkerは、activeな頂点を全てループ
して、それぞれの頂点で計算を実行させる
 メッセージは非同期に飛ばされるが、スーパーステ
ップの終わりまでには、配送されねばならない
 このステップは、一つでもactiveな頂点がある限り
、あるいは、一つでも転送中のメッセージがある限
り繰り返される

5. 計算終了後、Masterはそれぞれのworker
にグラフを保存するように指示する事があ
る

Pregelの実行
値の集約

ロードと保存

Master

障害同期

メッセージのcombine

http://java.dzone.com/news/google-pregel-graph-processing

Pregelの実行 Workerの構造

 Worker
 Partition
 Node Structure
の三層構造
http://java.dzone.com/news/google-pregel-graph-processing

Pregelの実行 Partitionの処理
処理モデル
 全てのactiveなノードは実行される
 全ての処理は、以下の場合に終了する
 activeノードがなくなった時
 メッセージがなくなった時

スーパーステップの実行
1. Inboxからメッセージを受け取る
2. 頂点と辺の属性を変更する
3. 新しいメッセージがあるまで停止
4. 他の頂点にメッセージを送る。メッセージ受け取った
頂点はactiveになる
5. 辺を消去、あるいは追加する（Topologyの変更）

Combiner
 Workerは、頂点から報告された複数のメッセージを
結合して、一つのメッセージとして送出する事が出来
る
 メッセージのトラフィックとディスクスペースを削減
出来る

http://web.engr.illinois.edu/~pzhao4/

Combiner in SSSP
class MinIntCombiner : public Combiner<int> {
virtual void Combine(MessageIterator* msgs) {
int mindist = INF;
for (; !msgs->Done(); msgs->Next())
mindist = min(mindist, msgs->Value());
Output("combined_source", mindist);
}
};

Aggregator
Aggregatorは、グローバルなコミュニケーショ
ン、グローバルなデータ、モニタリングに使用
される。
 頂点が報告する統計値を集約し計算する
 スーパーステップの間、workerはそれぞれの頂点か
らの値を集約して、部分的な集約値作る
 スーパーステップの最後には、それぞれのworkerか
らの部分的な集約値は木構造に集約される
 木構造は、並列計算が可能である
 グローバルな集約値は、Masterに送られる

Aggregator
Master

Aggregator

Worker
Partition
Node Structure

http://web.engr.illinois.edu/~pzhao4/

Topologyの変更
 アプリケーションのクラスタリングに必要と
なる
 クラスターは、単一の計算ノードに縮約出来
る
 最小スパニングツリー・アルゴリズムでは、
辺は削除可能である
 頂点や辺の追加要求は可能である

Topologyの変更
変更の順番:
 削除は追加の前に行われる
 辺の削除は、頂点の削除の前に行われる
 頂点の追加は、辺の追加の前に行われる

その他の条件の衝突は、ユーザが定義する
ハンドラで解決されねばならない

Fault Tolerance
チェックポイントの実行
 Masterはworkerに対して、定期的に、
workerのpartition達の状態（頂点の値、辺
の値、受け取ったメッセージ等）を、永続的
なストレージに書き出すように指示する

Failure detection
 通常の ―ping‖ メッセージを使う

Fault Tolerance
 Recovery
 Masterは、グラフの分割を、その時点で利用
可能なworkerに再割り当てする
 全てのworkerは、最新の利用可能なチェック
ポイントから、partitionの状態をリロードす
る

 狭義のRecovery
 送出されたメッセージのログをとる
 Recoveryが必要なpartitionだけを対象とする

 いったんメッセージが送出されていれば、
システムはpartitionの状態を復元出来る。
その他のpartitionを実行する必要はない

アプリケーションの例
PageRank

PageRank


ドキュメントの重要度を、参照の数とソ
ースのドキュメント自身の重要性に基づ
いて決定するのに用いられる

A = A 与えられたページ
T1 …. Tn = ページAを参照しているページ（引用）
d = 0と1の間の（通常は0.85）因子
C(T) = Tが引用しているページの数
PR(A) = ページAのPageRank

PR ( A)

PR (T1 )
(1 d ) d (
C (T1 )

PR (T2 )
........
C (T2 )

PR (Tn )
)
C (Tn )

PageRankのアルゴリズム
// 収束するまでループを繰り返す
// 全てのページのPageRankの初期値は、1.0である
While ( sum of PageRank of all pages – numPages > epsilon)
{
for each Page Pi in list {
PageRank(Pi) = (1-d);
for each page Pj linking to page Pi {
PageRank(Pi) += d ×
(PageRank(Pj)/numOutLinks(Pj));
}
}
}

PageRank in Pregel
// Superstep 0: Value of each vertex is 1/NumVertices()
virtual void Compute(MessageIterator* msgs) {
if (superstep() >= 1) {
double sum = 0;
for (; !msgs->done(); msgs->Next())
sum += msgs->Value();
*MutableValue() = 0.15 + 0.85 * sum;
}
if (supersteps() < 30) {
const int64 n = GetOutEdgeIterator().size();
SendMessageToAllNeighbors(GetValue() / n);
} else {
VoteToHalt();
}
}

アプリケーションの例
2部グラフのマッチング

2部グラフマッチング
L

R

L

R

http://www.geeksforgeeks.org/maximum-bipartite-matching/

 Input : 頂点の集合が二つの部分に分離して
いて、辺はこの二つの集合の間を結ぶものだ
けからなるグラフ
 Output : 共通の頂点を含まない辺の集合
 Pregelの実装 :
 randomized maximal matching algorithm

 頂点の値は、次の二つの値のペア
 頂点がどちらの集合に属するかのフラグ（Lか
R）
 マッチする頂点の名前

アルゴリズム
 Phase 1: まだマッチしていない左の頂点は、その近傍の
全ての頂点にマッチングのリクエストのメッセージを送る
。そして、停止する。
 Phase 2: まだマッチしていない右のノードは、受け取っ
たメッセージからランダムに一つのメッセージを選び、マ
ッチングのリクエストを許諾するというメッセージを送る
。その他のリクエストには、許諾しないというメッセージ
を送り、停止する。
 Phase 3: まだマッチしていない左の頂点は、受け取った
許可のメッセージの一つを選び、受け入れるというメッセ
ージを送る。
 Phase 4: マッチしていない右の頂点は、多くて一つの受
け入れのメッセージを受け取っている。マッチングが成立

アルゴリズム

リクエスト

許諾

受け入れ

マ

Pregelコード Phase 1
Class BipartiteMatchingVertex
: public Vertex<tuple<position, int>, void,
boolean> {
public:
virtual void Compute(MessageIterator* msgs)
{
switch (superstep() % 4) {
case 0: if (GetValue().first == ‘L’) {
SendMessageToAllNeighbors(1);
VoteToHalt();
}

case 1: if (GetValue().first == ‘R’) {
Rand myRand = new Rand(Time());
for ( ; !msgs->Done(); msgs->Next()){
if (myRand.nextBoolean()) {
SendMessageTo(msgs->Source, 1);
break;
}
}
VoteToHalt();
}

case 2: if (GetValue().first == ‘L’) {
Rand myRand = new Rand(Time());
for ( ; !msgs->Done(); msgs->Next) {
if (myRand.nextBoolean()) {
*MutableValue().second = msgs->Source());
SendMessageTo(msgs->Source(), 1);
break;
}
}
VoteToHalt();
}

case 3: if (GetValue().first == ‘R’) {
msgs->Next();
*MutableValue().second = msgs->Source();
}
VoteToHalt();
}
}};

Experiments

10億の頂点を持つ二分木の処理
workerのタスク数を変えた場合

Experiments

二分木の処理
800のworkerでグラフのサイズを変えた場合

Experiments

log-normal random graphs, mean out-degree 127.1 (thus over
127 billion edges in the largest case): varying graph sizes on
800 worker tasks

結論
 ―頂点のように考える‖ 計算モデル
 Master – 単一障害点かも？
 Combiner, Aggregator, topologyの変更
は、もっと多くのアルゴリズムをPregelに
移植する事を可能にする

参考文献
[1] Andrew Lumsdaine, Douglas Gregor, Bruce Hendrickson,
and Jonathan W. Berry, Challenges in Parallel Graph
Processing. Parallel Processing Letters 17, 2007, 5-20.
[2] Kameshwar Munagala and Abhiram Ranade, I/Ocomplexity of graph algorithms. in Proc. 10th Annual
ACM-SIAM Symp. on Discrete Algorithms, 1999, 687694.
[3] Grzegorz Malewicz , Matthew H. Austern , Aart J.C Bik ,
James C. Dehnert , Ilan Horn , Naty Leiser , Grzegorz
Czajkowski, Pregel: a system for large-scale graph
processing, Proceedings of the 2010 international
conference on Management of data, 2010
[4] Leslie G. Valiant, A Bridging Model for Parallel
Computation. Comm. ACM 33(8), 1990, 103-111.

Apache Giraph

http://giraph.apache.org/

Apache Giraph
 Apache Giraphは、高度なスケーラビリティ
の為に構築された反復グラフ処理のシステムで
ある。例えば、それはFacebookで、ユーザー
とその関係によって形成されるソーシャル・グ
ラフの解析の為に現在利用されている。
Giraphは、Googleで開発され2010年の論文
で記述されたグラフ処理のアーキテクチャーで
あるPregelに対するオープンソース版として始
まった。両方のシステムは、Leslie Valiantに
よって導入された分散コンピューティングの
BSPモデル（Bulk Synchronous Parallel
Model)にインスパイアされたものである。

Apache Giraph
 Giraphは、基本的なPregelモデルを超えて、
幾つかの特徴を付け加えた。それには、
master computation, sharded
aggregators, edge-oriented input, outof-core computation等々が含まれている。
しっかりした開発サイクルと世界中のユーザ
ーの成長するコミュニティとともに、Giraph
は、巨大なスケールでの構造化されたデータ
セットのポテンシャルを解き放すための自然
な選択になっている。

Hadoop Summit 2011 8月

Giraph: Large-scale
graph processing
infrastructure on
Hadoop
Avery Ching, Facebook
Christian Kunz, Jybe
10/14/2011
@Hortonworks, Sunnyvale, CA

http://www.slideshare.net/averyching/20110628giraph-hadoop-summit
http://www.youtube.com/watch?v=l4nQjAG6fac

Facebook： Scaling Apache
Giraph to a trillion edges
2013年8月15日 Avery Ching
Northern Western University
https://www.facebook.com/notes/facebookengineering/scaling-apache-giraph-to-atrillion-edges/10151617006153920

September 10, 2013

Scaling Apache Giraph
Nitay Joffe, Data Infrastructure Engineer
nitay@apache.org
@nitayj
http://www.slideshare.net/nitayj/
20130910-giraph-at-london-hadoop-users-group

Agenda
1

Background

2

Scaling

3

Results

4

Questions

Giraphとは何か?
• GoogleのPregelに基づいたApacheオープンソースのグラフ計算エ
ンジン
• Hadoop, Hive, HBase, Accumuloのサポートがある
• 単純な think like a vertex APIを持ったBSPモデル.
• Combiners, Aggregators, Mutabilityその他をサポート.
• 設定可能 Graph<I,V,E,M>:





I: 頂点のID
V: 頂点の値
E: 辺の値
M: メッセージデータ

BSPモデル

implements
Writable

プロセッサー
ローカルな
並列計算

Giraphは何でないのか?
• Neo4jのようなグラフデータベースではない
• 完全に非同期なMPIシステムではない
バリア
• 遅いツールではない.
同期

なぜHiveでないのか?
• あまりに多くのディスクを必要とし、メモリー・キャッ
シュにも制限がある
• それぞれの繰り返しが、MapReduceのジョブになる
Input
format

Map
tasks

Intermediate Reduce
files
tasks

Output
format

Input 0

Output
0

Input 1

Output
1

繰り返し！

Giraphのコンポーネント
 Master – アプリケーションの調整者
 スーパーステップの同期
 スーパーステップが始まる前に
workerに分割グラフを割り当てる

 Workers – 計算とメッセージング
 Handle I/O – グラフの読み書き
 割り当てられた部分グラフの計算
とメッセージング

 ZooKeeper
 グローバルなアプリケーションの状態を維持する

Giraphのデータの流れ
2

3

グラフのロード

計算と繰り返し

グラフの格納

Split 4

Load /
Send
Graph

Part 1
Part 2
Part 3

Comput
e / Send
Messag
es

Split

Send stats / iterate!

Worker
0

Comput
e / Send
Messag
es

Output
format
Part 0
Part 0
Part 1
Part 1
Part 2
Worker
1

Split 3

Part 0

Worker 1

Load /
Send
Graph

Split 2
Worker 1

Master

Split 1

In-memory
graph

Master

Split 0

Worker 0

Input format

Worker 0

1

Part 2
Part 3
Part 3

Giraph Job Lifetime
Input
Compute
Superstep

All Vertices
Halted?

Yes
Output

No
Master
halted?

Vertex Lifecycle
Vote to Halt

Yes

No
Active

Inactive

Received Message

単純なサンプル – 頂点の最大値を見つける
Processor 1

5

5

5

5

Processor 2

1

1
5

5

5

2

2

2
5

5

Time

連結要素
コミュニティを見つける

PageRank – ranking websites
• Send neighbors an equal fraction of your
page rank
• New page rank = 0.15 / (# of vertices) +
0.85 * (messages sum)
Mahout (Hadoop)
854 lines

Giraph
< 30 lines

Worker Crash
 Workerが一つでも失敗すると、スーパーステップの
失敗を引き起こす
 アプリケーションは、最後にコミットされたスーパー
ステップの状態に自動的に巻き戻される
 Masterは、どのスーパーステップの間でも、
ZooKeeperの―health‖ znodeで失敗を検出する
 Masterは、最後にコミットされたスーパーステップ
を選ぶと、ZooKeeperを通じて全てのWorkerぶコマ
ンドを送り、そのスーパーステップを再開する

Problem: Worker Crash.
Solution: Checkpointing.
Superstep i
(no checkpoint)

Superstep i+1
(checkpoint)

Superstep i+2
(no checkpoint)

Worker failure!

Superstep i+1
(checkpoint)

Superstep i+2
(no checkpoint)

Superstep i+3
(checkpoint)

Worker failure after
checkpoint complete!
Superstep i+3
(no checkpoint)

…

Application
Complete

Master Crash
 一つのアクティブなMasterは、代替のmasterを持っ
ており、アクティブなMasterが失敗したらそれに代わ
る
 アクティブなMasterの状態は、ZooKeeperに格納され
ているので、代替のMasterは、アクティブMasterが
失敗したステップからただちに処理を再開出来る。
 “アクティブ” Masterは、ZooKeeper内のキューとして
実装されている

Problem: Master Crash.

Solution: ZooKeeper Master Queue.

Before failure of active master 0
“Active”
Master 0

“Spare”
Master 1
“Spare”
Master 2

After failure of active master 0
“Active”
Master 0

Active
Master
State

ZooKeeper

“Active”
Master 1
“Spare”
Master 2

Active
Master
State

ZooKeeper

Problem: Primitive Collections.
• グラフは、よく {
タを持つ
• 型変換は、高価な処理である
Single Source
Shortest Path

0.5

1.7

3

0.7

5

2

0.8

s

Count In-Degree

1.2

0.4

4

0.8

1

Network Flow

1.2

0.4 2

}といったパラメー

0.5

0.2
0.7

t

4

1

3

5

Solution: Use fastutil, e.g. Long2DoubleOpenHashMap.
fastutilは、JavaのCollections Frameworkを、型に固有の
maps, sets, lists, queuesを追加して拡張したもので、小さ
なメモリーで高速なアクセス・挿入を可能とする

Problem: あまりにオブジェクトが多い
多くの時間がGCに費やされる
Graph: 10億頂点, 2000 億辺, 200 Worker
• Workerあたり10億辺辺の値に1オブジェクト
• List<Edge<I, E>>  ~ 100億オブジェクト

• Workerあたり500万頂点頂点の値に10オブジェクト
• Map<I, Vertex<I, V, E>  ~ 5000万オブジェクト
• 辺あたり1メッセージメッセージあたり10オブジェクト
• Map<I, List<M>>  ~ 100億オブジェクト
• Objects used ~= O(E*e + V*v + M*m) => O(E*e)

Problem:あまりにオブジェクトが多い
多くの時間がGCに費やされる

Solution: byte[]
• メッセージ、辺、頂点を、byte[]にシリアライズ化する
• 代表されたオブジェクトを持つ、繰り返しのインター
フェース
Input Input

Input

next()

Objects per worker ~= O(V)

next()

next()

Problem: byte[]のシリアライズ化
• DataInput? Kyro? Custom?

Solution: Unsafe
• Dangerous. No formal API. Volatile. Non-portable (oracle JVM only).

• AWESOME. As fast as it gets.
• True native. Essentially C: *(long*)(data+offset);

K-Means Clustering

Problem: Large Aggregations.

e.g. Similar Emails

Master

Worker

Worker
Worker
Worker

Worker

Solution: Sharded Aggregators.
Aggregator owners
Workers own aggregators
communicate
with Master

Aggregator owners
distribute values

Mas
ter

Mas
ter

Mas
ter
Wor
ker
Wor
ker

Wor
ker

Wor
ker
Wor
ker

Wor
ker

Wor
ker
Wor
ker

Wor
ker

Wor
ker

Wor
ker
Wor
ker

Wor
ker

Wor
ker
Wor
ker

End compute

Problem: ネットワーク Wait.Barrier
• RPC はモデルに合わない
• 同期型の呼び出しは良くない

Barrier
wait

compute
network

Begin superstep
End superstep

End compute
Barrier

Solution: Netty
queueサイズとスレッドを調整する

Barrier
compute

wait

network

Time to first message
Begin superstep End superstep

Scalability Graphs
Increasing Workers

Increasing Data Size
50 Workers, 20
Compute Threads
450

Iteration Time (sec)

Iteration Time (sec)

2B Vertices, 200B
Edges, 20 Compute
Threads
450
400
350
300
250
200
150
100
50
0

400
350
300
250
200
150
100
50

0
50

150

Workers

250

1E+09

Edges

Lessons Learned
 調整は動物園のようなもの。
ZooKeeper で耐障害性確保
 効率的なネットワークは難しい。
Nettyの助け.
 プリミティブなCollection, プリミティブ
パフォーマンスには fastutil.を使う
 byte[]は単純だが強力である
 Unsafe なのはいい事でもありうる

グラフがあるなら、Giraphを使おう

最終結果は？
Hiveとの比較
• 20x CPU の高速化
• 100x Elapsed time は、15時間 => 9分に

Facebook全体のグラフデータの処理は、もはや
「週末の処理」ではない。
いまでは、コーヒー・ブレークの仕事だ。

Trinity: A Distributed Graph
Engine on a Memory Cloud
2013年6月26日
ACM SIGMOD 2013
/Trinity.pdf

Abstract
 グラフ・アルゴリズムで実行される計算は、
データ・ドリブンで、高度なランダム・デー
タ・アクセスが要求される。ディスク技術の
大きな進歩にもかかわらず、それは、グラフ
計算に必要な効率的なランダム・アクセスの
レベルを与える事がいまだ出来ていない。一
方で、メモリー・ベースのアプローチは、一
台のマシンのメモリー容量の制限によって、
通常はスケールしない。この論文では、分散
メモリー・クラウド上の汎用のグラフエンジ
ンTrinityを紹介する。

Abstract
 最適化されたメモリー管理とネットワーク・
コミュニケーションによって、Trinityは、高
速のグラフ探索と効率的なパラレル計算をサ
ポートする。特に、Trinityは、オンライン、
オフライン双方の計算において、最良のパフ
ォーマンスを目指してメモリーとコミュニケ
ーションの最適化を行うように、グラフのア
クセス・パターンを活用する。このことで、
Trinityは尐数のコモディティ化したマシンで
も、効率的なオンラインの検索処理と、オフ
ラインでの大きなグラフの解析をサポートす
る事が出来る。

Abstract
 さらに、Trinityは、ユーザーがデータのスキ
ームと通信のプロトコルを宣言するTSLと呼
ばれる高度な仕様言語を提供している。これ
によって、一般的な目的でのグラフの管理と
計算は、非常に使いやすいものになる。我々
の実験では、低遅延のグラフの検索において
も、数十億ノードのWebスケールのグラフの
高速解析においても、Trinityはパフォーマン
スを示した。

Graph query and analytics
with Trinity
Haixun Wang
Microsoft Research Asia
http://www.cse.unsw.edu.au/~iwgd
m/2013/Slides/Haixun.pdf

Trinity
 分散インメモリーkey/valueストア
 オンライン検索処理グラフ・データベース
 Facebook上で3 hopの範囲の220万のユーザー検
索を 100ms以下の時間で
 entity検索等のグラフベース・サービスの基礎

 オフライングラフ解析パラレル・プラットオ
フォーム
 10億ノードのグラフ処理を60秒で
 グラフ解析の基礎

多様なグラフ操作
 オンライン検索処理





最短経路探索
部分グラフのマッチング
RDF用クエリ言語SPARQLでの検索
....

 オフライングラフ解析
 PageRank
 コミュニティの検出
 ....

 その他の処理
 グラフの生成、可視化等

グラフ処理のデータアクセスの特徴
 ランダムアクセス。局所性がほとんどない。
 ノードにとってみれば、隣りのノードの内
容は、グラフをどのように表現したとして
も、そのノードに「ジャンプ」するしかア
クセス出来ない
 データ・ドリブンでデータ中心
 計算は、グラフの構造によって命令される
。データの再利用は難しい。

クラスターとメモリーの費用
現在
1,000
サーバーの数
サーバーのメモリー容量 64GB
64TB
全体のメモリー容量
全体のサーバー・コスト $4M
$60
GBあたりのコスト

5-10年後
1,000
1TB
1PB
$4M
$4

単一マシン
の
RAM容量の
制限

ランダム
アクセス
への挑戦
Memory
Cloud
高速な
グラフ処理

低遅延
オンライン処理

パラレル
計算

高速
オフライン解析

辺の数

グラフの規模
Web
Facebook

アメリカの道路地図

ノードの数

どれだけのマシンが必要か？
 Facebook
 8億人のユーザ、1ユーザあたり130人の友達
がいるとして
 30 Trinity マシン

 Web
 250億ページ、1ページあたり40のリンクがあ
るとして
 150 Trinity マシン

Memory Cloudとメモリーtrunk
 Memory Cloudは、2p個のメモリーtrunkか
ら構成される。それぞれのマシンは、複数の
メモリーtrunkをホストする。
 一つのマシン上のローカル・メモリーを複数
のtrunkに分割するのは、次の二つの理由に
よる。
1. trunkレベルのパラレル計算は、ロックのオ
ーバーヘッドなしに実行出来る。
2. 一つの巨大なハッシュテーブルのパフォーマ
ンスは、ハッシュの衝突の故に最適ではない
。

Key/Value ストア
 Memory Cloud上に、Key/Value ストアを
構築する。
 Keyは、グローバルにユニークな64bitの識別
子、Valueは、任意長のblobである。
 Memory Cloudは、複数のマシン上に分散し
ているので、Key/Valueペアの位置を、マシ
ン上の物理アドレスでは指定出来ない。
 Trinityは、Key/Valueペアの位置を指定する
のに、ハッシュのメカニズムを利用する

ハッシュ・メカニズム
 まず、Key/Valueペアを格納しているマシン
を特定する。
 ついで、そのマシン上の一つのメモリー
trunk上で、Key/Valueペアの位置を見つけ
る。

マシンの特定
 64bitのglobal unique IDから、2pbitのハッシ
ュコード i を作る。
 Memory Cloudは、2p個のメモリーtrunkから
なるので、これで Key/Valueペアは、Memory
Cloud中の trunk i に格納されている事が分か
る。
 trunk i がどのマシン上にあるかを知る為に、
2p個のスロットからなる「アドレシング・テー
ブル」を作成しておく。それぞれのスロットに
は、マシンIDを入れておく。
 i番目のスロットをみれば、マシンが分かる。

一つのメモリーtrunk上で、
Key/Valueペアの位置を見つける
。
 グローバルなアドレッシングが機能する為に
は、それぞれのマシンが、「アドレッシング
・テーブル」のレプリカを保持する必要があ
る。
 それぞれのメモリーtrunkは、グローバルID
とKey/Valueペアの位置を示すoffsetと、そ
のsizeを格納したテーブルを持っている。
 このテーブルで、グローバルIDを引けば、
Key/Valueペアの位置と大きさが分かる。

64bitのユニークID

全てのマシンで
共有される２p個の
スロットを持つ
アドレッシング・
テーブル

p-bitのハッシュコード

二つの
テーブル

メモリー
trunkごと
のテーブル

基本的なデータモデルはCell

基本的なデータモデルはCell
 グラフのノードは、Cellである
 グラフの辺は、必ずしもCellではない
 辺が情報を持たない場合
 辺が簡単な情報を持つ場合（ラベルや重み
といった）
 辺が沢山の情報を持つ場合、独立したCell
を割り当てる

TSL
Trinity Specification Language
 TSLは、Memory Cloudの中のblobデータに
対して、オブジェクト指向のデータ操作を提
供する。
 TSLは、データの統合を容易にする。それは
グラフとRDBMSの中のデータのような外部
データとのインターフェースを定義する。
 TSLはシステムの拡張を容易にする。TSLで
定義されたスキーマと通信プロトコルで、
TSLのコンパイラーは、非常に効率のいいソ
ースを生成する。

Modeling a Movie and Actor Graph
[CellType: NodeCell]
cell struct Movie
{
string Name;
[EdgeType: SimpleEdge, ReferencedCell: Actor]
List<long> Actors;
}
[CellType: NodeCell]
cell struct Actor
{
string Name;
[EdgeType: SimpleEdge, ReferencedCell: Movie]
List<long> Movies;
}

Modeling Message Passing
struct MyMessage
{
string Text;
}
protocol Echo
{
Type: Syn;
Request: MyMessage;
Response: MyMessage;
}

Trinity Query Language

Memory Cloudは
ジョイン操作なしで
関係間の高速な探索
を与える

RDBMSは、追加的なストレージと
アクセス方法と、永続性を提供する

Trinity Query Language
TQL
FROM a in {" Employee.FullName='Nikki Dahi' "}
MATCH a(Employee)-->b(Problem)-->c(Incident)
RETURN a, b, c

SQL

A Distributed Graph Engine
for Web Scale RDF Data
Kai Zeng et al.
VLDB 2013.
83717/Trinity.RDF.pdf

Abstract
 RDFデータをサポートする多くの仕事がなされている
。しかし、最先端のシステムも方法も、今なおWeb
スケールのRDFデータを効率的にハンドル出来ていな
い。さらに、多くの有用な汎用的なグラフ・ベースの
操作（ランダム・ウォーク、到達可能性、コミュニテ
ィの発見といった）は、RDFデータの上ではサポート
されていない。というのも、既存のシステムの大部分
は、RDFデータ上の一つの特殊な操作：SPARQLでの
検索処理の為に、それに最大限の効果を持つように、
特殊なやりからでデータを格納しインデックス付けし
ているからである。この論文では、Webスケールの
RDFデータの分散メモリーベース・グラフエンジンで
あるTrinity.RDFを紹介する。

Abstract
 RDFデータを、三つ組みあるいはビットマップ・マト
リックスとして格納して、RDFデータを管理する代わ
りに、我々は、RDFをネーティブなグラフの形式で
RDFデータを格納する。それは、SPARQL検索におい
て、最先端のアプローチより、はるかにいい（ある場
合には、何十倍もいい）パフォーマンスを達成する。
さらに、データが、ネーティブなグラフの形式で格納
されているので、ランダム・ウォークや到達可能性と
いった別の操作も、RDFのグラフ上でサポート出来る
。我々は、実生活のWebスケールのRDFデータ上で
、我々のアプローチの有効性を示す為に、広い範囲の
実験を行う。

Trinity 参考文献
 Bin Shao, Haixun Wang, and Yatao Li, Trinity:
A Distributed Graph Engine on a Memory
Cloud, SIGMOD 2013.
 Wanyun Cui, Yanghua Xiao, Haixun Wang, Ji
Hong, and Wei Wang, Local Search of
Communities in Large Graphs, SIGMOD 2013
 Kai Zeng, Jiacheng Yang, Haixun Wang, Bin
Shao, and Zhongyuan Wang, A Distributed
Graph Engine for Web Scale RDF Data, VLDB
2013.
 Zhao Sun, Hongzhi Wang, Bin Shao, Haixun
Wang, and Jianzhong Li, Efficient Subgraph
Matching on Billion Node Graphs, VLDB 2012.

 Bin Shao, Haixun Wang, and Yanghua Xiao,
Managing and Mining Large Graphs: Systems
and implementations (tutorial), SIGMOD 2012.
 Lijun Chang, Jeffrey Yu, Lu Qin, Yuanyuan Zhu,
and Haixun Wang, Finding Information Nebula
over Large Networks, in ACM CIKM, October
2011.
 Ruoming Jin, Lin Liu, Bolin Ding, and Haixun
Wang, Reachability Computation in Uncertain
Graphs, in VLDB, September 2011.
 Ye Yuan, Guoren Wang, Haixun Wang, and Lei
Chen, Efficient Subgraph Search over Large
Uncertain Graphs, in VLDB, September 2011.

 Ruoming Jin, Yang Xiang, Ruan Ning, and
Haixun Wang, Path-Tree: An Efficient
Reachability Indexing Scheme for Large
Directed Graphs, in ACM Transactions on
Database Systems (TODS), ACM Transactions
on Database Systems (TODS), 2011

Balancing Workload Across
Nodes with Akka 2
Derek Wyatt
http://letitcrash.com/post/29044669
086/balancing-workload-acrossnodes-with-akka-2

Distributed (in-memory)
graph processing with Akka
Adelbert Chang
http://letitcrash.com/post/30257014
291/distributed-in-memory-graphprocessing-with-akka

twitter cassovary
https://github.com/twitter/cassovary

Cassovaryとは？
 Cassovaryは、JVMの為のシンプルな‖ビッグ
・グラフ‖処理ライブラリーである。大部分の
JVM上で走るグラフライブラリーは、柔軟だ
がスペース効率が良くない。Cassovaryは、
最初から数十億の頂点と辺からなるグラフを
効率的にハンドル出来るようにデザインされ
ている。典型的な使用例は、twitterのような
巨大ネットワークの大規模なグラフデータの
マイニングと解析である。Cassovaryは、
Scalaで書かれており、JVMをホストとする
どんな言語上でも、共通のデータ構造とアル
ゴリズムで利用出来る。

他のグラフ・ライブラリーとの比較
既に沢山の優れたグラフ・マイニングのライブラリーが
存在している。それらの多くは、次のような特徴を持っ
ている。
1. C/C++ で書かれている。Stanfordの SNAP やCMU
の GraphLab もこうした例に含まれる。JVMからこ
れらを使う典型的な仕方は、JNIブリッジを使う事で
ある。
2. 柔軟性の為にストレージの効率性を犠牲にしている。
こした例には JUNG が含まれる。それはJavaで書か
れているが、頂点や辺は大きなオブジェクトとして格
納されている。
3. もっと沢山の事をしようとしている。典型的には、
Neo4Jを含む完全なグラフ・データベース達である。

 他方で Cassovary は、JVMの走る環境で使うのが容
易で、それに加えて数十億の辺でも効率的にスケール
することを意図している。Cassovaryは、意図的に
、永続性やデータベースの機能を提供するようには、
デザインされていない。
 また、Cassovaryは、現在、グラフの分割に関心を
持っていない。それ故、Apache Giraphのような分
散グラフ処理システムとは、直接比較出来ない。この
事で、Cassovaryは、グラフ上で複雑なアルゴリズ
ムを効率的に走らせる事が出来る。そうしなければ、
グラフ分割をうまく行う事の、よく知られている困難
によって、分散グラフ処理システムの諸問題を繰り返
す事になる。

 簡単に言えば、そこで動くグラフのサイズは、一つの
マシンで利用可能なメモリーによって制限されている
。しかし、スペース効率の良いデータ構造を利用すれ
ば、ほとんどの実践的なグラフでは、このことは制限
にならないように見える。
 例えば、無方向グラフのArrayBasedDirectedGraph
のインスタンスを使えば、一千万個の頂点と１０億
の辺を持つグラフは、6GB以下のメモリーしか消費し
ないし、それを超えても線形にスケールする。

FlockDB
FlockDBは、Twitterが利用する隣接リス
トを格納する分散グラフデータベースであ
る
https://github.com/twitter/flockdb

FlockDBの特徴
 高速の追加・更新・削除操作
 複雑な数値的な集合検索を行う能力
 数百万のエントリーを含む検索結果に対する
ページング
 辺を‖アーカイブ‖して、あとでリストアする
能力
 レプリカを含めた、水平的なスケーリング
 オンラインでのデータ・マイグレーション

FlockDBの特徴
 FlockDBは、尐数の問題を解決しようとしているので
、neo4jのようなグラフ・データベースより、ずっと
シンプルである。それは水平的にスケールし、Web
サイトのように、オンラインで低遅延な高速実行環境
の為にデザインされた。
 Twitterは、 FlockDBをソーシャル・グラフ（誰が誰
をフィローし、誰が誰をブロックしているかといった
）を格納し、第二のインデックスとして利用してきた
。
 2010の４月には、Twitterの FlockDB クラスターは
、130億の辺を格納し、一秒あたりの書き込み20K、
一秒あたりの読み込み100Kのピーク・トラフィック
を維持した。

It does what?
 もし、例えば、「ユーザーAはユーザーBをフォロー
している」というソーシャル・グラフを格納している
としよう。この関係は「BがAをフォローしていなく
ても、AはBをフォロー出来る」ので、非対称的であ
る。FlockDBは、こうした関係をノードAはノードB
を指しているというように、向きを持った辺として格
納出来る。
 FlockDBは、こうした辺を、ソートの情報と一緒に、
‖誰がAをフォローしているか？‖だけではなく、‖誰を
Aがフォローしているか？‖という質問にも答えられ
るように、両方向の情報としてで格納する。

 これは、有向グラフと呼ばれる（技術的には、
FlockDBは、有向グラフの隣接リストを格納している
）。
 それぞれの辺は、64bitの始点IDと64bitの終点ID、
状態（正常、削除済み、アーカイーフされている等）
、ソートに用いられる32bitの情報を持っている。
 辺は、前向きと後ろ向きの二つの方向で格納されてい
る。こうして辺は、始点IDからも終点IDからも検索
する事が出来る。

 例えば、ノード134がノード90を、ソート・ポジシ
ョン5で指しているとすれば、次のような二つの行が
格納される事になる。
forward: 134 -> 90 at position 5
backward: 90 <- 134 at position 5

 もし、ソーシャル・グラフを格納するのなら、このグ
ラフは「フォロー中」と呼ばれるかもしれない。そし
て、フォロアーのリストが最近のものから表示される
ように、現在の時間をソート・ポジションに入れるだ
ろう。
 もし、ユーザー134がNickで、ユーザー90がRobin
なら、FlockDBは、次の情報を格納する事になる。
forward: Nick follows Robey at 9:54 today
backward: Robey is followed by Nick at 9:54
today

FlockDBで利用されている
フレームワーク

Shards

https://github.com/hibernate/hibernate-shards
 You can't always put all your relational data in
a single relational database. Sometimes you
simply have too much data. Sometimes you
have a distributed deployment architecture
 Hibernate Shards is a framework that is
designed to encapsulate and reduce this
complexity by adding support for horizontal
partitioning on top of Hibernate Core. Simply
put, we aim to provide a unified view of
multiple databases via Hibernate.

Gizzard

https://github.com/twitter/gizzard
 Twitter has built several custom distributed
data-stores. Many of these solutions have a lot
in common, prompting us to extract the
commonalities so that they would be more
easily maintainable and reusable. Thus, we
have extracted Gizzard, a Scala framework
that makes it easy to create custom faulttolerant, distributed databases.

Thrift

https://github.com/apache/thrift
 Thrift is a lightweight, language-independent
software stack with an associated code
generation mechanism for RPC.
 Thrift provides clean abstractions for data
transport, data serialization, and application
level processing.
 The code generation system takes a simple
definition language as its input and generates
code across programming languages that uses
the abstracted stack to build interoperable RPC
clients and servers.

Gizzardは、もう使われていない

 (始点, 終点) は、ユニークでなければならない。すな
わち、ノードAからノードBを指す辺は、一つだけで
ある。しかし、ポジションや状態は、いつでも変更さ
れうる。
 ポジションは、検索結果のソーティングにのみ用いら
れる。状態は、その辺が削除されたらアーカイブされ
たかをマークするのに利用される。

大規模グラフデータ処理

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a 大規模グラフデータ処理

Similar a 大規模グラフデータ処理 (20)

Más de maruyama097

Más de maruyama097 (20)

大規模グラフデータ処理

Notas del editor