リクルート式ビッグデータの活用法

株式会社リクルートMIT システム基盤推進室

プロフェッショナルエンジニアリンググループ

石川 信行

はじめにですが。

2

（株）リクルート　　　ホールディングス

（株）リクルートキャリア

（株）リクルートジョブズ

（株）リクルートスタッフィング

（株）リクルート住まいカンパニー

（株）リクルートライフスタイル

（株）リクルートマーケティングパートナーズ

（株）スタッフサービス・ホールディングス

（株）リクルートアドミニストレーション

（株）リクルートテクノロジーズ

（株）リクルートコミュニケーションズ

主な事業会社

機能会社

ビッグデータグループ新設

ビッグデータグループが新設されました。

（「コンサル型」＋「エンジニア型」） × マーケター

コンサル型 エンジニア型

協働

事業担当者≒ マーケタービッグデータグループ

Hadoop エンジニア

分析者

リクルート式ビッグデータの活用法

株式会社リクルートテクノロジーズIT ソリューション部ビッグデータグループ

石川 信行

自己紹介□ 名前石川　信行（ 　　　 ground_beetle ）

□ 出身福島県　いわき市大学時代は、害虫制御学および生物統計学専攻

□ 経歴・ 2009 年リクルート新卒入社・営業支援システムのコーダー（ java ）、 DBA として参加。・ 2010 年 Hadoop 推進担当・現 Hadoop 案件推進・新用途開発チームリーダー

□ 趣味・外国産カブト虫飼育・スキューバダイビング・海水魚飼育

アジェンダ

1

•リクルートについて

2

•ビッグデータへの取り組みの現状

3

•利活用事例紹介

4

•課題の克服

5 •まとめ

リクルートについて

その人らしい最適な選択と意思決定ができるようサポート

◆ カスタマー自身も気づいていない新しい発見や可能性の提示◆ 安心して選択や行動ができるような客観的な評価や評判を提供

◆ マーケットの声を反映した商品・サービスの向上提案◆ 未だ見ぬカスタマーとの出会いを提供（集客支援）

クライアントの事業が発展、成長できるよう伴走

クライアントカスタマー

ビジネスモデル

カスタマーとクライアントがマッチングする仕組みを構築す

る

旅行

お稽古

時事

ファッション

飲食

ライフスタイル領域ライフイベント領域

進学

就職

結婚

転職

住宅購入

車購入

出産 / 育児

将来を考えて選択と意思決定をする大きな「イベント」

日常の中にある「何を食べようか」

といった、小さな選択と意思決定

※サービスの一部です

リクルートについて（事業概要）

創　業 ： 1960 年 3月 31日

資本金 ： 30億 264万円

売上高 ： 3,720 億 57 百万円（ 2011 年 4 月 1 日～ 2012 年 3 月 31 日）連結売上高 ： 8,066 億 61 百万円（ 2011 年 4 月 1 日～ 2012 年 3 月 31

日）従業員数 ： 5,974 名 （ 2012 年 4月 1日現在）男性： 2619 名・女性：

3355 名

代表者 ： 代表取締役社長　峰岸 真澄

リクルートについて（会社概要）

ビッグデータへの取り組みの現状

R-Stage Dev-Stage β-Stage 運用 -Stage

・技術要素調査・技術の実態を　把握する

・効果的な仕組みとしてプレ実装・活用方法をさらに開拓

・正式にフィジビリティスタディとして推進～展開をする

・実運用へ

Gate Review Gate Review Gate Review

ビッグデータ

（ Hadoop）

新技術のＲ＆Ｄ取り組みステップ

SHUFFLE

MAP

REDUCE

マスタサーバー

スレーブサーバー

MapReduce（ java プログラム）

HDFS（分散ファイルシステム）

大規模データを効率的に分散処理・管理するためのソフトウェア基盤（ JAVA フレームワーク）

・ MapReduce （ Java プログラム）

・ HDFS （分散ファイルシステム）これらで構成

リクルートが使用する Hadoop とは？

リサーチ段階

3～ 4台

2008～ 9

実験機

Web サイトのﾊﾞｯﾁ処理移植など、処理性能の評価・研究

