リクルート式Hadoopの使い方

リクルート式Hadoopの使い方
〜Hortonworks Data Platform (HDP)
の使用感を添えて〜
株式会社リクルートテクノロジーズ
ITソリューション統括部ビッグデータ部
シニアアーキテクト
石川信行

2Copyright © Recruit Technologies Co., Ltd. All Rights Reserved.
趣味etc
学歴
略歴
所属
氏名
RTC ITソリューション統括部
ビッグデータ部シニアアーキテクト
兼アドバンスドテクノロジーラボ
石川信行
神戸大学大学院農学研究科
害虫制御学専攻
新卒入社6年目。
カーセンサー.netで営業研修、Javaを用いたシステム
開発に参加し、その後Hadoopの導入検証に従事。
主要事業にHadoopを導入したのちビッグデータGに合
流。現事業対応リーダー、画像解析など技術開発に従
事。
海水魚飼育
外国産昆虫飼育
スキューバダイビング
自己紹介

リクルートのビジネスモデル
さまざまなドメインでマッチングモデルに基づいたビジネスを展開。
Matching
Business
HR
Bridal
Group
Buying
Used
Cars
Travel
Real
Estate
Beauty Gourmet
Social Games
E-Commerce
Ad Network
New Business
Consumers Enterprise

リクルートの事業領域
「選択」をサポートするような情報サービスを展開
Life event area Lifestyle Area
Travel
IT/ TrendLifestyle
Health & Beauty
Job Hunt
Marriage
Job Change
Home Purchase
Car Purchase
Child Birth
Education

Infrastructure
/Security
Project
Management
UXD/SEO
Internet Marketing
Big Data Solutions
Technology R&D
Systems
Development
リクルートテクノロジーズの立ち位置
リクルートホールディングスは7つの主要事業会社と３つの機能会社から成り立っている。
Recruit
Holdings
Recruit Career
Recruit Sumai Company
Recruit Lifestyle
Recruit Jobs
Recruit Staffing
Recruit Marketing Partners
Staff service Holdings
Recruit Technologies
Recruit Administration
Recruit Communications
Business/
Service
Function/
Support

1
2
最近のデータ活用状況紹介
3
4
5
データ利活用案件紹介
Hortonworks Data Platform の導入経緯
Hortonworks Data Platformの使用感
まとめと今後
アジェンダ

最近のデータ活用状況紹介

Server Database
数値で見るデータ解析環境
エコシステム
本番165台／開発24台 1343.2 TB

紹介案件
画像解析中古車情報サイト ECショップサイト
 カスタマーアダプティブ
UXデザイン
 ネイルデザイン判定
 不適切画像校閲
 アイテムレコメンド

カーセンサー.Net

カーセンサー：カスタマーアダプティブUXデザイン
全体最適個別最適
（カスタマーアダプティブUXデザイン）
従来はカスタマーを集合体と捉えた時に、
アクション貢献度の高い画面へ誘導する改善
本施策は検索KWDや絞込み条件などをみて、
一人一人にあった画面(機能)へ誘導する改善
カスタマーアダプティブUXデザインを実現する上で重要となる２つのポイント
1. Hadoopを使った
全カスタマーのログ解析 2. BIGDATAに裏付けられた
コンテキストの解釈
通常のツールでは集計に膨大な時間を要する
全カスタマーの「行動（画面遷移）」と「様態
（滞在時間etc）」の解析を、Hadoop利用に
より短時間で実現。
Hadoopにより集計したログに基き、カスタマー
の行動の要因となった「考え」「コンテキスト」を
推測。「データに血を通わせる」解釈の作業を
加える事で、よりカスタマーアダプティブなUXの
実施に繋げる。
共
通
の
画
面
C
V
共
通
の
画
面
共
通
の
画
面
C
V
最
適
な
画
面
Ａ
最
適
な
画
面
Ｂ
最
適
な
画
面
Ｃ
最
適
な
画
面
Ａ
最
適
な
画
面
Ｂ
最
適
な
画
面
Ｃ

カーセンサー：個別最適化フレーム
型化した検討プロセス及びデータを用いた膨大な量のカスタマー行動解析と可視化の自動化。
目的・方針整理仮説の設計
データ解析
モデル化
シナリオ設計シナリオ検証
型化した検討プロセス
各事業ログ
SiteCatalyst
アプリログ‥
Hadoop
バッチ集計
D3.jsで
ログデータを図示化
カスタマー行動モデル
の可視化
※可視化されたデータの表示画面
BIGDATAを用いたカスタマー行動解析及び可視化の自動化
★自動化

