Distributed Graph System & Related Topics -- TokyoWebMining18

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

• Quiz – 対象とするグラフの簡単な紹介 • 分散グラフシステムのお話（実装よりの話） – Pregel, GraphLab, Trinity graph engine – Giraph, FlockDB • SNS における A/B testing のお話（論文紹介） – Network Bucket Testing

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

グラフを表現するために必要な容量は？メモリに載せて計算できるか？

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

• •

Slide 8

Slide 8 text

グラフのスケール感：

Slide 9

Slide 9 text

グラフのスケール感：

Slide 10

Slide 10 text

が想定している大きなデータのスケール感

Slide 11

Slide 11 text

Pregel が想定している大きなデータのスケール感:

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

今日のお話 • 分散グラフシステムのお話 – 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 についての紹介をする

Slide 14

Slide 14 text

とは • グラフを分散処理するフレームワーク – Bulk Synchronous Parallel に基づくアプローチ • Efficient, scalable, checkpoint による fault-tolerant • グラフ頂点ごとにデータと処理を Worker に分配して分散処理 (Vertex-centric) • グラフ頂点は Fig. 1 の状態機械ですべてが Inactive になるまで処理

Slide 15

Slide 15 text

の処理はのくり返し • 処理は superstep のくり返しにより定義される • 各 superstep の終わりに他の Worker と同期通信 • メッセージを隣接ノードに送り、次の superstep でメッセージを受け取ることで更新する

Slide 16

Slide 16 text

のオープンソース実装 Pregel は多くのオープンソース実装が存在する – Giraph, GoldenOrb, Phoebos, Beagl, …. 中でも Giraph はコミュニティが活発で多くの機能が実用的なレベルで実装されている – 2012/05/16 から Apache Incubator を卒業して Apache Giraph は top level Project の一つに Pregel の個々の機能について Giraph 実装を見ながら紹介する

Slide 17

Slide 17 text

• Jakov Homan> One of LinkedIn's designers, Ashley Hall, was kind enough to come up with this logo proposal.

Slide 18

Slide 18 text

アルゴリズムと入出力の実装切り分けが可能 GiraphRunner でより簡潔に記述が可能

Slide 19

Slide 19 text

JIRA/GIRAPH-153 → Resolved • Hadoop 上の Key-Value Store からのロード – Adjacency list + vertex value をロード – Pregel paper は GFS, BigTable からロード可 • ref: Giraph の Cofluence → http://bit.ly/NnqG97

Slide 20

Slide 20 text

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.

Slide 21

Slide 21 text

