コミュニティ解析サービス、Twitter SmartList ( http://smartlist.bz )の苦労話やアルゴリズムなどです。 第5回若手Webエンジニア発表会にて、発表させていただきました。 http://www.zusaar.com/event/733053

1. コミュニティ解析サービス
Twitter SmartList
@mosa_siru
(第5回若手Webエンジニア交流会)
13年6月14日金曜日

2. • @mosa_siru って誰よ（聞き流し推奨）
• Twitter SmartList
• 工夫した点など
• コミュニティ分類アルゴリズムの紹介
アジェンダ
13年6月14日金曜日

3. お前誰よ
13年6月14日金曜日

4. • DeNA13年度新卒(研修中)
• 東大にて応用数学を専攻
• 複雑ネットワークのコミュニティ分類手法を研究
@mosa_siru
13年6月14日金曜日

5. なんかマトモそうな
経歴に見えますが…
13年6月14日金曜日

6. 実際はただの
ボンバーマンオタクです
＼(^o^)／
13年6月14日金曜日

7. • ボンバーマン極めてたら二留しました
• http://www.nicovideo.jp/watch/sm13612359
• 技解説動画が、はてぶで「注目の動画」になる
13年6月14日金曜日

8. でも1年半前から
バイト(脱ニート)して
Web系エンジニアに。
13年6月14日金曜日

9. • 勤怠管理システム (バイト先)
‣ PHPで酷いコードを書く
• 平民 (個人) http://heimin.herokuapp.com
‣ あがってはいけない大富豪。奥が深くローカルルール満載。
‣ Rails/ WebSocket(Pusher) / Memcached /CoffeeScript /
Canvas(EaselJS)
• Twitter SmartList (個人)
‣ これを紹介します。
プロダクト
13年6月14日金曜日

10. Twitter SmartList
13年6月14日金曜日

11. • ヘビーユーザーなのでリストを使いたい！
• でもリストって作るの面倒くさいですよね
Twitter
一人一人追加して、リストを選んで…面倒！！
→自動化したい！！
13年6月14日金曜日

12. 卒論のついでに
つくってみた
（というかこれを作りたいから
卒論のテーマをコミュニティ解析にしました）
13年6月14日金曜日

13. 13年6月14日金曜日

14. 13年6月14日金曜日

15. • smartlist.bz
• フォロー関係を元に、コミュニティが可視化される
• 100人以上のリストも簡単につくれる！
Twitter SmartList
13年6月14日金曜日

16. • 定量評価は難しいですが、 Twitterでのユーザーの評
判はかなり良好。
• 僕の場合以下のコミュニティに見事に分かれまし
た。
‣ ボンバーマン・ネット界隈
‣ 競技プログラマー
‣ 大学
‣ サークル
‣ etc..
コミュニティ分類精度
13年6月14日金曜日

17. • Ruby on Rails
• Twitter APIでフォロー情報を取ってくる
• コミュニティ解析：Python (networkx)
‣ XMLRPCでRubyと同期通信
‣ アルゴリズムは後で紹介
• サーバー：Nginx + unicorn さくらVPS
• データベース：Redis
構成
13年6月14日金曜日

18. 工夫した点
13年6月14日金曜日

19. • フォローしている友人の友人関係を取り出す必要が
ある
単純にデータベースに格納すると、700人フォロー
のユーザーを1人解析しただけでも、2万件ほどの友
人関係の情報となる
• リストとして友人関係を一気に
格納するために、Redisを使用した
• オンメモリなKVSで、動作が速い
(bulk insertなしに3.7秒で友人情報を全て格納)
• スキーマレスなので、手軽に解析結果も格納できる
(1)Redis
13年6月14日金曜日

20. 【参考】このくらい友人情報が多い
@mosa_siru の友人間のネットワーク
13年6月14日金曜日

21. • 取るべき情報：
• フォローしている友人のプロフィール情報
• フォローしている友人の友人関係
• フォロー数750人のユーザー解析には、1500回API
を叩く必要がある！
→単純にAPIを叩くと、17分かかった
→並列処理でAPIを叩くことで、33秒に！
• gem ‘parallel’ がお手軽。
(2)並列処理
13年6月14日金曜日

22. • コミュニティ解析の計算に数分かかる場合があるの
で、バックグラウンドで計算する
• gem ‘resque’でジョブキューに入れて非同期実行
(3)非同期実行
13年6月14日金曜日

23. でもこのサービス
もう動きません
13年6月14日金曜日

24. 13年6月14日金曜日

25. 13年6月14日金曜日

26. • Twitter API ver 1.0 では、しかるべき手続きを踏め
ばアカウントが「White List」に入れて、1時間に
20000回リクエストを送れた
• しかしver 1.1では、15分に15回しか友人情報を取得
できない
（ユーザー1人の解析につき1000回とか必要）
• ver 1.0 は、2013/06/11に廃止された
こういうことです
13年6月14日金曜日

27. うん、それ無理。
13年6月14日金曜日

28. • 15分ごとに、ログインユーザのOAuthトークンを用
いてちまちまAPIを叩くことで、せめて1日後には結
果が表示されるようにする
• 誰が使うんだろうそのサービス…
対策案
13年6月14日金曜日

29. • APIを使ったサービスや、マッシュアップは、お手
軽に良さげなサイトが作れます。
• でもその分、API提供元に振り回されることになり
ます。
教訓
13年6月14日金曜日

30. (このまま終わっても悲しいので)
アルゴリズムの解説をします
13年6月14日金曜日

31. • この世にある色んな関係は、「頂点」と「枝」だけで
モデル化することができます。
• そこに潜む特徴的な性質を見つけ出す学問が「複雑ネ
ットワーク」です。
• 例：「6次の隔たり」(スモールワールド性)
友人の友人の友人の友人の友人の友人がアルカ⃝ダ
は、全ての人に言える確率が高い。
複雑ネットワーク
13年6月14日金曜日

32. • ネットワークの一部のうち、内部に枝が相対的に多く
見出されるようなもの。
• 様々な厳密な定義と分類アルゴリズムが存在。
‣ コミュニティのオーバーラップ（頂点が複数のコミュニティに属
すること）を許すか否かで二分されます。
コミュニティ
13年6月14日金曜日

33. オーバーラップを許さない手法
(よく研究されている)
オーバーラップを許す手法
(最近注目されだした)
• グラフ分割
• 階層的クラスタリング
• Girvan-Newman Algorithm
• Modulatiry最適化
• Surprise最適化
• Clique Percolation Method
• 線グラフ化
• Girvan-Newman Algorithm の拡張
• Modularityの拡張
• 今回はオーバーラップを許す方が自然。
(例：サークルのとある友人は、職場の友人でもある。)
• 有名なClique Percolation Method (CPM)
Palla et al. 2005[1] を用いました。
コミュニティ分類手法
13年6月14日金曜日

34. Clique Percolation Method
(CPM)
13年6月14日金曜日

35. その前に用語の定義
（グラフ理論の話）
13年6月14日金曜日

36. クリーク(clique)
• クリーク：グラフ(ネットワーク)の一部で、任意の
頂点のペアが全て枝で結ばれているような頂点集合
‣ グラフの中にたくさんあります
• 極大クリーク：他のクリークの一部とならないよう
なクリーク
‣ これもたくさんあります
【例】
三角形のクリーク(3-クリーク)がたくさん
ある。
例えば赤い4点は 4-クリークとなり、極大
クリークである。
13年6月14日金曜日

37. 無向グラフ・有向グラフ
• 有向グラフ：枝に向きがついているグラフ
• 無向グラフ：枝に向きがないグラフ
(他にも重みがついているグラフなどがあります。)
13年6月14日金曜日

38. CPMのコミュニティ定義
• 以下無向グラフとします．自然数 k を取り、「k-クリ
ークコミュニティ」を定義します。
• k-クリークコミュニティ：「隣接」する頂点数 k 以上
の極大クリークを経由して互いに行き来できるクリー
ク集合
• 隣接： k - 1 個以上の頂点を共有すること
k = 4 での例．
三角形を共有すれば隣接する．
4-クリークコミュニティの例
13年6月14日金曜日

39. よくわからないかもしれませんが、
現実のネットワークでは、この定義で
上手く分類できるケースが多いです。
13年6月14日金曜日

40. この定義のもとでの解析アルゴリズムを
高速化したのが卒論のテーマであり、
SmartListにも使われています。
13年6月14日金曜日

41. まとめ
• Twitter APIを使うと、色々楽しいことができます。
‣ それでも並列処理など、工夫する点があります。
‣ そして、APIに振り回されます。
• 数学やアルゴリズムの勉強をすると、なんだかんだ
で面白いことができます。
• 一番面白いのはボンバーマンです。
13年6月14日金曜日

42. お疲れ様でした。
• @mosa_siru
• まだまだWeb系エンジニア新人
なので、仲良くしてください！
• SmartListが再稼働したときは試してみてください！
※以降の資料は、アルゴリズムの詳細解説となります。
13年6月14日金曜日

43. ここからはアルゴリズムを
詳しく知りたい人向け。
（完全に付録）
13年6月14日金曜日

44. CPMの特徴
• オーバーラップを許容
• あるコミュニティの生成過程が他のコミュニティに影
響されることはない
• ローカル（辺や頂点が変更されても，コミュニティへ
の影響は局所的である）
• 確率的な手法や近似を行っていないため，決定性があ
り，結果に再現性がある．
• k の値を変更することで，抽出条件の厳しさを調整す
ることができる．
13年6月14日金曜日

45. CPMの実装
• CFinder： Palla et al. 2005 [1]
‣ 原型となる実装．ソフトウェア化されている．
• Sequential CPM (SCP)： Kumpula et al. 2007 [2]
‣ 疎なグラフで，k = 3, 4 程度で高速．
• CPM on steroids (COS)： Gregori et al. 2012 [3]
‣ 並列計算を可能にし，プロセッサーの数に比例して高速化．
• fast CPM (f-CPM)：Reid et al. 2012 [4]
‣ CFinderを高速化し，巨大で密なグラフも計算可能にする．
13年6月14日金曜日

46. CFinderのアルゴリズム
1.グラフ上の極大クリークを
全て抽出
2.極大クリーク間の
共有頂点数を全て調べ，
行列で表示
（クリークグラフ）
3. k 以上の対角成分，k - 1
以上の非対角成分を残す
4.この操作によりできた
グラフの連結成分が
k- クリークコミュニティ．
4 2 2 1
2 3 1 2
2 1 4 3
1 2 3 5
1 0 0 0
0 0 0 0
0 0 1 1
0 0 1 1
4
4
5
3
2
2
1
3
2
1
(1) 元のグラフ (4) k-クリークコミュニティ
(2) クリークグラフ (3) クリークグラフへの操作
k = 4 対角成分は k 以上，
それ以外の成分は
(k-1) 以上を残す．
連結成分を抽出
極大クリーク間の
共有頂点を見る
13年6月14日金曜日

47. CPMの計算困難性(1)
• 極大クリーク数の二乗回，共有頂点数を調べる必要あり
‣ グラフが密な場合，大量に極大クリークが存在することがある．（例：
ソーシャルグラフ）
‣ カリフォルニア工科大学生のfacebookネットワークでは，
頂点数769 に対し極大クリーク数は31745．k = 5 での隣接する極大ク
リーク対は170万以上にのぼる． (Reid et. al. 2011)
‣ このような例では，極大クリーク対はほとんど同じ頂点を共有する．
‣ 極大クリーク数が多くなる理由として，大きな極大クリークから一部の
枝を取り除くと，大量の極大クリークが生成されることが挙げられる．
(例) 6-クリークから辺を2本取り除くと，
4つの極大クリークが生成される．
13年6月14日金曜日

48. CPMの計算困難性(2)
• 頂点や枝によって k- クリークコミュニティは表現できな
い．膨大な数の k- クリーク集合か極大クリーク集合で表
す必要がある．
‣ k-クリークコミュニティは， k- クリークに属していないような (k - 1)-ク
リークを含みうるため（図）．
‣ あるクリークが k- クリークコミュニティのどれかのクリークに隣接する
か否か調べるためには，コミュニティ内の全ての極大クリークか k- クリ
ークに対し共有頂点数を調べねばならない．
(例)k = 4. 緑と橙の頂点はk-クリークコミュニティ
をなすが，青の頂点はこのコミュニティに含まれ
ない．
13年6月14日金曜日

49. fast CPM (f-CPM)
• クリークグラフを作らない．極大クリーク間の不要な隣接
判定を行わないことにより高速化．
‣ 極大クリークAとBが隣接し，BとCが隣接することがわかったら，A, B,
Cは1つのコミュニティに属しているので，AとCが隣接するか否か調べ
る必要はない．
‣ 1つも共有頂点を持たない極大クリーク同士の共有頂点数は調べる必要
はない．
• 密なネットワークに対してもCPMが適用できるようにな
る．
49
13年6月14日金曜日

50. directed CPM (CPMd)
• 有向グラフに対するCPM．Palla et al. 2007 [5]
‣ 以下のように有向クリークを定義した上でのCPM．
‣ 枝の向きを無視してCPMすることはできるが，きちんと向きを考慮にい
れる．
• 有向クリークの定義：「ある部分グラフにおいて，任意の
頂点間に枝が存在し，DAGである（＝閉路を持たな
い）．」
‣ ただし双方向枝( )がある場合は，それを無視した上で閉路判定する．
‣ Palla et al. 2007 [5]の定義とは異なるが，同値な定義を採用．
50
13年6月14日金曜日

51. 有向クリークの例
0
2
0
2,3 2,3
1,2
1
3
0
2
2
2
1
1,2
1,2
2
(a) 双方向枝なし
(c) 双方向枝あり (d) 双方向枝あり
(b) 双方向枝なし
有向クリークである 有向クリークでない
51
13年6月14日金曜日

52. 提案手法「fast CPMd 」(f-CPMd)
• CPMdの既存手法では，有向クリークを抽出した後，
CFinderと同様のアルゴリズムを用いていた．
• ここにf-CPMと同様の改良を施すことで高速化する．
提案手法のアルゴリズム
1. 無向グラフにし，全ての極大クリークを列挙
‣ Bron-Kerbosch Algorithm [6] の高速化 (Koch et al. 2001 [7])
2. 極大クリークに対し，有向グラフにおいて対応する部分グラフから双方向
枝を取り除き，DAG判定
3. 得られた有向極大クリーク集合を用いてf-CPMを行う
52
13年6月14日金曜日

53. 提案手法の速度評価実験(1)
• CPMdとf-CPMdの速度を比較．
• データセット
SmartListで取得した，あるユーザーを基点にしたフォロ
ーネットワーク（下図）において，p|V|個 (0<p≦1)の頂点を
ランダムに選んでデータセットを複数作成
53
頂点数 |V| 380
枝数 |E| 5600
有向極大クリーク数 4063
有向極大クリークの平均頂点数 6.216
有向最大クリークの頂点数 14
13年6月14日金曜日

54. 提案手法の速度評価実験(1)結果
• CPMdもf-CPMdも，頂点数に対し計算時間は指数的
• p = 0.9 では，提案手法が350倍以上速い．
• p = 1.0 では，既存手法は11時間以上かけても計算が終わ
らなかった一方で，提案手法は6.7秒で終了した．
13年6月14日金曜日

55. 提案手法の速度評価実験(2)
• f-CPMdの計算量の内訳（以下）を評価．
1. 無向グラフに変換して極大クリークを抽出
2. 有向グラフにおいてDAG判定
3. 得られた有向極大クリークに対しf-CPM
• データセット
SmartListで取得した，あるユーザーを基点にしたフォロ
ーネットワークを複数用意．
データ1 データ2 データ3 データ4 データ5
頂点数 802 1175 1026 773 524
枝数 20566 38353 15870 28287 14821
有向極大クリーク数 14880 59215 12294 125905 15722
有向極大クリークの平均頂点数 9.068 5.782 5.064 14.16 14.75
有向最大クリークの最大頂点数 27 17 13 24 26
13年6月14日金曜日

56. 提案手法の速度評価実験(2)結果
• 有向極大クリーク数とその頂点数が多いグラフでは，
(3)f-CPMの計算時間が支配的
13年6月14日金曜日

57. 参考文献
[1] G. Palla, I. Derényi, I. Farkas, and T. Vicsek. Uncovering the overlapping community
structure of complex networks in nature and society. Nature, 435:814-818, 2005.
[2] J. M. Kumpula, M. Kivelä, K. Kaski, and J. Saramäki. Sequential algorithm for fast
clique percolation. Physical Review E, 78:026109, 2008.
[3] E. Gregori, L. Lenzini, and S. Mainardi. Parallel k-clique community detection on
large-scale networks. Parallel and Distributed Systems, IEEE Transactions on, PP:1, 2012.
[4] F. Reid, A. McDaid, and N. Hurley. Percolation computation in complex networks.
arXiv:1205.0038, 2012.
[5] G. Palla, I. J. Farkas, P. Pollner, I. Derényi, and T. Vicsek. Directed network modules.
New Journal of Physics, 9:186, 2007.
[6] C. Bron and J. Kerbosch. Algorithm 457: finding all cliques of an undirected graph.
Communications of the ACM, 16:575-577, 1973.
57
13年6月14日金曜日