リクルートにおけるデータ活用の現実解について

2017/09/27 PyData.Tokyo Meetup #15での、松﨑の講演資料になります

Transcript

1. リクルートにおけるデータ 活用の現実解について リクルートテクノロジーズ/リクルートホールディングス 松﨑 遥
2. 自己紹介(松﨑 遥) リクルートテクノロジーズ ビッグデータ部 → 来月からはリクルートホールディングス データ・AI戦略本部 仕事：リクルート最大のAI基盤を5年ぶりに刷新しようとしているが、今までとは全く違う システムにしたく、それを設計するのが仕事(“新アーキテクチャPJ“の責任者) 趣味：ロールプレイングゲーム 同じものを延々とやる 真・女神転生III-NOCTURNE - 15年目に突入 来歴：中学では半田付け・Z80(8bitCPU)など 大学・大学院は物理(一般相対論・量子力学・カオス) → 現実との関わりへの飢え 大学院時代未踏でバイト以降ずっとプログラマ c++, objc, php, java, scala, haskell,sa, js, nodejs → 数学とコンピューティングの融合への欲求 私が2015年1月末にリクルートに来たところ、そこには10億件が入ったDBがあった。 2 情報幾何 NN/DNN 心が豊かになる ナニコレ?
3. ライフイベント領域 進学 就職 結婚 転職 住宅購入 車購入 出産/育児 旅行 IT/トレンド 生活/地域情報 グルメ・美容 ライフスタイル領域 選択・意思決定 を支援する情報サービスの提供 「まだ、ここにない、出会い。」を実現する リクルート運営サービスのご紹介
4. リクルートID 一人ひとりにあった最適な情報を提供し、皆様の選択や行動を支える存在となることを目指す
5. Pontaポイント
6. ここまででの情報の要約 • リクルートには、全サービスのログを横断して分析する組織がある • 最良の場合には、一人一人に対して、 • ファッション • グルメ • 車・家購入 • 結婚 • お稽古 • 美容 • 通販 といった多様なデータが取れるため、非常に分析しがいのあるデータ 6
7. さてせっかくなので ロールプレイング していただきましょう 7
8. Q:あなたが 人間の最新の行動予測モデルを実データに適用しようとお考えになり、 リクルートの全サービス全データへのアクセスを手に入れたとします。 それでは、持てるスキルを総動員するとして - あなたは何をしますか? 具体的に、どんな仕事をすることになるのか、イメージをしてみてください。 ※あくまで、今回のテーマ「理想vs現実解」の「理想」部分を考える導入としての問い 8
9. 理想はこう (ナイーブですが、あくまで私の理想) 何を想定されたか、具体的な内容は個人差がありますが、以下の構造は共通するのでは？ 9 何かを 機械学習 経済的 リターン 「予測の精度を上げる」 「儲かる」
10. しかし現実はこう 2017年現在の業務構造 10 データ 解読 データ 整形 機械学習 分散計算 公開 経済的 リターン 効果 検証 承認 横展開
11. 理想と現実との差分 データ活用業務の９割を占めるこれらの仕事の正体とは??? 11 データ 解読 データ 整形 機械学習 分散計算 公開 経済的 リターン 効果 検証 承認 横展開
12. 現実解を理解するために 私は黎明期から関わってる数少ない人間の生き残り(2人)のうちのひとりなので、 これがなんでこうなってしまったか全て説明できます。 大きく3つに分けてご説明しましょう。 1. まずは分散計算とは何か、から。 2. つぎに、データのデリバリーについて。 3. 最後に、モデルの説明性について。 そして、現実解をふまえて、先ほどの質問をもう一度考えていただきましょう。 12
13. アジェンダ 1/3 分散計算について 13 データ 解読 データ 整形 機械学習 分散計算 公開 経済的 リターン 効果 検証 承認 横展開
14. 分散計算とは Q: あなたは、10億件のログが入ったテキストファイルと、以下の社長命令を受け取りました。 「明日の役員会までに、この12ヶ月でじゃらんで生じた取引の件数を出して下さい」 あなたは、この課題には、自分の専門知識は不要であると感じました。 なぜなら、これは本質的に以下のSQLと同じだからです。 あなたは同様のロジックをpythonで実装し、実行を始めました。仕事は完了です。 1時間後に様子を見てみると、あなたのscriptはpythonとしては破格の性能を叩き出しており、 1000万行中968,714件がじゃらんで生じた取引であることがわかりました。 どうしますか? 1: 謝る 2: 今ある数字を100倍して社長に提出する 3: Hadoopクラスタを買う 14 select count(1) from LOG where service=’JLN’ Hadoopとは – 巨大なデータ処理をmap/reduce と呼ばれる小さなタスクに分解し、 各ノードで実行・統合するMW。
15. 理想:Hadoopを買うと魔法のように問題は解決? 15 Hadoop 100台 ≒100倍速 =1時間後 (ここはTrue) あなた 「9,644万人泊」 結果 もちろんNO
16. 分散処理系を買うとはどういうことか? リクルート横断データ基盤における分散処理系導入状況 16 ソース 保存(DataWarehouse) 加工(DataMart) 機械学習 Cloud On- Premi se google adobe Recruit S3 ExaData Production Hadoop ExaData Sandbox Hadoop 松﨑実験 クラスタ BigQuery (dremel) DataProc (ManagedHadoop)
17. =運用チームも買う(人件費がかかる)ということ リクルート横断データ基盤における分散処理系導入状況 17 ソース 保存(DataWarehouse) 加工(DataMart) 機械学習 Cloud On- Premi se google adobe Recruit S3 ExaData Production Hadoop ExaData Sandbox Hadoop 松﨑実験 クラスタ GA/Omniture 運用チーム AWS運用 (Security)T ExaData運用 +DBAチーム Hadoop運用 +SREチーム GCP運用 +契約管理T データリンク チーム
18. 分散処理系では運用チーム無しで仕事は出来ない 18 Hadoop 分散システムは よく落ちる やりなおし あなた 「 」 結果 よく考えれば当たり前 故障率pとして1-(1-p)^n=np+o(p^2)なのだから そして速いほどよく落ちる Kudu>Spark>Hadoop while (true) { }
19. でも、落ちたときの復旧さえなんとかなれば 19 Hadoop N台 ≒N倍速 あなた 集計だけでなく (統計的)機械学習も可能 台数に応じた無制限な高速化 (スケールアウト)
20. 分散処理系では実装も制限される いかなるState-of-the-Artなモデルも、分散計算ロジックが開発できなければ計算完了しない =机上の空論 分散計算ロジックを開発する： 1. JavaでMapReduceを書く 2. ScalaでRDD操作を書く 3. 素直に実装済みモデルを利用する – Mllib, Hivemall → Collaborative Filteringや、Logistic Regressionなどが生き残り続ける一因。 ※GPUは分岐演算と、長いデータへの不均一な処理(要は文字列処理)が出来ないため こうした一般的なタスクには不向き(Hadoopは何でもできる) 20
21. 実例1：リコメンデーション 横断データによるリコメンデーションとは、 「全てのサービスへのアクセス情報から、特定のサイトでの購買アイテムを予測」 するタスク。実は3年間、Collaborative Filteringを強化し続けている。CFは簡単に分散する State-of-the-Artモデルを実装した時の性能の伸びが10%程度だったのに対し、 Adhocなフィルタによる • 性能の伸びは1つ毎に最大250% • Hadoopロジック開発が容易 であるため、Adhocなフィルタは5個以上開発された。 分散システムの宿命として2ヶ月に1回は原因不明のエラーで失敗するが、単純ゆえ管理も楽 現在のリコメンデーションロジック： 21 CF コンテン ツ類似 による Boost 購買地 域による Boost 保有ポイ ントによ るBoost Recency による Boost Deviceに よる Boost 3-gram(!) リクルートの 強み Pontaの強み
22. アジェンダ 2/3 デリバリーについて 22 データ 解読 データ 整形 機械学習 分散計算 公開 経済的 リターン 効果 検証 承認 横展開
23. デリバリーとは何か? 一般に、価値を届けること ここでは特に、必要な時にデータがあることを言う。 23 機械学習 予測結果 Web開発者 予測結果 に対する オンラインログ 効果検証する 分析者 UIを切り替えるのに使うが、 データはどこにあるのか? 検定したいが、 クリックログや 購買ログはどこだ? ？ ？ ここを つなぐこと
24. 実例2:予測データ提供API 低負荷版API 24 Hadoop 予測データ HBase 予測データ RecruitID 指定 コピー(5〜30分) ランダム アクセス が遅い ランダム アクセス が速い DIRTy (Data Intensive Real Time) js <script> 追加 高負荷版API Hadoop 予測データ BigTable/ Spanner js Autoscale(1台〜20台・15s/台) KVSを使った デリバリーの仕組み
25. 実例3:リコメンデーションモニタリングシステム ポイント • ランダムアクセス/集計は適切に分散処理可能な基盤が異なる • デリバリーとは、当該処理が得意なシステム上にデータを届けること • レイテンシーは1日以上かかることが多い(日次ジョブ) • 予測データの公開や、効果検証時にデリバリー業務が発生する • デリバリーのコストはスクラッチ開発を含むため相当高い 25 js 予測データ 問い合わせ browser ログ収集 専用インスタンス js製BIツール Hive 他社BIツール 集計が遅い 集計が速い HBase HiveServer2を使った デリバリーの仕組み コピー(5〜30分)
26. 実例4:コンテンツ生成システム データ移動を発生させないアーキテクチャは可能か? ＝ランダムアクセスと集計が両方(そこそこ)速いデータベース上に、 予測データと実績データを両方おくことは可能か?それを可能にする技術はあるか? ウィンドウ集計の例) banditアルゴリズムにおける報酬の標本平均の計算 26 Spanner 学習アルゴリズム 効果測定者 RecruitID 指定 js 予測結果 /生成コンテンツ browser 開封/購買 実績データ ウィンドウ集計 単純集計 予測データと実績データのJOIN処理 w/ ゼロレイテンシー
27. アジェンダ 3/3 説明性について ここまで出来ていれば、機械学習で儲かっている状態。しかし未来にも繋がなければならない 27 データ 解読 データ 整形 機械学習 分散計算 公開 経済的 リターン 効果 検証 承認 横展開
28. Q:我々の仕事は誰が与えてくれるか A:自分で作る 「自ら機会を創り出し、機会によって自らを変えよ」 ここまでで、仕事はほぼ始まったばかり。 ここからは主に、上司を説得し、偉い人や事業部の人を巻き込むことになる。 コンピュータークラスターやチームの人件費なども説得して予算をとる。 そして事業部の人の頭の中はめまぐるしく変わる。 相手は一日中企画のことばっか考え続けてるプロ。 彼らのニーズを理解し、スピードについていければ、新しい企画がアウフヘーベン出来る。 すると何が起こるか?より良いソフトウェアになる。 最高の精度のものを先に作り、その精度の良さで説得していくのも手ではある。 が、その場合相手のニーズに響かなければどうしても説得できない。 アルゴリズムの”磨き込み”をしている間に、企画者の頭の中が切り替わってしまう。 ＝つくりこまないほうがいい =CF(でも)いい 28
29. 実例5:企画は生き物(再掲:コンテンツ生成システム) 一人一人に違ったバナー広告を出す広告システム(凡庸なアイディア) → 広告を管理する部の人を紹介してもらう → A/Bテストの大変さの愚痴を聞く。とくにシステム間のデータ転送が大変らしい → バナー配信システムと効果検証システムが同じシステムならいいのになぁ → リコメンドの効果測定で苦労し、同じ課題だなぁと思う → バナー広告を出す際に、Httpヘッダーを偽装する方法を思いつく → バナー広告に限らず、メールの画像も本質的には同じ気がしてくる → メール施策担当者と仲良くなるために甲子園予選(清宮)に同行 → 社内の誰よりもメールの仕組みに詳しくなる → メールの画像差し替えに成功 → DataProcやSpannerで遊んでいたところ、システム統合に使えると気づく → 上長に熱くSpannerの可能性を語り、巨大な予算を獲得する → SpannerやAutoscaleを思う存分使って実装する → 開発協力を祈願しバブルサッカーを執り行う → 社内のバンディットアルゴリズム専門家の頼みごとを1つ解決しフラグを立てる → 社内のバンディットアルゴリズム専門家にシステムを見せ意気投合する → 結果的に、A/Bテスト指標をリアルタイムフィードバックとして得ながら変化する html/JSON/画像の提供システムとなり、1億Access/Dayを捌くスペックとなる → メールの部のさらに上位組織にパエリアを作って振る舞う義務を課される なかなかモデルの作り込みは出来ないが、気づけばより多くの物事が動く流れが出来ている 29 + + + + + + + x15 + 協業者数
30. 応用問題(再掲) Q:では、State-of-the-Artなモデルがあるとき、それを現実世界に持ち込み、 「精度が向上」→「儲かる」が実現されるにはどうすれば良いか? 30
31. 応用問題(再掲) Q:では、State-of-the-Artなモデルがあるとき、それを現実世界に持ち込み、 「精度が向上」→「儲かる」が実現されるにはどうすれば良いか? 31 paper discussion conference experiment あなた 企画者 科学者 技術者 決裁者 説明力 分散化 データフ ロー設計 強力なツール・ Recruiting 社外 データ 解読 データ 整形 機械学 習 分散計 算 公開 経済的 リターン 効果 検証 承認 横展開 ✅ ✅ ✅ ✅ ✅ ✅ ✅ 価値の創出
32. 応用問題(再掲) Q:では、State-of-the-Artなモデルがあるとき、それを現実世界に持ち込み、 「精度が向上」→「儲かる」が実現されるにはどうすれば良いか? 32 paper discussion conference experiment あなた 企画者 科学者 技術者 決裁者 説明力 分散化 データフ ロー設計 強力なツール・ Recruiting 社外 データ 解読 データ 整形 機械学 習 分散計 算 公開 経済的 リターン 効果 検証 承認 横展開 ✅ ✅ ✅ ✅ ✅ ✅ ✅ 価値の創出 これも企業内で価値を創出するための1つの解 すべてあなたひとりで実現可能 そしてすべてがあなたを助けてくれる人のおかげ
33. 最後にお伝えしたいこと 理想と現実のギャップというネガティブになりがちなテーマでお話しさせていただきましたが、 実はネガティブさは全くなく、私はむしろ明るく現実を楽しんでさえいます。 何が面白いか • 自分しか知らないリアリティがあり、生きている実感が得られる • 多くの人を説得して周り、大きなプロジェクト/予算を獲るときのヒヤヒヤ感 • そして全ての障害をクリアし振り返ったときの、仕事のでかさ • グローバルに追いつけ追い越せという気概/文化 がここにあります。一緒に戦ってくれる同士はいつも募集中です。 本日はご興味を持って聞いていただき、 ありがとうございました。 33