Hadoopによるリクルートでの技術調査とその活用
- 1. リクル トにおけるHadoop活⽤と リクルートにおけるHadoop活⽤と 技術調査について Takeshi NAKANO Marketing & IT Div Div. Recuruit Co., Ltd. 1
- 2. アジェンダ 1. はじめに 2. 技術的な話(Solr/Cache-module/Hadoop) 3. エンジニアとして考えること 4. まとめとこれから れ 2
- 3. はじめに 3
- 4. 自己紹介 • 中野 猛 (NAKANO Takeshi / @tf0054) • リクルート＝社会⼈歴11年⽬ • 6年情報⼯学を学び⼊社後もずっとエンジニア • イ インフラ等基盤系の部署からスタート 等基盤系 部 タ ト • 新ビジネス検討をお⼿伝いし • 新技術検討のチームをリード 4
- 5. リクル トご紹介 リクルートご紹介 5
- 6. リクル トご紹介 リクルートご紹介 ■ Human Resources 6
- 7. リクル トご紹介 リクルートご紹介 ■ Further education and Learning 7
- 9. リクル トご紹介 リクルートご紹介 ■ Bridal & Baby 9
- 10. リクル トご紹介 リクルートご紹介 ■ Travel 10
- 12. リクル トご紹介 リクルートご紹介 ■ Coupons 12
- 13. リクル トご紹介 リクルートご紹介 ■ Lifestyle and Others 13
- 14. 事業形態 • MIT(Marketing&IT) ≒ 情報システム部 • 各事業にはそれぞれ専属のMIT(システム担当G) • 基盤/PMO系の機能はMIT内横断 ⾃動⾞ ゼクシィ ・・・ リクナビ MIT MIT MIT MIT (PMO / Infra etc.) 14
- 15. 独自採用の技術 15
- 16. ①SOLR 16
- 17. システム概要 • 多くのサイトでドリルダウン検索、⽂字列検索の実 相が急務に • ここにプロプライエタリな商⽤ミドルを導⼊ 案件 ここにプロプライエタリな商⽤ミドルを導⼊、案件 個別に対応されていた • ただ、⾼価に過ぎ、事業収益に影響を及ぼしていた • そこでOSSの検索エンジンを検証 約2年かけ全サ そこでOSSの検索エンジンを検証、約2年かけ全サ イトの検索機能を⼊れ替え 17
- 18. 事例 • DBとの連携 • 通常のS l 通常のSolr • 更新データ準備 → インデクシング → Commit → 検索に反映 この間のデ タ更新に時間を要する この間のデータ更新に時間を要する ※ ※ データサイズにより異なる • コネクションサーチ • 在庫DBを更新 → 検索に反映 DBの更新のみ 在庫数や、画⾯への表⽰有無のみの変更であればより理想的 ① 検索クエリ発行 ② SQL発行 Solr DB ユーザ ④ 結果の返却 ③ ResultSet ①の結果と③をマージ この結果が少ないほど⾼速 18
- 19. 効果 • サイトの使い勝⼿向上(操作性＋レスポンス) • 商⽤ミドルを駆逐し、保守ラインセンス費を削減。 • シノニム検索等、ミドル⾃体の動作掌握が不可⽋な 機能の利⽤レベル向上に寄与。 • Solr本の共同執筆でノウハウ整理。 19
- 20. ②CACHE-MODULE 20
- 21. システム構成 • ウェブサイトのリソース消費が問題に ウェブサイトのリソ ス消費が問題に • 同時に体感速度の重要性も確認されてきた • Apacheの追加モジュールを社内開発して対応 • (Apacheの機能ゆえ)基本的に開発⾔語も問わない 機能ゆ 基本的 発 わ • 基本は組まれたHTMLをキャッシュするもの • 独⾃タグにてHTMLの⼀部を動的差し替え (カート機能、〜さんこんにちわ等) カ ト機能 さん んにちわ等 21
- 22. システム構成 • アプリ(前提) • ページのメインどころはキャッシュから • 個別部分(パーツ)は独⾃タグで都度動的作成 個別部分( ツ) 独⾃タグ 都度動的作成 • これらをApacheでマージしブラウザへ パーツ パーツ ■独⾃タグの例 <lcs:include src="cache:///test/p01 jsp" src= cache:///test/p01.jsp expires="every 5 minutes" /> 22
- 23. システム構成 • 構成概要 Internet apache Tomcat 設定ファイル 設定 イル TokyoTyrant Batch (memcached) キャッシュデータ 23
- 24. システム構成 • 構成詳細 クローラの変なUAなど、 クロ ラの変なUAなど IPレンジで判定できない キャリア４つ＋C(google ＋C(Y!)＋C(goo)など個別 もののみを書く ファイル化 apache mod_mobile_door キャリアを判別しENVに定義(例:X_CLIENT_TYPE=AU) 1.ENV(X_CLIENT_TYPE)＋UAを⾒て適切なCAパラメータを付与 mod_rewrite 2.付与されたCAから適切なENV(X_LCS_CONTENT_TYPE)をセット 書き換え後URLをキーにKVSを検索 mod_rec_cache mod rec cache (Tomcatに回る場合も書き換え後URLで回す) mod_proxy CAパラメータはバッチか TokyoTyrant mod_p y_ajp proxy jp らしか発⽣しえない Tomcat mod_template indefiniteだったら動く Cache0(fake filter) ?CA=AUを外しUAを偽装 mod_deflate _ RFW(mobile filter) Cache1(cache filter) 24
- 25. 効果 • ウェブサーバのリソース削減に寄与（４割程度） ウェブサ バのリソ ス削減に寄与（４割程度） • DBサーバのリソース削減に寄与（２割程度） • キャッシュ有効期間調整による⾼負荷時対応等 25
- 26. ③HADOOP 26
- 27. システム構成 • いくつかの事業でバッチ処理時間がひっ迫 • DBの垂直拡張だけでは限界＋コスト⾼に • その打開策としてBigデータ処理に着⽬ • 各種 各種DWH的ツールを含めて調査しHadoopに 的 を含 査 • バッチ⾼速化の⽤途だけでなく、 マイニング⽤途が利⽤の拡⼤を牽引 27
- 28. ログ集計本番 個別PV 個別 単純 事例1：バッチ処理の高速化 集計 集計 流⼊回 集計ログ step1_01 数（初 A.sh 期表 流⼊回 ⽰）集 個別PV集計 アクセスロ step1_02 数（前計B.sh グ 画⾯不 流⼊回数集計 約1100万レ 明）集 step1_02 ⼀覧表⽰回数 コード ⼀覧表計C.sh 集計 ⽰回数 アクション ⾏動履歴反響情報 ⾏動 情報 （100） アク 集計step1_03 実⾏回数集計 ション xxx_PAGE 10並列 A.sh 実⾏ 成果集計 約80分 前画⾯ 回数集 step1_04 約50万レ エリア 計 D.sh コード ２－１． データ ⾏動履歴リクエスト情報 ター step2_05_ yyy_SITE yyy SITE ログ集計 （ （160） ） 成果抽 抽出 ゲット1.sh 1 sh Temporary 下準備 1並列×10回 出 エリア その他 エリア抽 集計 ター データstep2_05_ (100) step2_05_ マスター系 出データ 約30分 0.sh ゲット 抽出①2.sh step3_ SQLをHive@Hadoop化 (110) SYUKEI_ エリア 05.sh ⾏動その他履歴集計ログ データ TEMP アクセスロ zzz_LOG Temporary step2_05_ 抽出② 3.sh 対象範囲 グ 近く 事例も 成果抽出 モバイル x10〜x100近くでる事例も データ ACCESS_LOG _TEMP ２－３． 集計 ⾏動履歴 ２－３． ２－２． ログ集計 その他DB ログ集計 アクセスログ 集計ログ キャッ 取込 込 本番 集計キャッシュ xxx_ACCESS_LOG bbb_LOG シュ作成 (120) (140) (150) モバイル ⾏動その他履歴 1並列 1並列 5並列×2回 1分 144分 約20分 １バッチ 2時間22分 ｘｘｘ系バッチ全体で約6時間 28
- 29. 事例2：アソシ 事例2：アソシエーション分析 ション分析 どの施策(左記だとキャンペーンA、 1回⽬の訪問 検索、ブックマ ク)が最もコンバ 検索、ブックマーク)が最もコンバー キャンペーンA キャンペ ンA サイト閲覧 離脱 ジョンに貢献したかを、貢献度で評 価したい。 2回⽬の訪問 検索 サイト閲覧 離脱 Hadoop＋Webのアクセスログで、 Hadoop＋Webのアクセスログで サイトを越えた集計が可能に。 3回⽬の訪問 ブックマーク サイト閲覧 コンバージョン 流 ア ⼊ ク シ ョ ン どの施策からアクセス どの施策がアクションに キャンペーンAで捕捉したユーザは、 キャンペ ンAで捕捉したユ ザは したユーザが多い？ 貢献している？ 何⼈がコンバージョンしたか？ ・この広告は⽌める？ ・キャンペーンAを続ける？ ・ポイント付与とメール配信に⼒を⼊れる？ ・キャンペーンAを⽌める？ 29
- 30. 補足：githubにて公開中 https://github.com/recruitcojp htt // ith b / it j • WebHive • ウェブ上からHiveQLを流せる • ログイン管理や実⾏記録等セキュリティ機能が充実 • OdbcHive • Hadoop(Hive)をより⾝近にする • MS-Accessから直接使えるように作成(≠JDBC) • α版 30
- 31. これから、で考えていること から、 え ＊リアルタイム処理 31
- 32. リアルタイム処理 • 今気にしているもの • 貯めてから処理→出たところから処理? • Y!のS4 32
- 33. エンジニア同士のシナジー ンジ ア同士のシナジ • 各事業を深く理解しているエンジニア • 競合事例の把握と対応を検討 • 各事業システムの構造を把握 • チーム内のエンジニア • マイニングなど応⽤技術を把握 グ • OSSソース⾃体を読み構造を理解/確認 33
- 34. 非 ンジ アとのシナジ 非エンジニアとのシナジー • 分析やマイニングの専⾨家 • リコメンドロジックの設計と評価 • 予測分析の設計と評価 • 事業/マーケティングの専⾨家 • ⾏動ターゲティングの設計と評価 グ • 営業⾏動のチューニング 34
- 35. エンジニアとして考えること 35
- 36. どうしてゆくとよいか • 良い⼈⽣と⾔われても • 楽しい/良い仕事をやってゆくには • “居つかない”こと • 「試合中に精神的機能が⼀時⽌って瞬間的動作の出 来ない状態」(by weblio / 剣道⽤語 / 内 樹 来な 状態 内⽥樹) 36
- 37. ①ス シャリストｘゼネラリスト ①スペシャリストｘゼネラリスト • スペシャリストとしての進化 • ゼネラリストとは何か • 出来るようになるハズ 37
- 38. ②こだわりｘ柔軟さ • 深く理解する価値 • 9:1くらい(?)にはに飽きるべき • コミュニケーション時にも注意が必要 38
- 39. ③アプリの知識ｘインフラの知識 • 軸⾜の話 • アプリは作っちゃうもの(アイデア/発想) • クラウド時代のインフラ知識 39
- 40. ④オ プンソ スｘプ プラ タリ ④オープンソースｘプロプラエタリ • 作りを確認できることは⼤きな価値 • 相談できる(という意味で)サポートも⼤きな価値 • どちらも使い切り替えてゆく 40
- 41. まとめとこれから 41
- 42. エンジニアとは(まとめ) ンジ アとは(まとめ) • 内部ベース/”居つかない”こと＝プロ? 内部ベ ス/ 居つかない こと プロ? • 場は変化する。その時々に適当な解を • 外部ベ ス/出⼒量 感謝され量 価値? 外部ベース/出⼒量＝感謝され量＝価値? • 説明を作る/考えることも、ある意味エンジニアリング!? • 仕掛けるエンジニア！ • テクノロジードリブン テクノロジ ドリブン 42
- 43. ( ンジ アが)未来を創る (エンジニアが)未来を創る • インターネットがそもそも インタ ネットがそもそも • スマートフォンもそう • Hadoopなどデータマーケティングも本格化 • 未来を作 未来を作ってゆきましょう! ゆき 43
- 44. END 44
- 45. カンファレンス準備中 • “Hadoop Conference 2011 Fall” Hadoop Fall • Hadoopユーザ会の皆さまと企画中！ • 9/26＠汐留 45