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.

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

7,532 views

Published on

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

Published in: Engineering

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

×