Hadoopによるリクルートでの技術調査とその活用

1,431 views

Published on

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,431
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
15
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Hadoopによるリクルートでの技術調査とその活用

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

×