実験・検証

20台

ラボ環境

2010

システム移行などで余ったハードウェアを再利用

第 1世代環境

120台

プライベートクラウド

2011

商用利用が可能な設計（セキュリティなど非機能面）を施した環境

第 2世代環境

40台 （今後拡大）

プライベートクラウド環境との融合を進めた環境

プライベートクラウド

2012

イマココ

部分的な環境融合

完全なる環境融合

システム構成概要

MapR / GreenplumMR

Node5 Node6 Node7 Node8

TaskTrackerFileServer

TaskTrackerFileServer

TaskTrackerFileServer

TaskTrackerFileServer

Warden

Node1 Node2

CLDB

JobTracker

Node3 Node4

TaskTrackerFileServer

TaskTrackerFileServer

TaskTrackerFileServer

TaskTrackerFileServer

CLDB CLDB CLDB

CLDBCLDBCLDBCLDB

JobTracker JobTracker JobTracker

JobTrackerJobTrackerJobTrackerJobTracker

Apache Hadoop / CDH

SlaveNode1 SlaveNode2 SlaveNode3 SlaveNode4

Heartbeat + DRBD

MasterNode1 MasterNode2 MasterNode3 MasterNode4

JobTracker

NameNode

SecondaryNameNode

SecondaryNameNode

NameNode

JobTracker

TaskTracker

DataNode

TaskTracker

DataNode

TaskTracker

DataNode

TaskTracker

DataNode

Master4台＋ Slave15台+batch1台の 20台構成をベースに利用リソースに応じて Slave を増設

３ Nodeから、利用リソースに応じて増設

第２世代第１世代

システム構成概要

利活用事例紹介

【事例紹介①】

　自動車事業

無料相談仲介 仲介

カーセンサー独自の品質基準による車選び物件や状態選定はお任せ＋カーナビ /ETC ＋保証 / アフター

車選び～契約までのワンストップサービス車選び〜実車確認〜契約代行

簡単

安心

仲介

* クルマなびカウンター：対面形式で車選びを支援する新サービス

「クルマなびカウンター * 」における活用事例

お客様 販売店

＠イオンタウン仙台泉大沢

車の価格設定

どこにデータ活用がされているのか？

条件の近いものをまとめ、一律の保証等を付けて同一品質・同一価格を実現する

実際には？

どのような項目でまとめれば良いか？最適な値段はいくらなのか？

必要なことこれが難しい。なぜか？

車種 / グレード / 年式 / 走行 /修復歴 / ナビ /ETC/駆動方式 /色 / ミッション /排気量 / 車検残 /禁煙車 /本革シート / モニター / キーレス / サンルーフ /保証 /整備/ エリア…　

■価格算出に求められること マーケット・商材の特殊性から、価格算出するために必要なこと

　　

➤ 統計的分析が難しい

➤ 全データを対象にしたトライ＆エラーの繰り返し

■マーケット・商材の特殊性 中古車マーケットは感覚的な値付けの世界＝「正価」のないマーケット 一物一価の商材。価格決定因子が複雑 外部環境（輸出、為替、新車）からの影響値が大きい

オプションはざっと 30超！

まさに出

番！

もともと、アイディアはあったが…

組み合わせが膨大なため、車種やエリアを限定しても集計が困難。限定しているので、価格算出の信頼度が低い。

外部データ

この集計ではダメだ…やり直そう…

カーセンサーのデータ *：　 1億件 /月オートオークションのデータ：18万

件 /月 ➤ 実現できそうもない

数日

行動履歴DB

本番DB

*月間で 340万件 ×30オプションの and条件

既にバッチ高速化で hadoop の実用性を認識

Hadoop環境

仮説→実行→検証を高速に繰り返し答えを導くことができた

Hadoop を活用できるのでは？

色々試せる！

1 時間半

外部データ

行動履歴DB

本番DB

簡単

安心

仲介

お客様 販売店

Hadoop 活用でサービス完成！

行動履歴DB

外部データ

本番DB

Hadoop環境

毎月 950 車種の価格を 30 分で分析！

オープン後の課題に対して追加分析も。

