Sparkを活用したレコメンドエンジンのパフォーマンスチューニング＆自動化

1. / 38 Sparkを活用したレコメンドエンジンのパフォーマンスチューニング＆自動化ビッグデータ部加嵜長門 2016年7月25日夏真っ盛り！Spark + Python + Data Science祭り

2. / 38 DMM.com ～総合エンターテイメントサイト 2 月間 25億PV 会員 1700万人多様なサービス形態

3. / 38 DMM.comの主な事業 3 動画配信デジタル配信事業電子書籍 AKB48 AKB48グループ劇場を独占配信動画チャンネル TBSオンデマンド、バンダイチャンネルをはじめとした、映画・ドラマ、アニメ、アイドル、バラエティーなどを配信ペーパーレスな読書スタイルコミック、小説、写真集などの電子書籍をPC、スマホで閲覧 ec系事業無店舗型ネットレンタルいろいろレンタルネット通販 DVD、CD、コミック、ゲーム、ホビーなどをネットショッピングネットで借りて、自宅へ届き、ポストへ返却ブランドバッグ、デジカメから季節モノまで必要なものを必要な時にラクラクレンタル

4. / 38 DMM.comの主な事業 4 オンラインゲーム事業 FX/CFD事業オンライン英会話事業充実のラインナップ PC、スマホで遊べるオンラインゲーム FX業界トップクラスの実績自宅や外出先のスマホで英会話学習

5. / 38 DMM.comの主な事業 5 .make /３Dプリント事業ロボット事業太陽光発電事業ものつくりプラットフォーム製造業の新しいカタチクリエイターが集うものつくりシェアスペース MVNO事業世界初のロボットキャリア DMMではじめるロボットとの新生活格安SIM/スマホ販売

6. / 38 DMM.comラボにおけるSpark活用の歴史 • Developers Summit 2015 • Sparkによるリアルタイムレコメンド • http://event.shoeisha.jp/devsumi/20150219/session/642/ • プレスリリース • Sparkを活用したアジアパシフィック初のレコメンド基盤実現 • http://www.cloudera.co.jp/customers/dmm.html • Spark Conference Japan 2016 • Hive on Sparkを活用した高速データ分析 • 『詳解 Apache Spark』発売 • 8章 GraphX を担当 6 2015年2月 2015年9月 2016年2月 2016年4月

7. / 38 Sparkを活用したレコメンドシステム導入実績 • DMM.comサービス内のレコメンド • プラットフォームの共通モジュール • 外部ASP • 事業部独自実装など多数 • Sparkを活用したレコメンド • 2015年8月～ • 順次導入を進めている 7 13 168

8. / 38 レコメンド導入の伸びを支えるシステム 8 230 CPUs 580 GB memory 360 CPUs 900 GB memory 13 168 x 13 x 1.5 x 1.3 レコメンド導入数 YARN リソース処理時間/日 3h 4h 自動化パフォーマンスチューニング

9. / 38 アジェンダ • レコメンド導入の自動化 • レコメンドの基礎 • ユーザ・アイテムマトリクス • レコメンドの分類 • データ処理の流れ • チューニング • 精度チューニングとパフォーマンスチューニング • Sparkチューニング • データの偏り 9

11. / 38 レコメンド導入の自動化 11 サービスに新しくレコメンドを1つ追加する場合レコメンドの「レシピ」を書く（所要時間1分）「レシピ」にしたがってテストを実行ステージング環境チューニング自動化本番環境テスト環境要件テスト性能テスト精度テスト結合テストリリーステストで問題があれば…

12. / 38 レコメンドの基礎 – 協調フィルタリング 12 対象ユーザ閲覧中の商品閲覧他のユーザ購入購入レコメンド

13. / 38 協調フィルタリングのマトリクス表現 13 item user

14. / 38 ユーザ・アイテムマトリクス 1 2 3 4 1 1 2 1 1 3 1 1 4 1 1 14 item user

