Spark／MapReduceの機械学習ライブラリ比較検証

All Right Reserved. Copyright.(C) Recruit Technologies Co.,Ltd.
レコメンドバッチ高速化に向けた
Spark／MapReduceの
機械学習ライブラリ比較検証
堀越保徳(リクルートテクノロジーズ)
濱口智大(NTTデータ)
2015年5月21日

目次
1
1. レコメンドバッチ高速化検証
• 背景と目的
• 検証内容
• 検証結果
• まとめ
2. Sparkノウハウ共有
• 検証を通じて実感したSparkのメリット
• 重要なパラメータ
• ハマりどころや注意点

１．レコメンドバッチ高速化検証
2

自己紹介
3
 氏名：堀越保徳
 Twitter： @hotoku
 Blog： http://d.hatena.ne.jp/hotoku/

目次
4
• 背景と目的
• 検証内容
• 検証結果
• まとめ

背景と目的
5
 背景
• これまでデータ分析処理基盤としてHadoop(Hive/Mahout)を活用してきた
• 処理性能の課題に関してはスケールアウトで対応してきた
• レコメンドバッチの長時間化が深刻化
• バッチの多様化
レコメンドA、レコメンドB、モニタリングX、モニタリングY、…
• データ量増加
○千万レコード／日、様々なデータ（PV、CV、各種事業マスタ、…）
• スケールアウト以外のアプローチを模索
• Mahoutがアルゴリズム開発の主軸をMapReduce→Sparkに変更
 目的
• 次世代のデータ分析処理基盤としてSparkの実用可能性を探る
• インフラ面での検証に先駆けて、アプリ面で実運用に耐えうる有用性を備え
ているか検証する

目次
6
• 背景と目的
• 検証内容
• 検証結果
• まとめ

検証内容
7
 概要
• Spark MLlib VS MapReduce Mahout レコメンドライブラリの比較
 検証対象アルゴリズム
• アイテムベース協調フィルタリング
• ALS協調フィルタリング
 検証環境
• AWS上に2クラスタを構築
 比較観点
• 実行時間（実時間）
• レコメンド精度（F-尺度）
• スケール性

対象アルゴリズム
8
 アルゴリズムの位置づけ
Spark MLlib
アイテムベース
※MLlibに実装がないため新規作成
ALS
MapReduce Mahout
 アイテムベース
ALS
処理基盤をSparkにすることで、
実行時間、レコメンド精度は
どのように変化するか？
アルゴリズムの違いによって、
MapReduce vs Sparkの結果は
どのように変化するか？
処理基盤軸
ア
ル
ゴ
リ
ズ
ム
軸
※現行

9
 アイテムベース協調フィルタリング：繰り返し計算はない
• 協調フィルタリング：「この商品を見た人は、こんな商品も見ています」
をアイテム間の類似度を基に計算するアルゴリズム
• ユーザの行動履歴からアイテム間の類似度を計算
• ユーザが高い評価を付けたアイテムに似ているアイテムを推薦
ベクトルの
類似度算出
評価値行列アイテム類似度行列
ユーザ
アイテムアイテム
アイテム
予測値行列
ユーザ
アイテムアイテム
アイテムユーザ
アイテム
×
レコメンド
ユーザ
アイテム
上位N件抽出

10
 ALS協調フィルタリング：繰り返し計算が多い
