大規模グラフデータ処理

大規模グラフデータ処理

1. 1. 大規模グラフデータ処理 @maruyama097 丸山不二夫
2. 2. 今日のウェブは、さまざまページの間に張ら れた無構造でランダムなリンクによって成り たっています。 Open Graph(オープンググ ラフ)は人々の間の関係を構造化します。 Zuckerberg 2010年4月 f8コンファレンス
3. 3. GoogleのKnowledge Graphは、単に FreebaseやWikipedia、そしてCIA World Factbookといった、パブリックなリソースに 基づいているだけではない。それは、もっと 巨大なスケールで、拡張されている。なぜな ら、我々は、包括的な広さと深さにフォーカ スしてきたからだ。 我々は、あなたが聞こうと思いもしなかった 質問に答え、あなたの発見をさらに助ける為 に、Knowledge Graphを、利用することが 出来る。
4. 4. はじめに  巨大なクラウドと無数のデバイス達がネット ワークでつながる世界では、我々がリーチ出 来る範囲にも、驚くほど大量の「情報」があ ふれている。  「Webスケール」と呼ばれる、これらの情報 の量的特徴付けは、それ自身、現代のITが挑 戦を続けている課題の質的特徴をよく表して いる。  一方、我々人間が直接知りうる事には、自然 な限界がある。Webスケールの情報に、我々 が関心を持つのは、そこに我々が理解しうる
5. 5. はじめに  文書間の参照グラフを利用したPageRankは 、Webスケールの情報から、我々の関心にそ う情報を我々が理解出来る範囲で抽出する、 もっとも成功した手法である。  SNSの爆発的成長は、人間と人間の関係グラ フ、いわゆる「ソーシャル・グラフ」をネッ トワーク上に作り上げた。それは、現代の Webスケールデータの代表的な存在になった 。
6. 6. はじめに  現在のグラフに対する関心は、直接的には、 モバイルと個人に対して最適の広告を配布す るというビジネス上の動機でドライブされて いる。それは、現代のIT企業間の競争のもっ とも中心的な分野である。  モバイルと個人に対する「最適の広告」を「 最適の情報」と読み替えると、現在進行中の 技術的変化の特質がよく理解出来ると思う。 それは、無理な読み替えではない。両者は、 同じ技術を共有しているからだ。
7. 7. はじめに  「知識グラフ」に対する関心の高まりは、人 間の認知能力とりわけ意味理解の能力を解明 し、機械に学習能力を与え、機械と人間の将 来の関係のあり方を考えるという、ITの最も 重要で長期的な諸課題に我々が近づいている 事を意味しているのかもしれない。  問題を立てる事と、問題を解くのは別の事で ある。ただ、問題を立てるだけの条件がそろ ってきていることは、大事な変化である。そ して、こうした変化の下で、次世代のイノベ ーションが起きるのは確実である。
8. 8. はじめに  講演では、現時点での代表的なWebスケール の大規模グラフデータ処理技術として、次の 三つの技術を取り上げる。  Google Pregel  Apache Giraph  Microsoft Trinity
9. 9. Agenda  Part I グラフとグラフデータ処理  Part II 検索の進化と 大規模グラフデータ処理  Part III Google Pregel  Part IV Apache Giraph  Part V MS Trinity
10. 10. Part I グラフとグラフデータ処理
11. 11. 様々なグラフ グラフは、頂点とそれを結ぶ辺だけからな る単純な図形である。それは、基本的には ２つのものの関係を表現したものだと解釈 出来る。我々は、複雑な現実の様々な対象 の背後に、グラフ構造を見つけ出す。
12. 12. Euler ケーニヒスベルク の7つの橋巡り 頂点 辺
13. 13. 様々な対象・様々なグラフ 生物学的ネットワーク プログラムの流れ図 ソーシャル・ネットワーク 輸送ネットワーク タンパク質のネットワーク http://www.cse.unsw.edu.au/~iwgdm/2013/Slides/Haixun.pdf
14. 14. Deep learning Google DistBelief http://stanford.edu/~acoates/papers/ CoatesHuvalWangWuNgCatanzaro_icml2013.pdf
15. 15. 物理学のグラフ http://arxiv.org/pdf/0711.0770.pdf
16. 16. グラフのタイプ グラフには、辺の向きやラベルの有無によ って、幾つかのタイプにわけられる。現在 のグラフ・データベースの多くは、「プロ パティー・グラフ・モデル」を採用してい る。
17. 17. グラフのタイプ 無向グラフ
18. 18. グラフのタイプ 有向グラフ ＵＭＬダイアグラム http://en.wikipedia.org/wiki/Unified_Modeling_Language
19. 19. グラフのタイプ TwitterのFollow 有向グラフ Webぺージのリンク
20. 20. 全ての辺が同じ意味を持つ 単一関係グラフ  辺を区別する方法がなく、全ての辺が同じ意 味・型を持っている。こうした構造は、「単 一関係グラフ(single-relational graphs)」 と呼ばれる。  単一関係グラフは、グラフ理論やネットワー ク科学で、おそらくは、もっともよく使われ ているグラフの型である。 The Graph Traversal Programming Pattern http://www.slideshare.net/slidarko/graph-windycitydb2010
21. 21. 複数関係グラフ  複数関係グラフは、辺に、例えば、「フォロ ーする」とか「引用する」といった、明確な 型付けを許す。  辺にラベルを付ける事によって、辺は異なっ た意味を持ち、頂点も異なった型を持つよう になる。  例  follows : user → user  created : user → webpage  cites : webpage → webpage
22. 22. 複数関係グラフによって、 グラフの表現力は拡大される 引用する 引用する 生成する 生成する 生成する フォローする 引用する フォローする 生成する フォローする フォローする 生成する フォローする
23. 23. プロパティー・グラフの柔軟性  プロパティー・グラフは、複数関係グラフを、頂点・ 辺の両方とも Key/Valueのプロパティー・マップを 保持出来るように拡張したものである。この事によっ て、辺の意味は、もっと洗練されたものに出来る。  次のグラフは、以下の文章を表現している。 Peter Neubauer created the Neo4j webpage on 2007/10.
24. 24. プロパティー・グラフを利用した グラフ・データベースのデータ構造の例 http://en.wikipedia.org/wiki/Graph_database
25. 25. グラフ処理のスタイル
26. 26. グラフ・データベースと リレーショナル・データベース  リレーショナル・データベースでも、グラフ の表現は可能である。ただし、例えば、「友 達の友達の友達」「友達の友達が引用してい る文書が引用している文書」といった検索を 実現しようとすれば分かるように、グラフ上 では単純にノードを横断するだけの処理が、 リレーショナル・データベースでのグラフ表 現では、ノードを移動する度に、テーブルの ジョインが必要になる。これでは、効率的な 検索は望めない。
27. 27. グラフ・データベースと 大規模グラフデータ処理システム  グラフ・データを処理するのに、グラフ・デ ータベースは極めて強力なツールである。そ の利用は、エンタープライズでの利用を含め て、今後、ますます拡大して行くだろう。  ただ、小論は、グラフ・データベースを対象 とはしていない。それは、現状ではWebスケ ールの大規模なグラフ・データを処理するス ケーラビリティをまだ持っていないからであ る。  一方で、BSPモデルに基づく大規模グラフデ ータ処理システムは、基本的にはバッチ型の
28. 28. Part II 検索の進化と 大規模グラフデータ処理
29. 29. He who controls the graph, controls the world.
30. 30. 2000年代 大規模データ処理の第一世代の開始  現代のITの中核的な技術の一つは、大規模分 散システムによる大規模データの処理技術で ある。「世界中の情報を検索可能にする」と いうミッションを掲げたGoogleの、Webス ケールの検索技術の実現がこうした時代の幕 を開いた。21世紀の始まりとその時期は、ほ ぼ等しい。  クローリングで収集した膨大なページへのイ ンデックス付けとPageRankの計算が、 Webスケールのデータ処理の中心だったのだ が、そうした処理は、MapReduceを用いた
31. 31. 2010年代 大規模データ処理の第二世代への転化  モバイル・デバイスSNSの爆発的な普及を背 景として、2010年ごろ、バッチ処理からリア ルタイム処理への大規模データ処理の大きな 転換が始まる。  Googleのシステムの転換については、昨年７月の丸 山の「大規模分散システムの現在--- GFS, MapReduce, BigTableは、どう進化したか」を参照 されたい。 https://drive.google.com/file/d/0B04ol8GVySU ueWQ2dkZUSFFETlk/edit?usp=sharing
32. 32. ソーシャル・グラフと 大規模グラフデータ処理  こうした変化の口火を切ったのは、個人とモ バイルをターゲットとして、「世界をもっと つながったものに」を会社のミッションとす るFacebookの躍進だった。2010年4月に公 開されたFacebookのOpen Graphは、「ソ ーシャル・グラフ＝大規模グラフデータ」処 理の重要性に多くの人の目を向けさせた。  Googleの対応も興味深い。2010年６月、前 述の検索インデキシングのリアルタイム化を 実現したCaffeinの投入と同じ日に、大規模 グラフデータ処理のエンジンPregelを発表す
33. 33. 検索と大規模グラフデータ  2010年に行われた技術的転換は、バッチから リアルタイムへの進化だけではなく、データ の量への注目からデータの質的なグラフ構造 への注目を特質とする大規模データ処理の第 二世代の開始を意味するものである。  ただ、この技術的転換の意味を、検索の分野 で「知識グラフ」の探索として、明確に定式 化したのは、2012年のGoogleの Knowledge Graphである。この動きに、 FacebookはSearch Graphで、Microsoft は Satori/Trinityで、ただちに追走を開始
34. 34. グラフデータと「知識」の探求の始ま り  GoogleのKnowledge Graphについては、 2012/07/12 の丸山の講演「Google の新しい検索 技術 Knowledge Graph について」 を参照されたい 。 https://docs.google.com/file/d/0B04ol8GVySUu UFUtbWcxNFlHY3c/edit?usp=sharing  ただ、大規模なグラフデータから、我々にと って有用な「知識」「意味」を抽出しようと いう取り組みは、まだ始まったばかりである 。
35. 35. 「知識グラフ」と開かれた課題  「知識グラフ」に対する関心は、次のようなよ り長期的な課題の実現と結びついている。      自然言語を用いたインターフェース 知識とそれをハンドルする能力の機械への移転 生物の多様な認知能力と学習能力の理解 人間の言語能力の理解 学習する機械  楽観的に語るならば、我々は、こうした課題を 解決する時代の入り口に、さしかかっているの かもしれない。
36. 36. Facebook Open Graph 「人々の関係を構造化する」 2010年4月21日 f8 Conference Keynote http://www.livestream.com/f8conference/vi deo?clipId=pla_e7a096b4-3ef9-466d-9a37d920c31040aa
37. 37. Open Graph  「今日のウェブは、さまざまページの間に張 られた無構造でランダムなリンクによって成 りたっています。Open Graph(オープンググ ラフ)は人々の間の関係を構造化します。」 Zuckerberg  Facebookは、2010年に、ソーシャル・グラ フの拡張であるオープングラフの初期バージ ョンを導入した。このオープングラフ・プロ トコルを通じて、Web中の人々が好きなウェ ブサイトやページを含めることが出来る。 Open Graph https://developers.facebook.com/docs/opengraph/
38. 38. 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/
39. 39. Our new search index: Caffeine 検索インデックス付けのリアルタイム化 2010年6月8日 Google Webmaster Central Blog http://googlewebmastercentral.blogspot.jp/ 2010/06/our-new-search-indexcaffeine.html
40. 40. Pregel: A System for LargeScale Graph Processing Googleの大規模グラフデータ処理エンジン 2010年6月8日 SIGMOD 2010 http://kowshik.github.io/JPregel/pregel_paper .pdf
41. 41. Google+ 一般公開 GoogleのSNSへの参入 2011年9月21日 試験サービスの開始は、2011年6月２８日 http://ja.wikipedia.org/wiki/Google+#cite_ note-1
42. 42. Apache Giraph 0.1 incubating Release Pregelのオープンソース・クローン 2012年2月6日 https://giraph.apache.org/ http://archive.apache.org/dist/incubator/gir aph/
43. 43. 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
44. 44. 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
45. 45. The Knowledge Graph http://www.google.com/insidesearch/features/search/knowledge.html
46. 46. Marie Curieの検索
47. 47. Facebook Graph Search Facebookの知識ベースの検索サービス 2013年1月15日 ―Introducing Graph Search Beta‖ http://newsroom.fb.com/News/562/Introdu cing-Graph-Search-Beta
48. 48. ―Graph Search‖ は、Googleがして いるようなリンクではなく、答えを与 える  「Facebookが現在行っているこれら全ての ことより、ずっ面白いのは、人々に彼らが望 むグラフのどんな断片でも得ることが出来る パワーとツールを与える事である。」  「Graph Searchは、正確な検索をすれば、 ある一つの答えを与えるようにデザインされ ている。答えを与えるかもしれない複数のリ ンクではない。... 例えば、Grah Searchに 「サンフランシスコに住んでいる私の友達は 誰？」と質問出来る。」 http://techcrunch.com/2013/01/15/ facebook-announces-its-third-pillar-graph-search/
49. 49. Facebook Graph Search 「カリフォルニア州サンフランシスコに住んでいる人」
50. 50.  ザッカーバーグは、Graph Searchは「非常 に初期のベータ段階にある」と語った。「製 品の最初の取り組みでは、友達・写真・場所 ・興味にフォーカスする。」  FacebookのGraph Searchは完全にパーソナ ライズされている。「スター・ウォーズとハ リー・ポッターが好きな友達は？」という検 索は、質問する人によって全く違う答えを返 す。 http://techcrunch.com/2013/01/15/ facebook-announces-its-third-pillar-graph-search/
51. 51. 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
52. 52. Bing Snapshot  Bingでは、我々は検索はwebのページを指す 青いリンク以上のものであるべきだと信じて いる。我々はまた検索は現実の世界の反映で あるべきだと信じている。それが、我々が昨 年6月に検索結果ページの中央のコラムに答え を一目で見る事の出来るSnapshotという特 徴を導入した理由である。この検索結果は、 現実世界をよりよく理解し開拓する、豊かな 検索である。我々は、まず、映画、レストラ ン、ホテルから始めた。
53. 53. Bing Satori  Snapshotのの基礎にある技術は、我々を取 り巻く世界を、単に「人、場所、物」といっ たものの集まりとしてだけではなく、これら のものの関係として、深く理解することを目 的にデザインされた。Bingのエンジニアリン グ・チームの中では、この技術は、理解を意 味する日本語の「悟り(Satori)」と呼ばれて いた。Satoriは、繰り返し成長を続け、検索 者にディジタルとフィジカルな世界のより有 用なモデルを提供する、数十億のエンティテ ィと関係をカバーするまでになった。
54. 54. 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
55. 55. Facebook Scaling Apache Giraph to a trillion edges FacebookのGiraph拡張の試み 2013年8月15日 Avery Ching Northern Western University https://www.facebook.com/avery.ching
56. 56. 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
57. 57. 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/
58. 58. Moonshot Changes  Knowledge Graph: 文字列ではなく物事。 質問の背後に実際にあるものを知る  Voice search: ますます改良されている  Conversational search: 代名詞を考える  Google Now: 質問をしなくても、次のステ ップを先読みする  Deep learning: 神経回路網を学習する為に 、数千のコンピュータが利用されている
59. 59. Hummingbird  質問を行っているのなら、それは、自然言語 での質問かもしれないし、そこには必要では ない言葉が含まれているかもしれない。 「愛しのテキサスの首府は？」 Hummingbirdは、重要な言葉を切り出して 、その言葉にもっと知的に点数を加えるとい う方向への一つのステップである。
60. 60. 検索の未来 未来の大きな流れ  機械学習： 検索をする人に、如何にしたらもっと大 きな価値を与えられるかを解き明かす試みを、続けて いこうとしている  モバイル: 2011年のYouTubeの携帯電話からの トラ フィックは6%だった。2012年には、それは25%に なり、2014年にはYouTubeのトラフィックの40% を占めると予想されている。もし、モバイルについて の戦略を明確に持っていないのなら、それについて考 えた方がいい。  社会性/主体性/著作権： 自分が何者であるかを知る こと。主体性は大きな違いを生み出しうる。人々が耳 を傾ける人物であるという事は、長期間続くシグナル である。
61. 61. 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
62. 62. 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
63. 63. 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    
64. 64. Part II まとめ 検索とグラフをめぐる主要な出来事 2012/06/16 2013/01/15 2013/03/21 2013/06/26 2013/08/15 Giraph  2013/09/26      Google Knowledge Graph Facebook Search Graph Microsoft Satori Microsoft Trnity Facebook Trillon Edges Google Hammingbird
65. 65. Part III Google Pregel
66. 66. Pregel: A System for LargeScale Graph Processing 2010年6月8日 SIGMOD 2010 http://kowshik.github.io/JPregel/preg el_paper.pdf
67. 67. Pregel: A System for LargeScale 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
68. 68. Pregel開発の背景と動機
69. 69. グラフ処理の必要性  実践的な計算問題の多くがグラフに関係して いる。（Webグラフ、ソーシャル・ネットワ ーク、輸送ネットワーク） 例:      最小経路 クラスタリング ページランク 最大フロー・最小カット 連結要素
70. 70. グラフのスケール  ソーシャル・ネットワークは、人々の間の関 係を表すグラフである。輸送ルートは、地理 的な位置の物理的なつながりを表現するグラ フである。伝染病の伝播もグラフを形成する 。サッカーチーム間の試合もコンピュータ・ ネットワークのトポロジーもそうである。お そらく、もっとも広がっているグラフは、 webそのものだろう。そこでは、ドキュメン トが頂点で、リンクが辺である。  これらのグラフのスケールは、ある場合には 数十億の頂点、数兆の辺を持ち、その効率的
71. 71. グラフ・アルゴリズム 挑戦 その1  頂点毎には、ほんの尐しの計算しか必要とされな い。  実行の途中で、並列計算の程度が変わる。  Munagala and Ranadeは、グラフ・アルゴリズ ム の IO の 複 雑 さ の 下 限 を 示 し た 。 http://www.daimi.au.dk/~large/ioS06/MR.p df
72. 72. グラフ処理の他のアプローチ  新しいアルゴリズム全てに対して、分散インフラ環境 を構築する  Map Reduce  ステージ間のコミュニケーションのオーバーヘッ ド  コンピュータ上のグラフ・ライブラリー  スケールしない  その他の並行グラフ処理システム  fault-toleranceでない スケーラブルな分散処理のソリューションが求 められている
73. 73. グラフの規模拡大と グラフ処理に対する要求の変化  先に述べたグラフの多くは、その構造や起源がそれぞ れ異なるにもかかわらず、二つの共通点を持つ。その 一つは、それらのグラフのサイズが膨張し続けている 事であり、もう一つは、人々がお互いに知りたいと思 っている事実や細部は、無限に存在するように見える 事である。  例えば、地理的な位置情報を考えてみよう。普通の地 図（これもグラフだ）の比較的単純な分析で、二つの 都市の最小経路を与える事が出来る。しかし、もっと 進んで分析を洗練させれば、もっと豊かな情報、スピ ード制限とか予想される交通渋滞とか道路工事や天候 の状態まで、応用出来る。
74. 74. グラフの規模拡大と グラフ処理に対する要求の変化  実距離を計測した最短ルートに加えて、最も 景色のいいルートや最も燃料効率のいいルー ト、一番休憩場所の多いルートといったもの の情報を得る事も出来る。こうしたオプショ ンやそれ以上のものを、もしも適切なツール と入力情報があれば、グラフから引き出し、 便利に利用出来る。Webグラフも同様である 。Webは、数十億の文書を含み、かつ、毎日 のようにその数は増え続けている。
75. 75. 検索とグラフ処理  巨大な量の情報から、必要とする情報を見つ け出すのを助ける為に、Googleは、ウェブペ ージの言語からそのページを参照しているペ ージの数と質にいたるまで、Webグラフから 200以上の情報を抽出している。それを成し 遂げる為に、広い範囲のグラフのデータをマ イニングするスケールするインフラを必要と している。
76. 76. Pregel  Pregelという名前は、レオナルド・オイラー にちなんだものである。彼の有名な定理をイ ンスパイアしたケーニヒスベルクの橋は、プ レゲル川にかかっていた。  ScalableでFault-tolerantなプラットフォー ム  任意のアルゴリズムを表現出来る柔軟なAPI  ValiantのBulk Synchronous Parallelモデル にインスパイアされている  頂点中心の計算 (頂点のように考える)
77. 77. Bulk Synchronous Parallel の計算モデル Bulk Synchronous Parallel（BSP）モデ ルは、ハーバード大のLeslie Valiant によ って，1980年代に提案された。 http://web.mit.edu/6.976/www/hand out/valiant2.pdf
78. 78. MapReduceの原論文でも、BSPモデルは 引用されている。 http://static.googleusercontent.com/media/ research.google.com/ja//archive/ mapreduce-osdi04.pdf
79. 79. BSPの計算モデル  BSPコンピュータは、コミュニケーション・ ネットワークで結合された複数のプロセッサ から構成される。  それぞれのプロセッサは、高速のローカル・ メモリーをもち、それぞれ異なる計算スレッ ドを走らせる事がある。  BSP計算は、一連のグローバルなスーパース テップを繰り返し実行する。
80. 80. BSPの計算モデル 全体の流れ 入力 スーパーステップ (一連の繰り返し) 出力 http://en.wikipedia.org/wiki/Bulk_synchronous_parallel
81. 81. スーパーステップを構成するもの  BSPのスーパーステップは、以下の三つ の要素から構成される 1. 並行計算 2. コミュニケーション 3. バリア同期
82. 82. 一つのスーパーステップの構造 複数のプロセッサー ローカルな計算 ノード間の コミュニケーション バリア同期 http://en.wikipedia.org/wiki/Bulk_synchronous_parallel
83. 83. スーパーステップの構成要素 並行計算  いくつかの計算は、参加している全てのプロ セッサで並行に実行される。  それぞれのプロセスは、プロセッサのローカ ル・メモリーに格納された値のみを使う。  この計算は、それが他の全ての計算とは非同 期であるという意味で、独立である。
84. 84. スーパーステップの構成要素 コミュニケーション  スーパーステップの中で、プロセスは、ノー ド間でデータを交換する。  この交換は、双方向のsend, receiveではな く、一方向のput, getである。  コミュニケーションは、メッセージ・パッシ ングで行われる。
85. 85. スーパーステップの構成要素 バリア同期  プロセスはこの地点（バリア）に到達すると 、他の全てのプロセスがコミュニケーション 動作を終了するまで待つ。  計算とコミュニケーションの動作は、各プロ セッサ毎に独立に行われるので、時間が合っ ている必要はない。  バリア同期がスーパーステップを締めくくる 。
86. 86. Pregelの計算モデル Pregelの計算モデルは、BSPモデルである 。 基本的には、グラフの頂点が、一つの計算 ノードに対応していると考えるといい。 グラフの計算は、主要に、頂点上で行われ る。
87. 87. MapReduceでの アルゴリズムとの違い グラフ・アルゴリズムは、一連のMapReduceの 連続的な呼び出しとしても記述出来る  MapReduce  一つのステージから次のステージに、グラ フ全体の状態を渡す  MapReduceの連鎖のステップでは協調が 必要となる  Pregel  計算を行うマシン上に、頂点と辺を保持す る  ネットワーク転送はメッセージのみ
88. 88. Pregelの計算モデル 「頂点」上での計算 1. 直前のスーパーステップで送られたメッセージを 受け取る 2. ユーザーが定義した同一の関数を実行する 3. 自分の値、あるいは、外向けの辺の値を変更する 4. 他の頂点にメッセージを送る（次のスーパーステ ップで受け取られる） 5. グラフのトポロジーを変化させる 6. 他に仕事がなければ、停止の投票をする
89. 89. Pregelの計算モデル 「頂点」の状態遷移と終了条件 State 頂点の状態マシン machine for a vertex 停止の投票 メッセージの受け取り スーパーステップの終了条件  全ての頂点が同時にInactiveになった時  メッセージが無くなった時
90. 90. Pregelの計算サンプル 最小経路を見つける ここでは、ある始点から、全てのノードへ の最小経路を見つける「単一始点最小経路 SSSP （Single Source Shortest Path） 」を求める問題を、BSPに基づくPregelが 、どのように解くのかを見てみよう。 http://zhenxiao.com/read/Pregel.ppt
91. 91. グラフ処理の流れ グラフ情報入力 スーパーステップ １ 並行計算 コミュニケーション バリア同期 スーパーステップ2 並行計算 コミュニケーション バリア同期 並行計算 コミュニケーション バリア同期 スーパーステップ3 並行計算 コミュニケーション バリア同期 スーパーステップ4 結果出力
92. 92. 単一始点最小経路 実行サンプル スーパーステップ： 0 D B 1 10 A 2 0 9 3 5 4 6 7 C 2 E 次のようなグラフが あったとしよう。 辺の数字は、ノード 間の距離、ノードの 数字は、最終的に は始点からの最小 の距離が入る。 始点には0を、各ノ ードには、無限大を 入れておく。
93. 93. 単一始点最小経路 実行サンプル スーパーステップ： 1 並行計算 ・全てのノードを Activeにする D B 1 ・並行計算1 10 A 2 0 9 3 5 4 6 7 C 送られたメッセージ で最小なものをm とする。このステップ では、メッセージは ない。A以外は、 m=無限大として処理 ・並行計算1 2 E mと自分の値をくら べて小さな方を自 分の値とする。変化なし
94. 94. 単一始点最小経路 実行サンプル スーパーステップ： 1 コミュニケー ション D B ・コミュニケーション 1 10 10 A 2 0 9 3 5 4 6 7 5 C 2 E 自分の値と外向き の辺の数字を足し て、隣りの頂点にメ ッセージを送る
95. 95. 単一始点最小経路 実行サンプル スーパーステップ： 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
96. 96. 単一始点最小経路 実行サンプル スーパーステップ： 2 並行計算 D B ・並行計算2 1 10 送られたメッセージ で最小なものをm とする 10 A 2 0 9 3 5 4 6 7 5 C 2 E 無限大＋nも無限大 である。
97. 97. 単一始点最小経路 実行サンプル スーパーステップ： 2 並行計算 D B 10 10 ・並行計算2 1 mと自分の値をくら べて小さな方を自 分の値に変更する 10 A 2 0 9 3 5 4 6 7 5 C 5 2 E 変更出来なければ コミュニケーション スキップして Inactiveに
98. 98. 単一始点最小経路 実行サンプル スーパーステップ： 2 コミュニケー ション D B 8 10 A 2 0 5 11 1 10 14 9 3 12 C 4 6 7 5 ・コミュニケーション 7 2 E 自分の値を変更し たノードは、自分の 値と外向きの辺の 数字を足して、隣り の頂点にメッセージ を送る
99. 99. 単一始点最小経路 実行サンプル スーパーステップ： 2 バリア同期 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
100. 100. 単一始点最小経路 実行サンプル スーパーステップ： 3 並行計算 D B 8 10 A 2 0 5 11 1 10 送られたメッセージ で最小なものをm とする 14 9 3 12 C 4 6 7 5 ・並行計算3 7 2 E
101. 101. 単一始点最小経路 実行サンプル スーパーステップ： 3 並行計算 D B 1 8 ・並行計算3 11 mと自分の値をくら べて小さな方を自 分の値に変更する 10 A 2 0 9 3 5 4 6 7 C 5 2 7 E 変更出来なければ コミュニケーション スキップして Inactiveに
102. 102. 単一始点最小経路 実行サンプル スーパーステップ： 3 コミュニケー ション 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
103. 103. 単一始点最小経路 実行サンプル スーパーステップ： 3 バリア同期 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
104. 104. 単一始点最小経路 実行サンプル スーパーステップ： 4 並行計算 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 送られたメッセージ で最小なものをm とする
105. 105. 単一始点最小経路 実行サンプル スーパーステップ： 4 並行計算 D B 1 8 ・並行計算4 9 mと自分の値をくら べて小さな方を自 分の値に変更する 10 A 2 0 9 3 5 4 6 7 C 5 2 7 E 変更出来なければ コミュニケーション スキップして Inactiveに
106. 106. 単一始点最小経路 実行サンプル スーパーステップ： 4 コミュニケー ション D B 9 1 8 ・コミュニケーション 自分の値を変更し たノードは。自分の 値と外向きの辺の 数字を足して、隣り の頂点にメッセージ を送る 10 A 2 0 9 3 5 4 7 C 5 2 6 13 7 E
107. 107. 単一始点最小経路 実行サンプル スーパーステップ： 4 バリア同期 D B 1 8 ・バリア同期4 9 10 A 2 0 9 3 5 4 7 C 5 2 6 13 7 E メッセージを受け取 ったノードだけを Activeにする E
108. 108. 単一始点最小経路 実行サンプル スーパーステップ： 5 並行計算 D B 1 8 ・並行計算5 9 送られたメッセージ で最小なものをm とする 10 A 2 0 9 3 5 4 7 C 5 2 6 13 7 E
109. 109. 単一始点最小経路 実行サンプル スーパーステップ： 5 並行計算 D B 1 8 ・並行計算5 9 mと自分の値をくら べて小さな方を自 分の値に変更する 10 A 2 0 9 3 5 4 7 C 5 2 6 13 7 E 変更出来なければ コミュニケーション スキップして Inactiveに
110. 110. 単一始点最小経路 実行サンプル スーパーステップ： 5 バリア同期 ・バリア同期 全てのノードが 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
111. 111. Pregelでプログラムを書く API  定義されている Vertex classを継承する Compute関数を書き換える 受け取った メッセージ 変更された 達 Modify vertex 頂点の値 送り出す value out msg メッセージ
112. 112. 先のサンプルのPregelプログラム 並行計算 並行計算 コミュニケーション バリア同期
113. 113. Pregel システム・アーキテクチャー
114. 114. Pregelの システム・アーキテクチャー Pregelのシステムも、 master/workerモデル  Master  workerを協調動作させる  workerの失敗を回復する  Worker  タスクを処理する  他のworkerと通信する  永続するデータは、GFSあるいはBigTableと いったシステムの分散ストレージを使う  一時的なデータは、ローカル・ディスクに格 納する
115. 115. Pregelの実行 グラフの分割 1. プログラムの多くのコピーが、マシンのク ラスター上で実行を始める 2. Masterはグラフを分割し、一つあるいは それ以上の分割グラフをそれぞれの workerに割り当てる worker 2 worker 1 Master グラフ分割 worker 3
116. 116. Pregelの実行 頂点への入力データの割り当て 3. Masterは、それぞれのworkerに、分割さ れた入力情報を割り当てる  workerは、頂点をロードし、activeのマーク をつける worker 2 worker 1 Master 入力データ の worker 3
117. 117. Pregelの実行 スーパーステップの実行 4. Masterは、それぞれのworkerにスーパー ステップを実行するように指示する  それぞれのworkerは、activeな頂点を全てループ して、それぞれの頂点で計算を実行させる  メッセージは非同期に飛ばされるが、スーパーステ ップの終わりまでには、配送されねばならない  このステップは、一つでもactiveな頂点がある限り 、あるいは、一つでも転送中のメッセージがある限 り繰り返される 5. 計算終了後、Masterはそれぞれのworker にグラフを保存するように指示する事があ る
118. 118. Pregelの実行 値の集約 ロードと保存 Master 障害同期 メッセージのcombine http://java.dzone.com/news/google-pregel-graph-processing
119. 119. Pregelの実行 Workerの構造  Worker  Partition  Node Structure の三層構造 http://java.dzone.com/news/google-pregel-graph-processing
120. 120. Pregelの実行 Partitionの処理 処理モデル  全てのactiveなノードは実行される  全ての処理は、以下の場合に終了する  activeノードがなくなった時  メッセージがなくなった時 スーパーステップの実行 1. Inboxからメッセージを受け取る 2. 頂点と辺の属性を変更する 3. 新しいメッセージがあるまで停止 4. 他の頂点にメッセージを送る。メッセージ受け取った 頂点はactiveになる 5. 辺を消去、あるいは追加する（Topologyの変更）
121. 121. Combiner  Workerは、頂点から報告された複数のメッセージを 結合して、一つのメッセージとして送出する事が出来 る  メッセージのトラフィックとディスクスペースを削減 出来る http://web.engr.illinois.edu/~pzhao4/
122. 122. 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); } };
123. 123. Aggregator Aggregatorは、グローバルなコミュニケーショ ン、グローバルなデータ、モニタリングに使用 される。  頂点が報告する統計値を集約し計算する  スーパーステップの間、workerはそれぞれの頂点か らの値を集約して、部分的な集約値作る  スーパーステップの最後には、それぞれのworkerか らの部分的な集約値は木構造に集約される  木構造は、並列計算が可能である  グローバルな集約値は、Masterに送られる
124. 124. Aggregator Master Aggregator Worker Partition Node Structure http://web.engr.illinois.edu/~pzhao4/
125. 125. Topologyの変更  アプリケーションのクラスタリングに必要と なる  クラスターは、単一の計算ノードに縮約出来 る  最小スパニングツリー・アルゴリズムでは、 辺は削除可能である  頂点や辺の追加要求は可能である
126. 126. Topologyの変更 変更の順番:  削除は追加の前に行われる  辺の削除は、頂点の削除の前に行われる  頂点の追加は、辺の追加の前に行われる その他の条件の衝突は、ユーザが定義する ハンドラで解決されねばならない
127. 127. Fault Tolerance チェックポイントの実行  Masterはworkerに対して、定期的に、 workerのpartition達の状態（頂点の値、辺 の値、受け取ったメッセージ等）を、永続的 なストレージに書き出すように指示する Failure detection  通常の ―ping‖ メッセージを使う
128. 128. Fault Tolerance  Recovery  Masterは、グラフの分割を、その時点で利用 可能なworkerに再割り当てする  全てのworkerは、最新の利用可能なチェック ポイントから、partitionの状態をリロードす る  狭義のRecovery  送出されたメッセージのログをとる  Recoveryが必要なpartitionだけを対象とする  いったんメッセージが送出されていれば、 システムはpartitionの状態を復元出来る。 その他のpartitionを実行する必要はない
129. 129. アプリケーションの例 PageRank
130. 130. PageRank Courtesy: Wikipedia
131. 131. 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 )
132. 132. 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)); } } }
133. 133. 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(); } }
134. 134. アプリケーションの例 2部グラフのマッチング
135. 135. 2部グラフ マッチング L R L R http://www.geeksforgeeks.org/maximum-bipartite-matching/
136. 136. 2部グラフ マッチング  Input : 頂点の集合が二つの部分に分離して いて、辺はこの二つの集合の間を結ぶものだ けからなるグラフ  Output : 共通の頂点を含まない辺の集合  Pregelの実装 :  randomized maximal matching algorithm  頂点の値は、次の二つの値のペア  頂点がどちらの集合に属するかのフラグ（Lか R）  マッチする頂点の名前
137. 137. 2部グラフ マッチング アルゴリズム  Phase 1: まだマッチしていない左の頂点は、その近傍の 全ての頂点にマッチングのリクエストのメッセージを送る 。そして、停止する。  Phase 2: まだマッチしていない右のノードは、受け取っ たメッセージからランダムに一つのメッセージを選び、マ ッチングのリクエストを許諾するというメッセージを送る 。その他のリクエストには、許諾しないというメッセージ を送り、停止する。  Phase 3: まだマッチしていない左の頂点は、受け取った 許可のメッセージの一つを選び、受け入れるというメッセ ージを送る。  Phase 4: マッチしていない右の頂点は、多くて一つの受 け入れのメッセージを受け取っている。マッチングが成立
138. 138. 2部グラフ マッチング アルゴリズム リクエスト 許諾 受け入れ マ
139. 139. 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(); }
140. 140. 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(); }
141. 141. 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(); }
142. 142. 2部グラフ マッチング Pregelコード Phase 4 case 3: if (GetValue().first == ‘R’) { msgs->Next(); *MutableValue().second = msgs->Source(); } VoteToHalt(); } }};
143. 143. 実験結果
144. 144. Experiments 10億の頂点を持つ二分木の処理 workerのタスク数を変えた場合
145. 145. Experiments 二分木の処理 800のworkerでグラフのサイズを変えた場合
146. 146. 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
147. 147. 結論  ―頂点のように考える‖ 計算モデル  Master – 単一障害点かも？  Combiner, Aggregator, topologyの変更 は、もっと多くのアルゴリズムをPregelに 移植する事を可能にする
148. 148. 参考文献 [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.
149. 149. Part IV Apache Giraph
150. 150. Apache Giraph http://giraph.apache.org/
151. 151. Apache Giraph  Apache Giraphは、高度なスケーラビリティ の為に構築された反復グラフ処理のシステムで ある。例えば、それはFacebookで、ユーザー とその関係によって形成されるソーシャル・グ ラフの解析の為に現在利用されている。 Giraphは、Googleで開発され2010年の論文 で記述されたグラフ処理のアーキテクチャーで あるPregelに対するオープンソース版として始 まった。両方のシステムは、Leslie Valiantに よって導入された分散コンピューティングの BSPモデル（Bulk Synchronous Parallel Model)にインスパイアされたものである。
152. 152. Apache Giraph  Giraphは、基本的なPregelモデルを超えて、 幾つかの特徴を付け加えた。それには、 master computation, sharded aggregators, edge-oriented input, outof-core computation等々が含まれている。 しっかりした開発サイクルと世界中のユーザ ーの成長するコミュニティとともに、Giraph は、巨大なスケールでの構造化されたデータ セットのポテンシャルを解き放すための自然 な選択になっている。
153. 153. 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
154. 154. 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
155. 155. 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
156. 156. Agenda 1 Background 2 Scaling 3 Results 4 Questions
157. 157. Background
158. 158. 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システムではない バリア • 遅いツールではない. 同期
159. 159. なぜHiveでないのか? • あまりに多くのディスクを必要とし、メモリー・キャッ シュにも制限がある • それぞれの繰り返しが、MapReduceのジョブになる Input format Map tasks Intermediate Reduce files tasks Output format Input 0 Output 0 Input 1 Output 1 繰り返し！
160. 160. Giraphのコンポーネント  Master – アプリケーションの調整者  スーパーステップの同期  スーパーステップが始まる前に workerに分割グラフを割り当てる  Workers – 計算とメッセージング  Handle I/O – グラフの読み書き  割り当てられた部分グラフの計算 とメッセージング  ZooKeeper  グローバルなアプリケーションの状態を維持する
161. 161. 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
162. 162. 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
163. 163. 単純なサンプル – 頂点の最大値を見つける Processor 1 5 5 5 5 Processor 2 1 1 5 5 5 2 2 2 5 5 Time 連結要素 コミュニティを見つける
164. 164. 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
165. 165. Scaling
166. 166. Worker Crash  Workerが一つでも失敗すると、スーパーステップの 失敗を引き起こす  アプリケーションは、最後にコミットされたスーパー ステップの状態に自動的に巻き戻される  Masterは、どのスーパーステップの間でも、 ZooKeeperの―health‖ znodeで失敗を検出する  Masterは、最後にコミットされたスーパーステップ を選ぶと、ZooKeeperを通じて全てのWorkerぶコマ ンドを送り、 そのスーパーステップを再開する
167. 167. 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
168. 168. Master Crash  一つのアクティブなMasterは、代替のmasterを持っ ており、アクティブなMasterが失敗したらそれに代わ る  アクティブなMasterの状態は、ZooKeeperに格納され ているので、代替のMasterは、アクティブMasterが 失敗したステップからただちに処理を再開出来る。  “アクティブ” Masterは、ZooKeeper内のキューとして 実装されている
169. 169. 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
170. 170. 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を追加して拡張したもので、小さ なメモリーで高速なアクセス・挿入を可能とする
171. 171. 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)
172. 172. Problem:あまりにオブジェクトが多い 多くの時間がGCに費やされる Solution: byte[] • メッセージ、辺、頂点を、byte[]にシリアライズ化する • 代表されたオブジェクトを持つ、繰り返しのインター フェース Input Input Input next() Objects per worker ~= O(V) next() next()
173. 173. 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);
174. 174. 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
175. 175. 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
176. 176. Results
177. 177. 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
178. 178. Lessons Learned  調整は動物園のようなもの。 ZooKeeper で耐障害性確保  効率的なネットワークは難しい。 Nettyの助け.  プリミティブなCollection, プリミティブ パフォーマンスには fastutil.を使う  byte[]は単純だが強力である  Unsafe なのはいい事でもありうる グラフがあるなら、Giraphを使おう
179. 179. 最終結果は？ Hiveとの比較 • 20x CPU の高速化 • 100x Elapsed time は、15時間 => 9分に Facebook全体のグラフデータの処理は、もはや 「週末の処理」ではない。 いまでは、コーヒー・ブレークの仕事だ。
180. 180. Part V Microsoft Trinity
181. 181. Trinity: A Distributed Graph Engine on a Memory Cloud 2013年6月26日 ACM SIGMOD 2013 http://research.microsoft.com/pubs/183710 /Trinity.pdf
182. 182. Abstract  グラフ・アルゴリズムで実行される計算は、 データ・ドリブンで、高度なランダム・デー タ・アクセスが要求される。ディスク技術の 大きな進歩にもかかわらず、それは、グラフ 計算に必要な効率的なランダム・アクセスの レベルを与える事がいまだ出来ていない。一 方で、メモリー・ベースのアプローチは、一 台のマシンのメモリー容量の制限によって、 通常はスケールしない。この論文では、分散 メモリー・クラウド上の汎用のグラフエンジ ンTrinityを紹介する。
183. 183. Abstract  最適化されたメモリー管理とネットワーク・ コミュニケーションによって、Trinityは、高 速のグラフ探索と効率的なパラレル計算をサ ポートする。特に、Trinityは、オンライン、 オフライン双方の計算において、最良のパフ ォーマンスを目指してメモリーとコミュニケ ーションの最適化を行うように、グラフのア クセス・パターンを活用する。このことで、 Trinityは尐数のコモディティ化したマシンで も、効率的なオンラインの検索処理と、オフ ラインでの大きなグラフの解析をサポートす る事が出来る。
184. 184. Abstract  さらに、Trinityは、ユーザーがデータのスキ ームと通信のプロトコルを宣言するTSLと呼 ばれる高度な仕様言語を提供している。これ によって、一般的な目的でのグラフの管理と 計算は、非常に使いやすいものになる。我々 の実験では、低遅延のグラフの検索において も、数十億ノードのWebスケールのグラフの 高速解析においても、Trinityはパフォーマン スを示した。
185. 185. Graph query and analytics with Trinity Haixun Wang Microsoft Research Asia http://www.cse.unsw.edu.au/~iwgd m/2013/Slides/Haixun.pdf
186. 186. Trinity  分散インメモリーkey/valueストア  オンライン検索処理グラフ・データベース  Facebook上で3 hopの範囲の220万のユーザー検 索を 100ms以下の時間で  entity検索等のグラフベース・サービスの基礎  オフライングラフ解析パラレル・プラットオ フォーム  10億ノードのグラフ処理を60秒で  グラフ解析の基礎
187. 187. 多様なグラフ操作  オンライン検索処理     最短経路探索 部分グラフのマッチング RDF用クエリ言語SPARQLでの検索 ....  オフライングラフ解析  PageRank  コミュニティの検出  ....  その他の処理  グラフの生成、可視化等
188. 188. グラフ処理のデータアクセスの特徴  ランダムアクセス。局所性がほとんどない。  ノードにとってみれば、隣りのノードの内 容は、グラフをどのように表現したとして も、そのノードに「ジャンプ」するしかア クセス出来ない  データ・ドリブンでデータ中心  計算は、グラフの構造によって命令される 。データの再利用は難しい。
189. 189. クラスターとメモリーの費用 現在 1,000 サーバーの数 サーバーのメモリー容量 64GB 64TB 全体のメモリー容量 全体のサーバー・コスト $4M $60 GBあたりのコスト 5-10年後 1,000 1TB 1PB $4M $4
190. 190. 単一マシン の RAM容量の 制限 ランダム アクセス への挑戦 Memory Cloud 高速な グラフ処理 低遅延 オンライン処理 パラレル 計算 高速 オフライン解析
191. 191. 辺の数 グラフの規模 Web Facebook アメリカの道路地図 ノードの数
192. 192. どれだけのマシンが必要か？  Facebook  8億人のユーザ、1ユーザあたり130人の友達 がいるとして  30 Trinity マシン  Web  250億ページ、1ページあたり40のリンクがあ るとして  150 Trinity マシン
193. 193. Trinity Cluster の構造
194. 194. Memory Cloudとメモリーtrunk  Memory Cloudは、2p個のメモリーtrunkか ら構成される。それぞれのマシンは、複数の メモリーtrunkをホストする。  一つのマシン上のローカル・メモリーを複数 のtrunkに分割するのは、次の二つの理由に よる。 1. trunkレベルのパラレル計算は、ロックのオ ーバーヘッドなしに実行出来る。 2. 一つの巨大なハッシュテーブルのパフォーマ ンスは、ハッシュの衝突の故に最適ではない 。
195. 195. Key/Value ストア  Memory Cloud上に、Key/Value ストアを 構築する。  Keyは、グローバルにユニークな64bitの識別 子、Valueは、任意長のblobである。  Memory Cloudは、複数のマシン上に分散し ているので、Key/Valueペアの位置を、マシ ン上の物理アドレスでは指定出来ない。  Trinityは、Key/Valueペアの位置を指定する のに、ハッシュのメカニズムを利用する
196. 196. ハッシュ・メカニズム  まず、Key/Valueペアを格納しているマシン を特定する。  ついで、そのマシン上の一つのメモリー trunk上で、Key/Valueペアの位置を見つけ る。
197. 197. マシンの特定  64bitのglobal unique IDから、2pbitのハッシ ュコード i を作る。  Memory Cloudは、2p個のメモリーtrunkから なるので、これで Key/Valueペアは、Memory Cloud中の trunk i に格納されている事が分か る。  trunk i がどのマシン上にあるかを知る為に、 2p個のスロットからなる「アドレシング・テー ブル」を作成しておく。それぞれのスロットに は、マシンIDを入れておく。  i番目のスロットをみれば、マシンが分かる。
198. 198. 一つのメモリーtrunk上で、 Key/Valueペアの位置を見つける 。  グローバルなアドレッシングが機能する為に は、それぞれのマシンが、「アドレッシング ・テーブル」のレプリカを保持する必要があ る。  それぞれのメモリーtrunkは、グローバルID とKey/Valueペアの位置を示すoffsetと、そ のsizeを格納したテーブルを持っている。  このテーブルで、グローバルIDを引けば、 Key/Valueペアの位置と大きさが分かる。
199. 199. 64bitのユニークID 全てのマシンで 共有される２p個の スロットを持つ アドレッシング・ テーブル p-bitのハッシュコード 二つの テーブル メモリー trunkごと のテーブル
200. 200. 基本的なデータモデルはCell
201. 201. 基本的なデータモデルはCell  グラフのノードは、Cellである  グラフの辺は、必ずしもCellではない  辺が情報を持たない場合  辺が簡単な情報を持つ場合（ラベルや重み といった）  辺が沢山の情報を持つ場合、独立したCell を割り当てる
202. 202. TSL Trinity Specification Language  TSLは、Memory Cloudの中のblobデータに 対して、オブジェクト指向のデータ操作を提 供する。  TSLは、データの統合を容易にする。それは グラフとRDBMSの中のデータのような外部 データとのインターフェースを定義する。  TSLはシステムの拡張を容易にする。TSLで 定義されたスキーマと通信プロトコルで、 TSLのコンパイラーは、非常に効率のいいソ ースを生成する。
203. 203. 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; }
204. 204. Modeling Message Passing struct MyMessage { string Text; } protocol Echo { Type: Syn; Request: MyMessage; Response: MyMessage; }
205. 205. Trinity Query Language Memory Cloudは ジョイン操作なしで 関係間の高速な探索 を与える RDBMSは、追加的なストレージと アクセス方法と、永続性を提供する
206. 206. Trinity Query Language TQL FROM a in {" Employee.FullName='Nikki Dahi' "} MATCH a(Employee)-->b(Problem)-->c(Incident) RETURN a, b, c SQL
207. 207. A Distributed Graph Engine for Web Scale RDF Data Kai Zeng et al. VLDB 2013. http://research.microsoft.com/pubs/1 83717/Trinity.RDF.pdf
208. 208. Abstract  RDFデータをサポートする多くの仕事がなされている 。しかし、最先端のシステムも方法も、今なおWeb スケールのRDFデータを効率的にハンドル出来ていな い。さらに、多くの有用な汎用的なグラフ・ベースの 操作（ランダム・ウォーク、到達可能性、コミュニテ ィの発見といった）は、RDFデータの上ではサポート されていない。というのも、既存のシステムの大部分 は、RDFデータ上の一つの特殊な操作：SPARQLでの 検索処理の為に、それに最大限の効果を持つように、 特殊なやりからでデータを格納しインデックス付けし ているからである。この論文では、Webスケールの RDFデータの分散メモリーベース・グラフエンジンで あるTrinity.RDFを紹介する。
209. 209. Abstract  RDFデータを、三つ組みあるいはビットマップ・マト リックスとして格納して、RDFデータを管理する代わ りに、我々は、RDFをネーティブなグラフの形式で RDFデータを格納する。それは、SPARQL検索におい て、最先端のアプローチより、はるかにいい（ある場 合には、何十倍もいい）パフォーマンスを達成する。 さらに、データが、ネーティブなグラフの形式で格納 されているので、ランダム・ウォークや到達可能性と いった別の操作も、RDFのグラフ上でサポート出来る 。我々は、実生活のWebスケールのRDFデータ上で 、我々のアプローチの有効性を示す為に、広い範囲の 実験を行う。
210. 210. 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.
211. 211. 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.
212. 212. 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
213. 213. Appendix 参考資料
214. 214. Balancing Workload Across Nodes with Akka 2 Derek Wyatt http://letitcrash.com/post/29044669 086/balancing-workload-acrossnodes-with-akka-2
215. 215. Distributed (in-memory) graph processing with Akka Adelbert Chang http://letitcrash.com/post/30257014 291/distributed-in-memory-graphprocessing-with-akka
216. 216. twitter cassovary https://github.com/twitter/cassovary
217. 217. Cassovaryとは？  Cassovaryは、JVMの為のシンプルな‖ビッグ ・グラフ‖処理ライブラリーである。大部分の JVM上で走るグラフライブラリーは、柔軟だ がスペース効率が良くない。Cassovaryは、 最初から数十億の頂点と辺からなるグラフを 効率的にハンドル出来るようにデザインされ ている。典型的な使用例は、twitterのような 巨大ネットワークの大規模なグラフデータの マイニングと解析である。Cassovaryは、 Scalaで書かれており、JVMをホストとする どんな言語上でも、共通のデータ構造とアル ゴリズムで利用出来る。
218. 218. 他のグラフ・ライブラリーとの比較 既に沢山の優れたグラフ・マイニングのライブラリーが 存在している。それらの多くは、次のような特徴を持っ ている。 1. C/C++ で書かれている。Stanfordの SNAP やCMU の GraphLab もこうした例に含まれる。JVMからこ れらを使う典型的な仕方は、JNIブリッジを使う事で ある。 2. 柔軟性の為にストレージの効率性を犠牲にしている。 こした例には JUNG が含まれる。それはJavaで書か れているが、頂点や辺は大きなオブジェクトとして格 納されている。 3. もっと沢山の事をしようとしている。典型的には、 Neo4Jを含む完全なグラフ・データベース達である。
219. 219. 他のグラフ・ライブラリーとの比較  他方で Cassovary は、JVMの走る環境で使うのが容 易で、それに加えて数十億の辺でも効率的にスケール することを意図している。Cassovaryは、意図的に 、永続性やデータベースの機能を提供するようには、 デザインされていない。  また、Cassovaryは、現在、グラフの分割に関心を 持っていない。それ故、Apache Giraphのような分 散グラフ処理システムとは、直接比較出来ない。この 事で、Cassovaryは、グラフ上で複雑なアルゴリズ ムを効率的に走らせる事が出来る。そうしなければ、 グラフ分割をうまく行う事の、よく知られている困難 によって、分散グラフ処理システムの諸問題を繰り返 す事になる。
220. 220. 他のグラフ・ライブラリーとの比較  簡単に言えば、そこで動くグラフのサイズは、一つの マシンで利用可能なメモリーによって制限されている 。しかし、スペース効率の良いデータ構造を利用すれ ば、ほとんどの実践的なグラフでは、このことは制限 にならないように見える。  例えば、無方向グラフのArrayBasedDirectedGraph のインスタンスを使えば、 一千万個の頂点と１０億 の辺を持つグラフは、6GB以下のメモリーしか消費し ないし、それを超えても線形にスケールする。
221. 221. FlockDB FlockDBは、Twitterが利用する隣接リス トを格納する分散グラフデータベースであ る https://github.com/twitter/flockdb
222. 222. FlockDBの特徴  高速の追加・更新・削除操作  複雑な数値的な集合検索を行う能力  数百万のエントリーを含む検索結果に対する ページング  辺を‖アーカイブ‖して、あとでリストアする 能力  レプリカを含めた、水平的なスケーリング  オンラインでのデータ・マイグレーション
223. 223. FlockDBの特徴  FlockDBは、尐数の問題を解決しようとしているので 、neo4jのようなグラフ・データベースより、ずっと シンプルである。 それは水平的にスケールし、Web サイトのように、オンラインで低遅延な高速実行環境 の為にデザインされた。  Twitterは、 FlockDBをソーシャル・グラフ（誰が誰 をフィローし、誰が誰をブロックしているかといった ）を格納し、第二のインデックスとして利用してきた 。  2010の４月には、Twitterの FlockDB クラスターは 、130億の辺を格納し、一秒あたりの書き込み20K、 一秒あたりの読み込み100Kのピーク・トラフィック を維持した。
224. 224. It does what?  もし、例えば、「ユーザーAはユーザーBをフォロー している」というソーシャル・グラフを格納している としよう。この関係は「BがAをフォローしていなく ても、AはBをフォロー出来る」ので、非対称的であ る。FlockDBは、こうした関係をノードAはノードB を指しているというように、向きを持った辺として格 納出来る。  FlockDBは、こうした辺を、ソートの情報と一緒に、 ‖誰がAをフォローしているか？‖だけではなく、‖誰を Aがフォローしているか？‖という質問にも答えられ るように、両方向の情報としてで格納する。
225. 225.  これは、有向グラフと呼ばれる（技術的には、 FlockDBは、有向グラフの隣接リストを格納している ）。  それぞれの辺は、64bitの始点IDと64bitの終点ID、 状態（正常、削除済み、アーカイーフされている等） 、ソートに用いられる32bitの情報を持っている。  辺は、前向きと後ろ向きの二つの方向で格納されてい る。こうして辺は、始点IDからも終点IDからも検索 する事が出来る。
226. 226.  例えば、ノード134がノード90を、ソート・ポジシ ョン5で指しているとすれば、次のような二つの行が 格納される事になる。 forward: 134 -> 90 at position 5 backward: 90 <- 134 at position 5
227. 227.  もし、ソーシャル・グラフを格納するのなら、このグ ラフは「フォロー中」と呼ばれるかもしれない。そし て、フォロアーのリストが最近のものから表示される ように、現在の時間をソート・ポジションに入れるだ ろう。  もし、ユーザー134がNickで、ユーザー90がRobin なら、FlockDBは、次の情報を格納する事になる。 forward: Nick follows Robey at 9:54 today backward: Robey is followed by Nick at 9:54 today
228. 228. FlockDBで利用されている フレームワーク
229. 229. 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.
230. 230. 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.
231. 231. 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.
232. 232. Gizzardは、もう使われていない
233. 233.  (始点, 終点) は、ユニークでなければならない。すな わち、ノードAからノードBを指す辺は、一つだけで ある。しかし、ポジションや状態は、いつでも変更さ れうる。  ポジションは、検索結果のソーティングにのみ用いら れる。状態は、その辺が削除されたらアーカイブされ たかをマークするのに利用される。