Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
Amebaにおけるレコメンデーションシステムの紹介
Next
Download to read offline and view in fullscreen.

Share

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

Download to read offline

夏真っ盛り!Spark + Python + Data Science祭り 発表資料
http://connpass.com/event/34680/

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

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

  1. 1. / 38 Sparkを活用したレコメンドエンジンの パフォーマンスチューニング&自動化 ビッグデータ部 加嵜長門 2016年7月25日 夏真っ盛り!Spark + Python + Data Science祭り
  2. 2. / 38 DMM.com ~総合エンターテイメントサイト 2 月間 25億PV 会員 1700万人 多様な サービス 形態
  3. 3. / 38 DMM.comの主な事業 3 動画配信 デジタル配信事業 電子書籍 AKB48 AKB48グループ劇場を独占配信 動画チャンネル TBSオンデマンド、バンダイチャンネ ルをはじめとした、映画・ドラマ、ア ニメ、アイドル、バラエティーなどを 配信 ペーパーレスな読書スタイル コミック、小説、写真集などの 電子書籍をPC、スマホで閲覧 ec系事業 無店舗型ネットレンタル いろいろレンタルネット通販 DVD、CD、コミック、ゲーム、 ホビーなどをネットショッピン グ ネットで借りて、自宅へ届き、ポストへ返却 ブランドバッグ、デジカメから 季節モノまで 必要なものを必要な時にラクラ クレンタル
  4. 4. / 38 DMM.comの主な事業 4 オンラインゲーム事業 FX/CFD事業 オンライン英会話事業 充実のラインナップ PC、スマホで遊べるオンラインゲーム FX業界トップクラスの実績 自宅や外出先のスマホで英会話学習
  5. 5. / 38 DMM.comの主な事業 5 .make /3Dプリント事業 ロボット事業 太陽光発電事業 ものつくりプラットフォーム 製造業の新しいカタチ クリエイターが集う ものつくりシェアスペース MVNO事業 世界初のロボットキャリア DMMではじめるロボットとの新 生活 格安SIM/スマホ販売
  6. 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. 7. / 38 Sparkを活用したレコメンドシステム導入実績 • DMM.comサービス内のレコメンド • プラットフォームの共通モジュール • 外部ASP • 事業部独自実装 など多数 • Sparkを活用したレコメンド • 2015年8月~ • 順次導入を進めている 7 13 168
  8. 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. 9. / 38 アジェンダ • レコメンド導入の自動化 • レコメンドの基礎 • ユーザ・アイテムマトリクス • レコメンドの分類 • データ処理の流れ • チューニング • 精度チューニングとパフォーマンスチューニング • Sparkチューニング • データの偏り 9
  10. 10. / 38 アジェンダ • レコメンド導入の自動化 • レコメンドの基礎 • ユーザ・アイテムマトリクス • レコメンドの分類 • データ処理の流れ • チューニング • 精度チューニングとパフォーマンスチューニング • Sparkチューニング • データの偏り 10
  11. 11. / 38 レコメンド導入の自動化 11 サービスに新しくレコメンドを1つ追加する場合 レコメンドの「レシピ」を書く(所要時間1分) 「レシピ」にしたがってテストを実行 ステージング環境 チューニング自動化 本番環境 テスト環境 要件テスト 性能テスト 精度テスト 結合テスト リリース テストで問題があれば…
  12. 12. / 38 レコメンドの基礎 – 協調フィルタリング 12 対象ユーザ 閲覧中の商品 閲覧 他のユーザ 購入 購入 レコメンド
  13. 13. / 38 協調フィルタリングのマトリクス表現 13 item user
  14. 14. / 38 ユーザ・アイテムマトリクス 1 2 3 4 1 1 2 1 1 3 1 1 4 1 1 14 item user
  15. 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. 16. / 38 全サービス横断のユーザ・アイテムマトリクス 16 全サービスの ユーザ 全サービスのアイテム 汎用的なデータ構造として、全 サービス横断の、巨大なユーザ・ アイテムマトリクスを作成 実態はHiveテーブル レコメンドの要件に応じて、部分 空間を抽出する HiveクエリのWHERE句で絞り込み
  17. 17. / 38 全サービス横断のユーザ・アイテムマトリクス 17 サービスAの ユーザ サービスAのアイテム サービスBの ユーザ サービスBのアイテム サービスC&Dの ユーザ サービスCのアイテム サービスDのアイテム サービス横断の レコメンドも可能
  18. 18. / 38 レコメンドの分類 • 巷のいろいろなレコメンドのカテゴリ • DMMでは3種類に分類 • Ranking • 任意の場所からアイテムをレコメンド • UserToItem • 人に対してアイテムをレコメンド • ItemToItem • アイテムに対してアイテムをレコメンド 18 サイトTOP サービスTOP アイテム アイテム アイテム サービスTOP アイテム アイテム アイテム サービスTOP アイテム アイテム アイテム ECサイトの構造例 Ranking ItemToItemUserToItem
  19. 19. / 38 Ranking 19 item user アイテムごとに スコア計算
  20. 20. / 38 UserToItem 20 item user 類似ユーザを 見つける
  21. 21. / 38 ItemToItem 21 item user アイテム同士の 相関を計算
  22. 22. / 38 レコメンドの分類例 22 レコメンドの説明 入力 出力 分類 あなたにおすすめの商品 ユーザID その人に似ているユー ザが買った商品 UserToItem この商品を買った人はこんな 商品も興味があります 商品ID 同時に買われた商品 ItemToItem あなたの閲覧履歴からおすす め 過去に閲覧したア イテム 類似のアイテム ItemToItem 新着アイテム (時刻) 新着アイテム Ranking 地域別人気アイテム (位置情報) 人気アイテム Ranking ユーザ属性(年齢・性別など) に基づくおすすめ商品 (ユーザ属性) 人気アイテム Ranking あなたにおすすめの友達 ユーザ 類似ユーザ UserToItem
  23. 23. / 38 データ処理の流れ 23 Ranking  対象データの抽出  後段Spark処理のためのデータ整形 UserToItem ItemToItem  機械学習  ベクトル計算  レコメンド計算結果をDBにエクスポート Sparkではレコメンド計算だけを記述したい データ整形は前段のHiveに任せる
  24. 24. / 38 レコメンドの「レシピ」 24 { "hive": { "対象ユーザ、対象アイテムの条件": "サービスID、フロア条件など", "レコメンド種類": "(Ranking, UserToItem, ItemToItem)", "スコアの計算方法": ~, }, "spark": { "アルゴリズム": ~, "パラメタ": ~, "リソース設定": "メモリ、コア数、Executor数など", }, "sqoop": { "出力先": ~, } } recommendXX.json5
  25. 25. / 38 レコメンド導入の自動化 まとめ • データの抽象化と汎用化 • 巨大なマトリクス構造 • レコメンドの種類を3タイプに抽象化 • 個別の設定やチューニング項目を設定ファイル化 • テスト・リリースの自動化 25
  26. 26. / 38 アジェンダ • レコメンド導入の自動化 • レコメンドの基礎 • ユーザ・アイテムマトリクス • レコメンドの分類 • データ処理の流れ • チューニング • 精度チューニングとパフォーマンスチューニング • Sparkチューニング • データの偏り 26
  27. 27. / 38 レコメンドのチューニング 27 チューニング パフォーマンスチューニング 精度チューニング  そもそも処理が失敗する場合  処理はできるが時間がかかりすぎる場合  定量的指標 Coverage, Mean Average Precision, B-pref, …  定性的指標 ユーザテスト 最終的には、リリースしてみてABテストで改善していく
  28. 28. / 38 パフォーマンスチューニング • Sparkのパフォーマンスチューニング • ボトルネックとなる箇所の特定 • データの偏りを解消 • リソースの調整 • 詳しくは以前の発表 「Hive on Spark を活用した高速データ分析」 • その他の項目を調整 • データ構造の改善 • ロジックの改善 • …etc. 28
  29. 29. / 38 データの偏りはなぜ起こるか? • データの偏り • Skewed Data • スケールフリーネットワーク • 人気者はより人気者になりやすい • 売れている商品はより売れやすい • 例:ロングテール商品 • 分散処理の限界 • 全件ソートなど 29 https://en.wikipedia.org/wiki/Long_tail ロングテール 上位20%の商品が売上の80%を占める
  30. 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. 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. 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. 33. / 38 自己結合時のデータの偏り 33 key value key value JOIN Task
  34. 34. / 38 データの偏りの解消 • パフォーマンスが数十倍改善することも • 1分50秒 → 5秒 • 5時間 → 30分 • 3時間 → 3分 • 主な手法 • パーティショナーの最適化 • パーティション数の調整 • 外れ値の除外 • キーにSaltを加えた多段処理 34
  35. 35. / 38 外れ値の除外 • 上限を設ける • 評価アイテム数が多いユーザは、最新N件の評価アイテムのみ使う • 1アイテムしか評価していないユーザは、モデルの計算処理から省く • 分割する • 評価が集中するアイテムのスコアを別枠で計算する 35
  36. 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. 37. / 38 チューニング まとめ • 精度チューニング • リリース後にABテスト • パフォーマンスチューニング • ボトルネックとなる箇所の特定 • リソース調整の前に、データの偏り(skewed data)を解消する • データの偏りがボトルネックになる場合、リソースを増やしても効果が薄い • データの特性を見ながら調整 37
  38. 38. / 38 今後の展望 • HiveとSparkの統合 • 設計当時、Sparkの処理はRDDベースだった • データの整形やフィルタがHive(SQL)に比べ冗長だった • DataFrames, DataSet, Pipelineの登場で、状況が変わった • パフォーマンス・保守性向上のため、HiveとSparkは統合していきたい • 行動ログに依存しないレコメンド • コンテンツベース • メディアデータの解析 • 画像、音声、動画、・・・ • Deep Learningの活用 38
  • KenichiTakahashi1

    Apr. 25, 2017
  • KeisukeKadoyama

    Mar. 26, 2017
  • kmikami

    Mar. 15, 2017
  • HaradaTomoki

    Aug. 1, 2016
  • diealie

    Jul. 31, 2016
  • YoshiakiAmano

    Jul. 30, 2016
  • MoriKeigo

    Jul. 27, 2016
  • sakai

    Jul. 26, 2016
  • ssuserd3923a

    Jul. 26, 2016
  • ssuser14ba1a

    Jul. 26, 2016
  • yukiokuno754

    Jul. 26, 2016

夏真っ盛り!Spark + Python + Data Science祭り 発表資料 http://connpass.com/event/34680/

Views

Total views

9,062

On Slideshare

0

From embeds

0

Number of embeds

5,566

Actions

Downloads

32

Shares

0

Comments

0

Likes

11

×