• 協調フィルタリング：「この商品を見た人はこんな商品も見ています」
を行列因子分解によって求めるアルゴリズム
• 評価値行列をユーザ特徴量行列とアイテム特徴量行列に分解してモデル化
• ユーザ特徴行列×アイテム特徴行列で未評価のアイテムの評価値を予測
評価値行列ユーザ特徴量行列
アイテム特徴量行列
ユーザ
アイテム
ユーザ
アイテム
)()(),(
22
),(
2
),(    j juji iuiIji j
T
iji ununvurVUf 
●交互最小二乗法(ALS:Alternative Least Square)
+ WR:Weighted λ Regulation
どちらかを固定してどちらかを最適化する
それを目的関数が閾値以下となるまで繰り返す

検証環境
11
 AWS構成
• Master × 2台、Slave × 10台
• コア数 4
• メモリ 32GB
• ディスク 160GB
 主要ソフトウェア
• CentOS 6.5
• Java 1.7.0
• Hadoop 2.6.0
• Mahout 0.9
• Spark 1.2.0
 使用データ
• レコード数 1億3千万件
• ユーザ数 1000万件
• アイテム数 200万件
• サイズ 2GB
Master
Slave
Client
EC2
x1
EC2
x2
EC2
x10
Master
Slave
Client
EC2
x1
EC2
x2
EC2
X10
Spark用クラスタ MapReduce用クラスタ
レコード数ユーザ数アイテム数データ密度サイズ(MB)
1 35,872,326 4,765,166 512,882 0.0000147 510
2 61,192,747 6,659,384 865,736 0.0000106 873
3 77,865,758 7,694,202 1,097,982 0.0000092 1,113
4 97,967,251 8,797,225 1,334,746 0.0000083 1,400
5 116,938,309 9,734,990 1,563,344 0.0000077 1,677
6 134,976,806 10,489,833 1,830,912 0.0000070 1,943

比較観点
12
 レコメンド精度（F-尺度）
• Recommend ：レコメンドされたユーザ×アイテム
• Order ：購買されたユーザ×アイテム
• Match ：レコメンドされ、かつ、購買されたユーザ×アイテム
• 適合率（recall）
• 再現率（precision）
• F-尺度（f-measure）
 スケール性
• AWSのスレーブノード数を増加させ、実行時間が短縮されるか検証
• ノード数： 5、10、15、20で検証
commendR
Match
recall
e

Order
Match
presicion 
recallprecision
recallpresicion
measuref


・・2
RecommendOrder
Match
U

目次
13
• 背景と目的
• 検証内容
• 検証結果
• まとめ

検証結果（１）実行時間
14
 Spark vs Mahout（アイテムベース）
⇒ Spark： Mahout の約1/5 に短縮
23分32秒
4分57秒
4.8倍

検証結果（１）実行時間
15
 Spark vs Mahout（ALS）
⇒ Spark： Mahout の1/32 に短縮
6分55秒
3時間41分46秒
3分14秒
36分48秒
32.1倍
ALSは繰り返し計算が多いため、
Sparkの優位性が際立つ

検証結果（２）レコメンド精度
16
 Spark vs Mahout
⇒ ほぼ同等のレコメンド精度を確認

検証結果（３）スケール性の確認
17
 Spark vs Mahout
⇒ Spark／Mahoutともにノード増加に応じて実行時間が短縮

目次
18
• 背景と目的
• 検証内容
• 検証結果
• まとめ

まとめ
19
 実行時間比較（Spark/MapReduce）
• アイテムベース： 1/5
• ALS ： 1/32
⇒ Spark導入により実行時間の短縮が十分期待できる
 レコメンド精度比較
• アイテムベース、ALSともにMapReduceとほぼ同等のレコメンド精度を確認
⇒ 実用に耐えうる有用性
 スケール性比較
• Sparkのスケール性がMapReduceと同等であることを確認
⇒ データ量増加に対してリソースを増強することで対応可
次世代のレコメンド処理基盤としてSparkの有用性が確認できた

２．Sparkノウハウ共有
20

自己紹介
21
 氏名：濱口智大
 所属：
 NTTデータ第三法人事業本部
 仕事：
 入社してしばらくはレガシーシステムの維持管理
 2013年からビッグデータ
 今回の検証ではSparkでのアイテムベース実装を担当

目次
22

目次
23

検証を通じて実感したSparkのメリット
24
 Ease of Use
 Speed

一般的なプログラム
25
 計算方法
CPU
メモリ
ストレージ
：演算
：変数
：ファイル
ファイルから変数にデータを読み込み、
あれこれ演算して
結果をファイルに書き出す

一般的なプログラム
26
 WordCountの例

並列プログラム Hadoopのアプローチ
27
 計算方法
CPU
メモリ
ストレージ
CPU
メモリ
ストレージ
CPU
メモリ
ストレージ
： MapReduce
： HDFS
…
HDFSからデータ読み込み、HDFSに書き出すまでの処理を
Map + Reduceのフレームワークに当てはめる

並列プログラム Hadoopのアプローチ
28
 WordCountの例

並列プログラム Sparkのアプローチ
29
 計算方法
CPU
メモリ
ストレージ
CPU
メモリ
ストレージ
CPU
メモリ
ストレージ
： API
： HDFS
…
HDFSファイルからRDDの変数にデータを読み込み、
RDD用のAPIであれこれ演算して
結果をHDFSファイルに書き出す
： RDD

30
 WordCountの例

31
 WordCountの例

Spark-shell
32
 インタラクティブなシェルで手軽に動作確認ができる
まず、spark-shellでお試し
→ ある程度の処理の流れができたらアプリケーションにまとめる

Speedに関する検証結果
33
 今回の検証結果： Spark ＞ MapReduce となった
• ALS（繰り返し処理が多い） ⇒ 約32倍
• アイテムベース（繰り返し処理がない） ⇒ 約5倍

Speed Spark ＞ MapReduceの要因考察
34
観点 MapReduce Spark
処理フロー必ずMap→Reduceのジョブとし
て作成するため非効率なケース
も
（無駄なMap／Reduceを挟む）
読み込んだデータをRDDに保持
し、次々に処理を適用していく
ので効率的なフローが実現可
実行スケジューリング Map→Reduceのジョブを人間が
スケジュールしてプログラムを
書く
（基本直列に並べる？）
SparkのDAG実行エンジンが最
適化して実行
（ステージ分割、タスク生成、
実行スケジューリング）
データアクセス 1ジョブ毎にHDFSに結果を書き
出すため、中間データもHDFS
に保持
中間データはRDDとしてメモリ
（＋ローカルディスク）に保持
処理起動のオーバヘッド連続した処理の場合、1ジョブ
毎に1アプリケーションとして
実行するため、処理起動のオー
バヘッドが発生
連続した全ての処理を1アプリ
ケーションとして実行するため、
処理起動のオーバヘッドが小さ
い
 MapReduceとSparkの比較

目次
35

重要なパラメータ
36
 メモリ関連のパラメータ
 並列度関連のパラメータ

メモリ関連のパラメータ
37
 重要パラメータ
パラメータ説明
spark.executor.memory Executorプロセスのヒープサイズ
spark.yarn.executor.memoryOverhead ExecutorプロセスのOFFヒープ
spark.storage.memoryFraction キャッシュ領域のヒープ全体に占める割合
spark.shuffle.memoryFraction シャッフル使用領域のヒープ全体に占める割合
spark.executor.extraJavaOptions –xmn 世代別GCにおけるNew領域のサイズ
ちゃんと設定しないと色んな問題が発生・・・
Container
Container
Executor
Executor
Executor memory(= heap) Executor
memory
overhead
(=off heap)
storage shuffle
New領域 Old領域
Driver

問題1： Lost executor
38
 問題
YARNコンテナで確保できるメモリサイズを超過し、YARNによって
Executorをkillされる
 原因
spark.yarn.executor.memoryOverhead の不足によって発生
（spark.executor.memoryが足りなかった場合はOOMで落ちる）
エラーメッセージが異なる場合があるので注意！
15/03/03 23:33:54 INFO yarn.YarnAllocationHandler: Completed container
container_1424912468099_0195_01_000009 (state: COMPLETE, exit status: -100)
15/03/03 23:33:54 INFO yarn.YarnAllocationHandler: Container marked as failed:
container_1424912468099_0195_01_000009. Exit status: -100. Diagnostics: Container released on a *lost* node
15/03/03 23:33:54 ERROR cluster.YarnClusterScheduler: Lost executor 5 on spaken410: remote Akka client
disassociated
15/02/25 22:04:54 WARN yarn.YarnAllocationHandler: Container killed by YARN for exceeding memory limits. 17.2
GB of 17.1 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
15/02/25 22:04:55 ERROR cluster.YarnClusterScheduler: Lost executor 2 on spaken508: remote Akka client
disassociated

問題1： Lost executor
39
 対処
spark.yarn.executor.memoryOverheadを増やす
 設定方針
1. Executor実行のために確保する全体メモリサイズを決める
2. spark.executor.memory ＋ spark.yarn.executor.memoryOverhead
＝全体メモリサイズ（1.で決めたサイズ）
となるように設定
3. Lost executorが発生する場合は、
spark.yarn.executor.memoryOverheadを上げ、その分
spark.executor.memoryを下げる

問題2： GC overhead limit exceeded
40
 問題
GCが発生しすぎてアプリケーションが落ちる
 原因
• そもそもメモリが不足
• メモリの使われ方がGCの仕組みにマッチしていない
 考え方
• GCではオブジェクトの生存期間毎にNew／Oldに分けて管理している
• Old領域がいっぱいになるとFull GCが走り時間がかかる
• Sparkのメモリの使い方として、キャッシュやシャッフルに使われる
領域のデータは生存期間が長い

 設定方針
Old領域 ≧ キャッシュ領域＋シャッフル領域
つまり
New領域
≦ Executorメモリ全体ー (キャッシュ領域＋シャッフル領域)
spark.executor.extraJavaOptions –xmn
≦ spark.executor.memory
× (1 ー (spark.storage.memoryFraction ＋ spark.shuffle.memoryFraction))
となるように設定
それでもGCが頻発するなら、
• 並列度を上げて処理単位を小さくする ※parallelismに関しては後ほど詳しく
• spark.storage.memoryFraction, spark.shuffle.memoryFractionを下げる
（メモリに乗らない分はディスクに退避）
問題2： GC overhead limit exceeded
41

並列度関連のパラメータ
42
 重要パラメータ
パラメータ説明
spark.executor.instances(--num-executor) Executorプロセス数
spark.executor.cores(--executor-cores) 1Executor当たりのコア数（同時実行スレッド数）
spark.default.parallelism パーティション数（データの分割数）
チューニングが重要なパラメータ
Container
Container
Executor
Driver
corecore core core
Executor
プロセス数
Executor当たりのコア数
処理対象データ …
パーティション数
処理窓口数
＝Executorプロセス数
× Executor当たりのコア数
総タスク数
＝パーティション数

Parallelismのチューニング
 処理のデータ、アルゴリズムによって最適なParallelismを求める
• Parallelismが不十分な場合
Executorリソースに対して処理データ量が多い
→GC、Shuffle spillにより処理時間が伸びる
• Parallelismが過剰な場合
1タスク当たりの処理時間が短縮されなくなる
→タスク数増に比例して処理時間が伸びる

目次
44

ハマりどころや注意点
45
 偏ったデータ
 既存資産の流用
• Task not serializable
• マルチスレッド問題

偏ったデータ
46
 問題：偏ったデータがボトルネックとなる
key-value型の処理で特定のキーにデータが集中した場合、
処理の長時間化やOOMによるアプリ停止が発生
 対策：偏ったデータを間引く
key-value型の分散処理に共通する課題 ※Spark固有の問題ではない
アルゴリズムを変更する対処が必要
精度低下を許容できる範囲でデータを間引いて計算
Web UIでボトルネック発生を確認

偏ったデータ
47
 アイテムベースで発生した問題の対応
SparkのWebUIからボトルネックが発生している箇所を特定
・レコメンドスコア計算
ratings ：1アイテム当たり最大100万超
similarities ：1アイテム当たり最大50万超
⇒ アイテムIDでjoinすると最大100万×50万＝5000億レコードが
1つのキーに集中
⇒ 偏ったデータによるボトルネックが発生する

偏ったデータ
48
 アイテムベースで発生した問題の対応
MapReduceもkey-value型なので同じ問題が発生するはず
Mahoutではどのように対処しているのか？？
Mahoutと同様のオプションを実装することで偏ったデータによる問題を回避
アルゴリズムに手を加えて、偏ったデータを間引いた計算に変更
オプション意味
--maxPrefsPerUser レコメンド計算に使用するユーザ評価値の1ユーザあ
たりの評価済みアイテム数の最大値を制限
--maxSimilaritiesPerItem レコメンド計算に使用するアイテム類似度の1アイテ
ムあたりの類似アイテム数の最大値を制限
--maxPrefsInItemSimilarity アイテム類似度計算に使用するユーザ評価値の1ユー
ザあたりの評価済みアイテム数の最大値を制限

既存資産の流用
49
 問題１： Task not serializable
RDDとして保持する対象となるクラスや、RDDの演算時に使用するクラスが
Serializableを実装していない場合に発生
※既存のコードをSparkに移植する際にハマりやすいポイント
 対策
1. 対象クラスにSerializableを実装する
2. Kryo Serializationを利用する

50
 Kryo Serializationを利用する方法
1. org.apache.spark.serializer.KryoRegistratorを継承したクラスを定義
2. SparkContext生成時にSparkConfに1.で作成したクラスを設定する
import com.esotericsoftware.kryo.Kryo
import org.apache.spark.serializer.KryoRegistrator
class MyRegistrator extends KryoRegistrator {
override def registerClasses(kryo: Kryo) {
kryo.register(classOf[MyClass])
}
}
val conf = new SparkConf()
conf.set("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
conf.set("spark.kryo.registrator", "MyRegistrator")
val sc = new SparkContext(conf)

51
 問題2：マルチスレッド問題
SparkのExecutorはマルチスレッドでタスクを処理するため、各タスク内の処理
をスレッドセーフにする必要がある
既存のコードがスレッドセーフでない場合、Sparkに移植すると問題が発生
タイミングの問題のため、毎回同じ例外が発生する訳ではなく、解析が難しい
※今回の検証ではFastByIDMapというクラスを使用した処理で以下の例外が発生
・ArrayIndexOutOfBoundsException
・NullPointerException
 対策
1. スレッドセーフでないクラスをスレッドセーフなクラスに置き換える
2. Executorがマルチスレッドで動作しないような設定にする

52
 Executorがマルチスレッドで動作しないような設定
考え方
1. Executor数を使用可能なコア数と同数にする
2. Executor当たりのコア数を1にする
例： Workerノード数が10、各ノードのコア数が4コアの場合
→ 使用可能なコア数： 40コア
※ただし、基本的にはマルチスレッドの方が処理効率がいいので
問題がなければマルチスレッドを推奨
マルチスレッド設定非マルチスレッド設定
Executor数
spark.executor.instances
(--num-executors)
10 40
Executor当たりのコア数
spark.executor.cores
(--executor-cores)
4 1

まとめ
53
 Sparkのメリット
• 直感的なプログラミング
• 処理速度
 重要なパラメータ
• メモリ関連パラメータ
• 並列度関連パラメータ
 ハマりどころや注意点
• 偏ったデータに注意
• 既存資産の流用時に注意

54

Spark／MapReduceの機械学習ライブラリ比較検証

Recommended

More Related Content

What's hot (20)

Similar to Spark／MapReduceの機械学習ライブラリ比較検証 (20)

More from Recruit Technologies (20)

Recently uploaded (9)