大規模グラフデータ処理
TRANSCRIPT
大規模グラフデータ処理
@maruyama097丸山不二夫
今日のウェブは、さまざまページの間に張られた無構造でランダムなリンクによって成りたっています。 Open Graph( オープンググラフ ) は人々の間の関係を構造化します。
Zuckerberg 2010 年 4 月 f8 コンファレンス
Google の Knowledge Graph は、単にFreebase や Wikipedia 、そして CIA World Factbook といった、パブリックなリソースに基づいているだけではない。それは、もっと巨大なスケールで、拡張されている。なぜなら、我々は、包括的な広さと深さにフォーカスしてきたからだ。
我々は、あなたが聞こうと思いもしなかった質問に答え、あなたの発見をさらに助ける為に、 Knowledge Graph を、利用することが出来る。 Google 2012 年 5 月
はじめに 巨大なクラウドと無数のデバイス達がネット
ワークでつながる世界では、我々がリーチ出来る範囲にも、驚くほど大量の「情報」があふれている。
「 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
様々な対象・様々なグラフ
Google DistBelief
Deep learning
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 Patternhttp://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/0B04ol8GVySUueWQ2dkZUSFFETlk/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/0B04ol8GVySUuUFUtbWcxNFlHY3c/edit?usp=sharing
ただ、大規模なグラフデータから、我々にとって有用な「知識」「意味」を抽出しようという取り組みは、まだ始まったばかりである。
「知識グラフ」と開かれた課題 「知識グラフ」に対する関心は、次のようなよ
り長期的な課題の実現と結びついている。 自然言語を用いたインターフェース 知識とそれをハンドルする能力の機械への移転 生物の多様な認知能力と学習能力の理解 人間の言語能力の理解 学習する機械
楽観的に語るならば、我々は、こうした課題を解決する時代の入り口に、さしかかっているのかもしれない。
Facebook Open Graph
「人々の関係を構造化する」2010 年 4 月 21 日 f8 Conference Keynotehttp://www.livestream.com/f8conference/video?clipId=pla_e7a096b4-3ef9-466d-9a37-d920c31040aa
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/googles-schmidt-social/
Our new search index: Caffeine
検索インデックス付けのリアルタイム化2010 年 6 月 8 日Google Webmaster Central Bloghttp://googlewebmastercentral.blogspot.jp/2010/06/our-new-search-index-caffeine.html
Pregel: A System for Large-Scale Graph Processing
Google の大規模グラフデータ処理エンジン2010 年 6 月 8 日SIGMOD 2010http://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 incubatingRelease
Pregel のオープンソース・クローン2012 年 2 月 6 日https://giraph.apache.org/http://archive.apache.org/dist/incubator/giraph/
Google Knowledge Graph
Google の知識ベース検索サービス2012 年 5 月 16 日 “Introducing the Knowledge Graph: things, not strings”http://googleblog.blogspot.co.uk/2012/05/introducing-knowledge-graph-things-not.html
Google Knowledge Graph新しい検索の三つの特徴 正しい「もの」を見つける。（ 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 Graphhttp://www.google.com/insidesearch/features/search/knowledge.html
Marie Curie の検索
Facebook Graph Search
Facebook の知識ベースの検索サービス2013 年 1 月 15 日“Introducing Graph Search Beta”http://newsroom.fb.com/News/562/Introducing-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/search/archive/2013/03/21/satorii.aspx
Bing Snapshot
Bing では、我々は検索は web のページを指す青いリンク以上のものであるべきだと信じている。我々はまた検索は現実の世界の反映であるべきだと信じている。それが、我々が昨年 6 月に検索結果ページの中央のコラムに答えを一目で見る事の出来る Snapshot という特徴を導入した理由である。この検索結果は、現実世界をよりよく理解し開拓する、豊かな検索である。我々は、まず、映画、レストラン、ホテルから始めた。
Bing Satori
Snapshot のの基礎にある技術は、我々を取り巻く世界を、単に「人、場所、物」といったものの集まりとしてだけではなく、これらのものの関係として、深く理解することを目的にデザインされた。 Bing のエンジニアリング・チームの中では、この技術は、理解を意味する日本語の「悟り (Satori) 」と呼ばれていた。 Satori は、繰り返し成長を続け、検索者にディジタルとフィジカルな世界のより有用なモデルを提供する、数十億のエンティティと関係をカバーするまでになった。
MicrosoftTrinity: A Distributed Graph Engine on a Memory Cloud
MS の新しいアーキテクチャのグラフエンジン2013 年 6 月 26 日ACM SIGMOD 2013http://research.microsoft.com/pubs/183710/Trinity.pdfhttp://research.microsoft.com/apps/pubs/default.aspx?id=183710
Facebook Scaling Apache Giraph to a trillion edges
Facebook の Giraph 拡張の試み2013 年 8 月 15 日 Avery ChingNorthern Western Universityhttps://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/fifteen-years-onand-were-just-getting.html
Google: Moonshot Changes !
検索の現状と未来について2013 年 10 月 23 日Pubcon Las Vegas 2013Keynote Talk With Matt Cuttshttp://www.youtube.com/watch?v=K7JhnWHbwnEhttp://www.bruceclay.com/blog/2013/10/matt-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 Weekhttp://www.businessweek.com/articles/2014-01-30/facebook-turns-10-the-mark-zuckerberg-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 Google Knowledge Graph 2013/01/15 Facebook Search Graph 2013/03/21 Microsoft Satori 2013/06/26 Microsoft Trnity 2013/08/15 Facebook Trillon Edges
Giraph 2013/09/26 Google Hammingbird
Part III
Google Pregel
Pregel: A System for Large-Scale Graph Processing
2010 年 6 月 8 日SIGMOD 2010http://kowshik.github.io/JPregel/pregel_paper.pdf
Pregel: A System for Large-Scale Graph Processing
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.pdf
グラフ処理の他のアプローチ 新しいアルゴリズム全てに対して、分散インフラ環境を構築する
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/handout/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 計算を行うマシン上に、頂点と辺を保持す
る ネットワーク転送はメッセージのみ
Pregel の計算モデル「頂点」上での計算1. 直前のスーパーステップで送られたメッセージ
を受け取る2. ユーザーが定義した同一の関数を実行する3. 自分の値、あるいは、外向けの辺の値を変更す
る4. 他の頂点にメッセージを送る（次のスーパーステップで受け取られる）
5. グラフのトポロジーを変化させる6. 他に仕事がなければ、停止の投票をする
Pregel の計算モデル「頂点」の状態遷移と終了条件
State machine for a vertex
スーパーステップの終了条件 全ての頂点が同時に Inactive になった時
メッセージが無くなった時
頂点の状態マシン
停止の投票
メッセージの受け取り
Pregel の計算サンプル 最小経路を見つける
ここでは、ある始点から、全てのノードへの最小経路を見つける「単一始点最小経路 SSSP （ Single Source Shortest Path）」を求める問題を、 BSP に基づくPregel が、どのように解くのかを見てみよう。
http://zhenxiao.com/read/Pregel.ppt
グラフ情報入力
結果出力
スーパーステップ１
スーパーステップ2スーパーステップ3スーパーステップ4
並行計算コミュニケーションバリア同期
並行計算コミュニケーションバリア同期
並行計算コミュニケーションバリア同期
並行計算コミュニケーションバリア同期
グラフ処理の流れ
単一始点最小経路 実行サンプルスーパーステップ： 0
0
10
5
2 3
2
1
9
7
4 6
次のようなグラフがあったとしよう。辺の数字は、ノード間の距離、ノードの数字は、最終的には始点からの最小の距離が入る。始点には 0 を、各ノードには、無限大を入れておく。
A
B
C
D
E
単一始点最小経路 実行サンプルスーパーステップ： 1 並行計算
0
10
5
2 3
2
1
9
7
4 6
・全てのノードを Active にする
・並行計算 1 送られたメッセージ で最小なものを m とする。このステップ では、メッセージは ない。 A以外は、 m= 無限大として処理・並行計算 1 m と自分の値をくら べて小さな方を自 分の値とする。変化なし
A
B
C
D
E
単一始点最小経路 実行サンプルスーパーステップ： 1 コミュニケーション
0
10
5
2 3
2
1
9
7
4 6
10
5
・コミュニケーション 1
自分の値と外向き の辺の数字を足し て、隣りの頂点にメ ッセージを送るA
B
C
D
E
単一始点最小経路 実行サンプルスーパーステップ： 1 バリア同期
0
10
5
2 3
2
1
9
7
4 6
10
5
・バリア同期 1
メッセージを受け取 ったノードだけを Active にする A, B, C, D, EA
B
C
D
E
単一始点最小経路 実行サンプルスーパーステップ： 2 並行計算
0
10
5
2 3
2
1
9
7
4 6
10
5
A
B
C
D
E
・並行計算 2
送られたメッセージ で最小なものを m とする
無限大＋ n も無限大 である。
単一始点最小経路 実行サンプルスーパーステップ： 2 並行計算
0
10
5
10
5
2 3
2
1
9
7
4 6
10
5
A
B
C
D
E
・並行計算 2
m と自分の値をくら べて小さな方を自 分の値に変更する
変更出来なければ コミュニケーションを スキップして Inactive に
単一始点最小経路 実行サンプルスーパーステップ： 2 コミュニケーション
0
10
5
10
5
2 3
2
1
9
7
4 6
11
7
12
814
A
B
C
D
E
・コミュニケーション 2
自分の値を変更し たノードは、自分の 値と外向きの辺の 数字を足して、隣り の頂点にメッセージ を送る
単一始点最小経路 実行サンプルスーパーステップ： 2 バリア同期
0
10
5
10
5
2 3
2
1
9
7
4 6
11
7
12
814
A
B
C
D
E
・バリア同期 2
メッセージを受け取 ったノードだけを Active にする B, C, D, E
単一始点最小経路 実行サンプルスーパーステップ： 3 並行計算
0
10
5
10
5
2 3
2
1
9
7
4 6
11
7
12
814
A
B
C
D
E
・並行計算 3
送られたメッセージ で最小なものを m とする
単一始点最小経路 実行サンプルスーパーステップ： 3 並行計算
0
8
5
11
7
10
5
2 3
2
1
9
7
4 6A
B
C
D
E
・並行計算 3
m と自分の値をくら べて小さな方を自 分の値に変更する
変更出来なければ コミュニケーションを スキップして Inactive に
単一始点最小経路 実行サンプルスーパーステップ： 3 コミュニケーション
0
8
5
11
7
10
5
2 3
2
1
9
7
4 6
9
14
13
1510
A
B
C
D
E
・コミュニケーション 3
自分の値を変更し たノードは。自分の 値と外向きの辺の 数字を足して、隣り の頂点にメッセージ を送る
単一始点最小経路 実行サンプルスーパーステップ： 3 バリア同期
0
8
5
11
7
10
5
2 3
2
1
9
7
4 6
9
14
13
1510
A
B
C
D
E
・バリア同期 3
メッセージを受け取 ったノードだけを Active にする A, C, D, E
単一始点最小経路 実行サンプルスーパーステップ： 4 並行計算
0
8
5
11
7
10
5
2 3
2
1
9
7
4 6
9
14
13
1510
A
B
C
D
E
・並行計算 4
送られたメッセージ で最小なものを m とする
単一始点最小経路 実行サンプルスーパーステップ： 4 並行計算
0
8
5
9
7
10
5
2 3
2
1
9
7
4 6A
B
C
D
E
・並行計算 4
m と自分の値をくら べて小さな方を自 分の値に変更する
変更出来なければ コミュニケーションを スキップして Inactive に
単一始点最小経路 実行サンプルスーパーステップ： 4 コミュニケーション
0
8
5
9
7
10
5
2 3
2
1
9
7
4 6
13
A
B
C
D
E
・コミュニケーション 4
自分の値を変更し たノードは。自分の 値と外向きの辺の 数字を足して、隣り の頂点にメッセージ を送る
単一始点最小経路 実行サンプルスーパーステップ： 4 バリア同期
0
8
5
9
7
10
5
2 3
2
1
9
7
4 6
13
A
B
C
D
E
・バリア同期 4
メッセージを受け取 ったノードだけを Active にする E
単一始点最小経路 実行サンプルスーパーステップ： 5 並行計算
0
8
5
9
7
10
5
2 3
2
1
9
7
4 6
13
A
B
C
D
E
・並行計算 5
送られたメッセージ で最小なものを m とする
単一始点最小経路 実行サンプルスーパーステップ： 5 並行計算
0
8
5
9
7
10
5
2 3
2
1
9
7
4 6
13
A
B
C
D
E
・並行計算 5
m と自分の値をくら べて小さな方を自 分の値に変更する 変更出来なければ コミュニケーションを スキップして Inactive に
単一始点最小経路 実行サンプルスーパーステップ： 5 バリア同期
0
8
5
9
7
10
5
2 3
2
1
9
7
4 6A
B
C
D
E
・バリア同期 全てのノードが inactive になった ので、スーパース テップは終了する
・これで、始点から の最小経路が求ま った B: 8 C: 5 D: 9 E: 7
Pregel でプログラムを書く API 定義されている Vertex class を継承する
Compute 関数を書き換える
受け取ったメッセージ達
out msg
Modify vertex value
変更された頂点の値 送り出す
メッセージ
先のサンプルの Pregel プログラム
並行計算
並行計算
コミュニケーション
バリア同期
Pregelシステム・アーキテクチャー
Pregel のシステム・アーキテクチャーPregel のシステムも、 master/worker モデル Master
worker を協調動作させる worker の失敗を回復する
Worker タスクを処理する 他の worker と通信する
永続するデータは、 GFS あるいは BigTable といったシステムの分散ストレージを使う
一時的なデータは、ローカル・ディスクに格納する
Pregel の実行 グラフの分割 1. プログラムの多くのコピーが、マシンの
クラスター上で実行を始める2. Master はグラフを分割し、一つあるいは
それ以上の分割グラフをそれぞれのworker に割り当てる
グラフ分割
worker 1 worker 2
worker 3
Master
Pregel の実行頂点への入力データの割り当て 3. Master は、それぞれの worker に、分割
された入力情報を割り当てる worker は、頂点をロードし、 active のマー
クをつける
入力データの割り当て
worker 1 worker 2
worker 3
Master
Pregel の実行スーパーステップの実行4. Master は、それぞれの worker にスーパー
ステップを実行するように指示する それぞれの worker は、 active な頂点を全てルー
プして、それぞれの頂点で計算を実行させる メッセージは非同期に飛ばされるが、スーパーステップの終わりまでには、配送されねばならない
このステップは、一つでも active な頂点がある限り、あるいは、一つでも転送中のメッセージがある限り繰り返される
5.計算終了後、 Master はそれぞれの workerにグラフを保存するように指示する事がある
Pregel の実行
http://java.dzone.com/news/google-pregel-graph-processing
値の集約 障害同期
ロードと保存 メッセージの combine
Master
Pregel の実行 Worker の構造
http://java.dzone.com/news/google-pregel-graph-processing
Worker Partition Node Structure の三層構造
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
http://web.engr.illinois.edu/~pzhao4/
Aggregator
Worker
Partition
Node Structure
Master
Global
Aggregation
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
Courtesy: Wikipedia
PageRank
A = A 与えられたページT1 …. Tn = ページ A を参照しているページ（引用）d = 0 と 1 の間の（通常は 0.85）因子C(T) = T が引用しているページの数PR(A) = ページ A の PageRank
))(
)(........
)(
)(
)(
)(()1()(
2
2
1
1
n
n
TC
TPR
TC
TPR
TC
TPRddAPR
ドキュメントの重要度を、参照の数とソースのドキュメント自身の重要性に基づいて決定するのに用いられる
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部グラフ マッチング
http://www.geeksforgeeks.org/maximum-bipartite-matching/
L R L R
2部グラフ マッチング Input : 頂点の集合が二つの部分に分離して
いて、辺はこの二つの集合の間を結ぶものだけからなるグラフ
Output : 共通の頂点を含まない辺の集合 Pregel の実装 :
randomized maximal matching algorithm
頂点の値は、次の二つの値のペア 頂点がどちらの集合に属するかのフラグ（ L
か R） マッチする頂点の名前
2部グラフ マッチングアルゴリズム
Phase 1: まだマッチしていない左の頂点は、その近傍の全ての頂点にマッチングのリクエストのメッセージを送る。そして、停止する。
Phase 2: まだマッチしていない右のノードは、受け取ったメッセージからランダムに一つのメッセージを選び、マッチングのリクエストを許諾するというメッセージを送る。その他のリクエストには、許諾しないというメッセージを送り、停止する。
Phase 3: まだマッチしていない左の頂点は、受け取った許可のメッセージの一つを選び、受け入れるというメッセージを送る。
Phase 4: マッチしていない右の頂点は、多くて一つの受け入れのメッセージを受け取っている。マッチングが成立して、停止する。
2部グラフ マッチングアルゴリズム
リクエスト 許諾 受け入れ マッチ
2部グラフ マッチング 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(); }
2部グラフ マッチング Pregel コード Phase 2
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(); }
2部グラフ マッチング Pregel コード Phase 3
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(); }
2部グラフ マッチング Pregel コード Phase 4
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/O-complexity of graph algorithms. in Proc. 10th Annual ACM-SIAM Symp. on Discrete Algorithms, 1999, 687-694.
[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.
Part IV
Apache Giraph
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, out-of-core computation等々が含まれている。しっかりした開発サイクルと世界中のユーザーの成長するコミュニティとともに、 Giraph は、巨大なスケールでの構造化されたデータセットのポテンシャルを解き放すための自然な選択になっている。
Giraph: Large-scale graph processing infrastructure on HadoopAvery Ching, FacebookChristian Kunz, Jybe 10/14/2011@Hortonworks, Sunnyvale, CA
http://www.slideshare.net/averyching/20110628giraph-hadoop-summithttp://www.youtube.com/watch?v=l4nQjAG6fac
Hadoop Summit 2011 8 月
Facebook： Scaling Apache Giraph to a trillion edges
2013 年 8 月 15 日 Avery ChingNorthern Western Universityhttps://www.facebook.com/notes/facebook-engineering/scaling-apache-giraph-to-a-trillion-edges/10151617006153920
Scaling Apache Giraph
Nitay Joffe, Data Infrastructure Engineer
@nitayj
September 10, 2013
http://www.slideshare.net/nitayj/20130910-giraph-at-london-hadoop-users-group
Agenda
1 Background
2 Scaling
3 Results
4 Questions
Background
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: メッセージデータ
Giraph は何でないのか ?• Neo4j のようなグラフデータベースではない• 完全に非同期な MPI システムではない• 遅いツールではない .
implementsWritable プロセッサー
ローカルな並列計算
コミュニケーション
バリア同期
BSP モデル
なぜ Hive でないのか ?
Inputformat
Outputformat
Map tasks
Intermediate
files
Reducetasks
Output 0
Output 1
Input 0
Input 1
繰り返し！
• あまりに多くのディスクを必要とし、メモリー・キャッシュにも制限がある
• それぞれの繰り返しが、 MapReduce のジョブになる
Giraph のコンポーネント
Master – アプリケーションの調整者 スーパーステップの同期 スーパーステップが始まる前に
worker に分割グラフを割り当てる Workers – 計算とメッセージング
Handle I/O – グラフの読み書き 割り当てられた部分グラフの計算
とメッセージング ZooKeeper
グローバルなアプリケーションの状態を維持する
Giraph のデータの流れ
Split 0
Split 1
Split 2
Split 3
Work
er
1Mast
er
Work
er
0
Input format Load
/ SendGrap
h
Load /
SendGrap
h
グラフのロード
1
Part 0
Part 1
Part 2
Part 3
Compute /
SendMessag
es
Work
er
1
Compute /
SendMessag
es
Mast
er
Work
er
0
In-memory graph
Send stats / iterate!
計算と繰り返し
2
Work
er
1W
ork
er
0 Part 0
Part 1
Part 2
Part 3
Output format
Part 0
Part 1
Part 2
Part 3
グラフの格納
3
Split 4
Split
Giraph Job Lifetime
Output
Active Inactive
Vote to Halt
Received Message
Vertex Lifecycle
All Vertices Halted?
Input
Compute Superstep
No
Master halted?
No
Yes
Yes
単純なサンプル – 頂点の最大値を見つける
5
15
2
5
5
25
5
5
5
5
1
2
Processor 1
Processor 2
Time
連結要素コミュニティを見つける
PageRank – ranking websites
Mahout (Hadoop)
854 lines
Giraph< 30 lines
• Send neighbors an equal fraction of your page rank
• New page rank = 0.15 / (# of vertices) + 0.85 * (messages sum)
Scaling
Worker Crash
Worker が一つでも失敗すると、スーパーステップの失敗を引き起こす
アプリケーションは、最後にコミットされたスーパーステップの状態に自動的に巻き戻される
Master は、どのスーパーステップの間でも、 ZooKeeper の“ health” znode で失敗を検出する
Master は、最後にコミットされたスーパーステップを選ぶと、 ZooKeeper を通じて全ての Workerぶコマンドを送り、 そのスーパーステップを再開する
Problem: Worker Crash.
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)
ApplicationComplete
…
Solution: Checkpointing.
Master Crash
一つのアクティブな Master は、代替の master を持っており、アクティブな Master が失敗したらそれに代わる
アクティブな Master の状態は、 ZooKeeper に格納されているので、代替の Master は、アクティブMaster が失敗したステップからただちに処理を再開出来る。
“アクティブ” Master は、 ZooKeeper内のキューとして実装されている
“Spare”Master 2
ActiveMaster State“Spare”
Master 1
“Active”Master 0
Before failure of active master 0
“Spare”Master 2
ActiveMaster State“Active”
Master 1
“Active”Master 0
After failure of active master 0
ZooKeeper ZooKeeper
Problem: Master Crash.
Solution: ZooKeeper Master Queue.
Problem: Primitive Collections.• グラフは、よく {Null,Int,Long,Float,Double} といったパ
ラメータを持つ• 型変換は、高価な処理である
3
Solution: Use fastutil, e.g. Long2DoubleOpenHashMap.
fastutil は、 Java の Collections Framework を、型に固有の maps, sets, lists, queues を追加して拡張したもので、小さなメモリーで高速なアクセス・挿入を可能とする
1
24
5
1.2
0.50.8
0.4
1.7
0.7
Single Source Shortest Path
s
t
1.2
0.50.8
0.4
0.2
0.7
Network Flow
3
1
24
5
Count In-Degree
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()next()
next()Objects per worker ~= O(V)
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);
Problem: Large Aggregations.
Worker
Worker
Worker
Worker
Worker
Master
Workers own aggregators
Worker
Worker
Worker
Worker
Worker
Master
Aggregator owners communicatewith Master
Worker
Worker
Worker
Worker
Worker
Master
Aggregator owners distribute values
Solution: Sharded Aggregators.
Worker
Worker
Worker
Worker
Worker
Master
K-Means Clusteringe.g. Similar Emails
Problem: ネットワーク Wait.• RPC はモデルに合わない• 同期型の呼び出しは良くない
Solution: Nettyqueueサイズとスレッドを調整する
BarrierBarrier
Begin superstep
compute
network
End compute
End superstep
wait
BarrierBarrier
Begin superstep
compute
network
wait
Time to first message
End compute
End superstep
Results
50 100 150 200 250 3000
50100150200250300350400450
2B Vertices, 200B Edges, 20 Compute
Threads
Workers
Itera
tion
Tim
e (
sec)
Increasing Workers Increasing Data Size
1000000000 1010000000000
50
100
150
200
250
300
350
400
450
50 Workers, 20 Compute Threads
Edges
Itera
tion
Tim
e (
sec)
Scalability Graphs
Lessons Learned
調整は動物園のようなもの。ZooKeeper で耐障害性確保
効率的なネットワークは難しい。Netty の助け .
プリミティブな Collection, プリミティブパフォーマンスには fastutil. を使う
byte[] は単純だが強力である Unsafe なのはいい事でもありうる
グラフがあるなら、 Giraph を使おう
最終結果は？
Hive との比較• 20x CPU の高速化• 100x Elapsed time は、 15時間 => 9 分に
Facebook全体のグラフデータの処理は、もはや「週末の処理」ではない。いまでは、コーヒー・ブレークの仕事だ。
Part V
Microsoft Trinity
Trinity: A Distributed Graph Engine on a Memory Cloud
2013 年 6 月 26 日ACM SIGMOD 2013http://research.microsoft.com/pubs/183710/Trinity.pdf
Abstract
グラフ・アルゴリズムで実行される計算は、データ・ドリブンで、高度なランダム・データ・アクセスが要求される。ディスク技術の大きな進歩にもかかわらず、それは、グラフ計算に必要な効率的なランダム・アクセスのレベルを与える事がいまだ出来ていない。一方で、メモリー・ベースのアプローチは、一台のマシンのメモリー容量の制限によって、通常はスケールしない。この論文では、分散メモリー・クラウド上の汎用のグラフエンジン Trinity を紹介する。
Abstract
最適化されたメモリー管理とネットワーク・コミュニケーションによって、 Trinity は、高速のグラフ探索と効率的なパラレル計算をサポートする。特に、 Trinity は、オンライン、オフライン双方の計算において、最良のパフォーマンスを目指してメモリーとコミュニケーションの最適化を行うように、グラフのアクセス・パターンを活用する。このことで、 Trinity は少数のコモディティ化したマシンでも、効率的なオンラインの検索処理と、オフラインでの大きなグラフの解析をサポートする事が出来る。
Abstract
さらに、 Trinity は、ユーザーがデータのスキームと通信のプロトコルを宣言する TSL と呼ばれる高度な仕様言語を提供している。これによって、一般的な目的でのグラフの管理と計算は、非常に使いやすいものになる。我々の実験では、低遅延のグラフの検索においても、数十億ノードの Web スケールのグラフの高速解析においても、 Trinity はパフォーマンスを示した。
Graph query and analytics
with Trinity
Haixun WangMicrosoft Research Asiahttp://www.cse.unsw.edu.au/~iwgdm/2013/Slides/Haixun.pdf
Trinity 分散インメモリー key/value ストア
オンライン検索処理グラフ・データベース Facebook 上で 3 hop の範囲の 220万のユーザー検索を 100ms以下の時間で
entity検索等のグラフベース・サービスの基礎
オフライングラフ解析パラレル・プラットオフォーム 10億ノードのグラフ処理を 60秒で グラフ解析の基礎
多様なグラフ操作 オンライン検索処理
最短経路探索 部分グラフのマッチング RDF 用クエリ言語 SPARQL での検索 ....
オフライングラフ解析 PageRank コミュニティの検出 ....
その他の処理 グラフの生成、可視化等
グラフ処理のデータアクセスの特徴 ランダムアクセス。局所性がほとんどない。
ノードにとってみれば、隣りのノードの内容は、グラフをどのように表現したとしても、そのノードに「ジャンプ」するしかアクセス出来ない
データ・ドリブンでデータ中心 計算は、グラフの構造によって命令され
る。データの再利用は難しい。
クラスターとメモリーの費用
現在 5-10 年後サーバーの数 1,000 1,000
サーバーのメモリー容量 64GB 1TB
全体のメモリー容量 64TB 1PB
全体のサーバー・コスト $4M $4M
GB あたりのコスト $60 $4
ランダムアクセスへの挑戦
単一マシンの
RAM容量の制限
高速なグラフ処理
パラレル計算
低遅延オンライン処理
高速オフライン解析
MemoryCloud
ノードの数
辺の数
Web
アメリカの道路地図
グラフの規模
どれだけのマシンが必要か？ Facebook
8億人のユーザ、 1ユーザあたり 130 人の友達がいるとして
30 Trinity マシン
Web 250億ページ、 1 ページあたり 40 のリンク
があるとして 150 Trinity マシン
Trinity Cluster の構造
Memory Cloud とメモリー trunk
Memory Cloud は、 2p 個のメモリー trunkから構成される。それぞれのマシンは、複数のメモリー trunk をホストする。
一つのマシン上のローカル・メモリーを複数の trunk に分割するのは、次の二つの理由による。
1. trunk レベルのパラレル計算は、ロックのオーバーヘッドなしに実行出来る。
2. 一つの巨大なハッシュテーブルのパフォーマンスは、ハッシュの衝突の故に最適ではない。
それぞれのメモリー trunk は、 TFS（ HDFSのような）にバックアップされる。
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-bit のハッシュコード
全てのマシンで共有される２ p 個のスロットを持つアドレッシング・テーブル
メモリーtrunkごとのテーブル
二つのテーブル
基本的なデータモデルは Cell
基本的なデータモデルは Cell
グラフのノードは、 Cell である
グラフの辺は、必ずしも Cell ではない 辺が情報を持たない場合 辺が簡単な情報を持つ場合（ラベルや重み
といった） 辺が沢山の情報を持つ場合、独立した Cell
を割り当てる
TSLTrinity Specification Language
TSL は、 Memory Cloud の中の blob データに対して、オブジェクト指向のデータ操作を提供する。
TSL は、データの統合を容易にする。それはグラフと RDBMS の中のデータのような外部データとのインターフェースを定義する。
TSL はシステムの拡張を容易にする。 TSL で定義されたスキーマと通信プロトコルで、 TSL のコンパイラーは、非常に効率のいいソースを生成する。
[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 a Movie and Actor Graph
struct MyMessage{ string Text;}protocol Echo{ Type: Syn; Request: MyMessage; Response: MyMessage;}
Modeling Message Passing
Trinity Query Language
Memory Cloud はジョイン操作なしで関係間の高速な探索を与える
RDBMS は、追加的なストレージとアクセス方法と、永続性を提供する
Trinity Query Language
FROM a in {" Employee.FullName='Nikki Dahi' "}MATCH a(Employee)-->b(Problem)-->c(Incident)RETURN a, b, c
TQL
SQL
A Distributed Graph Engine for Web Scale RDF Data
Kai Zeng et al.VLDB 2013.http://research.microsoft.com/pubs/183717/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.
Trinity 参考文献 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.
Trinity 参考文献 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
Appendix
参考資料
Balancing Workload Across Nodes with Akka 2
Derek Wyatthttp://letitcrash.com/post/29044669086/balancing-workload-across-nodes-with-akka-2
Distributed (in-memory) graph processing with Akka
Adelbert Changhttp://letitcrash.com/post/30257014291/distributed-in-memory-graph-processing-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 で利用されているフレームワーク
Shardshttps://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.
Gizzardhttps://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 fault-tolerant, distributed databases.
Thrifthttps://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 を指す辺は、一つだけである。しかし、ポジションや状態は、いつでも変更されうる。
ポジションは、検索結果のソーティングにのみ用いられる。状態は、その辺が削除されたらアーカイブされたかをマークするのに利用される。