どんなに頑張って分析しても必ず課題は出てくる。問題はこれをいかに迅速に解決できるか。事業担当者が現場で

感じている感覚をデータですばやく証明する。

特定の色の車の取引価格が高く仕入れが難しい！オプション料金にするかど

うか考えている。

距離や年式などをずらした際の価格変動をみたい。

GW やお盆が売れゆきは？去年のシーズナリティを見たい。

【事例紹介②】

　じゃらんリサーチセンター　

じゃらん net宿泊実行履歴とは？

• 年間 6020万人泊の宿泊予約、宿泊実行履歴データ– サービス開始の 2000 年 11月 11日から約 12 年間の蓄積

– 会員数 1032万人（ 2012 年 2月末時点）–契約宿泊施設数　 2万 2462軒– 国内最大級の宿泊予約サイト

ムムッ…

これらのデータを使って解析した結果を地方自治体に向けて公開するセミナーを開催している。今年はビッグデータ解析関連の講演も行われた。

関東への宿泊旅行者（全国）：連泊地域

同じ地域内での連泊は１位横浜、２位舞浜、３位お台場、４位箱根、５位銀座・東京

【調査概要】じゃらん net蓄積データより、Ｎは旅行件数を表す。関東圏（ 1都 6 県）以外の居住者に対する関東圏内の連泊・転泊集計期間： 2011 年 4月 1日～ 2012 年 3月 31日チェックイン分１室 2 名以上での利用（レジャーユースを想定）

※連泊転泊の定義：連続した日程による同一人物による 2泊以上の予約を連泊と呼ぶ。この時、 2泊目の宿泊エリアが代わった時を転泊と呼ぶ。つまり同じエリア内にあるＡホテルからＢホテルに移ってもこれは連泊扱いとなる。

関東（１都６県）での人気宿泊地域の連泊・転泊動向実態を把握する

南関東居住者と北海道居住者の周遊宿泊状況の違い29

– 北海道旅行者は、４割が道内から、３割が南関東から

– 北海道居住者は「網走・北見・知床」と「　　　　釧路・阿寒・根室・川湯・屈斜路」が最多の転泊組み合わせ– 南関東居住者は、「旭

川・層雲峡」「札幌」が最多の転泊組み合わせ

じゃらん net宿泊実行履歴データより北海道居住者と南関東居住者の転泊状況の分析（ 2011 年 7月～ 9月の夏季 3か月）

【事例紹介③】

　ブライダル事業

効果集計データ及びロジックが分散かつ複雑　 ➤ データ品質の悪化

効果基盤システムの課題

課題１

ログ集計処理２

ログ集計処理１

課題１　データとロジックが分散。データ品質の悪化を招く

SC ログ集計処理

課題２　大量データを高速に扱えない

大量データ処理を高速に行う基盤が存在しない　 ➤ 集計工数の肥大化

「ログデータ集計基盤」再構築における事例

課題２

分析は手作業中心。データ取得方法も異なる　 ➤ 分析業務の効率が悪い

事業の分析運用面での課題

課題３

課題３　手作業＆異なるデータ取得方法により効率が悪い

データが分散。十分な分析ができない　 ➤ 集客ほか効果増に繋がらない

「ログデータ集計基盤」再構築における事例

課題４

データ加工

課題４　データ分散により効果に繋がる分析ができない

「ログデータ集計基盤」再構築で目指したこと

効果データ・集計ロジックが集約されデータ品質が良い

システム面で目指す状態

理想１

大量データの高速処理が可能であり、対応工数が抑えられる

理想２

効果分析業務が最適に効率化されている

分析運用面で目指す状態

理想３

様々なデータを効果分析に利用することができる理想４

打ち手を整理すると…

効果データ・集計ロジックの集約理想１

大量データの高速処理の実現理想２

効果分析業務の効率化理想３

多様なデータの分析を可能に理想４

大量データの高速処理

データの一元管理

まさに出

番！

【システム化 対応前】

既存システム G

既存システム D 既存システム E

既存システム F

既存システム B

既存システム A

ASP

既存システム C

集計結果

集計結果

整形②

I/F

集計①