カーセンサー：打ち手の例
UI施策の一例（バルーン表出）
物件一覧に初回来訪し、物件のヒット件数が30件以上だったカスタマーにだけ、地域絞込み機能の活用を促す導線を表示
物件一覧から地域絞込み画面へ誘導

ポンパレモール

ポンパレモール：アイテムレコメンド
ポイント確認画面を借りて
ポンパレモールへパーソナライズレコメンドを実装

Genesis
API
※現在絶賛改装中のため、構成は日々変わっています
Hadoop
HBase
裏側の仕組み
レコメンド用
JavaScript
行動ログ
モニタリング
API
行動ログ
（蓄積）
DWH（Exadata）
Hadoopクラスタ
事業データ
事業データ
レコメンドデータ
作成バッチ
ログ蓄積
バッチ
事業データ
ディスプレイ
API
レコメンド API
レコメンドデータ
ログ蓄積 API
モールAPI
（アイテム情報取得）
 事業は規定の組み込み用JS数行とJS、
CSSファイル配置のみで作業終了
 独自デザインのCSSやHTMLでレコメンド面
を作りたい場合でもフロントTのみの作業で
完結
 クラウド、オンプレ、スマホ、PC、会員、
非会員のすべてのケースで対応可能
Point

JSによるリアルタイムグラフ描写
 レコメンドの表出ログ、クリックログをリアルタイムに取得し、Hbaseに格納
 クリック数やCTRなどの本当に必要な特定項目に絞り、可視化の簡素化
 CRMチームが施策実施後直に効果が分かるツールとして積極利用

画像解析

多様化するデータ解析
レコメンド、帳票以外に「人の作業代替」という新たなジャンルのデータ解析ソリューションが増えつつある。
利益貢献コスト削減
レコメンデーション帳票レポート
指標・目的
 CVR最大化
 CPA最適化
指標・目的
 最適化
 次期戦略策定
指標・目的
 無駄の排除
 工数削減
 人はよりクリエイティブに
作業代替
（AI領域）

ホットペッパービューティ：スマホWEBにおけるネイル判別実装
似ているデザインから探す
カラーから探す
39色から選択可能
似ている画像を表示
New①
New②
New① New②

ホットペッパービューティ：デザイン判別フロー
INPUT画像爪箇所判別爪画像のベクトル変換
→
①(0.3,0.2,0.4,…)
②(0.4,0.1,0.3,…)
③(0.3,0.2,0.5,…)
④(0.7,0.8,0.1,…)
⑤(0.4,0.2,0.4,…)
予め作成した判別モ
デルとベクトルを照合
ワンカラーフレンチ
アニマル
リボン
逆フレンチ
①
②
③⑤
④
デザイン判別結果
逆フレンチ4本
アニマル1本
が映っていると判定

入力画像に対して判別モデルの持つラベル単位で推定確率を算出して
その結果を重み付け処理することにより、最終的に入力画像が以下の
いずれに分類されるかを識別する機能を提供するシステムを提供。
 Safe
通常の画像・適切な画像
 Sexual
女性の裸体など性的な画像・不適切な画像
 Grotesque
出血や遺体など残虐、猟奇的な画像・不適切な画像
ギャザリー：不適切校閲

woman_naked
woman
sexual
man_portrait
man
safe
woman_under
ware
woman
safe
woman_norm
al
woman
safe
man_sumou
man
safe
man_underwa
re
man
safe
image_wound
other
grotesque
image_wound
other
grotesque
plant_flower
view
safe
※ 上から順に最高スコアラベル, 最高スコアカテゴリ, 不適切判別結果
ギャザリー：判別結果例

Active Learning
Convolutional neural networkで生成したモデルに対して、日々アップロードされる画像から
「これをモデルに追加したら判別精度が上がるはずだという画像」をレコメンドしてくれるシステムを構築。

1. あらかじめ作成したモデル推定結果
を利用
ActiveLearning
対象データ選定処理
HBase
HBase
投入処理
画像
リスト
2. 現状のモデルが推定に迷っているような
データを対象として選び出す。
3. 作成した画像の
リストを HBase に
投入
4. タグ付け WebUI からタグ付けを行う
ギャザリー用
定常画像解析
美容ネイル用
定常画像解析
日々の処理
データの
モデル
推定結果
Active Learning学習データ作成フロー
5. モデルに画像を追加し、再構築

Hortonworks Data Platform
の導入経緯

課題感新たなエコシステム検討の必要性
 Sparkによる分析処理高速化
 バッチ処理高速化を念頭にHiveの集計高速化
 コールドスタート対応などを見越してのストリーム処理の検討
 セキュリティ、アクセスコントロールの検討
施策やニーズが多様化し、エコシステムの導入や
アーキテクト変更を積極的に実施していく必要が出てきた。

