Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Distributed Graph System & Related Topics -- To...

@smly
June 09, 2012
1.3k

Distributed Graph System & Related Topics -- TokyoWebMining18

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

@smly

June 09, 2012
Tweet

Transcript

  1. • Quiz – 対象とするグラフの簡単な紹介 • 分散グラフシステムのお話(実装よりの話) – Pregel, GraphLab, Trinity

    graph engine – Giraph, FlockDB • SNS における A/B testing のお話(論文紹介) – Network Bucket Testing
  2. 今日のお話 • 分散グラフシステムのお話 – 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 についての紹介をする
  3. とは • グラフを分散処理するフレームワーク – Bulk Synchronous Parallel に基づくアプローチ • Efficient,

    scalable, checkpoint による fault-tolerant • グラフ頂点ごとにデータと処理を Worker に分配 して分散処理 (Vertex-centric) • グラフ頂点は Fig. 1 の 状態機械ですべてが Inactive になるまで処理
  4. の処理は のくり返し • 処理は superstep のくり返しにより定義される • 各 superstep の終わりに他の

    Worker と同期通信 • メッセージを隣接ノードに送り、次の superstep でメッセージを受け取ることで更新する
  5. のオープンソース実装 Pregel は多くのオープンソース実装が存在する – Giraph, GoldenOrb, Phoebos, Beagl, …. 中でも

    Giraph はコミュニティが活発で多くの機能 が実用的なレベルで実装されている – 2012/05/16 から Apache Incubator を卒業して Apache Giraph は top level Project の一つに Pregel の個々の機能について Giraph 実装を見なが ら紹介する
  6. • Jakov Homan> One of LinkedIn's designers, Ashley Hall, was

    kind enough to come up with this logo proposal.
  7. JIRA/GIRAPH-153 → Resolved • Hadoop 上の Key-Value Store からのロード –

    Adjacency list + vertex value をロード – Pregel paper は GFS, BigTable からロード可 • ref: Giraph の Cofluence → http://bit.ly/NnqG97
  8. 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.
  9. における • Partition により Worker にグラフ頂点を割り当てる • Pregel ではユーザーがアルゴリズムに適した Partitionを定義可能

    • Pregel paritioning is not locality-preserving – データとアルゴリズムによりけり – RPC による communication が大量発生し非効率 になる可能性がある  – Default: hash(VertexID) mod N (=# of partition)
  10. における • GIRAPH partitioning – HashPartition – RangePartition • グラフのノードIDをパーティションを作りたい順に

    re-ordering することで自分の実装に適合した局所性 のある処理が可能 • 元の Pregel が可能であったように気軽に Partitioning を差し替えることはできないが MasterGraphPartition#createInitialPartitionOwners() を 実装することで可能(contribute しよう)
  11. の拡張 Outgoing edge 以外にも Weighted edge, Bi- directional edge などを取り扱いたい

    独自の Vertex implementation を定義しメンバ変数 を増やす・タスク依存のメンバを増やしたい • シリアライズ・デシリアライズを独自の vertex implementation 用に定義 • それらを inputFormat, outputFormat に渡す • ref: github.com/smly/giraph-classifier, JIRA/GIRAPH-99
  12. • リソースの使い方に注意する – Super-step をヘタに定義するとリソースを 無駄遣いすることがあり得る – CPU と IO

    は実装を見てないので把握していない がメモリは確実に無駄遣いになる worker1 worker2 worker3 worker4 worker5 上では 処理として動作 している が遊ぶ
  13. (注: このテーマに関する個人的な意見です) どのような場面で Giraph を選択すべきか? – Pregel framework に書き換え可能である –

    メモリに載せることができるか?(リソース) • Single で載るならオレオレ実装 • 分散すればメモリに載るなら Giraph • EMR や S3 などすぐにリソースを使える場合は便利 – 辺に対する処理が多いか?(処理する量) • 少ない場合は GraphDB 便利(よくある場面) • 多い場合はオレオレ実装 or Giraph
  14. 伝統的な テストの場合 • 伝統的な A/B テスト – 独立一様にテストセット A, B

    をサンプリング – 比較手法をそれぞれのテストセットに提示 – 結果が統計的に有意性であるかを見る Methods # of users # of clicks # of Conversion Method A 10000 29 10 Method B 10000 10 7 • 複雑なテストケースではまだ考える余地がある
  15. 独立一様にサンプリングできないケース ソーシャルな仕組みに対するテスト – 複数の友人から影響を受けアクションを起こ すような新機能の効果を測定したい – 招待、ターゲティングメッセージ、 Social component 付きの広告、

    見た人の友人に表示されることを目的とした ユーザーページに表示する情報 – グラフ上で隣接したユーザーは同じような行 動をする傾向にあるという前提がある 論文の main contribution はこの問題の定式化/ テストフレームワーク/サンプリング手法の提案
  16. どのような問題が起こるか? • 効果の分布に偏りがあるため、独立一様にサンプリ ングできない  – 背景にあるグラフに依存して分布する – Homophily assumption:

    グラフ上で隣り合っている ノードは同じような振る舞いをする – 例:ゲームをするセグメント・しないセグメント
  17. 何をゴールとしてテストセットを作るか • 目標とすること – テストセットから全体の効果の推定 – 確率変数を新機能の効果の有無を表す二値変 数であるとし、テストセットは – 和の期待値が知りたい

    – なるべく分散を小さくしたい min Var[ X ] • 分散が小さくなるようにテストセットを作る • ランダムな始点から適切にランダムウォークす ることでテストセットを集める
  18. ではどのようにテストセットを作る? • テストセットに十分な数の友人と一緒にユー ザーが現れるようにする – しかし一方で全体から一様に近いサンプルを 依然として必要とする • 以下の制約の上でテストセットを作る –

    新機能による弱い影響と、ユーザーからの影 響を区別するために 人以上の友人がいる場 合を考える(※) – テストセットのサイズ (budget) は多くても
  19. 問題の定式化 テストセットは Core と Fringe から構成される – Core をサンプリング (Walk-based)

    – Fringe を追加して C ∪ F 上で次数の下限 d の制約 を満たすようテストセットを構成する C = {1, 2, 3} d >= 3
  20. 問題の定式化 テストセットは Core と Fringe から構成される – Core をサンプリング (Walk-based)

    – Fringe を追加して C ∪ F 上で次数の下限 d の制約 を満たすようテストセットを構成する C = {1, 2, 3} d >= 3
  21. 問題の定式化 テストセットは Core と Fringe から構成される – Core をサンプリング (Walk-based)

    – Fringe を追加して C ∪ F 上で次数の下限 d の制約 を満たすようテストセットを構成する C = {1, 2, 3} d >= 3 F = {4, 5} 制約を満たすため しておく
  22. ウォークから推定量 テストセットからパフォーマンスを推定する – r.v. の和 の期待値を得たい – テストセットから推定 – ウォークに依存しない一般的な表記:

    個の 上の ノード集合 上で重複して 出現した回数 上に出現する 回数の期待値 (重複や出現回数の期待値で正規化した) 確率変数の平均を
  23. ウォークから推定量 テストセットからパフォーマンスを推定する – r.v. の和 の期待値を得たい – テストセットから推定 – ウォークに依存しない一般的な表記:

    個の 上の ノード集合 上で重複して 出現した回数 上に出現する 回数の期待値 部分観測の平均を全体の数でかける
  24. • ノードのサンプリングにおける state-of-the-art な手法 • Metropolis Sampling では high-degree node

    に対す るバイアスを避ける – Unweighted ではすべての隣接ノードから一様 にランダムで隣接ノードを選ぶ – もし (遷移先の次数のほうが大) である場合は次数に従う確率で遷移をしない • Walk 中に訪問するノードの重複が増える • 得られる Uniq なノード集合が少なくなる傾向  形式的に特徴付けられていないが マルコフ連鎖の分析の質を決める
  25. • Unweighted と Metropolis のいいとこ取り • Unweighted は … –

    重複ないので Var 小さくなる  – High-degree の Bias あるので Var 大きくなる  • Metropolis は … – High-degree の Bias ないので Var 小さくなる  – 重複できるので Var 大きくなる 
  26. • Unweighted と Metropolis のいいとこ取り • Unweighted は … –

    重複ないので Var 小さくなる  – High-degree の Bias あるので Var 大きくなる  • Metropolis は … – High-degree の Bias ないので Var 小さくなる  – 重複できるので Var 大きくなる 
  27. • Weighted は … – High-degree の Bias ないので Var

    小さくなる  – 重複ないので Var 小さくなる  • Incomming/outgoing weight を normalize する • 以下の iteration で Matrix scaling
  28. • Weighted は Fringe を多く必要とするという点に おいて effective ではない – Walk

    の endpoint の次数は多くの場合 1 – Walk の多くは次数 2 • Triangle-Closing は三角形の Walk をする bias を入 れることで Core をより compact にする
  29. Algorithm 2 は compact だが high-degree の bias を 得る傾向にあるため、Algorithm

    1 と同様これを弱 くする (なるべく一様に) 現在のポイント より いっこ前が である確率 を normalize
  30. Algorithm 2 は compact だが high-degree の bias を 得る傾向にあるため、Algorithm

    1 と同様これを弱 くする (なるべく一様に) 目 → と 目 → の 確率を計算 それぞれの確率の平均をとる
  31. 実験に用いたデータセット • Facebook から州ごと (GT, NI, HN, SV) に切り出す •

    それぞれを bag-of-word の bag とみなす • Bag ごとに bias を勝手に定義することで人工的なテ ストをする • 本来は bag の数も比率もすべて unknown • 1 % (1000) を budget と設定
  32. 他の話題 • Bag-of-coin によるモデル化と最適なウォーク長 についての分析 • 各 Walk の定量評価(Fringe の数)

    • 後続の研究 [L Katzir+, WWW 2012] Framework and Algorithms for Network Bucket Testing – Yahoo! Labs., Haifa, Israel の仕事 – 勾配法による最適化など. RMSE で比較
  33. • K-core decomposition しても良い場面? • 効果測定の視点で注目すると: – 誰からのレコメンドかというデータは捨てて いる –

    セグメントごとの影響の違いは考慮される – いろんなセグメントがある場面では有用そう – 多くの友人を持つノードはより影響されると いう直感(※)は盛り込まれていない