整形③ 集計②

整形①マスタデータの整形やアクセスログの整

形

サイカタ 集計I/F

営業・顧客

MP

I/FDB データ・ログ

ファイルなどの収集

既存システム D 既存システム E

既存システム F

既存システム B

既存システム A

ASP

既存システム C

集計結果

集計結果

サイカタ

営業・顧客

MP

I/FDB データ・ログ

ファイルなどの収集

整形①

②

③

Hadoop

集計

EUC

集計結果

他システム連携

【システム化 対応後】

主な効果（一部のみ紹介）

効果データ・集計ロジックの集約

理想１

大量データの高速処理の実現理想２

効果分析業務の効率化理想３

多様なデータの分析を可能に理想４

データ遡及工数削減（▲ 60％）

14 時間の集計処理→15 分

分析工数の削減（▲ 85％）

アトリビューション分析の実現

上記以外にも副次的な効果が多数

【事例紹介④】

　住宅事業

オーナーレポート

SUUMO で所有している大量データをつかって、クライアントへの分析商品展開、営業側で利用するための提案ツール作成を実施。

– クライアントが物件オーナーとの接点を強化し、各種提案をスムーズに行っていただくための物件レポート作成サービス

その他にも…

１週間分のログをクレメンタインでレコメンド計算

約８万人にレコメンド

でレコメンド計算１年半分

約２０万人にレコメンドCVR は

１ .６倍に

アソシエーションルールによるレコメンドエリアの算出

下まで閲覧するとレコメンドバナー表出

40

事業Ａ

事業Ｂ

事業Ｃ

事業Ｄ

事業Ｅ

事業Ｆ

事業Ｇ

事業Ｈ

事業Ｉ

事業Ｊ

事業Ｋ

事業Ｌ

事業Ｍ

サイト間クロス UU調査

サイト横断モニタリング

指標

施策シェア分析

レコメンド

予約分析

ＢＩメルマガ施策

リスティング分析

KWD×LP 分析

クチコミ分析

ステータス分析

LPO

メール通数分析

自然語解析

現行応募相関

行動ﾀｰｹﾞﾃｨﾝｸﾞ

KPI モニタリング

レコメンド ログ分析

自然語解析 メール コメンﾚド 需要予測 クレンジング

需要予測

ｸﾗｲｱﾝﾄ HP 分析

領域間クロスUU

ｶｽﾀﾏｰﾌﾟﾛﾌｧｲﾙ

集客モニタリング

商材分析

レコメンド

ｶｽﾀﾏｰﾄﾗｯｷﾝｸﾞ共通バナー

KPI モニタリング

アクション数予測 効果集計

価格分析 コメンドﾚ クラスタリング クチコミ分析

レコメンド

レコメンド

効果見立て分析

１３事業に対し、

年間１００件超の

データ利活用を展開中

課題の克服

~Hadoop エコシステムを使う ~

技術で実現できることを背景としたソリューションの紹介、技術力・インフラ基盤の提供、活用方法の事例展開や新たな用途開発など

「エンジニア型」アナリストの動き方ビッグデータ関連技術の活用方法を、技術力・インフラ基盤と共に提供し、新たな施策を事業とともに考え実装していく

➤ アルゴリズムを「実装する」・「組み合わせる」

エンジニア型アナリスト事業担当者

事業の状況を背景とした、新たな施策の検討、期待する成果・目的の設定

しかしながら、現実はそううまくもいかない。

いろいろ課題が絶えず出てくる。データを抽出する工数が…既存のシステムに影響が…

機械学習など分からない… etc

そんな課題をエコシステムで解決していく

Hadoop を選んだ理由

　スケーラブルであること

コストがかからないこと　　

エコシステムが大きい、コミュニティが活性であること　　

大規模計算処理システムとして Hadoop を選んだ理由は以下の通り。

ある程度自由に他の製品と組み合わせが可能なこと　　

各種機能は「エコシステム」で簡単に利用

ＳＱＬライクな操作言語として、Ｈ iveマイニングのライブラリとして、 mａｈｏｕｔデータ連携ツールとして、ＳｑｏｏｐＪＯＢスケジューリングツールとして、 Aｚｋａｂａｎ

