リクルートを支える横断データ基盤と機械学習の適用事例

4. (C) Recruit Technologies Co.,Ltd. All rights reserved. 自己紹介 {"ID" ："fetaro" "名前"："渡部徹太郎" "研究"："東京工業大学でデータベースと情報検索の研究 (@日本データベース学会)" "仕事"：{前職:["証券会社のオンライントレードシステムのWeb基盤", "オープンソースなら何でも。主にMongoDB,NoSQL"], 現職:["Web企業の分析基盤,Exadata,Hortonworks,EMR"] 副業:["MongoDBコンサルタント" ]} "エディタ"："emacs派", "趣味"： ["自宅サーバ","麻雀"] } 3

9. (C) Recruit Technologies Co.,Ltd. All rights reserved. リクルートテクノロジーズ 8 基盤プロジェクト管理 UI/SEOビッグデータ部 R&D IT Promotion リクルートホールディングスリクルートキャリアリクルート住まいカンパニーリクルートライフスタイルリクルートジョブズリクルートスタッフィングリクルートマーケティングパートナーズスタッフリクルートテクノロジーズリクルートアドミニストレーションリクルートコミュニケーションズ事業会社機能会社

12. (C) Recruit Technologies Co.,Ltd. All rights reserved. 横断データ基盤の構成要素メール / 広告マスタデータ Recruit Servic e Web・アプリ Exadata RDS BigQuery S3 行動データ GKE データ提供集計/予測/分類可視化・BI・レポート出力蓄積データアプリケーション GCS stackdriver logging spannerk8s 収集・・・ 50サイト加工セグメント抽出(独自アプリ)

13. (C) Recruit Technologies Co.,Ltd. All rights reserved. 横断データ基盤のプロファイル  データ  データ量：2,000+TB  サービス：50  データベース：160  テーブル：8000  処理  サーバ数：200+  ジョブ数：10000  クエリ数： 100,000,000/月  体制  分析環境利用者数：400人  開発者数：87人 12

14. (C) Recruit Technologies Co.,Ltd. All rights reserved. 横断データ基盤の典型的な処理パターン  サイト横断でデータを取得、機械学習によりユーザを推定、メール・ポイント最適化、UI/UX改善に利用する 13 Aサイト行動データ Exadata マスターデータ S3 Web 機械学習による属性推定個人情報マスク名寄せ DWH化 API化推定結果の格納 Exadata リスト作成メールポイント最適化 UI/UX 改善ブラウザ Point Aサイトに訪れたこと無いユーザでも、 Bサイトの情報から属性を推定できる Bサイト

15. (C) Recruit Technologies Co.,Ltd. All rights reserved. 横断データ基盤の課題  課題 14 行動データ Exadata マスターデータ S3 Web 機械学習による属性推定個人情報マスク DWH化 API化推定結果の格納 Exadata メールリスト作成メールポイント UI/UX 改善行動データの取得までに時間がかかる高SLAと低SLAが混在課題３：オンプレミスの限界オンプレミスの拡張性の限界 (データ量・計算力) Webだけでなくアプリログ収集が求められている Aサイトブラウザ Bサイト高SLA 低SLA

17. (C) Recruit Technologies Co.,Ltd. All rights reserved. メタデータ管理  メタデータ可視化Web  データを探す機能 • データベース一覧・テーブル一覧 • キーワード検索 • 名前が似ているテーブル  データの意味を知る機能 • テーブル定義 • コード値 • 利用者のコメント • よく利用しているユーザ  データの関係を知る機能 • 外部参照一覧 • JOINされることが多いテーブル  データの変化を知る機能 • テーブル定義変更検知・通知 16 Web アプリ OLTP DB 分析 DB Web アプリ OLTP DB Web アプリ OLTP DB メタデータ可視化Web リクルートのほぼ全サイトで導入 OLTP DB, 分析DBの両方から情報を収集