15. / 38 サービスごとのユーザ・アイテムマトリクス • アイテム数、ユーザ数の規模や比率が異なる • サービスの特徴に応じたチューニングが不可欠 15 サービス名ユーザ数アイテム数特徴サービスA 50,000 200,000 アイテム数が多いサービスB 1,000,000 200 ユーザ数が多いアイテム数は極端に少ないサービスC 1,500,000 300,000 ユーザ数もアイテム数も多いサービスD 100,000 4,000,000 アイテム数が極端に多い

16. / 38 全サービス横断のユーザ・アイテムマトリクス 16 全サービスのユーザ全サービスのアイテム汎用的なデータ構造として、全サービス横断の、巨大なユーザ・アイテムマトリクスを作成実態はHiveテーブルレコメンドの要件に応じて、部分空間を抽出する HiveクエリのWHERE句で絞り込み

17. / 38 全サービス横断のユーザ・アイテムマトリクス 17 サービスAのユーザサービスAのアイテムサービスBのユーザサービスBのアイテムサービスC&DのユーザサービスCのアイテムサービスDのアイテムサービス横断のレコメンドも可能

18. / 38 レコメンドの分類 • 巷のいろいろなレコメンドのカテゴリ • DMMでは3種類に分類 • Ranking • 任意の場所からアイテムをレコメンド • UserToItem • 人に対してアイテムをレコメンド • ItemToItem • アイテムに対してアイテムをレコメンド 18 サイトTOP サービスTOP アイテムアイテムアイテムサービスTOP アイテムアイテムアイテムサービスTOP アイテムアイテムアイテム ECサイトの構造例 Ranking ItemToItemUserToItem

19. / 38 Ranking 19 item user アイテムごとにスコア計算

20. / 38 UserToItem 20 item user 類似ユーザを見つける

21. / 38 ItemToItem 21 item user アイテム同士の相関を計算

22. / 38 レコメンドの分類例 22 レコメンドの説明入力出力分類あなたにおすすめの商品ユーザID その人に似ているユーザが買った商品 UserToItem この商品を買った人はこんな商品も興味があります商品ID 同時に買われた商品 ItemToItem あなたの閲覧履歴からおすすめ過去に閲覧したアイテム類似のアイテム ItemToItem 新着アイテム（時刻）新着アイテム Ranking 地域別人気アイテム（位置情報）人気アイテム Ranking ユーザ属性（年齢・性別など）に基づくおすすめ商品（ユーザ属性）人気アイテム Ranking あなたにおすすめの友達ユーザ類似ユーザ UserToItem

23. / 38 データ処理の流れ 23 Ranking  対象データの抽出  後段Spark処理のためのデータ整形 UserToItem ItemToItem  機械学習  ベクトル計算  レコメンド計算結果をDBにエクスポート Sparkではレコメンド計算だけを記述したいデータ整形は前段のHiveに任せる

24. / 38 レコメンドの「レシピ」 24 { "hive": { "対象ユーザ、対象アイテムの条件": "サービスID、フロア条件など", "レコメンド種類": "(Ranking, UserToItem, ItemToItem)", "スコアの計算方法": ~, }, "spark": { "アルゴリズム": ~, "パラメタ": ~, "リソース設定": "メモリ、コア数、Executor数など", }, "sqoop": { "出力先": ~, } } recommendXX.json5

25. / 38 レコメンド導入の自動化まとめ • データの抽象化と汎用化 • 巨大なマトリクス構造 • レコメンドの種類を3タイプに抽象化 • 個別の設定やチューニング項目を設定ファイル化 • テスト・リリースの自動化 25

27. / 38 レコメンドのチューニング 27 チューニングパフォーマンスチューニング精度チューニング  そもそも処理が失敗する場合  処理はできるが時間がかかりすぎる場合  定量的指標 Coverage, Mean Average Precision, B-pref, …  定性的指標ユーザテスト最終的には、リリースしてみてABテストで改善していく

