大規模データを対象とした分析処理の 高速化に関する取り組み1....
TRANSCRIPT
Copyright 2012 NTT Corporation
大規模データを対象とした分析処理の高速化に関する取り組み
1
鬼塚 真 主幹研究員(特別研究員)
NTTソフトウェアイノベーションセンタ
自己紹介
2
所属など NTT ソフトウェアイノベーションセンタ 主幹研究員(特別研究員)
群馬県出身,ワシントン大(911の時)
過去の研究開発テーマ オブジェクトリレーショナル DBMS の研究開発 XMLストリーム処理/DBMSの高速化 CBoC type2 分散テーブルの開発
現在の研究テーマ MapReduce の高速化
機械学習の高速化 (クラスタリング,ランダムウォーク等)
最先端ハードウェアを利用した高速インデックス
画像検索 ホームラン検索
テレビ番組通知
ニュース配信
カラオケ検索
3
管理情報区分:B 関係者限り
© 2012 NTT Software Innovation Center
分散処理による大規模データ分析の背景・狙い
大規模データを高速に処理できる分析システムを短期間で開発できる技術の確立
・情報爆発と言われる時代を迎え、情報処理システムにおける大規模データ処理に対するニーズが高まっている ・NTTグループ各社においても、各種ログ情報などの大量データをビジネス・サービスへ活用しようとする動きが進んできている
背景
狙い
4
管理情報区分:B 関係者限り
© 2012 NTT Software Innovation Center
分散処理による大規模データ分析の概要
技術目標: 単一マシン向けの分析プログラム(機械学習・統計処理)から最
適な分散処理プログラムを導出
技術課題 1. 抽象言語から分散プログラムの導出・最適化(NII胡教授) 2. 分散処理プログラムの高速処理アルゴリズム
統計処理(集約処理,結合処理)の高速化 機械学習(クラスタリング・推薦)の高速化
3. 最新ハードを利用した高速化・省電力 (東工大横田教授)
select m.source, m.dest, m.count, c.rank from (select n.dest, sum(n.rank/n.count) as rank from Graph as n group by n.dest) as c,Graph as m where m.source = c.dest
最適化 高速な分散処理
実行計画
Copyright 2012 NTT Corporation
目次
大規模データ分析について
分析処理の高速化の取り組み MapReduce の高速化 (HW2011)
Map Multi-Reduce: reduce の事前実行
PJoin: 事前パーティション分割と準結合の利用
機械学習の高速化
K-dash: Random Walk with Restart による高速
top-k 検索アルゴリズム (PVLDB2012)
グラフクラスタリングの高速化アルゴリズム
5
Copyright 2012 NTT Corporation
大規模データ分析について
6
大規模データ分析 MapReduce高速化 まとめ 機械学習高速化
Copyright 2012 NTT Corporation 7
大規模データ分析の適用例
n-gram/クラスタリングによる分析 データ: webコンテンツ/SNS
目的: 頻出パターンの学習
用途: 音声認識,日英翻訳
履歴を用いたパーソナライズ データ: web履歴・ビデオ視聴履歴
目的: RWR, トピックモデル学習
用途: パーソナライズ検索
ネットワークトラフィック解析 40Gbps トラフィックデータ
目的: パケット遅延・欠損検出
用途: QoS 制御, 障害解析
serve as the incoming 92
serve as the incubator 99
serve as the independent 794
…
4-gram
大規模データ分析 MapReduce高速化 まとめ 機械学習高速化
Copyright 2012 NTT Corporation
MapReduce の高速化
8
大規模データ分析 MapReduce高速化 まとめ 機械学習高速化
Copyright 2012 NTT Corporation
MapReduce とは?
分散処理のプログラミングモデル&システム 高スケール性: 1万ノード(マシン),ペタバイトデータ シンプルなAPI: map関数/reduce関数 分散処理特有の複雑さ(負荷分散・可用性)が隠ぺい
Google が開発 webの検索エンジンのバックエンドの用途のため開発
PageRank 計算,転置ファイル構築 2008年時点で 20PB/day を MapReduceで処理 [Dean et al., OSDI 2004, CACM Jan 2008, CACM Jan 2010]
Hadoop project においてオープンソース化
大規模データ分析 MapReduce高速化 まとめ 機械学習高速化
Copyright 2012 NTT Corporation
MapReduce のアーキテクチャ
10
MapReduce: 分散処理システム
分散ファイルシステム DFS 上で構築 DFS: GFS (Google FS), HDFS (Hadoop DFS)
2フェーズ + Shuffle Map フェーズ: 入力レコード毎にmap関数を実行
ポイント: マシン毎に独立した処理
Shuffle:同一key の(key, value) 群を束ねる
Reduce フェーズ: 束ねた結果に reduce 関数を実行
ポイント: 複数マシンにまたがり必要な処理
大規模データ分析 MapReduce高速化 まとめ 機械学習高速化
Copyright 2012 NTT Corporation
MapReduce のアーキテクチャ(続き)
11
User Program
Input Data
Split 1
Split 0
Split 2
Split 3
Split 4
read local write
fork fork
fork
assign map
assign reduce
Output File 0
Output File 1
node
process
file
worker
Master
worker
worker
worker
worker
worker
worker
Map タスク Map タスク Map task Reduce タスク Reduce task
remote read, sort
shuffle
大規模データ分析 MapReduce高速化 まとめ 機械学習高速化
Copyright 2012 NTT Corporation
プログラム例: wordCount 入力文書毎に map関数を適用する
単語毎に (word, 1) を出力する
12
単語毎に頻度を積算する
[Dean et al., OSDI 2004]
大規模データ分析 MapReduce高速化 まとめ 機械学習高速化
Copyright 2012 NTT Corporation
MapReduce の設計思想
13
以下の要素からなるモデル・システム
関数型言語のインタフェース • map (f) [r1,...,rn] = [f(r1),...., f(rn)]
• reduce (⊕) [r1,...,rn] = r1 ⊕ .... ⊕ rn
分散環境への適用 • map:マシン内データ処理,reduce:マシン間データ処理
• 論理プラン = 物理プラン
• (key, value) + partition 関数によるシャッフル処理
• エラー処理などの分散特有の処理を隠ぺい
• ファイルを介してプロセス間通信 (高速なリカバリ)
MapReduce 導入 高速化の研究動向 研究の方向性 高速化の取り組み
Copyright 2012 NTT Corporation
MapReduce: デザインパターンと実施例
14
MapReduce プログラムのデザインパターン Local Aggregation
Pairs and Stripes
Computing Relative Frequencies
Secondary Sorting
Relational Joins
MapReduce の利用例 転置インデックス
グラフアルゴリズム(幅優先探索など)
EMアルゴリズム
大規模データ分析 MapReduce高速化 まとめ 機械学習高速化
Copyright 2012 NTT Corporation
MapReduce 高速化の取り組み
1. Map Multi-Reduce: MapReduce extended with reduce pushdown
15
skip
大規模データ分析 MapReduce高速化 まとめ 機械学習高速化
Copyright 2012 NTT Corporation 16
Motivation
Performance problems in MapReduce [DeWitt, 2009] no schema, no index, ignoring data skew,
communication cost, materialization cost In particular materialization/communication costs
Copyright 2012 NTT Corporation 17
Overview of Map Multi-Reduce Idea:
Pushing down reduce function and iteratively applying it so as to reduce intermediate data.
Efficiency:
2.4 times more efficient than original MR in real dataset
Limitations and opportunities • reduce function needs to be associative and commutative
: summation, count sum(2,3,1) = sum(sum(2,3),1) : average avg(2,3,1) != avg(avg(2,3),1)
• reduce function reduces intermediate data : statistical computation: word count, OLAP queries : sort, building inverted index
Copyright 2012 NTT Corporation 18
BTW, what is the pushdown? A well-know technique in DBMS pushdown reduces intermediate data size,
while ensuring the correctness of query result Usually effective for single query optimization
SELECT person.name, dept.name
FROM dept, person
WHERE person.age > 20
AND person,deptid = dept.id
Query
dept person
join
selection
execution plan 1
projection
dept person
join
selection
execution plan 2
projection
Pushing down reduce function in MapReduce
Copyright 2012 NTT Corporation
Technique 1: incremental reduce
19
hashmap<key, value> is used for record structure reduce function is applied before buffering at map task
Split N Map
function MapOutputBuffer sort&spill Spill files mergeParts Output file
Map
function
Reduce
function
Record reduce
Split N MapOutputBuffer sort&spill Spill files mergeParts Output file
Reduce function is applied incrementally
Original MapReduce
Copyright 2012 NTT Corporation
User Program
worker
worker
worker
Input Data
fork fork
fork
Master
worker
worker
assign map
assign reduce
local write
remote read, sort
Output File 0
Output File 1
Split 1
Split 0
Split 2
Split 3
Split 4
read
worker
worker
worker
worker
worker
assign local reduce
Technique 2: Local reduce
21
node
process
file
local reduce task applies the reduce function to the map outputs of the same node
Master also controls local reduce tasks
Local Reduce タスク Local Reduce タスク Local reduce task
Copyright 2012 NTT Corporation
Experiments
23
Hardware/software settings Linux (CentOS5.4, 2.8GHz, main memory 8GB)×90 nodes Java1.6, Hadoop 0.19.2
Workload Datasets: ・Trec terabyte dataset
0.5TB, # of unique terms 86,500k, 678 terms/input record ・synthetic datasets (with uniform term distribution)
0.5-7TB, # of unique terms 100-400k, 62 terms/input record Analysis pattern: wordCount
Purpose Comparison: Map Multi-reduce variations vs MapReduce IO reduction effect by record/local reduce Scalability, effect of # of unique terms
Copyright 2012 NTT Corporation
Response times (Trec terabyte) response time is improved by 58%, 2.4 times faster. effect of local reduce
with record & local reduces, performance of map phase is improved, however 6% gets worse as a whole caused by local reduce overhead.
24
58% 52% With record reduce Without local reduce
with record reduce & local reduce
Copyright 2012 NTT Corporation
Effect by record reduce (Trec terabyte) Size of data put into buffer is reduced to 1/30 Size of spill files reduces to 1/3 (63% reduction) Performance improved mostly by IO cost reduction
25
1/30 1/12
Map
function
Reduce
function
Record reduce
Split N MapOutputBuffer sort&spill Spill files mergeParts Output file
Reduce function is applied incrementally
63% 67%
Copyright 2012 NTT Corporation 27
Related work Local aggregation
combiner: does not reduce the data put into the buffer in-mapper combining design pattern [Lin et al., 2010]
complicates the mapper and may run out of memory.
Split N Map
function MapOutputBuffer
sort&
combine&
spill
Spill files mergeParts
(combine) Output file
Copyright 2012 NTT Corporation 28
Summary of Map Multi-Reduce Idea:
Pushing down reduce function and iteratively applying it so as to reduce intermediate data.
Efficiency:
2.4 times more efficient wordCount than original MR in Trec terabyte
1.9 times than original MR in web N-gram
On going work: Extend Map Multi-reduce to support semantic
compression on keys (stripes design pattern)
Copyright 2011 NTT Corporation
MapReduce 高速化の取り組み
2. PJoin: Efficient join processing with MapReduce
for OLAP applications
29
大規模データ分析 MapReduce高速化 まとめ 機械学習高速化
Copyright 2011 NTT Corporation
技術の概要
PJoin (pre-partition-based join) [到達点] 多次元データ分析(OLAP)処理において,シャッフル量を 1/3 に削減することで処理時間を,従来技術より 42.8% 高速化
[戦略] 複数の分析処理において共通するシャッフル処理を前もって実行(事前処理)することで,分析処理時のコストを削減
30
Copyright 2011 NTT Corporation
背景: 多次元データ分析(OLAP)とは?
31
統計的な分析処理の典型的な手法 履歴・トランザクションデータを格納する factテーブル(大) fact テーブルを多角的な次元で集約演算を実施するための,複数の dimension テーブル
PARTKEY
NAME
MFGR
BRAND
TYPE
SIZE
CONTAINER
COMMENT
RETAILPRICE
PARTKEY
SUPPKEY
AVAILQTY
SUPPLYCOST
COMMENT
SUPPKEY
NAME
ADDRESS
NATIONKEY
PHONE
ACCTBAL
COMMENT
ORDERKEY
PARTKEY
SUPPKEY
LINENUMBER
RETURNFLAG
LINESTATUS
SHIPDATE
COMMITDATE
RECEIPTDATE
SHIPINSTRUCT
SHIPMODE
COMMENT
CUSTKEY
ORDERSTATUS
TOTALPRICE
ORDERDATE
ORDER-
PRIORITY
SHIP-
PRIORITY
CLERK
COMMENT
CUSTKEY
NAME
ADDRESS
PHONE
ACCTBAL
MKTSEGMENT
COMMENT
PART (P_)
SF*200,000
PARTSUPP (PS_)
SF*800,000
LINEITEM (L_)
SF*6,000,000
ORDERS (O_)
SF*1,500,000
CUSTOMER (C_)
SF*150,000
SUPPLIER (S_)
SF*10,000
ORDERKEY
NATIONKEY
EXTENDEDPRICE
DISCOUNT
TAX
QUANTITY
NATIONKEY
NAME
REGIONKEY
NATION (N_)
25
COMMENT
REGIONKEY
NAME
COMMENT
REGION (R_)
5
スター型スキーマ (TPC-H) クエリ 9 (TPC-H)
集約演算
多テーブル結合処理
グループ化
Copyright 2011 NTT Corporation
ハッシュ結合による方法:
• シャッフル量に起因する通信コスト・IOコストが大
通信コスト・IOコストの削減が最重要課題
背景: 従来の MapReduce 結合処理の課題
32
orders 1
hash(x)
mapper
…
lineitem n …
lineitem 1
Join
reducer
…
hash(x)
Join
orders n
Join
…
シャッフル量が大
hash(y)
hash(y)
製品単位の売り上げログ
伝票
Copyright 2011 NTT Corporation
[方針] テーブル結合処理時のシャッフル量を削減する
[前提] OLAP分析では,更新よりも参照処理の性能が重要
1対多の関係でテーブル結合処理する
[戦略]
複数の分析処理において共通的なシャッフル処理を 事前処理することで,分析処理時のコストを削減
• 結合条件(主キー)によるテーブルの事前シャッフル • 準結合の活用 + 中間データの事前生成
複数MapReduce 間でシャッフル量を削減する結合計画
[効果]
分析処理時のシャッフル量を削減
Nテーブル結合演算によりMapReduce job数を削減
PJoin の概要
33
Copyright 2012 NTT Corporation 34
BTW, what is the semi-join?
A well-know technique in distributed DBMS
Natural join (⋈)
Copyright 2012 NTT Corporation 35
BTW, what is the semi-join?
A well-know technique in distributed DBMS
Natural join (⋈)
Copyright 2012 NTT Corporation 36
BTW, what is the semi-join?
A well-know technique in distributed DBMS
Natural join (⋈)
Copyright 2012 NTT Corporation 37
BTW, what is the semi-join?
A well-know technique in distributed DBMS
Semijoin (⋉)(⋊)
Natural join (⋈)
Copyright 2012 NTT Corporation 38
BTW, what is the semi-join?
A well-know technique in distributed DBMS
Semijoin (⋉)(⋊)
Natural join (⋈)
Copyright 2012 NTT Corporation 39
BTW, what is the semi-join?
A well-know technique in distributed DBMS
Semijoin (⋉)(⋊)
Natural join (⋈)
Copyright 2012 NTT Corporation 40
BTW, what is the semi-join?
A well-know technique in distributed DBMS
Semijoin (⋉)(⋊)
Natural join (⋈)
Employee ⋈ Dept = (Employee ⋉ Dept ) ⋈ Dept
Copyright 2012 NTT Corporation 41
BTW, what is the semi-join?
A well-know technique in distributed DBMS
Semijoin (⋉)(⋊)
Natural join (⋈)
Employee ⋈ Dept = (Employee ⋉ Dept ) ⋈ Dept
Copyright 2012 NTT Corporation 42
BTW, what is the semi-join? (cont.)
A well-know technique in distributed DBMS semi-join is used before the original join, so as to
reduce communication cost between DB severs
Employee ⋈ Dep
Copyright 2012 NTT Corporation 43
BTW, what is the semi-join? (cont.)
A well-know technique in distributed DBMS semi-join is used before the original join, so as to
reduce communication cost between DB severs
(Employee ⋉ Dept ) ⋈ Dept
Employee ⋈ Dep
Copyright 2012 NTT Corporation 44
BTW, what is the semi-join? (cont.)
A well-know technique in distributed DBMS semi-join is used before the original join, so as to
reduce communication cost between DB severs
(Employee ⋉ Dept ) ⋈ Dept
Employee ⋈ Dep
Materializing foreign key table for semi-join
Copyright 2012 NTT Corporation
[方針] テーブル結合処理時のシャッフル量を削減する
[前提] OLAP分析では,更新よりも参照処理の性能が重要
1対多の関係でテーブル結合処理する
[戦略]
複数の分析処理において共通的なシャッフル処理を 事前処理することで,分析処理時のコストを削減
• 結合条件(主キー)によるテーブルの事前シャッフル • 準結合の活用 + 中間データの事前生成
複数MapReduce 間でシャッフル量を削減する結合計画
[効果]
分析処理時のシャッフル量を削減
Nテーブル結合演算によりMapReduce job数を削減
PJoin の概要
45
Copyright 2011 NTT Corporation
PJoin の特徴①: シャッフル量削減
46
テーブルの事前シャッフル実行
Pre-computation
lineitem
orders
hash(x)
hash(y)
…
lineitem b
lineitem a
lineitem z
orders 1
orders n
DFS read shuffle
製品単位の
売り上げログ
伝票
Copyright 2011 NTT Corporation
PJoin の特徴①: シャッフル量削減
47
テーブルの事前シャッフル実行,準結合中間データの事前生成
Pre-computation
lineitem
orders
hash(x)
hash(y)
…
lineitem b
lineitem a
lineitem z
orders 1
orders n …
lineitem_
orders n
lineitem_
orders 1 hash(y)
lineitem primary key &
foreign key (orders primary key)
DFS read shuffle
伝票
製品単位の
売り上げログ
Copyright 2011 NTT Corporation
PJoin の特徴①: シャッフル量削減
48
Query execution
lineitem a
orders processing
+
準結合
mapper
…
lineitem_
orders n
orders n
…
lineitem_
orders 1
orders 1
orders processing
+
準結合
Joining with
liteitem
reducer
…
Joining with
liteitem
lineitem z
テーブルの事前シャッフル実行,準結合中間データの事前生成 mapper で準結合処理後に,reducer で残処理を実行
Pre-computation
lineitem
orders
hash(x)
hash(y)
…
lineitem b
lineitem a
lineitem z
orders 1
orders n …
lineitem_
orders n
lineitem_
orders 1 hash(y)
lineitem primary key &
foreign key (orders primary key)
DFS read shuffle
伝票
製品単位の
売り上げログ
Copyright 2011 NTT Corporation
従来手法と PJoin の比較
49
PJoin
lineitem a
orders processing
+
準結合
mapper
…
lineitem_
orders n
orders n
…
lineitem_
orders 1
orders 1
orders processing
+
準結合
Joining with
liteitem
reducer
…
Joining with
liteitem
lineitem z
シャッフル量が削減 シャッフル量が削減
DFS read shuffle
orders 1
hash(x)
mapper
…
lineitem z
…
lineitem a
Join
reducer
…
hash(x)
Join
orders n
Join
…
シャッフル量が大
hash(y)
hash(y)
従来手法: ハッシュ結合
DFS read が増加
Copyright 2011 NTT Corporation
PJoin の特徴②: Nテーブル結合
50
PJoin
スター型スキーマの場合 複数 mapper を実行
全 mapper 結果は S の主キーでシャッフル
reducer は1つで処理可能
mapper (T の主キーで結合処理) reducer (S の主キーで結合処理)
T S one many
T1 S one many
TN one
many
T の主キーで結合処理
Nテーブル結合が 1つのMapReduce job で実現可能
製品単位の売り上げログ 伝票
製品単位の売り上げログ 伝票
小売店
Copyright 2011 NTT Corporation
PJoin の特徴③: スター型クエリ結合計画
51
多次元データ分析のスター型スキーマ dimension テーブルから処理を開始し,fact テーブルを最後に実行することで,中間データを削減する
lineitem
orders
partsupp part supplier
nation
*
*
* *
*
lineitem, orders,
$J2
partsupp, part, $J1
supplier, nation
J1
J2
J3
Q9 でアクセスするテーブル構成 Q9 結合計画
J1
J2
J3 fact テーブルの結合を最後に実行
Copyright 2011 NTT Corporation
評価実験
評価環境 Linux (CentOS5.4, 2.8GHz, 主記憶 8GB)×50台 Java1.6, Hadoop 0.19.2
ベンチマーク: TPC-H ベンチマーク [データ] 104GB, 207GB, 311GB 準結合中間データ: 83GB, 167GB, 250GB [分析クエリ] TPC-Hにおける結合演算を利用する 17クエリ
評価観点: PJoin と従来の Join 手法の比較 • 全体: PJoin と,従来の2つの Join 手法の応答性能比較
• PJoin vs reduce-side join (スター型結合計画, Hive 計画) • 詳細
• PJoin による シャッフル量,HDFS read/write 量の影響 • スケール性評価
52
Copyright 2011 NTT Corporation
応答時間 (104GB, 50台)
従来手法より33.4% (star plan比), 42.8% (Hive plan比) 改善の効果: MapReduce job 数削減 ,HDFS+シャッフル量削減
性能 = (HDFS r/w) + 0.5×(local r) + (local w) + 1.5×(shuffle)
53
0
1
2
3
4
5
6
resp
on
se t
ime
(min
)
PJoin
reduce-side join (star plan)
reduce-side join (Hive plan)
Copyright 2011 NTT Corporation
シャッフル量 (104GB, 50台)
従来手法より62.6% (star plan), 62.2% (Hive plan)改善 Q18 は悪化: WHERE条件の選択効果の低下が原因
54
0
5
10
15
20
25
30
35
40
45
Sh
uff
le (
GB
)
PJoin
reduce-side join (star plan)
reduce-side join (Hive plan)
Copyright 2011 NTT Corporation
HDFS read量 (104GB, 50台)
従来手法より51.4% (star plan), 52.2 % (Hive plan)増加 PJoin では準結合中間データを参照するため
55
0
10
20
30
40
50
60
HD
FS
Rea
d (
GB
)
PJoin
reduce-side join (star plan)
reduce-side join (Hive plan)
Copyright 2011 NTT Corporation 57
PJoin まとめ 特徴:
シャッフル処理の事前実行(pre-partitioning),準結合中間データの事前生成
準結合を mapper で実行,残りの結合処理を reducer で実行
効果:
TPC-H において 30-40%応答性能を改善 シャッフル量は1/3 に削減
今後の取り組み: ソースデータ更新に対する差分更新 行列掛け算に対する効果の測定
Copyright 2012 NTT Corporation
機械学習の高速化
58
大規模データ分析 MapReduce高速化 まとめ 機械学習高速化
Copyright 2012 NTT Corporation
機械学習の高速化
1. K-dash: Random Walk with Restart による高速 top-k 検索アルゴリズム
59
skip
大規模データ分析 MapReduce高速化 まとめ 機械学習高速化
D3-1
60
はじめに
• Random Walk with Restart (RWR)
– グラフにおけるノードの類似度の計算方法のひとつ
– 起点ノードからランダムウォークを繰り返した定常状態における確率をノードの類似度
• 本研究の目的 – 大規模なグラフに対して,RWR に基づき対象ノードの類似ノードを 個を高速かつ正確に検索
0.15
0.16
0.54 0.07
0.03
0.03
0.01
0.01
処理手順
以下の処理を定常状態が得られるまで繰り返す
①対象ノードを起点ノードとする
②隣接するノードにランダムウォークする
③一定確率で①にもどる.そうでなければ②へ戻る
K
D3-1
61
応用例
• レコメンデーション
– ノードを人またはアイテム,エッジを購買履歴としたグラフを作成
– 推薦対象者から RWR で類似度を計算
– 類似度の高いアイテムを推薦
– 協調フィルタなどの既存技術より高精度・拡張性も高い
推薦ユーザ
推薦アイテム 購入済みアイテム
D3-1
62 62 62
類似度の計算
• 類似度は行列の繰返し計算で定義される
A
p
qc
p )1( c
A
p c
q
:類似度に対応する列ベクトル
:グラフの隣接行列
:起点ノードに戻る確率
:対象ノードに対応する成分を1,その他を0とする列ベクトル
p
p
p
• 上位 個のノードを求めるには高い計算コスト 1. 類似度が収束するまで繰返し計算が必要
2. すべてのノードに対して類似度を計算
K
D3-1
63
提案手法の概要
1. 行列分解によりノード単位に計算(繰り返し計算不要)
– 隣接行列を疎な下三角行列 と上三角行列 に分解し,類似度を として計算
• 疎行列を用い高速に類似度を計算
• 特定ノードの類似度を正確に計算
2. 類似度の上限値を計算し探索範囲を足きり
– 類似度を計算してないノードの類似度の上限値を推定
• 上限値からノードを類似度を計算しないで枝刈り
1L 1UqLcUp 11
上位 個のノードを求めるにはすべてのノードの類似度を計算する必要があるのでは?
K
D3-1
64 64 64
行列分解:類似度の計算
• LU分解を用いて類似度を計算
– 逆行列の計算から特定ノードの類似度を正確に計算
– しかしグラフの行列 (すなわち行列 )が疎であっても逆行列 , は必ずしも疎にならない
• 行列が密な場合,類似度を高速に計算できない
c
1U
q
p
1L
I( :単位行列, ) AcIWLU )1(
A1U1L
W
, が疎になる条件を考察 1U1L
D3-1
65 65 65
行列分解:基本的な考え方
• , の成分は , の上/左の成分の積から計算
• , の成分は の対応する成分から計算
• すなわち の上/左の成分が0であれば逆行列は疎
1U1L UL
UL W
A
隣接行列を並び替えて上/左成分を疎にする
j
ik kjikij
ijij
jiLLL
jiL
ji
L
1
1
1
)(/1
)(/1
)(0
1
ijL
ijL
)(/1
)(1
)(0
1
1jiULWU
ji
ji
Lj
k kjikijjj
ij
ijL
ijW
D3-1
66 66
行列分解:疎行列の計算方法
• と を疎行列にするには隣接行列 の左/上の要素を0にすればよい
• 疎行列を得るための手法を考案
1. グラフを複数のクラスタに分割し並び替える
2. クラスタをまたがるノードを最後のクラスタに移動
3. 各クラスタ内で次数の小さい順にノードを並び替える
1L1U A
2.ノード移動
3.ノードの並び替え
1.クラスタ分割
D3-1
67 67
類似度の推定
• 類似度の上限値を推定し検索を打ち切る
• 類似度の上限値の推定は以下の通り
– 推定は対象ノードをルートとする幅優先木から行う
– 推定値は検索の過程で逐次的に更新可能
)1( )(
maxmaxmax 1)()(u u slVv lVv Vv
vvvu ApvApvApcp
ひとつ上の層からの類似度の伝搬量の最大値
同じ層からの類似度の伝搬量の最大値
下の層からの類似度の伝搬量の最大値
:ノード の類似度の推定値
:類似度を計算済のノードの集合
:ノード の幅優先木における層番号
:層番号が で類似度を計算済のノード集合
:ノード からの重みの最大値
:グラフにおける重みの最大値
up
sV
)( ulV
ul
)(max vA
maxA
u
u
ul
v
D3-1
68 68
評価実験:実験条件
• 実験マシン
– 4コアの 3.3 GHz Intel Xeon サーバ(32GB メモリ)
• 実験データ – 辞書
• オンライン辞書 FOLDOC のデータ
• ある単語の説明にその他の単語が用いられていると,それらの単語間にエッジがあるグラフデータ
– インターネット
• Oregon Route Views Project によるインターネットのグラフデータ
– 共著
• Condensed Matter E-Print Archive に投稿された論文の共著関係から得られたグラフデータ
• 比較手法 – Tong らによって提案された近似手法*
• グラフを特異値分解によって近似し,類似度の近似値を計算する手法
*Tong et al., “Fast Random Walk with Restarat and Its Applications”, ICDM 2006
D3-1
69 69 69
評価実験:検索時間と精度
• 検索時間と検索精度について実験
– 提案手法は従来手法より数万倍の高速化を達成
– 提案手法は従来手法と異なり検索結果が正確
(1)検索時間 (2) 検索精度
0.000001
0.00001
0.0001
0.001
0.01
0.1
1
辞書 インターネット 共著
処理時間[s]
提案手法(K=5) 提案手法(K=25)
提案手法(K=50) 従来手法(特異値100個)
従来手法(特異値1000個)
0
0.2
0.4
0.6
0.8
1
1.2
辞書 インターネット 共著
検索精度
提案手法従来手法(特異値100個)従来手法(特異値1000個)
D3-1
70
評価実験:ケーススタディ
• 辞書データを用いた類似語の検索結果
– 提案手法の検索結果は良好
– 従来手法は近似精度が低く,上位 個の検索には適さない
K
1 2 3 4 5
提案手法 Microsoft Windows W2K Windows/386 Windows 3.0 Windows 3.11
従来手法 Microsoft Windows Microsoft Networking Microsoft Network W2K Thumb
提案手法 Mac OSMacintosh userinterface
Macintosh filesystem
multitaskingMacintosh OperatingSystem
従来手法 Mac OS Rhapsody SORCERERMacintosh OperatingSystem
PowerOpenAssociation
提案手法 LinuxLinux DocumentationProject
Unix lintLinux NetworkAdministrators' Guide
従来手法 LinuxLinux DocumentationProject
SL5 debianize SLANG
ランキング
MicrosoftWindows
Mac OS
Linux
検索語 手法
D3-1
71
まとめ
• 問題設定
– 大規模なグラフに対して,RWR に基づき対象ノードの類似ノードを 個を高速かつ正確に検索
• 提案手法
– 行列分解
• 特定ノードの類似度を高速かつ正確に計算
– 類似度の推定
• 類似度を計算してないノードの類似度の上限値を推定
• 実験結果
– 正確な検索結果を保証しながら,従来手法より数万倍の高速化を達成
K
Copyright 2012 NTT Corporation
機械学習の高速化
2. グラフクラスタリングの高速化
72
skip
大規模データ分析 MapReduce高速化 まとめ 機械学習高速化
発表の流れ
1. 研究の背景
2. 既存手法:Louvain法
3. 提案手法
4. 評価実験
5. まとめと今後の課題
背景:グラフデータ
グラフデータの大規模化
– Ex) Facebookでは2011年にアクティブユーザ数が5億人,総会員数が8億人を突破
グラフデータのクラスタリング技術
– グラフデータ中のノードを一定の尺度で自動分類
– クラスタ内のエッジが密であり,クラスタ間のエッジが疎であるクラスタリング結果ほど良い
良いクラスタリング結果 クラスタ1 クラスタ2
悪いクラスタリング結果
クラスタ1 クラスタ3 クラスタ2
クラスタリング結果の評価尺度
クラスタリング指標:Modularity Q [Girvanら, Phys.Rev.2004]
– クラスタ内が密,クラスタ間が疎である程良い値を示す
クラスタ1 クラスタ2 クラスタ1 クラスタ2
Modularityによるクラスタリング手法
処理可能な グラフの規模
1万ノード
数百万ノード
数千万~ 1億ノード
Girvan-Newman法[Girvanら, Phys.Rev.2004]
Newman法[Newman, Phys.Rev.2004]
CNM法[Clausetら, Phys.Rev.2004],WT法[Wakitaら, WWW2008]
トップダウンにクラスタに存在しそうなエッジを削除する手法
貪欲法によりボトムアップからModularityを向上させる手法
ヒープの導入やヒューリスティクスによるNewman法の高速化
グローバル(グラフ全体)なModularity最適化アプローチ
Louvain法[Blondelら, IOP and SISSA Journal 2008]
隣接するノード同士にのみModularityの最適化を行う手法
ローカル(部分グラフ)なModularity最適化アプローチ
現在,最速かつ高いModularityを示す手法として知られる
<Louvain法を用いた近年の研究傾向>
・グローバルなグラフ構造を用いたModularityの向上 [ZhangらDASFAA2011][YeらASONAM2011][MeoらISDA2011] ・動的に変化するグラフへの応用[NguyenらINFOCOM2011] ・アプリケーションへの適用[BrowetらIWCIA2011]
本研究の目的と貢献
本研究の目的 – Louvain 方における問題点
1. 第1パス(クラスタ決定処理)における処理時間の増加 2. ノード選択順に依存した処理時間の増加
⇒ 次数の少ないノードから逐次集約することで解決 本研究の貢献
– 高速性 • 従来最速とされるLouvain法よりも高速に処理可能 • 本研究では133倍の高速化まで確認
– 正確性 • 最も良いModularityの値示すとされるLouvain法と同等のModularityを示す
– 大規模性 • 大規模かつべき乗則に従ったグラフデータである程より効率的に高速化が可能であることを示唆
大規模なグラフデータを対象に Modularityを用いたクラスタリングを高速化する
発表の流れ
1. 研究の背景
2. 既存手法:Louvain法
3. 提案手法
4. 評価実験
5. まとめと今後の課題
既存手法:Louvain法
Vincent D. Blondel et al., “Fast unfolding of communities in large
networks,” Journal of Statistical Mechanics, October 2008.
パス =
第1フェーズ:ノードのローカルクラスタリング
• ランダムな順序でノードを選択し,選択したノードをModularityが最も高くなる隣接ノードと同一クラスタとする
第2フェーズ:クラスタに含まれるノードの一括集約
• 同一クラスタ内のノードとエッジを一括集約し重み付きグラフに変換
1 1
1
3
2 12
14 2
6
第1フェーズ 第2フェーズ
集約した重み付きグラフに対してModularityが向上する限りパスを繰り返す
第2パスへ処理を繰り返す
Louvain法の問題点
問題点1:第1パスにおける処理時間の増加 – 第1フェーズの第1パスが占める
処理時間が99%以上
– グラフの規模が直接影響するため
グラフの規模に応じてさらに増加
問題点2:ノード選択順に依存した処理時間の増加
– Louvain法による処理を50回
試行した際の時間頻度分布
– ノードの選択順序に依存して
処理時間が大幅に変化
グラフの大規模化に伴い処理速度が極端に低下する
0 1 2 3 4 5 6 7 8 9
10
time(sec)
頻度
(回)
パス 1 2 3 4 合計
Time (sec)
857 0.29 0.03 0.03 857
各パス毎の処理時間経過
発表の流れ
1. 研究の背景
2. 既存手法:Louvain法
3. 提案手法
4. 評価実験
5. まとめと今後の課題
基本的なアイデア
Louvain法の考察 – クラスタリングと集約のフェーズが別れていることにより計算不要なノードとエッジがグラフに多く含まれている
提案手法におけるアプローチ
1. クラスタが決定した時点でノードを逐次的に集約
2. 所属クラスタが自明なノードの枝刈り
3. 次数順によるノード選択によるエッジ参照数削減
クラスタ
同一クラスタに張られた 複数のエッジの参照
結果が自明なノードへの参照
クラスタ内部の ノードとエッジの参照
ノードのランダム選択による エッジ参照数の増加
(1)計算対象ノードの逐次集約
クラスタが決定したノードを逐次に集約する – 同一クラスタを1ノード,エッジを重み付きエッジに変換することで,計算対象となるノードとエッジを削減
同一クラスタ と判明
逐次集約
集約処理前
特性:高速に高いModularityでクラスタリング可能 – ノードとエッジを削減するがクラスタ間のエッジの接続情報を保持
– 同一のノード選択順序が与えられればLouvain法と等価に処理が可能
2
2
集約された ノードとエッジ
集約処理後
クラスタ内:エッジ数の2倍 クラスタ間:エッジ数の1倍
(2)ノードの枝刈り(1/2)
クラスタが自明な2パターンを逐次的に枝刈りする – 自明なパターンを枝刈りすることにより不要な参照を削除 – Modularityの定義よりクラスタが自明なパターンは以下の通り
パターン1の枝刈り
– 次数1のノードを見つけ隣接ノードへ集約すれば良い
パターン2の枝刈り – 全てのノードが隣接ノードを常に監視し枝刈りのタイミングを決める必要
があり非効率
クラスタが自明となるパターン
パターン2 隣接ノードが全て同じ クラスタであるノード
パターン1
次数が1のノード
(2)ノードの枝刈り(2/2)
パターン2の枝刈りの効率化
– アプローチ1の逐次集約によりパターン2は他ノードへの次数が1となるノードとして表現される
– 逐次集約とパターン1による枝刈りを交互に実行することにより枝刈り可能
隣接ノードが全て同一クラスタである エッジ本数が1のノードとなる
4
3 12
逐次集約処理
パターン1として 枝刈り可能
(3)次数順ノード選択
次数の少ない順に計算対象ノードを選択する – グラフデータ中から他ノードへの次数が少ないノードを優先選択することでエッジの比較回数を抑制
A
C D
B
ノードAとBが同一のクラスタとなる場合
ノードAから選択
ノードBから選択
エッジ参照数3
エッジ参照数2
次数の少ないノードBを 選択したほうが効率が良い
A
C D
2
2
逐次集約
発表の流れ
1. 研究の背景
2. 提案手法
3. 既存手法:Louvain法
4. 評価実験
5. まとめと今後の課題
評価実験
概要
1. 提案手法とLouvain法の処理速度,処理精度を比較
2. 枝刈りの有無,次数順選択の有無による処理速度比較
データセット
– Stanford大学SNAP Projectの公開データ
• HepTh(論理物理学系論文の共著者関係):ノード数9,877 エッジ数51,971
• CondMat(論文の共著者関係):ノード数23,133 エッジ数186,936
• HepPh(エネルギー工学系論文の共著者関係):ノード数12,008 エッジ数237,010
• Email:ノード数36,692 エッジ数367,662
評価実験1:高速性と精度の評価
クラスタリング処理速度と精度をLouvain法と比較
– 提案手法はLouvain法に対して最大133倍の高速化
• 特にエッジ数が多いグラフデータほどより高速に処理している
– Modularityの値は同程度を示していることを確認
HepTh CondMat HepPh email
tim
e(m
sec)
提案手法
Louvain法
1
10
10 2
10 3
10 4
10 5
10 6
HepTh CondMat HepPh email
提案手法 0.744 0.703 0.615 0.562
Louvain 0.685 0.644 0.621 0.57
処理速度の比較
Modularityの比較
評価実験2:枝刈り有無による評価
処理速度を比較
– 枝刈り有の方が高速に処理可能
• 特にCondMat,emailの高速化効率が良く,それぞれ1.34倍,1.30倍を示している
0
1000
2000
3000
4000
5000
6000
7000
HepTh CondMat HepPh email
tim
e(m
sec)
枝刈り有
枝刈り無
処理速度の比較
評価実験3:次数順選択有無による評価
処理速度を比較
– 次数順選択の方が高速に処理可能
• 特にCondMat,emailの高速化効率が良く,それぞれ1.67倍,1.80倍を示している
0
2000
4000
6000
8000
10000
12000
HepTh CondMat HepPh email
tim
e(m
sec)
次数順
ランダム順
処理速度の比較
発表の流れ
1. 研究の背景
2. 既存手法:Louvain法
3. 提案手法
4. 評価実験
5. まとめと今後の課題
まとめ
提案手法 – 目的:大規模なグラフに対するクラスタリングの高速化
– アプローチ • ノードの逐次集約によるノード・エッジ参照数の削減
• ノードの枝刈りによるノード・エッジ参照数の削減
• 次数順ノード選択による参照エッジ数の抑制
本研究の貢献 – 高速性:データセットに対して最大で133倍の高速化に成功
– 正確性:高いModularityの値を示すLouvain法と同等Modularity値
– 大規模性:大規模かつべき乗則に従ったグラフデータである程より効率的に高速化が可能であることを示唆
今後の課題 – より大規模なデータセットでの評価・分析
– 分散並列処理への対応