大規模データを対象とした分析処理の高速化に関する取り組み1....

Copyright 2012 NTT Corporation

大規模データを対象とした分析処理の高速化に関する取り組み

1

鬼塚真主幹研究員(特別研究員)

NTTソフトウェアイノベーションセンタ

自己紹介

2

所属など NTT ソフトウェアイノベーションセンタ主幹研究員（特別研究員）

群馬県出身，ワシントン大(911の時)

過去の研究開発テーマオブジェクトリレーショナル DBMS の研究開発 XMLストリーム処理/DBMSの高速化 CBoC type2 分散テーブルの開発

現在の研究テーマ MapReduce の高速化

機械学習の高速化 (クラスタリング，ランダムウォーク等)

最先端ハードウェアを利用した高速インデックス

画像検索ホームラン検索

テレビ番組通知

ニュース配信

カラオケ検索

http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:University_of_Washington_Quad,_Spring_2007.jpg

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

最適化高速な分散処理

実行計画


目次

大規模データ分析について

分析処理の高速化の取り組み MapReduce の高速化 (HW2011)

Map Multi-Reduce: reduce の事前実行

PJoin: 事前パーティション分割と準結合の利用

機械学習の高速化

K-dash: Random Walk with Restart による高速

top-k 検索アルゴリズム (PVLDB2012)

グラフクラスタリングの高速化アルゴリズム

5


大規模データ分析について

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 の高速化

8



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 のアーキテクチャ

10

MapReduce: 分散処理システム

分散ファイルシステム DFS 上で構築 DFS: GFS (Google FS), HDFS (Hadoop DFS)

2フェーズ + Shuffle Map フェーズ: 入力レコード毎にmap関数を実行

ポイント: マシン毎に独立した処理

Shuffle:同一key の(key, value) 群を束ねる

Reduce フェーズ: 束ねた結果に reduce 関数を実行

ポイント: 複数マシンにまたがり必要な処理



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



プログラム例: wordCount 入力文書毎に map関数を適用する

単語毎に (word, 1) を出力する

12

単語毎に頻度を積算する

[Dean et al., OSDI 2004]



MapReduce の設計思想

13

以下の要素からなるモデル・システム

関数型言語のインタフェース • map (f) [r1,...,rn] = [f(r1),...., f(rn)]

• reduce (⊕) [r1,...,rn] = r1 ⊕ .... ⊕ rn

分散環境への適用 • map:マシン内データ処理，reduce:マシン間データ処理

• 論理プラン = 物理プラン

• (key, value) + partition 関数によるシャッフル処理

• エラー処理などの分散特有の処理を隠ぺい

• ファイルを介してプロセス間通信 (高速なリカバリ)

MapReduce 導入高速化の研究動向研究の方向性高速化の取り組み


MapReduce: デザインパターンと実施例

14

MapReduce プログラムのデザインパターン Local Aggregation

Pairs and Stripes

Computing Relative Frequencies

Secondary Sorting

Relational Joins

MapReduce の利用例転置インデックス

グラフアルゴリズム(幅優先探索など)

EMアルゴリズム


MapReduce Algorithm Design.pptx




MapReduce 高速化の取り組み

1. Map Multi-Reduce: MapReduce extended with reduce pushdown

15

skip



Motivation

Performance problems in MapReduce [DeWitt, 2009] no schema, no index, ignoring data skew,

communication cost, materialization cost In particular materialization/communication costs


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


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


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


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


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


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


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%


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


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)


MapReduce 高速化の取り組み

2. PJoin: Efficient join processing with MapReduce

for OLAP applications

29



技術の概要

PJoin (pre-partition-based join) [到達点] 多次元データ分析(OLAP)処理において，シャッフル量を 1/3 に削減することで処理時間を，従来技術より 42.8% 高速化

[戦略] 複数の分析処理において共通するシャッフル処理を前もって実行(事前処理)することで，分析処理時のコストを削減

30


背景: 多次元データ分析(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)

集約演算

多テーブル結合処理

グループ化


ハッシュ結合による方法:

• シャッフル量に起因する通信コスト・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)

製品単位の売り上げログ

伝票


[方針] テーブル結合処理時のシャッフル量を削減する

[前提] OLAP分析では，更新よりも参照処理の性能が重要

1対多の関係でテーブル結合処理する

[戦略]

複数の分析処理において共通的なシャッフル処理を事前処理することで，分析処理時のコストを削減

• 結合条件(主キー)によるテーブルの事前シャッフル • 準結合の活用 + 中間データの事前生成

複数MapReduce 間でシャッフル量を削減する結合計画

[効果]

分析処理時のシャッフル量を削減

Nテーブル結合演算によりMapReduce job数を削減

PJoin の概要

33


BTW, what is the semi-join?

A well-know technique in distributed DBMS

Natural join (⋈)




Natural join (⋈)




