Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (9)
Similar to Sparkを活用したレコメンドエンジンのパフォーマンスチューニング＆自動化
Similar to Sparkを活用したレコメンドエンジンのパフォーマンスチューニング＆自動化 (20)
More from Nagato Kasaki
Sparkを活用したレコメンドエンジンのパフォーマンスチューニング＆自動化
- 1. / 38 Sparkを活用したレコメンドエンジンの パフォーマンスチューニング＆自動化 ビッグデータ部 加嵜長門 2016年7月25日 夏真っ盛り！Spark + Python + Data Science祭り
- 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
- 10. / 38 アジェンダ • レコメンド導入の自動化 • レコメンドの基礎 • ユーザ・アイテムマトリクス • レコメンドの分類 • データ処理の流れ • チューニング • 精度チューニングとパフォーマンスチューニング • Sparkチューニング • データの偏り 10
- 11. / 38 レコメンド導入の自動化 11 サービスに新しくレコメンドを1つ追加する場合 レコメンドの「レシピ」を書く（所要時間1分） 「レシピ」にしたがってテストを実行 ステージング環境 チューニング自動化 本番環境 テスト環境 要件テスト 性能テスト 精度テスト 結合テスト リリース テストで問題があれば…
- 12. / 38 レコメンドの基礎 – 協調フィルタリング 12 対象ユーザ 閲覧中の商品 閲覧 他のユーザ 購入 購入 レコメンド
- 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 アイテム数が極端に多い
- 18. / 38 レコメンドの分類 • 巷のいろいろなレコメンドのカテゴリ • DMMでは3種類に分類 • Ranking • 任意の場所からアイテムをレコメンド • UserToItem • 人に対してアイテムをレコメンド • ItemToItem • アイテムに対してアイテムをレコメンド 18 サイトTOP サービスTOP アイテム アイテム アイテム サービスTOP アイテム アイテム アイテム サービスTOP アイテム アイテム アイテム ECサイトの構造例 Ranking ItemToItemUserToItem
- 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
- 26. / 38 アジェンダ • レコメンド導入の自動化 • レコメンドの基礎 • ユーザ・アイテムマトリクス • レコメンドの分類 • データ処理の流れ • チューニング • 精度チューニングとパフォーマンスチューニング • Sparkチューニング • データの偏り 26
- 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