Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ICDE2014 勉強会 新井担当分

http://www.kde.cs.tsukuba.ac.jp/dbreading/?ICDE2014%CA%D9%B6%AF%B2%F1

  • Login to see the comments

  • Be the first to like this

ICDE2014 勉強会 新井担当分

  1. 1. ICDE2014勉強会 Graphs III: Distributed Processing 新井 淳也 NTT スライド中の図はそれぞれの論文からの引用です 1
  2. 2. • GLog: A High Level Graph Analysis System Using MapReduce • MapReduce ジョブに変換可能なグラフ分析言語 GLog の提案 • Continuous Pattern Detection over Billion-Edge Graph Using Distributed Framework • 変化するグラフに対するグラフパターンマッチを Giraph 上で行う近似解法の提案 • How to Partition a Billion-Node Graph • 実世界のグラフを分割するためのスケーラブルなアルゴリ ズムの提案 2
  3. 3. • GLog: A High Level Graph Analysis System Using MapReduce • MapReduce ジョブに変換可能なグラフ分析言語 GLog の提案 • Continuous Pattern Detection over Billion-Edge Graph Using Distributed Framework • 変化するグラフに対するグラフパターンマッチを Giraph 上で行う近似解法の提案 • How to Partition a Billion-Node Graph • 実世界のグラフを分割するためのスケーラブルなアルゴリ ズムの提案 3
  4. 4. GLog: A High Level Graph Analysis System Using MapReduce Jun Gao, Jiashuai Zhou, Chang Zhou and Jeffrey Xu Yu • グラフ分析言語を使ってグラフ分散処理を効率的に記 述したい • Well-accepted な既存言語はない • 簡潔で表現力が高いグラフ分析言語 GLog を提案 • GLog 用のデータ形式として RG テーブルも提案 • GLog クエリは最適化して MapReduce ジョブに変換 • Pig より短く書ける上に 1.3~5.8 倍高速 4
  5. 5. 大規模グラフの処理には分散処理 • MapReduce, Pregel, GraphLab, ... • しかし効率的なプログラムを書くのが難しい • 大規模: 100M+ vertices 5
  6. 6. グラフ分析言語 • グラフ分析言語とクエリエンジンの組合せで 評価手順の最適化が可能 • Pig, Hive, YSmart, SystemML, ... • しかし広く使われているグラフ分析言語はない • 簡潔さと表現力の高さを両立できていない • e.g. PigLatin は繰り返し処理を記述できない 6
  7. 7. 貢献 • グラフデータ保存用の RG (Relational- Graph) テーブルと分析言語 GLog の提案 • GLog クエリを一連の MapReduce (MR) ジョブに変換する手法の発明 • 変換されたMRジョブの最適化戦略の設計 • 28ノード Hadoop クラスタ上での性能評価 7
  8. 8. グラフ分析システムの構造 が Hive, Pig, YSmart 等との違い MR ジョブとジョブ管理 プログラムを生成 8
  9. 9. RGテーブル • 関係テーブルをグラフのために拡張したもの • ネストしたデータも扱える • GLog の基盤となるデータモデル 9
  10. 10. GLog • Datalog ベースのクエリ言語 • Datalog: Prolog ベースのクエリ言語 • Datalog よりグラフ分析が書きやすい • 再帰の代わりに繰り返し文を使う • 複雑で柔軟なグラフ処理のため • 終了状態判定のために変数を使える • 関係テーブルではなく RG テーブル上で動作する 10
  11. 11. GLog による Landmark Index 構築 • aaa 11
  12. 12. GLog による Landmark Index 構築 • aaa GLog rule Variable rule 繰り返し 12
  13. 13. GLogからMRジョブへの変換 • 各ルールを関係DB上の操作へ変換 • Selection, projection, join, union, ... • 基本的に1ルール1ジョブ 13
  14. 14. MRジョブの最適化 • 最適化 ≒ ジョブ数の削減 • ジョブの数が性能に大きく影響する • 最適化テクニック 1. Rule merging • 1-side/2-side Operation のマージ • Shuffle-Shared Operation のマージ 2. Iteration rewriting 14
  15. 15. Rule merging: 1-side Operation のマージ Mapper 1 Reducer 1 Mapper 2 Reducer 2 Mapper 3 Reducer 3 1-side operation 2-side operation 1-side operation 依 存 依 存 MR ジョブへ変換したときに mapper か reducer の 片方にしかならない操作はマージできる場合がある 15
  16. 16. Rule merging: 1-side Operation のマージ Mapper Mapper 1 & 2 Reducer Reducer 2 & 3 2-side operation MR ジョブへ変換したときに mapper か reducer の 片方にしかならない操作はマージできる場合がある 16
  17. 17. Rule merging: Shuffle-Shared Operationのマージ • 一定の条件を満たすと 2-side op. 同士もマージできる • 詳しくは論文で 17 Mapper 2 Reducer 2 2-side operation Mapper 1 Reducer 1 2-side operation 依存
  18. 18. Rule merging: Shuffle-Shared Operationのマージ • 一定の条件を満たすと 2-side op. 同士もマージできる • 詳しくは論文で 18 Mapper 2 2-side operation Reducer Reducer Mapper 1 & Reducer 1 & Reducer 2
  19. 19. Iteration rewriting • ループ内のルールの順序を入れ替えることでマージ できる箇所を増やす • ループ内先頭のルールをループ前に出す • Shuffle-Shared operations になる場合がある 2-side operation 2-side operation 2-side operation 2-side operation 2-side operation マージ可能 Shuffle- Shared ops. 元のコード Iteration rewriting 後のコード 19
  20. 20. 評価 1. GLog の簡潔さと表現力について 2. GLog クエリの性能について • 環境 • 28ノードの Hadoop 0.20.3 クラスタ • Opteron 4180 2.60GHz 6コア, 48GB RAM • 1ノードあたり map と reduce それぞれ6スロット 20
  21. 21. 簡潔さと表現力 • Java が何百行も要す処理を2~13行で実現 • PigLatin も短いが、繰り返し処理のためには Java の コードを別に書く必要がある 21
  22. 22. Speed-up vs. Pig • Pig と比べ 1.3~5.8 倍高速 • 繰り返し処理最適化等グラフ向けサポートがあるため • 繰り返し処理のジョブ数が少ない: Connected Components で GLog の1ジョブに対し Pig は 5ジョブ ※ Queries は TABLE II にある各クエリ名の頭文字 22
  23. 23. • GLog: A High Level Graph Analysis System Using MapReduce • MapReduce ジョブに変換可能なグラフ分析言語 GLog の提案 • Continuous Pattern Detection over Billion-Edge Graph Using Distributed Framework • 変化するグラフに対するグラフパターンマッチを Giraph 上で行う近似解法の提案 • How to Partition a Billion-Node Graph • 実世界のグラフを分割するためのスケーラブルなアルゴリ ズムの提案 23
  24. 24. Continuous Pattern Detection over Billion-Edge Graph Using Distributed Framework Jun Gao, Chang Zhou, Jiashuai Zhou and Jeffrey Xu Yu • 変化するグラフ (e.g. ソーシャルネットワーク) の監視によりグラ フパターンを検出したい • パターン: 特定の属性を持つ頂点同士の結合 • パターン検出のインクリメンタルな近似解法を提案 • グラフの変化の影響を受ける部分だけを再計算する • Giraph 上に実装し評価 • およそ 0~30% の false-positive な検出 • 変化時に完全に再計算するより5~10倍高速 24
  25. 25. グラフ監視で検出したいパターン • 例えば絶えず変化するソーシャルグラフ上で • 企業が: ライバル社とサプライヤや販売会社のつながり • 警察が: 2つのギャングの構成員間のつながり • リアルタイムに近い速さで検出したい 25
  26. 26. グラフパターン検出 • 所与のグラフの部分グラフがクエリと同形かどうかを判定 • 頂点 (だけ) が「ラベル」を持つ無向グラフを想定 アルファベット: ラベル 頂点傍の数字: 頂点ID 26
  27. 27. パターン検出アルゴリズムの基本アイデア • グラフ上でメッセージを流す • メッセージには通過した頂点の情報が含まれる • クエリと同じラベルの頂点を同じ順序で辿った部分がマッチ • ‘Sink’ の頂点に全経路からのメッセージが集まったら全体がマッ チしたということ • Sink はクエリパターンの中から適当に決める a0 b0 c0 d0 a1 b1 c1 a2 d1 c3 e0 d3 a3 a4 c2 d4 Graph これをどう 検出するか? a e b d c c a d a d c Query 0 1 2 3 4 5 6 7 8 9 10 27 Sink Sink
  28. 28. Transition Rule によるパターン検出 • Transition rule で「クエリと同じラベルの頂点を同じ順序で 辿った」ことを検出する • ルールに従って配送されたメッセージが sink に揃ったらマッチ a0 b0 c0 d0 a1 b1 c1 a2 d1 c3 e0 d3 a3 a4 c2 d4 GraphTransition Rules 頂点へ 割当て生成 a e b d c c a d a d c Query 0 1 2 3 4 5 6 7 8 9 10 自身のラベルが a のとき、ラベル d の頂点からメッセー ジを受け取ったら、隣接するラベル c の頂点へ転送 28 ルール例:
  29. 29. インクリメンタルなパターン検出 • エッジ追加時: • エッジ両端の頂点で transition rule を再度確認し、充足され たものがあればメッセージを再送 • エッジ削除や頂点追加/削除も同様にルールを再確認する a0 b0 c0 d0 a1 b1 c1 a2 d1 c3 e0 d3 a3 a4 c2 d4 Graph 新しいエッジによって transition rule を満たせるようになる可能性がある 29 自身のラベルが a のとき、ラベル d の頂点からメッセージを受け取ったら、 隣接するラベル c の頂点へ転送
  30. 30. 評価 • データセット • ラベルはランダムに与える • クエリは頂点にランダムなラベルとエッジを与え生成 • 28ノードの Giraph 1.0 & Hadoop 0.20.3 ク ラスタを使用 30
  31. 31. クエリの頂点数×エッジ密度 vs. 精度 • およそ 0~30% の false-positive な検出 • Patten Density: クエリパターンのエッジ密度 (1.0で完全グラフ) • pcs (precision): 正解マッチ数 / 近似手法によるマッチ数 • False-positive が出ると値が 1.0 より小さくなる 31
  32. 32. 応答時間 32 提案手法 既存の厳密解法との比較 インクリメンタル計算と 完全再計算の比較 • 既存手法よりずっと大きい クエリパターンを扱える • グラフ変化の都度再計算 するより5~10倍高速
  33. 33. • GLog: A High Level Graph Analysis System Using MapReduce • MapReduce ジョブに変換可能なグラフ分析言語 GLog の提案 • Continuous Pattern Detection over Billion-Edge Graph Using Distributed Framework • 変化するグラフに対するグラフパターンマッチを Giraph 上で行う近似解法の提案 • How to Partition a Billion-Node Graph • 実世界のグラフを分割するためのスケーラブルなアルゴリ ズムの提案 33
  34. 34. How to Partition a Billion-Node Graph Lu Wang, Yanghua Xiao, Bin Shao, Haixun Wang • 実世界の大規模グラフを分散メモリ環境で分割したい • 分散処理時の効率的な負荷分散のため • Multilevel label propagation (MLP) を提案 • Label propagation (LP) でノードを集約してから METIS で分割 • Trinity 上に MLP を実装し評価 • 逐次実行 (METIS 比): エッジカット最大2倍増 (悪化)、最大約30倍高速化 • 8ノード実行: 6.5B edges のグラフを約4時間で分割 34
  35. 35. グラフ分割の既存手法: METIS • エッジカット (分割間を跨ぐエッジ数) の最小化を目指す • 3ステップの処理で分割 グラフを coarse にする (粗くする) 極大マッチング (頂点を共有しな いエッジの集合) を探し、エッジの 両端点を1頂点へ集約 1. グラフを coarse にする (粗くする) 極大マッチング (頂点を共有しな いエッジの集合) を探し、エッジの 両端点を1頂点へ集約 2. グラフを 分割する 3. グラフを 元に戻す (uncoarsening) 35
  36. 36. METIS の問題点 • 極大マッチングによる coarsening は 1. 実世界のグラフに適さない 2. Billion-edge グラフに適さない 36
  37. 37. METIS の問題点1: 実世界のグラフに適さない • クラスタ性を無視した頂点集約を行ってしまう • 実世界のグラフ: スケールフリー性、スモールワールド性、クラスタ性を持つグラフ 37
  38. 38. METIS の問題点2: Billion-edge グラフに適さない • ディスク上のデータアクセス効率が悪い • メモリに収まらないグラフデータはディスク上にある • 極大マッチング探索アルゴリズムはランダムアクセス を要求する • メモリの消費が多い • Coarsen 前後の頂点の対応情報を保持する • 何段階も coarsen を繰り返すためサイズが増大 38
  39. 39. これらの問題を解決する coarsening 手法が必要 39
  40. 40. Label Propagation (LP) • コミュニティ (クラスタ) を発見できるグラフ分析手法 • Coarsening に用いたときの利点 • 省メモリかつ高速 • Coarsen 前後の頂点対応データが小さい • 意味のある分割が可能 • コミュニティ構造に基づく分割になる 40
  41. 41. Label Propagation による分割 1. 全頂点に一意なラベルを与える • ここではラベルとして整数値を想定 2. 頂点のラベルを繰り返し更新 • 最も多くの隣接頂点に割り当てられているラベルへ自 身のラベルを書き換える 3. 収束または一定回数以上繰り返したら終了 • 同じラベルを持つ頂点は同じ分割に所属 2 2 0 1 1 1 2 0 1 1 41
  42. 42. Multi-level Label Propagation (MLP) • 3ステップの処理で分割 1. Coarsening • LP でグラフを coarse にする 2. Refinement • Coarse graph に対し METIS を適用して分割 3. Uncoarsening • Coarse graph を元に戻す • METIS と異なり coarsen 後も意味・構造が 保たれる 42
  43. 43. Pipelined MLP (pMLP) • 分散環境でもメモリに載らないような巨大グラフ を分散処理で分割するための手法 • Coarsening ステップをディスクベース化 • LP はディスクベースでも効率が良い • ラベルを更新しようとしている頂点の隣接頂点さえメモリ 上にあればよく、連続アクセスで読み込める • 全頂点のラベルはメモリ上に保持しなければならないが、グラフ データサイズで支配的なのは |E| であって、|V| は小さい • Coarsen 後はグラフが小さくなるのでメモリに載る 43
  44. 44. 評価: Sequential MLP • MLP を C 言語で実装し METIS と比較 • データセット • 頂点数 2M~5M、エッジ数 5M~40M 44
  45. 45. • METIS に比肩する エッジカット数 • 省メモリかつ高速 45 提案手法METIS
  46. 46. 評価: pMLP • pMLP を Trinity 上に実装し分散処理 • 全8ノード, RAM 48GB/machine データセット: LiveJournal (5M vertices, 40M edges) データセット: RMAT による生成 (平均次数26) 512M vertices, 6.5G edges 8ノードで4時間 46
  47. 47. 47

×