RDB

PV ログPV ログ問い合わせログ問い合わせログ 　　

レコメンドデータ

レコメンドデータ

Quest® Data Connector

外部データ

①Sqoop の活用

・ Hadoop と RDBMS とでデータをやり取りするためのしくみ・ Oracle データベースへの高速接続を提供する「 OraOop 」など

・ RDBMS を完全に撤廃させることなく、 RDBMS と　 Hadoop でデータを共有、使い分けを可能にする・複数の RDBMS による分析基盤作りにも有効

ログ

本番 DB Hadoop検証環境

　

　

本番データからHadoop データ

に連携する

・ DBからデータ移行に時間がかかる。

・工数がかかる。

・いわば Hadoop 上で動作する RDB・ SQL ライクな「 HiveQL 」で操作、処理結果は自動的にMapReduce へ

②Hive の活用

・おもに既存機能のリプレイス系の案件で活躍する・ SQL → Hive へ移行するだけで、低工数で簡単に　高速化が実現

見立てのために「とりあえずは

　 Hive で実装」

更なる高速化のために一部を MapReduce

へ書き換え

・ MapReduce が書けない。・移行工数を押さえたい！

③mahout の活用

・データマイニング系ロジックの Java ライブラリ・「アソシエーション分析」などのアルゴリズムが用意されている

・協調フィルタリングや、アソシエーションルール　に基づくレコメンドなど・複数の中から最適な条件を選定することが可能まずは、実際のデータで動かし、試す。これが大事。

行動履歴データ

行動履歴データ

　　

レコメンド物件の表示など

・機械学習のロジックを使いたい。が、難しくて実装できない。

リクルート的ビッグデータ解析フロー。

リクルートにおけるビッグデータ解析は TryandError方式。素早く環境を構築し、データを移行。実際のデータを用いて初回OUTPUT を行い、結果を見ながら要件を詰めて施策へ結び付けていく。

外部データ

ログ

本番 DB Hadoop検証環境

　

　

Hadoop エンジニア主導で素早くデータを蓄積

ある程度事業担当のやりたいことを汲み取り、迅速に初回

OUTPUT を作成

技術

分析

事業知見

　

　

実際のデータを見ながら、次の要件を検討

Output

効果を測定し、エンハンスや次期新施策を検討す

る。効果測定

正のビッグデータ

マネジメントループ

事業担当が自ら分析できる環境を提供

WEBGUIから HiveQL を実行できる webhive を公開。これにより、事業担当者も直接かつ簡単にビッグデータを扱える環境が整った。

ダブルクリックで登録済 HiveQL を選択

HiveQL処理結果をリンク先 URL よりダウンロード可能

HiveQL の編集

クエリ実行

とある事業では、ここ 4か月で 58個のクエリを事業担当

者が登録。ビッグデータを操るために自ら HiveQL

を学ぶ姿勢も浸透してきている。

githubからダウンロートできます！https://github.com/recruitcojp/WebHive今期中に、テーブル定義 DL 機能も追加。実際に現場で必要になった機能をどんどん追加予定。

まとめ

~今後も Hadoop を使い倒す ~

リクルート的ビッグデータ解析の価値とは。

技術力

　

　

・こんなこともできるのではないか。

という発想の壁の崩壊。

・新しい分析手法（必殺技）を試しやすく！

・システム知見吸収

・新しい技術の導入がしやすく。

・分析の知見も吸収。

事業知見

分析力

DWHor

RDB

with スマートデバイス：音声解析（ Siri ）・位置情報の取り込み、画像データの取り込み ほか　 ユーザ属性➤ ×GPS （行動履歴）分析による店舗情報プッシュなど

with リアルタイム分析：Hbase 、 S4 ・ STORM （リアルタイム分散処理プラットフォーム） ほか 活用　 リアルタイムレコメンド、フラッシュマーケティングなど➤

今後の展望

with 自然言語処理：Hadoop ＋ Mahout （マイニング）＋ Lucene （形態素分解）ほか 活用　 クチコミ分析、レコメンドメールなどへ応用展開➤