Semijoin (⋉)(⋊)

Natural join (⋈)




Semijoin (⋉)(⋊)

Natural join (⋈)

Employee ⋈ Dept = (Employee ⋉ Dept ) ⋈ Dept


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





(Employee ⋉ Dept ) ⋈ Dept

Employee ⋈ Dep





(Employee ⋉ Dept ) ⋈ Dept

Employee ⋈ Dep

Materializing foreign key table for semi-join


[方針] テーブル結合処理時のシャッフル量を削減する

[前提] OLAP分析では，更新よりも参照処理の性能が重要

1対多の関係でテーブル結合処理する

[戦略]

複数の分析処理において共通的なシャッフル処理を事前処理することで，分析処理時のコストを削減

• 結合条件(主キー)によるテーブルの事前シャッフル • 準結合の活用 + 中間データの事前生成

複数MapReduce 間でシャッフル量を削減する結合計画

[効果]

分析処理時のシャッフル量を削減

Nテーブル結合演算によりMapReduce job数を削減

PJoin の概要

45


PJoin の特徴①: シャッフル量削減

46

テーブルの事前シャッフル実行

Pre-computation

lineitem

orders

hash(x)

hash(y)

…

lineitem b

lineitem a

lineitem z

orders 1

orders n

DFS read shuffle

製品単位の

売り上げログ

伝票



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

伝票

製品単位の

売り上げログ



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

伝票

製品単位の

売り上げログ


従来手法と 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 が増加


PJoin の特徴②: Nテーブル結合

50

PJoin

スター型スキーマの場合複数 mapper を実行

全 mapper 結果は S の主キーでシャッフル

reducer は１つで処理可能

mapper (T の主キーで結合処理) reducer (S の主キーで結合処理)

T S one many

T1 S one many

TN one

many

T の主キーで結合処理

Nテーブル結合が 1つのMapReduce job で実現可能

製品単位の売り上げログ伝票

製品単位の売り上げログ伝票

小売店


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 テーブルの結合を最後に実行


評価実験

評価環境 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


応答時間 (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)


シャッフル量 (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




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




PJoin まとめ特徴:

シャッフル処理の事前実行(pre-partitioning)，準結合中間データの事前生成

準結合を mapper で実行，残りの結合処理を reducer で実行

効果:

TPC-H において 30-40%応答性能を改善シャッフル量は1/3 に削減

今後の取り組み: ソースデータ更新に対する差分更新行列掛け算に対する効果の測定



58




1. K-dash: Random Walk with Restart による高速 top-k 検索アルゴリズム

59

skip


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

：類似度に対応する列ベクトル

：グラフの隣接行列

：起点ノードに戻る確率

：対象ノードに対応する成分を１，その他を０とする列ベクトル

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

行列分解：基本的な考え方

• ，の成分は，の上/左の成分の積から計算

• ，の成分はの対応する成分から計算

• すなわちの上/左の成分が０であれば逆行列は疎

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



2. グラフクラスタリングの高速化

72

skip


発表の流れ

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. 研究の背景


3. 提案手法

4. 評価実験


既存手法：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. 研究の背景


3. 提案手法

4. 評価実験


基本的なアイデア

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. 提案手法


4. 評価実験


評価実験

概要

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


提案手法 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


tim

e(m

sec)

枝刈り有

枝刈り無


評価実験3：次数順選択有無による評価

処理速度を比較

– 次数順選択の方が高速に処理可能

• 特にCondMat，emailの高速化効率が良く，それぞれ1.67倍，1.80倍を示している

0

2000

4000

6000

8000

10000

12000


tim

e(m

sec)

次数順

ランダム順


発表の流れ

1. 研究の背景


3. 提案手法

4. 評価実験


まとめ

提案手法 – 目的：大規模なグラフに対するクラスタリングの高速化

– アプローチ • ノードの逐次集約によるノード・エッジ参照数の削減

• ノードの枝刈りによるノード・エッジ参照数の削減

• 次数順ノード選択による参照エッジ数の抑制

本研究の貢献 – 高速性：データセットに対して最大で133倍の高速化に成功

– 正確性：高いModularityの値を示すLouvain法と同等Modularity値

– 大規模性：大規模かつべき乗則に従ったグラフデータである程より効率的に高速化が可能であることを示唆

今後の課題 – より大規模なデータセットでの評価・分析

– 分散並列処理への対応

大規模データを対象とした分析処理の高速化に関する取り組み1....

Documents

Transcript of 大規模データを対象とした分析処理の高速化に関する取り組み1....

大規模データを対象とした分析処理の 高速化に関する取り組み1....

Documents

Transcript of 大規模データを対象とした分析処理の 高速化に関する取り組み1....

大規模データを対象とした分析処理の高速化に関する取り組み1....

Transcript of 大規模データを対象とした分析処理の高速化に関する取り組み1....