19. (C) Recruit Technologies Co.,Ltd. All rights reserved. データフロー管理  データフロー可視化  概要 • データと処理の関係性を管理 • 複数データストア • 処理の担当チーム管理 • データ数：7000 処理数：800  用途 • 障害発生時の影響調査 • 処理設計時のインプット  管理方法 • YAMLをgitで管理 18 データマート ETL マート化データマートマート化 DWH src src ETL レポートアプリケーションジョブコントローラデータとジョブの関係を可視化

20. (C) Recruit Technologies Co.,Ltd. All rights reserved. データフロー管理のFeature Work  入力データ鮮度条件可視化  当日のデータが必要 → 入力データの更新を待つ  １日前までのデータが必要 → 入力データ鮮度確認  データが有ればいい → 時刻起動  入力データ鮮度条件を考慮した障害影響把握  答えを出したい問題 • 入力データが１日更新されなかった。 • どのデータフローに影響があるのか？ 19

21. (C) Recruit Technologies Co.,Ltd. All rights reserved. データクオリティ管理  現状  各開発チームでスクリプトの中で個別に実装 • データ件数チェック • データ鮮度（収集が間に合っているかどうか）のチェック • データの「ユニーク性」、「非NULL」、「キーの結合可否」のチェック  Feature Work  分析者が出勤したら、使いたいデータの状態がひと目で分かる  データ品質管理をある程度標準化 • データ品質管理基盤を作成 • データの重要度に応じて、品質チェック 20 鮮度件数一意性非NULL 結合可否・・・テーブルA ◯ ◯ ◯ ◯ ◯ テーブルB ◯ ◯ ◯ テーブルC ◯ ◯ ◯ テーブルD ◯ ◯ テーブルE ◯ ◯ ◯

23. (C) Recruit Technologies Co.,Ltd. All rights reserved. 後半話者自己紹介(松﨑遥) リクルートホールディングスデータ・AI戦略本部守備範囲：施策立ち上げ〜予測〜アプリ実装〜フレームワーク化 Main Mission：リクルート最大のAI基盤を刷新すること趣味：情報幾何来歴：中学では半田付け・Z80(8bitCPU)など → 大学・大学院は物理(一般相対論・量子力学・カオス) → 現実との関わりへの欲求 → 大学院時代、隣の研究室の未踏PRJでバイト、以降ずっとプログラマ(emacs派) → c++, objc, php, COBOL, java, scala, haskell, R, python, SPSS, nodejs → 7年後、数学とコンピューティングの融合への欲求  2015年2月1日にリクルートにJoin 22 情報幾何 NN/DNN 心が豊かになる

24. (C) Recruit Technologies Co.,Ltd. All rights reserved. 機械学習の活用箇所 23 カスタマクライアント ②マッチング率向上・レコメンデーション・UI/UX支援・行動予測 ⑤機械学習の効率化(高速化/パラメータチューニング) ①集客のコスト削減・メール最適化・ポイント付与最適化・広告最適化・顧客セグメントの構築・顧客セグメントへの広告配信実行・外部ツールへのデータ連携 ④データドリブンな意思決定支援・顧客の潜在変数推定・(ペルソナ/ジャーニー/ナーチャリング) 年間数百件の新規施策増加

25. (C) Recruit Technologies Co.,Ltd. All rights reserved.  我々が行っている多様な予測 • 購買/利用サイト予測 • 属性予測 • キャンペーン反応率予測 • 生涯総価値予測 etc…  リクルートのFunnel構造理解の必要性(一例) 実例広告系施策 24 「マッチング率向上のために何ができるか」という共通目標の実現集客流入検索ブックマーク購買キャンセル? ここを改善するなら開封率予測ここなら属性予測に基づく検索UI切り替え Churn予測リコメンドの教師データへのブックマークの追加購買だけをいきなり増やすことはできない。各サービスの多様な Funnelへの理解が必須