課題感データ解析従事者の増加
・ビッグデータG創設期
（2012年）
・解析従事者
66名
・2013年
・解析従事者
119名
・2015年
10月1日現在
・解析従事者
212名
社内のデータ活用ニーズの高まりに応じて、データ解析従事者の数が年々増加。
単純に人員増加のほか、人員入れ替えや業務の分割化も進み、
Hadoopならびにエコシステムの知見、チューニングナレッジなどが希薄化していく
傾向が見られていた。

DataLake構想の必要性
Hadoopの強み生かしたDataLake構想の実現を模索している。
 ローデータから自在に定義を作り、Schema on readで施策を推進できる
自由さとスピードの速さ
 「すべてのデータはここにある」という絶対的安心感とすぐ隣にあるデータとの
連結容易性
 ここにあるデータを一元でマネジメントできればそこから発生するデータに一様
な正確さが出る。
 ※ただし、ここでいうローデータとはリクルートでいうRDBMSに格納されてい
るような綺麗な整形済みデータを表すのではなく、アプリケーションの生ログや
テキスト文そのもの、画像、動画、音声、マシンログなどありとあらゆるデータを
定義するものである。

データ基盤＆ETLデータソース群
私たちの考えるDataLake構想（あくまでも一例）
非構造データ
 IPGeo
 TVメタ etc
外部データ
DataBase
JOBScheduler
Ingestion
Process
Metadata
Management
各種DataBase
Interactive
Analytics
施策接続
Realtime
Batch
Story
Telling
・BI
API
MLlib、
GraphX
DeepLearning
 クリックログ
 位置情報 etc
リアルタイム情報
Data Mart
（HDFS）

Hadoop環境における課題感・目的意識
 施策の多様化・新施策発掘に対応するためのHadoopエコシステムの積極
的活用の推進
 急激な人員増加に伴う、Hadoopおよびエコシステム知見の希薄化。
 Hadoopのあり方の再検討（DataLake構想の設計）
 オープンソースコミュニティへの積極的貢献、知見吸収
私たちはユーザー企業でありシステムに何を使うかは検証を行い、公平な立場で導入
判断を行っている。
上記の課題解決・目的達成の解の一つとして2015年4月より、本格的に
Hortonworks Data Platformの検証を開始した。

の使用感

検証における観点
 システム検証
• 既存環境との差分確認、著しい性能劣化等がないことを目的とした、基本的な動
作確認を行う。
 運用検証
• 耐障害性が求められる機能において、想定されるユースケースを元にした擬似障害
を発生させ、期待される動作が行われることを確認する。
 監視検証
• 想定される障害に対して、トリガが発動し、正常にアラートが発報されることを確認
する。
 エコシステム検証
• 現在使われていない新しいエコシステムの基本機能の確認および活用用途の評価
を実施することを目的とした動作確認を行う。
 総合検証
• 実運用を想定した複数ジョブの定常実行時のクラスタ状態の正常性を確認する。
本検証では、以下のとおりの観点で評価を行った。

検証環境
 JournalNode
 AmbariServer
 MetricsControler
 NameNode
 ResourceManager
 ZKFailoverController
 ZookeeperSerer
 MetricsMonitor
 JournalNode
 NameNode
 ResourceManager
 ZKFailoverController
 ZookeeperSerer
 AppTimelineServer
 HBaseMaster
 HistoryServer
 HiveMetastore
 HiveServer2
 SparkHistoryServer
 MySQLServer
 MetricsMonitor
 JournalNode
 ZookeeperSerer
 HBaseMaster
 HiveMetastore
 HiveServer2
 FalconServer
 MySQLServer
 OozieServer
 RangerAdmin
 Usersync
 WebHCatServer
 MetricsMonitor
 DataNode
 RegionServer
 NodeManager
 FalconClient
 HBaseClient
 HDFSClient
 HiveClient
 MapReduce2Client
 OozieClient
 Pig
 SparkClient
 Sqoop
 TezClient
 YARNClient
 ZookeeperClient
 MetricsMonitor
 DataNode
 RegionServer
 NodeManager
 MetricsMonitor
Master Node × 3
Slave Node ×
10
HDP Cluster
構成図

検証結果概要
 Hortonworksの環境でも現行の全JOBを同等以上の性能で動かすこと
ができた。十分本番でも耐えうる設計であった。
 Hortonworks社のサポートレベルは高く有益であった。
 100％オープンソースの名に恥じなく、Sparkや、python、Rなど他のオー
プンソースとの組み合わせが設計しやすく、Tableauなどエンタープライズ系
製品との接続にも難がほとんどなかった。
 Ambariを使っての運用に関して一部不安定な個所が存在する、NFSゲー
