例によって途中参加だったので1つ目の発表は途中から＆macbook忘れてiPhoneでメモ取ったので日本語不自由な感じになっています。
Ibis: すごいpandas 大規模データ分析もらっくらく
Cloudera社 有賀康顕氏 ( @chezou )
Jupyter notebookでデモ
教師データを作ってからscikit-learnが出てくる
PySparkと比べて
- 設定が簡単
- 速い
- 参考値としては基盤にしているCloudera ImpalaがPySparkよりも7倍速い
spark-sklearn
pip install ibis-framework
でインストールできる
Impala使いたければClouderaのdirectorを使うと良いとのこと。
Amebaにおけるレコメンデーションシステムの紹介
サイバーエージェント社 内藤遥氏
レコメンデーションシステム概要
Amebaで使っているレコメンデーションシステムは以下の3種
- A.J.A. recommend
- phoenix ⇦今日はこれ
強調フィルタリング
Sparkを利用 - バトルrecommend
レコメンデーションシステムの利用
- 関連ハッシュタグ
- グルっぽ
- 読書の時間
概要
- アクティビティログをhadoopへ
- 推薦結果をhbaseへ
- キーにソルトとしてハッシュの頭1文字（分散のため
- 推薦結果のimp/clkなどをフィードバック
- バンデットアルゴリズムでCTRを元にリランキング
Item to Item collaborative filtering
ユーザーベースの協調フィルタリング
距離の近いユーザの評価を元にする
アイテムベース
アイテム間の距離を元にユーザの評価を元にする
アイテムの評価が少なくても精度が出せる
コサイン類似度
共起数（重複ユーザ数）を要素の平方根を積算した値で割る
ケースごとの工夫
シンプルにする
ブロードキャスト変数を使って各ワーカーに割り振る。
こうすると複雑なjoinが不要になる
推薦結果を鮮度の新しいものだけにしたい
事前にアイテムセット（フィルター）を作っておいて結果をフィルターする
Sparkを活用したレコメンドエンジンのパフォーマンスチューニング＆自動化
DMM.comラボ社 加嵜長門氏
作ったあとの運用の話
Spark活用システムの概要
2015年2月からSpark活用。
エンジニア3人で13件から168件
自動化してたから対応できた
リソースは1.5倍くらい
230CPUs / 580GB から 360CPUs / 900GB
時間は3hから4hへ
導入自動化
サービスが多いので新サービスでの利用開始を容易にしている
サービス追加したい時
- レシピを書く
- レシピに従ってテストを流す jenkins
- テスト環境で動作確認
- ステージングで性能
- 本番にリリース
サービスによってユーザ数とアイテム数の比率が大きく違うのでチューニングも個別に必要
スケール感はユーザ数100万人とか商品数400万点とか
全サービス横断のアイテムマトリクスを用意している
→サービス間のレコメンデーションも可能になる
ランキング
アルゴリズムは2種使い分けている
- ユーザーTOアイテム
- アイテムTOアイテム
- Hiveでデータ整形
- Sparkではレコメンド計算だけ
- シンプルさを維持するため
- SqoopでDBに出力
レシピはhive,spark,sqoopのパラメタ設定をJSONで定義している
精度チューニングは実際に投入してA/Bテストする（学術的な評価式もあるが、試さないとわからなところもある）
パフォーマンスはわかりやすく問題になるので事前にチューニング
- ボトルネックを探して
- データの偏りを解消する
20:80の法則によりデータの分割に失敗する時がある（分割しても偏っているケースが多い）
うまく分割できれば3時間→3分に短縮とか
（以下編集中）
LT枠
spark初心者がレコメンドでハマった
15分ごとにsubmitするとディスク枯渇
jarがコピーされる
クラスタを作り直しながらsubmitする
BigQueryからのロード時にパーティション数が少ない
executorが使い切れない
リパーティション大事
レコメンドされない
ユーザ多すぎて直積とれない
ユーザ集合にまとめて処理した
Sparkを使ったレコメンドエンジンのパフォーマンスチューニング
dag visualizationみよう
分散してなかったら分散させる
大量データでシャッフルさせるとダメ
複数回使うrddはキャッシュする
cpuボトルネックの時はシリアライズしない選択肢
KryoSerializer2倍速くなった