26. (C) Recruit Technologies Co.,Ltd. All rights reserved. 広告系施策における機械学習活用のあゆみ  2013: 数千万ID全量をさばけず、ランダムサンプリング  2015: 全量に対する計算が実現。普及せず • 予測データをテーブルとして提供 • 「使いにくい」。要望が出る度に開発が必要 • 「精度も他社製品に負けていないし、内製なのでコストも圧倒的に安い。どうして、使われないのか？？」 • 「このままdeep learningでのモデル改善、SparkやGPUでの高速化に舵をとっても使ってもらえないままなのでは無いか？」  2017: 普及に成功(大幅な方針転換) • なぜ普及したか＝テーブルではなく、本当に欲しかったものを提供したから • 自分で要望通り入力すると、自動的に予測でき、施策が実行される • どうやってこの解にたどり着いたのか?  ✕予測精度が圧倒的に優れているから  ◯？？？？？ 25

28. (C) Recruit Technologies Co.,Ltd. All rights reserved. 実例 (広告系施策) 2013~2014  テーブルを提供し自由に参照してもらう  例) プログラムから参照して広告を切り替える  うまくいったか? 27 データマート数の増加再利用性の低さ要望毎の新規開発新規開発の迅速化の仕組み Funnelが多様過ぎ、ウォーターフォールで全項目予見は不可能 Spring化, Jenkins化など。しかし根本的解決なのか?

30. (C) Recruit Technologies Co.,Ltd. All rights reserved. w/ random sampling 実例 (広告系施策) 2014~2015  引き続きDMPとしての充実・高精度化  デモグラフィック予測中心のラインナップをHive/JSONAPIで提供  当時の主力は • ロジスティック回帰 • 重回帰 • ニューラルネット • 決定木(Chaid, GBDT, RandomForest) など基礎的だが、Hadoop化によりようやく全量データの学習が実現 29 mapreduce hive TeZ spark hivemall python xgboost mllib mahout …

31. (C) Recruit Technologies Co.,Ltd. All rights reserved. 2015年当時の悩み  やっと予測精度が”パーソナライズ”水準に。  はたして予測結果は使われたのか？否  使いにくい＝要望が出る度に開発が必要 • 「〜〜というテーブルとJOINしたいがどうすればいいのか?」 • 「2016年8月以前と以降ではこのコードの解釈は違うので注意」 • 「前回の案件とほとんど同じなんだけど、この項目の計算式がちょっと変わった」 • 「サイトリニューアルに伴いマスタ全部変えてもらった件だけど、無しになったから。」 • 「Hadoopの可用性を99.99%にして欲しい」 • 「全員分(数千万人/数億cookie)の計算が明日までに終わらない・・・」 • 「精度向上は続けるとしても、普及には、まったく違うアイディアが必要なのでは?」  我々はこの先を見つけました 30

32. (C) Recruit Technologies Co.,Ltd. All rights reserved. 機械学習進化の積み重ねの歴史 (アルゴリズムの高度化、API化) 31 顧客セグメントをグラフィカルに作成したり自前で広告配信が可能にアルゴリズムや予測項目も高度化し、さらなる進化を実現するアーキテクチャ模索注力技術： ElasticSearch セグメントの柔軟な作成 Kubernates 柔軟なデプロイメント Spanner 予測データの提供・学習データ収集 Kafka 低レイテンシーの加工処理 2013 2015 2017

35. (C) Recruit Technologies Co.,Ltd. All rights reserved. 実例 (広告系施策) 2017~ browser elastic S3 node spanner node 34 GS 配信 System node Customer 原稿登録 Logic プロデューサーセルフBIで作成したセグメントに対して配信〜ログ収集〜Logic反映までが自動 1億リクエスト/Day対応 Hadoo p オートメーションツール全体図

36. (C) Recruit Technologies Co.,Ltd. All rights reserved. 広告系施策の進化を支えるコンピューティング  もちろん、機械学習や分散計算はいなくなったわけでは無い  以下を黒子のように死守してきた • ジョブツリーが10時間経っても終わらない問題 • ジョブ設計を抜本的にリライトし60分以内の完了を3ヶ月連続防衛 • Spark化による5倍の高速化 • データ転送問題(失敗/遅延) • できるだけSpannerに一元化し、データ転送自体を最小限に • 1億PVを捌く • AppEngineのAutoscaleを利用+nodeでノンブロッキングに • リリース作業の工数増加 • jarのFramework / Jenkins運用体制を構築 • (やや)deepなネットワークの導入 • 絶対誤差の大幅な減少 • データサイエンティストの増加 • Zeppelin / Jupyter / Cloud MLの導入 こうしたことはコンピューティング的には面白いが秘密裏でOK 35