トウエイが基本的にリードオンリーの設計で使いづらいなど細かなデメリットは
あるものの、Hortonworks社の今後の対応に期待している。

Sparkによる協調フィルタリングの精度改善
 データマートの変更：閲覧ログのアイテムを詳細化
Spark導入によって現実的な処理時間でより多くのアイテムを扱えるようになった
 レコメンド精度：現行の約2.5倍の精度を達成
 実行時間： Mahoutの約14倍の実行速度を達成 ※AWSで測定
閲覧ログのアイテムの定義件数ユーザ数アイテム数疎性
現行マートサイト＋イベント
※MFB, JLNの一部イベントのみアイテムを付加
146,306,632 11,145,324 1,832,209 0.99999284
Spark IB サイト＋イベント＋アイテム
※イベントをproductView,purchase等に限定 154,951,882 9,949,873 5,117,420 0.99999696
■ 現行
■ Spark IB
0.0269
0.0687
0
0.02
0.04
0.06
0.08
f-measure比較
0.7929
0.6142
0
0.2
0.4
0.6
0.8
1
User Coverage比較
Spark IB Mahout IB
実行時間 0:33:41 7:53:05

きめ細やかなサポート体制
HDPのバージョンアップにより生じた、解決が難しい課題に関しては、
WEBカンファレンスにて実画面を見ながらサポートいただいた。
このような手厚いサポート体制とレクチャーによる知見獲得は
知識が希薄化しつつある我々組織にとって非常に有益だと考える。

コミッタによるサポート力
 Hortonworks社に在籍するHiveのコミッタであるGopal Vijayaraghavan氏ら
と会話し、Hiveのチューニング処理に関して相談。
 「基本的にチューニングで10～20秒は早くできる」と断言、configの設定指針など
を指南いただいた。
hiveconf hive.prewarm.enabled=true —
hiveconf hive.prewarm.numcontainers=<n>
Pick a fixed number there, preferably a good fraction of the
cluster size (default = 10).
set tez.grouping.min-size=4194304;
set mapreduce.input.fileinputformat.split.maxsize=67108864;
set hive.tez.exec.print.summary=true;
ANALYZE TABLE <table> COMPUTE STATISTICS FOR COLUMNS;
set hive.stats.fetch.column.stats=true;
set hive.stats.fetch.partition.stats=true;
set hive.cbo.enable=true;

設定チューニング後の速度比較
処理時間（秒)
種類 HW(旧設定) HW(Config適応)
hiveクエリ① 25 13
hiveクエリ② 29 11
hiveクエリ③ 23 10
hiveクエリ④ 166 14
hiveクエリ⑤ 40 34
hiveクエリ⑥ 27 16
hiveクエリ⑦ 19 12
hiveクエリ⑧ 1,448 693
hiveクエリ⑨ 37 23
hiveクエリ⑩ 58 37
hiveクエリ⑪ 298 347
hiveクエリ⑫ 36 24
hiveクエリ⑬ 28 12
hiveクエリ⑭ 68 34
前項のConfigを適応し、Hiveの処理速度が宣言通り短縮。
こういったきめ細かなチューニングができるのも、コミッタを多く抱える
Hortonworksの強みであると確信している。
※一部FullJoinが走るものは速度劣化があったが、こちらも再度相談中。
※ ORC圧縮＋Snappy形式を適応

判断として
 コストメリットが十分ある。
 サポートが的確で、迅速である。
 豊富な知見をもち、バグ解決、チューニングを通じて相互に成長ができる。
 OSSベースで他のシステムとも親和性が高い。
 Hortonworksを導入している海外企業とディスカッションができる。
上記から
の導入を決定した。

まとめと今後

これから
これからもHadoopおよびそのエコシステムを使い倒し、データ利活用
を推進していく。
Hortonworks社との連携強化を行い、Hortonworks社のエンジ
ニアとともに協力して開発を行うことで、知識の向上とアーキテクチャの
最適化を目指す。
今後も最新のデータ解析周りの製品を貪欲に検証し、ビジネスに生か
していく。オープンソースへの貢献も視野に入れる。
１
2
3

ビジネスを踏まえて
泥臭くかつアグレッシブに
分析・エンジニアリングが
できる方。
ご連絡ください。
戦友をさがしています。
石川信行
Nobuyuki
Ishikawa
Yes, We Are Hiring!

ご静聴ありがとうございました
リクルートテクノロジーズ

リクルート式Hadoopの使い方

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to リクルート式Hadoopの使い方 (20)

More from Recruit Technologies (20)

リクルート式Hadoopの使い方