Recomendados
Más contenido relacionado
Similar a StreamGraph
Similar a StreamGraph (20)
Último
Último (7)
StreamGraph
- 1. Wikipedia の編集履歴を用いた 大規模 2 処理 竹野 創平*1、上野 晃司*1、雁瀬 優*1、鈴村豊太郎*2 *1 東工大, JST CREST *2 東工大, JST CREST, IBM 東京基礎研究所
- 2. 発表の構成 • はじめに • データストリーム処理とは • データストリーム処理系 System S • 大規模グラフ処理 • 必要性、問題定義、関連性解析、高速化手法、関連研究 • 実装 • 評価 • 対象とするデータ：Wikipedia • 議論 • まとめ
- 3. データストリーム処理とは ネットワーク、その他の技術の発達による 即時性の高い 膨大なリアルタイムデータ… 情報が手に入 例：ウェブ、スマートフォン、株式市場 る！ ストレージに蓄積せず に リアルタイ メモリ上のみで逐次処 ムで活用し 理 たい データストリーム バッチ処理 処理 バッチ処 即時の応答が可能 データの一部を参 蓄積後の応答 データ全体を参照 理蓄積したデータに 照 => 解析精度の限界 => 詳細な解析 詳細な解析処理 ストレージは不要 大規模ストレージ
- 4. データストリーム処理系 System S • データストリーム処理系 • 並列分散環境上で高速・簡易にデータストリーム処理を実行するミドル ウェア • System S (IBM Research), S4 (Yahoo! Inc.) …etc. データフローを記述し、オペレータ（ ）単位で処 理を適用 Source 組み込み オペレー タ ユーザー定義 オペレータ Source Filter MyOperator Sink C/C++,Java
- 5. 大規模グラフ処理
- 6. 大規模グラフ処理の必要性 インターネッ ソーシャル ト lumeta.com ネットワー lumberjaph.net ク • バッチ的な大規模グラフ処理の研究 • 一方で、リアルタイムでの大規模グラフ処理の要求 • 市場調査、株式市場、など データストリーム処理による解 決
- 7. 大規模グラフ処理の必要性 インターネッ ソーシャル ト lumeta.com ネットワー lumberjaph.net ク • バッチ的な大規模グラフ処理の研究 • 一方で、リアルタイムでの大規模グラフ処理の要求 • 市場調査、株式市場、など データストリーム処理による解 決 商品-ユーザー、株式-売買人、有名人-ファン
- 8. 問題定義 • 2部グラフを対象とする • 頂点間の関連性解析を行う • 解析精度と応答性の両立が必要 常時データストリーム処理を行い、 定期的にバッチ処理を実行するシステムが必要！ 2部グラフ
- 9. 問題定義 高速化のために コミュニティ構 造が必要 • 2部グラフを対象とする • 頂点間の関連性解析を行う • 解析精度と応答性の両立が必要 常時データストリーム処理を行い、 定期的にバッチ処理を実行するシステムが必要！ 2部グラフ
- 10. 大規模グラフに対する関連性解析 • 関連性解析アルゴリズム Random Walk with Restart [Tong,2006] 2部グラフに特化した解析アルゴリズム へ • バッチ処理 : BB_LIN [Tong,2008] - O(L3) • データストリーム処理 : FSU(Fast-Single-Update) [Tong,2008] - O(L2) • BB_LINの結果を近似的に差分更新することで、全体の再計算を避ける ただし、大規模な2部グラフに対してはそのまま適用 不可 L＝ バッチ処理 … 現実的な時間内で終わらない データストリーム処理 … 到着レート以内に処理でき ない
- 12. グラフ分割による高速化 • 高速化手法：グラフを分割する コミュニティ構 造
- 13. グラフ分割による高速化 • 高速化手法：グラフを分割する 計算量は小さい方の頂点群に依 存 コミュニティ構 → 小さい方の頂点群のみ分割 造
- 14. グラフ分割による高速化 • 高速化手法：グラフを分割する 計算量は小さい方の頂点群に依 存 コミュニティ構 → 小さい方の頂点群のみ分割 造 グラフ分割ライブラリ METIS[Karypis,1998] により分割
- 15. グラフ分割による高速化 • 高速化手法：グラフを分割する 計算量は小さい方の頂点群に依 存 コミュニティ構 → 小さい方の頂点群のみ分割 造 グラフ分割ライブラリ METIS[Karypis,1998] により分割 別々に 並列処理
- 16. 関連する先行研究 • Neighborhood Formation and Anomaly Detection in Bipartite Graphs * • グラフ分割を用いた２部グラフ解析（バッチ処理） • グラフ分割を用いた大規模 2 部グラフのデータストリーム 処理 ** • データストリーム処理のみの評価 • 対象の2部グラフが十分大規模でない • 本研究 • バッチ処理を実装、バッチ処理とデータストリーム処理のトレードオ フを検証 • 大規模２部グラフに対しての最適化及び適用による評価 * Sun, J., Qu, H., Chakrabarti, D. and Faloutsos, C. / (2008). ** 雁瀬優,上野晃司,鈴村豊太郎 / 情報処理学会論文誌 (ACS 論文誌第 35 号) (2011).
- 17. 関連する先行研究 • Neighborhood Formation and Anomaly Detection in Bipartite Graphs * • グラフ分割を用いた２部グラフ解析（バッチ処理） • グラフ分割を用いた大規模 2 部グラフのデータストリーム 処理 ** • データストリーム処理のみの評価 • 対象の2部グラフが十分大規模でない • 本研究 • バッチ処理を実装、バッチ処理とデータストリーム処理のトレードオ フを検証 • 大規模２部グラフに対しての最適化及び適用による評価 * Sun, J., Qu, H., Chakrabarti, D. and Faloutsos, C. / (2008). ** 雁瀬優,上野晃司,鈴村豊太郎 / 情報処理学会論文誌 (ACS 論文誌第 35 号) (2011).
- 18. 実装
- 19. システム要件 • 常時データストリーム処理を行い、定期的にバッチ処理 • グラフ分割の機能 • グラフ分割はバッチ処理時に実行（定期実行） • 定期実行時点では存在しなかった頂点の分割をどうするか（新規 頂点） • グラフ全体の格納 • エッジデータの追加が頻繁 • ある頂点についての列を一定時間で取り出せる • 疎行列演算を行う
- 20. バッチ処理時の動作 • Splitオペレータ • グラフ全体のデータを元に、 グラフをいくつかのサブグ ラフに分割し、その結果を マッピングに保持 • マッピングに従い、それぞ れのSubGraphオペレータ にグラフデータを送信 • SubGraphオペレータ • Splitオペレータから受け 取ったサブグラフデータを 隣接行列として保持 • BB_LINを実行し、頂点間 の関連性を解析、これを 「学習行列」として保持
- 21. データストリーム処理時の動作 • Sourceオペレータ • 外部からエッジ情報を受け 取り、Splitにエッジを送信 • Splitオペレータ • 受け取ったエッジをグラフ 全体のデータに反映 • マッピングに従って、適切 なSubGraphにエッジを送 信 • SubGraphオペレータ • 受け取ったエッジをサブグ ラフの隣接行列に反映 • FSU（Fast- Single−Update）を実行し、 学習行列を更新
- 22. 新規頂点の分割先 • データストリーム処理中に、バッチ処理グラフ分割時点 では存在しなかった頂点が現れたらどのサブグラフに配 属するか？ • 準備：適切な配属先サブグラフを決定するため、エッジ を新規頂点ごとのバッファに溜めていき、一定数に達し たら下記計算を実行 • 計算：現在のサブグラフのいずれかに配属したときに、 最も関連性の欠損が少なくなるようなサブグラフを計算 する。
- 23. グラフ全体の格納 • エッジデータの追加が高速 • 疎行列演算がそのまま可能 • CSR形式に似たデータ構造 • 列ベクトルの取り出しが容 易 • 時々ソートして重複を解消
- 24. グラフ全体の格納 • エッジデータの追加が高速 • 疎行列演算がそのまま可能 • CSR形式に似たデータ構造 • 列ベクトルの取り出しが容 易 • 時々ソートして重複を解消
- 25. 性能・精度の評価
- 26. 評価目的 • 精度低下になりうる要因 • グラフ分割による近似 • Fast-Single−Updateによる近似 • 分割数を増やしてスケールするか • バッチ処理とデータストリーム処理、 精度と即応性のトレードオフはどの程度か
- 27. 対象とするデータ: Wikipedia • Wikipedia（日本語版）の編集履歴を利用 • 編集者と記事の２部グラフ • 書き込みがユーザー – ページ間のエッジとなる • 書き込み頻度は,2011 年 3 月時点て 平均9.2 回/分 • ２つのスケールで評価 • 5000ユーザー • 200000ユーザー • ユーザー数 20万、ページ数 約180万、エッジ数 約2200万 • 実運用：編集の促進…特に大きな事件が起きたときなど
- 28. 評価環境 • 4ノードを使用 • CPU • 1ノードにつきIntel Xeon X5670(2.93GHz,6 コア)が2ソケット • 合計48コア • メモリ：1ノードにつき8GB • OS：CentOS 5.4 （カーネルVer：2.6.18） • ソフトウェア：InfoSphere Streams1.2.0(System S), gcc 4.1.2, METIS 4.0, ATLAS 3.8.3, LAPACK 3.3.0 • ネットワーク環境：1GB Ethernet • オペレータへの割り当て • Source,Splitに1台(12コア) • SubGraphに3台(36コア) • 実験 物理コアと 法による • gcc ”-O3 ”
- 29. 5,000ユーザーにおける実験結果 精度の評価方法 • グラフ分割なし、3分割,6分割,9分割 • 開始時点と後半、2回バッチ処理を実行 実アプリケーションにおける利 用を想定し、あるページに最も 関連する上位10個のページ （Top10)の精度を測定 比較対象： グラフ全体のデータを用いた Random Walk with Restart法に よるTop10 ・ランダムに選んだ25個のサン プルページの平均を利用 バッチ処理 バッチ処理
- 30. 200,000ユーザーにおける実験結果 • グラフを分割9分割,15分割,30分割 • 予備実験： • 150000エッジをデータストリーム処理した が、 関連性の変化は1%以内 • 30分割において、4.9エッジ/秒 …実データレートの約32倍 バッチ処理時点での精度 データストリーム処理時のスループット バッチ処理BB_LINの実行時間
- 31. 議論・まとめ
- 32. 議論 • ストリーム処理を続けていくと過去の蓄積が大きくなり、相対的に現 在のデータの影響力が小さくなる • 現実の複雑ネットワークグラフは、大部分の頂点は僅かなエッジしか 持たず、一部の頂点が多くのエッジを持つ傾向 ・データの新しさに応じてエッジに重み付けを行う ・古くなり一定以上影響の小さい頂点を削除する • 200,000ユーザーと5,000ユーザーの精度差 →蓄積による分割精度の 差？ • Wikipediaは時系列上での変化が小さいグラフだった可能性 変化の大きい大規模2部グラフによる検査・評価
- 33. まとめと今後の展望 • まとめ • 頂点数 20万、184万、エッジ数2200万である ウェブの大規模2部グラフを4ノード48コアで処理 • グラフ分割数に対して2乗、3乗の高速化を実現 • 実データレートの32倍でデータストリーム処理を実現 頂点数 200,000, • 7割以上の解析精度をバッチ処理で実現 分割数30 • 今後の展望 • 時系列変化が大きい大規模グラフへの適用 • データの新しさに応じたエッジの重み付け • TSUBAMEでの大規模評価
- 34. 参考文献 • [1] Tong, H., Faloutsos, C. and Pan, J.-y.: Fast Random Walk with Restart and Its Applications, ICDM ’06: Proceedings of the Sixth International Conference on Data Mining, Washington, DC, USA, IEEE Computer Society, pp.613–622 (2006). • [2] Tong, H., Papadimitriou, S., Yu, P.S. and Faloutsos, C.: Proximity Tracking on Time-Evolving Bipartite Graphs (2008). • [3] Karypis, G. and Kumar, V.: Multilevel k-way Partitioning Scheme for Irregular Graphs, Journal of Parallel and Distributed Computing, Vol.48, pp.96–129 (1998).