28. / 38 パフォーマンスチューニング • Sparkのパフォーマンスチューニング • ボトルネックとなる箇所の特定 • データの偏りを解消 • リソースの調整 • 詳しくは以前の発表「Hive on Spark を活用した高速データ分析」 • その他の項目を調整 • データ構造の改善 • ロジックの改善 • …etc. 28

29. / 38 データの偏りはなぜ起こるか？ • データの偏り • Skewed Data • スケールフリーネットワーク • 人気者はより人気者になりやすい • 売れている商品はより売れやすい • 例：ロングテール商品 • 分散処理の限界 • 全件ソートなど 29 https://en.wikipedia.org/wiki/Long_tail ロングテール上位20%の商品が売上の80%を占める

30. / 38 データの偏り：ユーザ・アイテムマトリクスの例 user item score 1 1 1 2 1 1 2 3 1 3 1 1 3 2 1 4 1 1 4 4 1 30 1 1 1 3 1 1 4 4 1 2 3 1 3 2 1 2 1 1 4 1 1 マトリクスのRDD, Hiveテーブル表現パーティショナーにより分割されて保持

31. / 38 Spark RDDで類似のユーザを探す user item score 1 1 1 2 1 1 2 3 1 3 1 1 3 2 1 4 1 1 4 4 1 31 item (user, score) 1 (1, 1) 1 (2, 1) 3 (2, 1) 1 (3, 1) 2 (3, 1) 1 (4, 1) 4 (4, 4) アイテムIDでJOINするため、アイテムID をキーに変更

32. / 38 item (user, score) 1 (1, 1) 1 (2, 1) 3 (2, 1) 1 (3, 1) 2 (3, 1) 1 (4, 1) 4 (4, 4) Spark RDDで類似のユーザを探す 32 1 (1, 1) 1 (2, 1) 1 (3, 1) 1 (4, 1) 3 (2, 1) 2 (3, 1) 4 (4, 4) 同じアイテムIDのデータは同じブロックに集められる

33. / 38 自己結合時のデータの偏り 33 key value key value JOIN Task

34. / 38 データの偏りの解消 • パフォーマンスが数十倍改善することも • 1分50秒 → 5秒 • 5時間 → 30分 • 3時間 → 3分 • 主な手法 • パーティショナーの最適化 • パーティション数の調整 • 外れ値の除外 • キーにSaltを加えた多段処理 34

35. / 38 外れ値の除外 • 上限を設ける • 評価アイテム数が多いユーザは、最新N件の評価アイテムのみ使う • 1アイテムしか評価していないユーザは、モデルの計算処理から省く • 分割する • 評価が集中するアイテムのスコアを別枠で計算する 35

36. / 38 キーにSaltを加えた多段処理 • 偏りの多いIDについて、ランダムなsaltを付与 • saltを加えたIDで処理した後、本来のIDで再度処理する 36 item 1 1 1 1 1 item-salt 1-001 1-002 1-002 1-003 1-003 item 1 1 1 1 1

37. / 38 チューニングまとめ • 精度チューニング • リリース後にABテスト • パフォーマンスチューニング • ボトルネックとなる箇所の特定 • リソース調整の前に、データの偏り(skewed data)を解消する • データの偏りがボトルネックになる場合、リソースを増やしても効果が薄い • データの特性を見ながら調整 37

38. / 38 今後の展望 • HiveとSparkの統合 • 設計当時、Sparkの処理はRDDベースだった • データの整形やフィルタがHive(SQL)に比べ冗長だった • DataFrames, DataSet, Pipelineの登場で、状況が変わった • パフォーマンス・保守性向上のため、HiveとSparkは統合していきたい • 行動ログに依存しないレコメンド • コンテンツベース • メディアデータの解析 • 画像、音声、動画、・・・ • Deep Learningの活用 38

Sparkを活用したレコメンドエンジンのパフォーマンスチューニング＆自動化

knagato

Sparkを活用したレコメンドエンジンのパフォーマンスチューニング＆自動化