リクルート式Hadoopの使い方

リクルート式Hadoopの使い方
株式会社リクルートMIT システム基盤推進室インフラソリューショングループ石川信行

はじめに・・・
□名前
石川　信行
（　　　ground_beetle）
□出身
福島県　いわき市
□経歴
・2009年リクルート新卒入社
・営業支援システムのコーダー（java）、DBAとして参加。
・JavascriptのLibであるSenchaを用いたスマホサイト開発
・現Hadoop推進担当
□趣味
・外国産カブト虫飼育
・スキューバダイビング
・海水魚飼育

リクルートの組織体制について
旅行C
営業
企画
自動車C
営業
企画
住宅C
営業
企画
MIT　United
事業担当MIT　
事業担当MIT　
事業担当MIT　
・マーケティング・分析チーム　
・インフラ基盤チーム　　　
各事業のネット戦略推進・開発を行う部署がMIT
Hadoop開発メンバーはインフラ基盤チームに所属
2/49

本日のアジェンダ

Hadoop導入に向けた課題点

リクルートにおけるHadoop導入の理由
なぜHadoopを導入しようと考えたのか。
バッチに代表される処理時間の増大対策。
Case
・夜間バッチが遅く、朝までに終わらない。
・処理の時間が長すぎて再実行・遡及ができない。
・アドホックなAccessの分析にも時間がかかる。
既存のシステムの高速化用途に使用。

Hadoopの導入における障壁
現行システムに影響を
与えたくない。
導入難
開発工数をかけたくない。
Hadoopの既存システムへの導入は非常に難しい。
少ない工数でなおかつ、現行の処理になるべく影響
を与えないように導入を検討しなければならなかった。

課題の克服と活用シーン

エコシステムをうまく合わせればよい。
例えばリクルートでは
これらのエコシステムを使用
Hadoopには、より簡単・便利にHadoopを使うための道具がそろっている！
状況に応じてエコシステムをうまく有効活用すべき。

Hive
SQLを使うユーザーが多いリクルートでは必須のエコシステム。HiveQLというSQLライクな操作言語を自動的にMapReduceに変換する。
リクルートで作製したツールであるWebHiveを使ってユーザーがアドホックにHiveを実行。
ソースはGithubのページに公開済み。
https://github.com/recruitcojp
MapReduce
・企画
・エンジニア
HDFS

