Distributed Graph System & Related Topics -- TokyoWebMining18

TokyoWebMining18 (http://tokyowebmining18.eventbrite.com/) での発表資料です。Pregel の概要、その OSS 実装である Apache Giraph の実装まわりの話題。また他の話題として Network Bucket Testing [Backstorm & Kleinberg 2011] の紹介をします。

2. • Quiz – 対象とするグラフの簡単な紹介 • 分散グラフシステムのお話（実装よりの話） – Pregel, GraphLab, Trinity graph engine – Giraph, FlockDB • SNS における A/B testing のお話（論文紹介） – Network Bucket Testing
5. グラフを表現するために必要な容量は？ メモリに載せて計算できるか？
7. • •
8. グラフの スケール感：
9. グラフの スケール感：
10. が想定している大きなデータの スケール感
11. Pregel が想定している大きなデータの スケール感:
13. 今日のお話 • 分散グラフシステムのお話 – G.Malewicz+, “Pregel: a system for large-scale graph processing,” SIGMOD 2010. – B. Shao+, “The Trinity graph engine,” Technical Report 161291, Microsoft Research 2012. – Y. Low+, “GraphLab: A New Parallel Framework for Machine Learning,” UAI 2010. • 今回は Pregel の概要 (3分) その実装 Apache Giraph についての紹介をする
14. とは • グラフを分散処理するフレームワーク – Bulk Synchronous Parallel に基づくアプローチ • Efficient, scalable, checkpoint による fault-tolerant • グラフ頂点ごとにデータと処理を Worker に分配 して分散処理 (Vertex-centric) • グラフ頂点は Fig. 1 の 状態機械ですべてが Inactive になるまで処理
15. の処理は のくり返し • 処理は superstep のくり返しにより定義される • 各 superstep の終わりに他の Worker と同期通信 • メッセージを隣接ノードに送り、次の superstep でメッセージを受け取ることで更新する
16. のオープンソース実装 Pregel は多くのオープンソース実装が存在する – Giraph, GoldenOrb, Phoebos, Beagl, …. 中でも Giraph はコミュニティが活発で多くの機能 が実用的なレベルで実装されている – 2012/05/16 から Apache Incubator を卒業して Apache Giraph は top level Project の一つに Pregel の個々の機能について Giraph 実装を見なが ら紹介する
17. • Jakov Homan> One of LinkedIn's designers, Ashley Hall, was kind enough to come up with this logo proposal.
18. アルゴリズムと入出力の実装切り分けが可能 GiraphRunner でより簡潔に記述が可能
19. JIRA/GIRAPH-153 → Resolved • Hadoop 上の Key-Value Store からのロード – Adjacency list + vertex value をロード – Pregel paper は GFS, BigTable からロード可 • ref: Giraph の Cofluence → http://bit.ly/NnqG97
20. Created → 17/Sep/11 10:09 Resolved!! → 09/May/12 20:19 Netty IO (Java NIO をラップした Client/Server Socket Framework, non-blocking I/O など) Avery Ching> [snip] These were some median runs. The overall runtime improved from 167722 -> 57795 with Netty (2.9x faster). Loading the vertices improved from 51025 -> 13393 (3.8x faster). More results coming tomorrow, but for bigger runs, the improvement is likely to be even more than 3x.
21. における • Partition により Worker にグラフ頂点を割り当てる • Pregel ではユーザーがアルゴリズムに適した Partitionを定義可能 • Pregel paritioning is not locality-preserving – データとアルゴリズムによりけり – RPC による communication が大量発生し非効率 になる可能性がある  – Default: hash(VertexID) mod N (=# of partition)
22. における • GIRAPH partitioning – HashPartition – RangePartition • グラフのノードIDをパーティションを作りたい順に re-ordering することで自分の実装に適合した局所性 のある処理が可能 • 元の Pregel が可能であったように気軽に Partitioning を差し替えることはできないが MasterGraphPartition#createInitialPartitionOwners() を 実装することで可能（contribute しよう）
23. の拡張 Outgoing edge 以外にも Weighted edge, Bi- directional edge などを取り扱いたい 独自の Vertex implementation を定義しメンバ変数 を増やす・タスク依存のメンバを増やしたい • シリアライズ・デシリアライズを独自の vertex implementation 用に定義 • それらを inputFormat, outputFormat に渡す • ref: github.com/smly/giraph-classifier, JIRA/GIRAPH-99
24. • リソースの使い方に注意する – Super-step をヘタに定義するとリソースを 無駄遣いすることがあり得る – CPU と IO は実装を見てないので把握していない がメモリは確実に無駄遣いになる worker1 worker2 worker3 worker4 worker5 上では 処理として動作 している が遊ぶ
25. (注: このテーマに関する個人的な意見です) どのような場面で Giraph を選択すべきか？ – Pregel framework に書き換え可能である – メモリに載せることができるか？（リソース） • Single で載るならオレオレ実装 • 分散すればメモリに載るなら Giraph • EMR や S3 などすぐにリソースを使える場合は便利 – 辺に対する処理が多いか？（処理する量） • 少ない場合は GraphDB 便利（よくある場面） • 多い場合はオレオレ実装 or Giraph
27. 伝統的な テストの場合 • 伝統的な A/B テスト – 独立一様にテストセット A, B をサンプリング – 比較手法をそれぞれのテストセットに提示 – 結果が統計的に有意性であるかを見る Methods # of users # of clicks # of Conversion Method A 10000 29 10 Method B 10000 10 7 • 複雑なテストケースではまだ考える余地がある
28. 独立一様にサンプリングできないケース ソーシャルな仕組みに対するテスト – 複数の友人から影響を受けアクションを起こ すような新機能の効果を測定したい – 招待、ターゲティングメッセージ、 Social component 付きの広告、 見た人の友人に表示されることを目的とした ユーザーページに表示する情報 – グラフ上で隣接したユーザーは同じような行 動をする傾向にあるという前提がある 論文の main contribution はこの問題の定式化/ テストフレームワーク/サンプリング手法の提案
29. 例 付きの広告
30. どのような問題が起こるか？ • 効果の分布に偏りがあるため、独立一様にサンプリ ングできない  – 背景にあるグラフに依存して分布する – Homophily assumption: グラフ上で隣り合っている ノードは同じような振る舞いをする – 例：ゲームをするセグメント・しないセグメント
31. 何をゴールとしてテストセットを作るか • 目標とすること – テストセットから全体の効果の推定 – 確率変数を新機能の効果の有無を表す二値変 数であるとし、テストセットは – 和の期待値が知りたい – なるべく分散を小さくしたい min Var[ X ] • 分散が小さくなるようにテストセットを作る • ランダムな始点から適切にランダムウォークす ることでテストセットを集める
32. ではどのようにテストセットを作る？ • テストセットに十分な数の友人と一緒にユー ザーが現れるようにする – しかし一方で全体から一様に近いサンプルを 依然として必要とする • 以下の制約の上でテストセットを作る – 新機能による弱い影響と、ユーザーからの影 響を区別するために 人以上の友人がいる場 合を考える（※） – テストセットのサイズ (budget) は多くても
33. 問題の定式化 テストセットは Core と Fringe から構成される – Core をサンプリング (Walk-based) – Fringe を追加して C ∪ F 上で次数の下限 d の制約 を満たすようテストセットを構成する C = {1, 2, 3} d >= 3
34. 問題の定式化 テストセットは Core と Fringe から構成される – Core をサンプリング (Walk-based) – Fringe を追加して C ∪ F 上で次数の下限 d の制約 を満たすようテストセットを構成する C = {1, 2, 3} d >= 3
35. 問題の定式化 テストセットは Core と Fringe から構成される – Core をサンプリング (Walk-based) – Fringe を追加して C ∪ F 上で次数の下限 d の制約 を満たすようテストセットを構成する C = {1, 2, 3} d >= 3 F = {4, 5} 制約を満たすため しておく
36. ウォークから推定量 テストセットからパフォーマンスを推定する – r.v. の和 の期待値を得たい – テストセットからこれを推定する – 特定のウォークに依存しない一般的な表記： 個の 上の ノード集合 上で重複して 出現した回数 上に出現する 回数の期待値
37. ウォークから推定量 テストセットからパフォーマンスを推定する – r.v. の和 の期待値を得たい – テストセットから推定 – ウォークに依存しない一般的な表記： 個の 上の ノード集合 上で重複して 出現した回数 上に出現する 回数の期待値 （重複や出現回数の期待値で正規化した） 確率変数の平均を
38. ウォークから推定量 テストセットからパフォーマンスを推定する – r.v. の和 の期待値を得たい – テストセットから推定 – ウォークに依存しない一般的な表記： 個の 上の ノード集合 上で重複して 出現した回数 上に出現する 回数の期待値 部分観測の平均を全体の数でかける
39. ウォークから推定量 テストセットからパフォーマンスを推定する – r.v. の和 の期待値を得たい – テストセットから推定 – ウォークに依存しない一般的な表記： 個の 上の ノード集合 上で重複して 出現した回数 上に出現する 回数の期待値 ここ以外は従来と同じ
40. • 一様にノードをサンプリング（Core を選択） • サンプリングしてきたノードの隣接 d ノードを ランダムに選択（Fringe を選択） 近傍の ノードを追加
41. • グラフから walk の始点をランダムに選ぶ • いくつかの hop を通じてノードを集める – 隣接に一様の確率（次数の逆数）で遷移 – は各 hop の遷移確率の和 から DP
42. • ノードのサンプリングにおける state-of-the-art な手法 • Metropolis Sampling では high-degree node に対す るバイアスを避ける – Unweighted ではすべての隣接ノードから一様 にランダムで隣接ノードを選ぶ – もし （遷移先の次数のほうが大） である場合は次数に従う確率で遷移をしない • Walk 中に訪問するノードの重複が増える • 得られる Uniq なノード集合が少なくなる傾向  形式的に特徴付けられていないが マルコフ連鎖の分析の質を決める
43. • Unweighted と Metropolis のいいとこ取り • Unweighted は … – 重複ないので Var 小さくなる  – High-degree の Bias あるので Var 大きくなる  • Metropolis は … – High-degree の Bias ないので Var 小さくなる  – 重複できるので Var 大きくなる 
44. • Unweighted と Metropolis のいいとこ取り • Unweighted は … – 重複ないので Var 小さくなる  – High-degree の Bias あるので Var 大きくなる  • Metropolis は … – High-degree の Bias ないので Var 小さくなる  – 重複できるので Var 大きくなる 
45. • Weighted は … – High-degree の Bias ないので Var 小さくなる  – 重複ないので Var 小さくなる  • Incomming/outgoing weight を normalize する • 以下の iteration で Matrix scaling
46. • Weighted は Fringe を多く必要とするという点に おいて effective ではない – Walk の endpoint の次数は多くの場合 1 – Walk の多くは次数 2 • Triangle-Closing は三角形の Walk をする bias を入 れることで Core をより compact にする
47. • high-degree の bias を得る傾向にあるため、これ を軽減するため Uniformize • Algorithm1 と同様のアプローチ+α – Triangle-closing step の重みを以下: この辺があれば
48. Algorithm 2 は compact だが high-degree の bias を 得る傾向にあるため、Algorithm 1 と同様これを弱 くする (なるべく一様に) 現在のポイント より いっこ前が である確率 を normalize
49. Algorithm 2 は compact だが high-degree の bias を 得る傾向にあるため、Algorithm 1 と同様これを弱 くする (なるべく一様に) 目 → と 目 → の 確率を計算 それぞれの確率の平均をとる
50. 実験に用いたデータセット • Facebook から州ごと (GT, NI, HN, SV) に切り出す • それぞれを bag-of-word の bag とみなす • Bag ごとに bias を勝手に定義することで人工的なテ ストをする • 本来は bag の数も比率もすべて unknown • 1 % (1000) を budget と設定
51. 重複の割合 重複が多いと Variance は大 ．Metropolis は多い
52. 同じ州 を遷移する確率 Triangle-Closing は同じタイプの集まり取れる
53. の比較 k (budget) = fixed. Hop 数を変えて Variance を比較 Triangle-Closing > Weighting > Metropolis > Unweighted
54. 他の話題 • Bag-of-coin によるモデル化と最適なウォーク長 についての分析 • 各 Walk の定量評価（Fringe の数） • 後続の研究 [L Katzir+, WWW 2012] Framework and Algorithms for Network Bucket Testing – Yahoo! Labs., Haifa, Israel の仕事 – 勾配法による最適化など. RMSE で比較
55. • K-core decomposition しても良い場面？ • 効果測定の視点で注目すると： – 誰からのレコメンドかというデータは捨てて いる – セグメントごとの影響の違いは考慮される – いろんなセグメントがある場面では有用そう – 多くの友人を持つノードはより影響されると いう直感（※）は盛り込まれていない
56. • 結果におけるバリアンスの差をどう見るか？ – チェビシェフを適用すると差小さくね？ – バイアスに差が大きい場合は普通のサンプリ ングではバリアンス大きくなる？ • Var[X] = 0.002 → Pr(誤差 ± 1以上) <= 0.002