夏真っ盛り!Spark + Python + Data Science祭り まとめ #summerDS
168サービスへのリコメンド提供。360CPU 900GBメモリを使って4時間くらいでできている。チューニング周りの成果 #summerds
2016-07-25 19:52:22現在のレコメンドシステム導入数。去年 13、今年 168。去年は裁くのに3時間かかっていたが今年は4時間で済んでる #summerDS
2016-07-25 19:52:24レコメンド数:13 -> 168 リソース:230CPUs, Memory580GB -> 360CPUs, Memory900GB 処理時間:3h -> 4h チューニングによって実現。 #summerDS
2016-07-25 19:53:53リコメンドのレシピを書いてテストを流す。要件や精度、結合テストが問題なければリリース。問題あればパラメータを再検討。 #summerds
2016-07-25 19:54:02@chezou 一般には当然できるのでは……、Sparkとかの上でうまく効率的に実装できるのかは分からないけれど…… #summerDS
2016-07-25 19:54:06レコメンド導入の自動化、レコメンドのレシピを1分で書き、レシピに従ってJenkinsで順次テスト環境、ステージング環境、本番とテストしながら進めていく。うまくいかなかったら隠しパラメータで調整する #summerDS
2016-07-25 19:54:21DMMレコメンド導入が1年で10倍で100件越え。レコメンド導入自動化していてできたと。新しいレコメンド導入時はレシピ書いてjenkinsポチだけ。必要な場合のみチューニング。#summerDS
2016-07-25 19:54:31レコメンド導入の自動化。1.レシピを書く(所要時間1分)。2.レシピに従ってテストを実行(Jenkins)。必要があればチューニング #summerDS
2016-07-25 19:54:38リコメンドエンジンは協調フィルタリングが一番メジャーなんですかね。 アイテム数・ユーザー数によって計算量が超変わるっぽい、 #summerds
2016-07-25 19:55:25全サービスのアイテムと全サービスのユーザのマトリックスを持っている。必要に応じてWhereで区切って取り出し。メリットとしては、サービス横断の分析が容易になる。素晴らしい!!! #summerDS
2016-07-25 19:58:07DMMサービスに応じてユーザ数やアイテム数のバリエーションがたくさんあるからチューニングが必要。 あと、全サービス横断のユーザー×アイテムマトリクスから必要に応じてマトリクスの領域を切り出してきてデータ作るから汎用的なデータ利用ができる。 参考になるわー #summerDS
2016-07-25 19:59:45Hiveで前処理をしてSparkでやる。Sparkジョブと分けているのは、リコメンドの計算と他処理を混ぜるとメンテしにくくなるから。 #summerds
2016-07-25 19:59:49「他サービスのマトリクスを繋げることで、サービス横断のクエリもできるようにしている」これかなり凄いのでは。。。#summerds
2016-07-25 20:00:22“データ整形、抽出みたいなETL処理はHiveでやって、Sparkはベクトル化や機械学習系の処理に注力する”良い戦略だと思います #summerDS
2016-07-25 20:00:22Sparkはレコメンドの計算に集中させ、前段の処理はHiveに任せる。きれいに役割分けて分かりやすい #summerDS
2016-07-25 20:00:26DMMではレコメンドを3種類に分けて実装している。Ranking、UserToItem、ItemTItemの3つ。前段にHiveを置いてSpark側はあまりいじらないように。 #summerDS
2016-07-25 20:00:50spark はレコメンドの処理に集中させて前処理は Hive にさせている。全て spark にすると複雑になり運用しにくくなる懸念があったとの事 #summerDS
2016-07-25 20:01:32こうして話を聞いていると、この界隈のよく使われている推薦アルゴリズムは協調フィルタリングや行列分解系で、LambdaMARTとかみたいなのは意外に使われていないのかな…… #summerDS
2016-07-25 20:02:23加嵜さんの以前のHive on Sparkの資料はこちらです slideshare.net/knagato/hive-o… #summerDS
2016-07-25 20:02:48