Hiveを使った実装
おもに既存機能のリプレイス系案件に活躍。
SQL->Hiveへ移行するだけで低工数で簡単に高速化を実現。
ユーザー定義関数も増え、アドホックな分析にも有効。
*parse_url(‘http://・・・・・・・, ’HOST‘) が便利。
見立てのために
「とりあえず、Hiveで実装」
Hive以上の更なる高速化を望むのであれば、MapReduceに一部書き換えを行う。

HotPepperの事例：　概要
・飲食ぐるメールと呼ばれる
メールレコメンドロジックのHadoop化
・アトリビューション分析と呼ばれる
「どの施策が効果に結び付いたか」を調べる分析
データはどちらもサイトカタリストを利用
取り組みの概要

Hotpepperグルメ・レコメンドメールのHive化
飲食ぐるメール（Hotpepperグルメのメールマガジン）では、
ログ処理時間の問題で、全会員のうち一部会員(8万人)にしかレコメンドメールを送れていなかった。処理をHadoop化することにより全会員（20万人）にレコメンドメールを送付する事が可能になった。
約８万人にレコメンドメール配信
マイニングツールでレコメンドを計算
１週間分
のログ
Before
１年半分
のログ
約２０万人にレコメンドメール配信
After
でレコメンドを計算
約１２万人のCTR・CVRが１．６倍に！
13

アトリビューション分析
どの施策（左記だとキャンペーンA、検索、ブックマーク）が最もコンバージョンに貢献したかを、貢献度で評価する。
1回目の訪問
キャンペーンA
離脱
サイト閲覧
2回目の訪問
検索
離脱
サイト閲覧
3回目の訪問
ブックマーク
コンバージョン
サイト閲覧
流入
アクション
キャンペーンAで捕捉したユーザは、
うち何人がコンバージョンしたか？
どの施策からアクセス
したユーザが多い？
どの施策がアクションに
貢献している？
・キャンペーンAを続ける？
・キャンペーンAを止める？
・このリスティングを止める？
・ポイント付与とメール配信に力を入れる？
特にリスティングの削減につながれば効果絶大

アトリビューション分析（続き）
アクション（イベント）に対する貢献度を、
過去に遡って一定のルールで割り振る。
4/1
美容携帯
ユーザID=NULL
5/1
美容PC
ユーザID=NULL
6/1
じゃらんPC
ユーザID=100
7/1
じゃらんPC
ユーザID=100
=有料
=無料
流入
リスティング
SEO
会員登録
メール
ポイント
★
期間
過去に遡って名寄せ（ユーザIDのセット）
★
アクション
過去に遡ってアクション（イベント）に対する貢献度を割り振る！
J
・会員登録がされるたびに過去に遡ってユーザIDをセット

Sqoopとは？
Sqoop、Quest Data Connector for Hadoop（OraOop）ともに、HadoopとRDBMSとでデータをやり取りするためのしくみ。OraOopは、Oracleデータベースへの高速接続の
スループットを提供するためのSqoopのフレームワーク。

Sqoopの長所・短所
短所
長所
・複数のプロセスで並列でデータを取りに行くため、高速にインポートが可能。
・hiveへのダイレクトロードが可能
・カラム指定でのインポート、条件指定のインポートが可能。
・Oraoopを使えば、マージエクスポートも可能
・Oraoopを使用しなければOracleに対する並列処理で、データの整合性が担保されない。
・改行コードの入っているカラムをインポートの際、不整合が起きる。
・エクスポートが遅い。（1.3.0.で高速化？）
・並列実行時のRDBへのCPU負荷に注意。
注意点はあるものの、Sqoop、対Oracleの場合はOraoopを併用することでデータ移行が容易になる。

Sqoop＋Hiveを使う！
現行システム
RDBMS
データ
データ
RDBMSを完全に撤廃させるのではなく、RDBMSとHadoopでデータを共有し、データ量が多く複雑な処理はHadoopへ、オンライン処理はRDBMSへ等の共存が図れるようになるため、導入難易度が非常に下がる。
データ保管場所の一元化など複数のRDBMSのデータをHadoopへ移行させ、分析基盤を作るのにも有効。

ゼクシィの事例：　概要
現在複数システムに分散しているデータと処理を、Hadoopによる分析基盤に統合。

現状と課題感
現状はデータが分散し複数システムで集計処理をしているため、下記の課題がある
　①効果情報（集計値）がシステム間で一致しない
　②分析作業が非効率（データを複数システムから手作業で取得し処理）
　③処理が遅く、複雑な分析処理が困難なため、アクション増や集客に繋がる分析が十分に行えない(フェア分析、ページ内遷移等)
④複数システムに処理が分散しているため、高コスト
効果情報
効果情報
企画
効果情報
システムB
システムA
効果情報
営業
効果情報
効果情報が一致しない
システムD
システムC
効果情報
集計処理
集計処理
集計処理
集計処理
クライアント

効果ログ基盤構築
Hadoopの大量／高速データ処理能力を活かし、
効果ログ基盤を構築しデータと処理を一元化、それにより下記の実現を目指す
　①効果情報の品質向上（システム間で一致）　　　　　
　②分析作業を一元／自動化
　③高速化によりアクション増や集客に繋がる分析の実現
④システムリプレイスと処理集約によるコスト削減　
効果情報
効果情報
企画
効果情報
効果情報
効果情報
営業
効果情報
今まで出来なかった分析の実現＋効果情報品質の向上の見込み
大きなコスト効果がある。
効果情報が一致しない
効果情報が一致
効果情報
集計処理
集計処理
集計処理
集計処理
クライアント

ゼクシィのフェア分析
地域別のホテルにおけるリアルタイム予約割合
地域別、業態別のリアルタイム予約数
大阪府
埼玉県
千葉県
東京都
神奈川
県
愛知県
京都府
兵庫県
地域別の式場・ゲストハウスにおける
リアルタイム予約割合
地域別、リアルタイム予約別の業態構成比率
大阪府
神奈川
県
埼玉県
千葉県
東京都
愛知県
京都府
兵庫県
埼玉は「式場、ゲストハウス」の
リアルタイム予約の割合が低い
23

Mahoutとは？
マイニング系ロジックのJavaライブラリ。Hadoop上において並列計算が可能。リクルートで使用しているアルゴリズムは
Parallel Frequent Pattern Mining（アソシエーション分析）
Non-distributed recommenders (“Taste”)
の2つ。
長所
短所
・Tasteによるユーザーベースのレコメンド用データを高速に作成。
ロジックを考える必要なし。
・ユーザーの購買履歴ログを用いてアソシエーション分析が可能。
・大量データの分析を早く簡単に実装できる。マイニングの経験がなくとも素早く実装可能。TryandErrorを繰り返すこと経験値を手軽に増やせる。
・ロジックがブラックボックス化しやすくデバッグが困難。パラメータの設定値は最早
「慣れ」の必要あり。
・inとoutのデータ形式は整形する必要がある。
・処理によってはスレーブに分散されないこともあり、OOMの傾向があり。

集計->分析へ　Mahoutを使う！
Hadoopは集計するだけの道具ではない。
大量の行動履歴や反響ログを用いたマイニング、
統計解析にも有効利用が可能。
Mahoutを使えば、マイニングの知識が少なくても
簡単に大量のログを用いて分析が可能。
・セッションID
ごとの閲覧履歴
・各種マスタ
（どのユーザーがどの物件をいつみたか？）
クレンジング済みデータ
クレンジング

カーセンサーの事例：　概要
車種選択画面での
「同時に閲覧されることが多い車種」のレコメンド。

物件レコメンド
Amazonライクな協調フィルタリングや、同車種などの独自条件、アソシエーションルールに基づくレコメンドなど、複数の条件の中で最適な条件を選定する必要。⇒ Hadoopの高速処理を生かし、最適な条件による実装が可能に！
Hadoopエコシステムのレコメンドエンジン
・ユーザーベース協調フィルタリング
・アイテムベース協調フィルタリング
などを実装
検索画面
お気に入り画面下に
レコメンド物件表示
行動履歴データ

アソシエーション分析結果例
確信度の高い順にレコメンド
Lift値の低いものは順番を下げる。
1以下のものは要考慮。
全車種に関して、行動履歴からアソシエーションルールに基づく車種どうしの関連性を算出。レコメンドにより対象車種以外の検討機会を与えることができた。

クラスタリング＋アソシエーション分析
データをあらかじめ性別、年齢などのクラスタにわけて
それぞれに対しレコメンドロジックを適用することも可能。
アソシエーション分析
データ
軽自動車
自動車行動履歴ログ
データ
オープンカー
商用車
データ
クラスタリング
（あらかじめ
データをbodytype
で分別）

ポンパレBIツールの導入
課題：マーケ／編成／営業がバラバラのデータ／分析結果を見ている
　　　分析処理が遅く、競合に比べ集客／売上に繋がる打ち手の見立てが遅い
　　　
HadoopでBIツール用のデータを作成し、BIツールに流しこむことで、OLAPで打ち手のPDCAを高速化
事業データ
アクセスログ
BIツール
サイカタデータ
マーケ
データマート
実績系データ
編成
各種マスタ
営業
行動系データ
ソーシャルデータ
32

各サイトでのHadoop利用状況
本番化
成果あり
仕掛中
共用環境
住宅専有
カーセンサー専有
美容・飲食・旅行系専有
ゼクシィ専有
飲食ぐるメール
レコメンド
領域間クロスＵＵ調査
ＫＰＩモニタリング
価格分析
キーマンズレコメンド
ポンパレメルマガ施策モニタリング
集客分析
アクション数予測
物件レコメンド
進学レコメンド
サイト間
クロスＵＵ調査
カスタマープロファイル分析
レコメンド
クラスタリング
進学クラスタリング
ポンパレ商材分析
（ＢＩツール活用）
商材分析
学び効果見立て分析
既存システム
高速化
サイト横断モニタリング指標
アクション数予測
じゃらんリスティング分析
ＣＭ効果予測
飲食KWD×ＬＰ
紐付け分析
レコメンド
施策シェア分析
休眠顧客化タイミング調査

初期インフラリソースはどの程度か。
Hadoopを活用している企業例を見るとどれも
千や万単位のサーバーを使っているように感じれる。
結論、導入が楽でも処理を回すためにはリソースを確保しなければならないのか？
リクルートでHadoop用に稼働しているサーバーは現在118台。だが、最少のクラスタ構成はサーバー６台。
Hadoopおよびエコシステムのチューニングを行えば、6台でもある程度の処理は回すことができる。

Hadoopで複数処理を回す方法

リクルートでのHadoop構成
スレーブ　HDD：600GB、メモリ8GB
マスタ　　　HDD：300GB、メモリ16GB
PVログ
問い合わせログ
RDB
画面表出用取り込みバッチ
レコメンド
データ
Quest® Data Connector
DC移行の際の除却サーバーを使い、マスタ1台、アプリサーバー1台、スレーブサーバー5台の構成でバッチJOBを流している。

カーセンサーでの処理の流れ
RDB
RDB
Select---from---left outer join ---
行動履歴
事業
マスタ
マスタデータJOIN＋加工
Outputファイル
アクセスログ
外部
データ
Javaによる統計解析・詳細な集計など
Version
Kensakubi（いつ）
service_cd
kojin_id（だれが）
kino_cd（どの画面で）
bukken_cd（どの物件を）
han_cd
keisai_houjin_cd
keisai_madoguchi_cd
route_id
Kensakubi（いつ）
kojin_id（だれが）
kino_cd（どの画面で）
bukken_cd（どの物件を）
Brand_name(ブランド名)
Shashu_name（車種名）
Soukou（走行距離）
Nenshiki（年式）
Price（価格）
keisai_houjin_cd
keisai_madoguchi_cd
route_id
基本的にHiveで整形し、Javaで計算あるいはMahoutで計算させる。

AzkabanでJOBをスケジューリングする
Tomcat上にWarを置き、JOBフローを作成できるWEBアプリ。LinkedInのチームによって作成されたオープンソース。
基本的にシンプルなツール
・JOBフローを図で確認できる。
・処理時間の推移をグラフで確認できる。
・失敗時のメール送信、再実行が可能。

スレーブ5台構成でHadoopを使い倒す。
流れている処理の概要は
日次でレコメンドの処理を回しつつ、月次の処理、HiveQLの実行も担保している。構築時は計約10時間の処理

処理速度をあげるための工夫
・mapの最大数を2->3へ変更。
・mapred.job.priorityでJOBの優先度を設定。
・Sqoopのmap数はOracleのCPU負荷を考慮し、限界まで上げて10にし、オプションでHiveへダイレクトロード。
・日本語長文カラムはインポート時にとってこない。
・Sqoopによる差分更新＋Hiveのパーティション化。
・MahoutのFPGrowth処理をToolrunnerに対応させ、Reduceを並列で。
・並列数をあげるのではなくChildのメモリをあげてGCを減らす。（予定）
10時間半->6時間半まで短縮！

結論　Hadoopは使える

Hadoopの利用用途は多様
なぜHadoopを導入しようと考えたのか。
データ管理の一元化。ログ基盤。
分析エンジン・レコメンドエンジンとして。

Hadoopの導入の真の効果
Hadoopの真価
あくまでもまだ
教科書通りの使い方
・高速処理ができるが故に要件を変え何度も
Try and Errorを繰り返せる。
・サンプリングに頼らない
ロングテール部の解析
・開発サイクルの短縮と
豊富なエコシステムによる
短期間で幅広い分野の知識習得
データ管理の一元化。
ログ基盤。
分析エンジン・レコメンドエンジンとして。

これまでの分析とどのように異なるか
・それまでの分析では、データ整備／集計の処理時間、
　方向転換のしずらさなどで時間が多く掛かった
・Hadoopにより、本番サーバに負荷なく、データ抽出、データ集計、　集計方法の変更、等がスピーディーにできるようになった
・仮説を出して様々な視点からデータを集計し、その検証結果をすぐに見ら　れるようになることで、トライ＆エラーを通して分析の精度を高めていく　事が可能になった
分析大変…
もっとこういう集計
にすれば良かった…
本番DB
行動履歴DB
外部データ
可視化されて分析しやすい！
データ出し直しも簡単！
色々試せる☆
本番DB
Hadoop
検証環境
行動履歴DB
外部データ

これまでの分析とどのように異なるか
Hadoopを導入してからどう変わったか
１サイクルが圧倒的にスピードアップ
Try & Errorを積み重ね、分析精度が上がっていく
仮説出し
統計的な値付けロジックを構築できるか？
ローデータ作成
Sqoopを使い、Hadoop環境にデータを一括インポート
小売、AAの大量データを活用して、マーケティングに活かせるデータ分析を行いたい
集計
条件を変えながら
利益額を算出
全期間・全項目を一気に投入。
分析
簡単なアプリを作成し
可視化しながら分析
Hadoopの並列処理で数10分で
集計が完了
可視化して直感的に傾向を掴む。
アウトプットを見て、集計条件を変更して、再度分析
１サイクルに数日

この分析の実現によりどのような事業メリットがあるか
ゴールが明確でない中で、スピーディーに分析を繰り返し価値あるOutputに辿りつけるようになった
価値ある
Output
【集計単位】
　AAデータ1か月
【指標】
　中央値、30%ライン
【集計単位】
　AAデータ6か月
【指標】
　中央値、50台ライン
【集計単位】
　年式×走行距離
　グレード単位
【指標】
　最頻値
１車種を４段階に
細分化して
期待収益の算出
【集計単位】
　年式×走行距離
【指標】
　平均値、中央値
単位を年式帯×走行距離帯にして
データ母数を担保
AAデータ、
小売データの
差額分析
仮説
＋
大量データ
【集計単位】
　年式帯×走行距離帯
【データ】6か月分
【指標】
　最頻値
6か月データと
1か月データの比較

この分析の実現によりどのような事業メリットがあるか
【マーケットデータの多用な分析】
保有している大量のマーケットデータから、貴重なマーケティングデータを集計することが可能に。
・AAデータ、小売データの差額を分析し、
車種ごとの期待収益の算出
・平均値ではない「相場価格」の算出
　->「最頻値」

Hadoopの真の効果
Hadoopの真価
・高速処理ができるが故に要件を変え何度も
Try and Errorを繰り返せる。
・サンプリングに頼らない
ロングテール部の解析
・開発サイクルの短縮と
豊富なエコシステムによる
短期間で幅広い分野の知識習得
大量のデータを高速に処理できるというHadoopの技術的視点は大事だが、むしろそれ以上のメリットは、
「Hadoopを使えば今までできなかったことができそう。」
と感じ、分析・商品企画をする人の意識を変え、
無意識に諦めていた発想の壁を取り払えることにある。
48/49

今後の方針・思っていること

最後に
リクルート全データを対象とした
ロングテール分析　　
リクルート外のデータと組み合わせた分析　　
Hadoopは万能ではないが、エコシステムを組み合わせることで比較的容易に導入が可能。
今後もこれまで以上にHadoopを使い倒していきたい。
分析結果の新事業への利用　　
MapRなどの次世代Hadoopの検討　　

MapRの検証
次世代Hadoopの検証を推進。
特にMapRは使い勝手の良さそうな機能が満載。
GUIベースのモニタリング画面。アラート検知
NFSマウントが可能。Sqoopと合わせて既存システムからのファイルのやりとりが便利。
スナップショットをとってある時点へリカバリー可能。
ボリュームを作成でき、ボリューム単位でアクセス制限が可能。リクルートのようにカンパニー制の会社ではマルチテナント使用が便利。

2度の渡米でMapRの検証を開始
現在EMCさんと共同で処理性能比較の検証中。
アメリカに出張し、オフィスにて共同検証を行った。
注：写真は検証風景ではありません。

MapRとCDHの処理時間比較
MapR、CDH3は同設定にて測定。
※CDH2は2010年8月に行われた検証の結果を引用
MapRの処理時間は、CDH2と比較して49%減、CDH3と比較して43%減という結果であった。（処理性能換算では、CDH2比2.04倍、CDH3比1.76倍）
処理性能向上の内訳としては、MapReduce前処理時間の速度向上もあるものの、全体としてはMapReduce処理時間の向上の影響が多勢を占めている。
処理種別ベースでの処理時間の比較 [sec]
サマリ種別ベースでの処理時間の比較 [sec]
運用周りの使い勝手の検証を含めて、今後も引き続きmapRを検証していく。また、同様にその他新技術も積極的に検証し、事業内実装に邁進していく予定。

リクルートの新サービスが世に出たらその後ろでHadoopが活躍しているかも知れません。

http://infra-engineer.com	1224
http://logmania.masakiplus.net	377
http://kshi-kshi.hateblo.jp	234
http://www.lifexweb.com	220
http://paper.li	37
http://dev-wiki.rakuten.co.jp	14
http://webcache.googleusercontent.com	6
http://www.slideshare.net	4
http://tweetedtimes.com	3
http://translate.googleusercontent.com	3
http://us-w1.rockmelt.com	1
http://feeds.feedburner.com	1

リクルート式Hadoopの使い方

by Nobuyuki Ishikawa on Sep 27, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

12 Embeds 2,124

Statistics

リクルート式Hadoopの使い方 — Presentation Transcript