における • Partition により Worker にグラフ頂点を割り当てる • Pregel ではユーザーがアルゴリズムに適した Partitionを定義可能 • Pregel paritioning is not locality-preserving – データとアルゴリズムによりけり – RPC による communication が大量発生し非効率になる可能性がある  – Default: hash(VertexID) mod N (=# of partition)

Slide 22

Slide 22 text

における • GIRAPH partitioning – HashPartition – RangePartition • グラフのノードIDをパーティションを作りたい順に re-ordering することで自分の実装に適合した局所性のある処理が可能 • 元の Pregel が可能であったように気軽に Partitioning を差し替えることはできないが MasterGraphPartition#createInitialPartitionOwners() を実装することで可能（contribute しよう）

Slide 23

Slide 23 text

の拡張 Outgoing edge 以外にも Weighted edge, Bi- directional edge などを取り扱いたい独自の Vertex implementation を定義しメンバ変数を増やす・タスク依存のメンバを増やしたい • シリアライズ・デシリアライズを独自の vertex implementation 用に定義 • それらを inputFormat, outputFormat に渡す • ref: github.com/smly/giraph-classifier, JIRA/GIRAPH-99

Slide 24

Slide 24 text

• リソースの使い方に注意する – Super-step をヘタに定義するとリソースを無駄遣いすることがあり得る – CPU と IO は実装を見てないので把握していないがメモリは確実に無駄遣いになる worker1 worker2 worker3 worker4 worker5 上では処理として動作しているが遊ぶ

Slide 25

Slide 25 text

(注: このテーマに関する個人的な意見です) どのような場面で Giraph を選択すべきか？ – Pregel framework に書き換え可能である – メモリに載せることができるか？（リソース） • Single で載るならオレオレ実装 • 分散すればメモリに載るなら Giraph • EMR や S3 などすぐにリソースを使える場合は便利 – 辺に対する処理が多いか？（処理する量） • 少ない場合は GraphDB 便利（よくある場面） • 多い場合はオレオレ実装 or Giraph

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

伝統的なテストの場合 • 伝統的な A/B テスト – 独立一様にテストセット A, B をサンプリング – 比較手法をそれぞれのテストセットに提示 – 結果が統計的に有意性であるかを見る Methods # of users # of clicks # of Conversion Method A 10000 29 10 Method B 10000 10 7 • 複雑なテストケースではまだ考える余地がある

Slide 28

Slide 28 text

独立一様にサンプリングできないケースソーシャルな仕組みに対するテスト – 複数の友人から影響を受けアクションを起こすような新機能の効果を測定したい – 招待、ターゲティングメッセージ、 Social component 付きの広告、見た人の友人に表示されることを目的としたユーザーページに表示する情報 – グラフ上で隣接したユーザーは同じような行動をする傾向にあるという前提がある論文の main contribution はこの問題の定式化/ テストフレームワーク/サンプリング手法の提案

Slide 29

Slide 29 text

例付きの広告

Slide 30

Slide 30 text

どのような問題が起こるか？ • 効果の分布に偏りがあるため、独立一様にサンプリングできない  – 背景にあるグラフに依存して分布する – Homophily assumption: グラフ上で隣り合っているノードは同じような振る舞いをする – 例：ゲームをするセグメント・しないセグメント

Slide 31

Slide 31 text

何をゴールとしてテストセットを作るか • 目標とすること – テストセットから全体の効果の推定 – 確率変数を新機能の効果の有無を表す二値変数であるとし、テストセットは – 和の期待値が知りたい – なるべく分散を小さくしたい min Var[ X ] • 分散が小さくなるようにテストセットを作る • ランダムな始点から適切にランダムウォークすることでテストセットを集める

Slide 32

Slide 32 text

ではどのようにテストセットを作る？ • テストセットに十分な数の友人と一緒にユーザーが現れるようにする – しかし一方で全体から一様に近いサンプルを依然として必要とする • 以下の制約の上でテストセットを作る – 新機能による弱い影響と、ユーザーからの影響を区別するために人以上の友人がいる場合を考える（※） – テストセットのサイズ (budget) は多くても

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

ウォークから推定量テストセットからパフォーマンスを推定する – r.v. の和の期待値を得たい – テストセットからこれを推定する – 特定のウォークに依存しない一般的な表記：個の上のノード集合上で重複して出現した回数上に出現する回数の期待値

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

ウォークから推定量テストセットからパフォーマンスを推定する – r.v. の和の期待値を得たい – テストセットから推定 – ウォークに依存しない一般的な表記：個の上のノード集合上で重複して出現した回数上に出現する回数の期待値部分観測の平均を全体の数でかける

Slide 39

Slide 39 text

ウォークから推定量テストセットからパフォーマンスを推定する – r.v. の和の期待値を得たい – テストセットから推定 – ウォークに依存しない一般的な表記：個の上のノード集合上で重複して出現した回数上に出現する回数の期待値ここ以外は従来と同じ

Slide 40

Slide 40 text

• 一様にノードをサンプリング（Core を選択） • サンプリングしてきたノードの隣接 d ノードをランダムに選択（Fringe を選択）近傍のノードを追加

Slide 41

Slide 41 text

• グラフから walk の始点をランダムに選ぶ • いくつかの hop を通じてノードを集める – 隣接に一様の確率（次数の逆数）で遷移 – は各 hop の遷移確率の和から DP

Slide 42

Slide 42 text

• ノードのサンプリングにおける state-of-the-art な手法 • Metropolis Sampling では high-degree node に対するバイアスを避ける – Unweighted ではすべての隣接ノードから一様にランダムで隣接ノードを選ぶ – もし（遷移先の次数のほうが大）である場合は次数に従う確率で遷移をしない • Walk 中に訪問するノードの重複が増える • 得られる Uniq なノード集合が少なくなる傾向  形式的に特徴付けられていないがマルコフ連鎖の分析の質を決める

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Slide 45

Slide 45 text

• Weighted は … – High-degree の Bias ないので Var 小さくなる  – 重複ないので Var 小さくなる  • Incomming/outgoing weight を normalize する • 以下の iteration で Matrix scaling

Slide 46

Slide 46 text

• Weighted は Fringe を多く必要とするという点において effective ではない – Walk の endpoint の次数は多くの場合 1 – Walk の多くは次数 2 • Triangle-Closing は三角形の Walk をする bias を入れることで Core をより compact にする

Slide 47

Slide 47 text

• high-degree の bias を得る傾向にあるため、これを軽減するため Uniformize • Algorithm1 と同様のアプローチ+α – Triangle-closing step の重みを以下: この辺があれば

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Algorithm 2 は compact だが high-degree の bias を得る傾向にあるため、Algorithm 1 と同様これを弱くする (なるべく一様に) 目 → と目 → の確率を計算それぞれの確率の平均をとる

Slide 50

Slide 50 text

実験に用いたデータセット • Facebook から州ごと (GT, NI, HN, SV) に切り出す • それぞれを bag-of-word の bag とみなす • Bag ごとに bias を勝手に定義することで人工的なテストをする • 本来は bag の数も比率もすべて unknown • 1 % (1000) を budget と設定

Slide 51

Slide 51 text

重複の割合重複が多いと Variance は大 ．Metropolis は多い

Slide 52

Slide 52 text

同じ州を遷移する確率 Triangle-Closing は同じタイプの集まり取れる

Slide 53

Slide 53 text

の比較 k (budget) = fixed. Hop 数を変えて Variance を比較 Triangle-Closing > Weighting > Metropolis > Unweighted

Slide 54

Slide 54 text

他の話題 • Bag-of-coin によるモデル化と最適なウォーク長についての分析 • 各 Walk の定量評価（Fringe の数） • 後続の研究 [L Katzir+, WWW 2012] Framework and Algorithms for Network Bucket Testing – Yahoo! Labs., Haifa, Israel の仕事 – 勾配法による最適化など. RMSE で比較

Slide 55

Slide 55 text

• K-core decomposition しても良い場面？ • 効果測定の視点で注目すると： – 誰からのレコメンドかというデータは捨てている – セグメントごとの影響の違いは考慮される – いろんなセグメントがある場面では有用そう – 多くの友人を持つノードはより影響されるという直感（※）は盛り込まれていない

Slide 56

Slide 56 text

• 結果におけるバリアンスの差をどう見るか？ – チェビシェフを適用すると差小さくね？ – バイアスに差が大きい場合は普通のサンプリングではバリアンス大きくなる？ • Var[X] = 0.002 → Pr(誤差 ± 1以上) <= 0.002