37. (C) Recruit Technologies Co.,Ltd. All rights reserved. 何が起こったのか  システムを取り囲む人が増えた→どういうことか?  このシステムは、「プロデューサーが」「要望を入力すると」「機械学習や分散基盤を意識せずに」「具体的なアクションと計測まで完結」させてしまう≠「テーブル+分厚いドキュメントが社内公開されてる状態」  なぜこの解にたどり着けたのか？  論文やTensorflowやGPUとだけ戯れていたわけではない 36

38. (C) Recruit Technologies Co.,Ltd. All rights reserved. 広告系施策の進化を支えるリクルートの現場 • マーケティング施策が依然有効だが、エンジニアには感覚が欠如 • 規模の追求に基づく施策構想は高度な専門分野 • Ponta-RecruitID連携 • アライアンス拡充(LAWSON様, JAL様等150サービス以上) • コミュニケーションがほぼ不成立 37 サイエンスエンジニアプロデューサークリエイティブ論文を書く人作る人メディア企画画像/原稿作成システム運用データコンサル

39. (C) Recruit Technologies Co.,Ltd. All rights reserved. 多様な人材との協業  鍵になるのがアウフヘーベン(Aufheben:独) 38 エンジニアプロデューサー武器がザクザクあるアイディアがくさるほどあるいいこと思いついたこんなツール売ってない？実は的外れだったり実は原理的に無理やると必ず儲かるアイディアを提供必要な武器を即座に提供危険な状態共通言語が話されている状態

40. (C) Recruit Technologies Co.,Ltd. All rights reserved. テーブル ID→JSON 変換API 具体的なクリエイティブ “コレ” SQL BIをポチポチこの前話した “アレ” 何が本質的「進化」か 39 顧客のターゲティングの方法アウトプットのフォーマット 2013 2015 2017 さすがにSQLなら誰でも書けると思っている SQLが書けても解読は不可能 BIが便利だと思っている貴重な開発リソースを少しも割きたく無い私は”アレ”に”コレ”を出したいだけなんだ!

41. (C) Recruit Technologies Co.,Ltd. All rights reserved. 共通言語 40 原稿登録企画サイエンスターゲット Black BoxでOK どんなセグメントでもあるなあアイディアが湧いてくる! 開封状況に応じ変化するロジックを載せたぞ実験用セグメントだけに影響するから自由この原稿で頼みますこれを使うとラクだ… システムの存在は空気のような感覚エンジニア気づかれないようにサーバーを増強

42. (C) Recruit Technologies Co.,Ltd. All rights reserved.  BlackBox外で創発的なコミュニケーションが可能になることこそが重要  これが、「性格テーブルを公開するから、企画考えて？」だったら？共創的コミュニケーション(例) 41 SQL BIポチポチこの前話した “アレ” 性格予測テーブル JSON API 具体的なクリエイティブ画像生成

44. (C) Recruit Technologies Co.,Ltd. All rights reserved. まとめ  普通のプラットフォーム  分散処理基盤  機械学習  リクルートのプラットフォーム  分析者目線のツール群 • メタデータ管理 • データフロー管理 • データクオリティ管理  プロデューサーのためのツール群 • 自分で要望通り入力できる • 自動的に機械学習による予測がロードされる • 自動的に施策が実行されるこれらが全て回っていて絶対に落ちず、双方向コミュニケーションで進化し続けるシステム 43 ２０１５年

リクルートを支える横断データ基盤と機械学習の適用事例

Tetsutaro Watanabe

リクルートを支える横断データ基盤と機械学習の適用事例