Hadoopカンファレンス20140707

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

プ　石川　信行

リクルート式 Hadoop の使い方

3rd Edition

自己紹介

2

氏名石川　信行

所属 RTC IT ソリューション統括部ビッグデータ 2G兼アドバンスドテクノロジーラボ

略歴新卒入社 6 年目。カーセンサー .net で営業研修、Java を用いたシステム開発に参加し、その後Hadoop の導入検証に従事。主要事業に Hadoop を導入したのちビッグデータ G に合流。現事業対応リーダー、画像解析など技術開発に従事。

学歴神戸大学大学院農学研究科　害虫制御学専攻

趣味 etc 海水魚飼育外国産昆虫飼育スキューバダイビング

アジェンダ

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

データ利活用案件紹介2

データ解析基盤について3

技術導入の過程4

取り掛かり中の技術紹介5

まとめと今後6

4

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

数値で見るデータ解析環境

5

本番 98 台、開発 24 台

543 TB

エコシステム

数値で見る Hadoop の使われ方

6

28,344

295

1038万

1 日あたりの全 JOB の数

1 日あたりの全 WebHive クエリの数

1 日あたりの全 Hbase クエリの数

※6/23~6/24 計測

数値で見るデータ解析案件状況

7

200

155

データ解析案件数（年間）

ビッグデータ部の案件従事人数

ぐらい

8

データ利活用案件紹介

ゼクシィ：パーソナライズ push

今週のあなたにオススメ会場一覧ができまし

た。

オススメ一覧閲覧

通知を受け取る

個社閲覧フェア予約

ブライダルフェア予約

Pusna によるプッシュアプローチ

Pusna （プッシュアプローチ）によるアクション増を実現する。

9

ゼクシィ：システム構成図

10

【期待される効果】① ユーザ毎の嗜好がソートに反映されるため　 CVR が上がる

② 検索行為をしなくても求人に応募できるため　応募数増が見込める

③ 一覧がユーザに望ましい求人の順番になるため　表示上位から応募されて、応募数増が見込める

ユーザ毎におすすめの求人をスコアが高い順で一覧表示する＋

ユーザが閲覧したタイミングでおすすめが変化する

タウンワーク：スマホリアルタイムレコメンド

タウンワーク： HBase テーブル利用概要

12

HBase

相関原稿スコアテーブル

おすすめ原稿スコアテーブル

おすすめ原稿リストテーブル

INPUTレコメンド更新時

OUTPUTレコメンド取得時

取得

更新

取得

INPUT （レコメンド更新時）取得　：　相関原稿スコアテーブル更新　：　おすすめ原稿スコアテーブル　　　　　おすすめ原稿リストテーブル

OUTPUT （レコメンド取得時）取得　：　おすすめ原稿リストテーブル

ポンパレモールアイテムレコメンド

13

6/23 にポイント確認画面を借りてポンパレモールへパーソナライズレコメンドを実装

裏側の仕組み

14

レコメンド用 JSP

Hadoop

HBase

行動ログ

モニタリング API

行動ログ（蓄積）

DWH・ Hadoop クラスタ

事業データ

事業データ

ディスプレイ API レコメンド API レコメンドデータ

レコメンドデータ

作成バッチ

ログ蓄積 API

ログ蓄積

バッチ

※現在絶賛改装中のため、構成は日々変わっています

レコメンドロジックを中央化し、 jsp組み込みで簡単にレコメンドを導入できるよう仕組み化

Hbase の構造～レコメンドデータの格納

15

フィールド値サンプル値

テーブル名 fs_rec_item -

テーブル概要 IDハッシュ化済みのとそのユーザのレコメンドリストを保持する。 -

行キー MD5(RID).substr(1, 16) 900150983cd24fb0

フィールド物理名論理名 -

カラムファミリー rec < >レコメンドデータ -

カラム修飾子 list < >レコメンドリスト shopUrl=1111,2222,3333&itemManageId=aaaa,bbbb,cccc

InMemory FALSE

BloomFilterType NONE

Scope 0

CompactionCompression NONE

Blocksize 65536

BlockCacheEnable TRUE

TimeToLive 2147483647

MaxVersions 1

Compression NONE

MemStoreFlushSize 67108864

DefferedLogFlush FALSE

ファミリー属性パラメータ設定値

テーブル属性パラメータ設定値

FileSizeMax 4294967296

ReadOnly FALSE

・ユーザー ID に対してレコメンドデータをリストで保存。・商品 API からとってきたデータを JSON形式のままそのままキャッシュ。⇒API に負荷はかけたくない


テーブル名ポンパレモール：商品詳細キャッシュテーブル

テーブル概要 fs_mall_iteminfo

行キー API認証キーを含まないモールへのリクエストパラメータ shopUrl=chatdor&itemManageId=ch-zakuro150&imgSize=96


カラムファミリー data データ

カラム修飾子 detail 商品情報詳細 json (2.5KB)形式で格納

Compression NONE


Blocksize 65536

Scope 0


InMemory FALSE




ReadOnly FALSE




TimeToLive 2147483647

MaxVersions 3

裏側の仕組み

16

レコメンド用 JSP

Hadoop

HBase

行動ログ

モニタリング API

行動ログ（蓄積）

DWH・ Hadoop クラスタ

事業データ

事業データ

ディスプレイ API レコメンド API レコメンドデータ

レコメンドデータ

作成バッチ

ログ蓄積 API

ログ蓄積

バッチ

※現在絶賛改装中のため、構成は日々変わっています

このあたり

JS によるリアルタイムグラフ描写

17

Hbase 上にためたデータをリアルタイムで描写・ロジックを変えた効果を今知りたい。・別にドリルダウンとかいらない。そんな余裕はない。・見たい指標がころころ変わる。・動くとなぜか感動する。人として。

グラフ描写の裏側

18

ログをリアルタイムに収集し、蓄積用、グラフ描写用の 2TBL に格納。また蓄積したデータMapReduce にて Hive に格納し、分析者が更なるトラッキングや集計ができるように加工している。・ key に SALT.Timestamp を仕様。 Timestampは描写間隔にしたい任意の秒数で丸め込み。・ Hbase の JavaAPI の increment.add を使用。


テーブル名 fs_cs_logging -

テーブル概要 IDとイベントコード、パラメータを保持 -

行キー HASH(MD5(Timestamp+ID+Math.Random())) 106d876c11457acbeafe7d3b4d947b90


カラムファミリー log < >ログデータ -

カラム修飾子 ts < >タイムスタンプ 2014-05-12 15:00:00

カラム修飾子 id <Hashed ID> 0000000000000000

カラム修飾子 evt < >イベントコード 001

カラム修飾子 prm < >パラメータ itemId=100000&shopId=70000&catId=50


設定値

Blocksize

ReadOnly

NONE

FALSE

NONE

1

CompactionCompression



TimeToLive 60480

67108864

FALSE

MemStoreFlushSize

ファミリー属性パラメータ

Scope 0

Compression

DefferedLogFlush

InMemory


65536

MaxVersions

FALSEfffc38d711b449cc9c1d835168ecd650 column=log:evt, timestamp=1398096898682, value=001fffc38d711b449cc9c1d835168ecd650 column=log:prm, timestamp=1398096898682, value=param1=value1fffc38d711b449cc9c1d835168ecd650 column=log:rid, timestamp=1398096898682, value=0000000000000000fffc38d711b449cc9c1d835168ecd650 column=log:ts, timestamp=1398096898682, value=2014-05-12 12:00:00...fffc38d711b449cc9c1d835168ecd650 column=log:evt, timestamp=1398096898682, value=001fffc38d711b449cc9c1d835168ecd650 column=log:prm, timestamp=1398096898682,


テーブル名 fs_cs_measure -

テーブル概要特定時間単位毎の各イベントの発生回数を保持 -

行キー SALT(000 010) . Timestamp( )～特定時間単位に丸め込まれている000.1398163200000


カラムファミリー cnt < >カウントデータ -

カラム修飾子 001 < >イベント：レコメンド表出14

カラム修飾子 002 < >イベント：レコメンドクリック3

InMemory FALSE

BloomFilterType ROW

Scope 0


Blocksize 65536


TimeToLive 604800

MaxVersions 1

Compression NONE






ReadOnly FALSE

000.1398163200000 column=cnt:001, timestamp=1398163424972, value=3000.1398163200000 column=cnt:002, timestamp=1398163424972, value=2000.1398163500000 column=cnt:001, timestamp=1398163590241, value=3000.1398163500000 column=cnt:002, timestamp=1398163590241, value=1...009.1398163200000 column=cnt:001, timestamp=1398163424972, value=7009.1398163200000 column=cnt:002, timestamp=1398163424972, value=3009.1398163500000 column=cnt:001, timestamp=1398163590241, value=2009.1398163500000 column=cnt:002, timestamp=1398163590241, value=1

300000ms 300レコードの丸め込み単位は（秒）とする

Hbase をもっと活かしたい！

19

リアルタイムに蓄積されたデータをロジックにフィードバックする。

もっと非構造データを格納し、利用する。

ストリーム処理に対するキャッシュ機構。

20

データ解析基盤について

全社 Hadoop・データ整形・加工・データストレージ

各事業 DB

全社 DWH・モデル作成・高速分析処理

　　　　　　　？

全社 BI・モニタリング・レポート

各事業 Hadoop

分析用外部データ

SNS・データｸﾗｳﾄﾞ

データソース群ビッグデータ基盤スタック利用者層

高度分析やモデル作成

レポート／モニタリング

エンドユーザー( エグゼ／マネージャ／営業 )

ビジネスインサイト

マーケター( プロデューサ／事業企画 )

データサイエンティスト（高度分析者）

機械学習やモデル実装

データサイエンティスト（エンジニア）

分析ツール群

Hadoopエコシステム

ビッグデータ基盤構成概要

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

2012 年Hadoop 活用拡大DWH 導入展開リアルタイム研究分析と技術の組織統合

ほぼ全ての事業でHadoop の活用を実施

ビッグデータ活用基盤を拡充（ DWH等）

　 2011 年Hadoop の本格展開

各サイトで本格展開を開始、 11 事業 40 案件に適用

Hadoop カンファレンスを R 後援で開催

2010 年高速集計基盤の研究

Hadoop のリサーチを開始、この段階の投資は最小限に抑えサーバはWeb オークションで調達

2013 年全社規模 BI 導入展開全社データ集約環境「 TotalDB」の推進

リサーチ環境第 1世代 Hadoop 第 2世代 HadoopDWH

インフラ基盤の進化

BI基盤

ビッグデータへの取り組み (2014 年）

2014 年

Node5

Node6

Node7

Node8

Node1

Node2

Node3

Node4

将来のあるべき姿からHW 、アーキテクチャーなどを検討する

第三世代Hadoop の検討

？

アドホック分析基盤の導入

24

技術導入の過程

25

いつもの体制図

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

コンサル型エンジニア型

協働

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

プ

Hadoop エンジニア分析者

26

データドリブンの意思決定・施策数が増加カスタマサイド、クライアントサイド、メール、 PUSH 、社内システム、社内帳票など利用シーンも多岐に。

施策ひとつひとつがより難易度高くかつ長期施策となり質が増加。シナリオマーケ、リアルタイムレコメンド、テキスト解析、機械学習などがお互い理解しやすくなった。

事業担当者≒マーケター

の知識向上、データドリブン施策の重要性が認識・拡散。

ここ数年での変化

開発ステージ

27

R-StageDev-Stage

β-Stage運用 -Stage

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

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

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

・実運用へ

Gate Review Gate Review Gate Review

マーケッターの知識向上に伴い、より密に伴走し、切磋琢磨しあうために、技術開発を推進している。

2011 年 Hadoop カンファレンスにて

28

とはいえ、既存のシステムもあり、大幅にコストをかけるわけにもいかない。Hadoop も既存のシステムとの関係を意識して導入を行った経緯がある。

テキスト解析 @2012

29

・いま使えるものを組み合わせて早く、安く提供。・ビジネスはマーケッターのほうがよく知っている。・が、少しは染み出すアグレッシブさが必要。・サービスがうまくいった時点でより高品質な構成へ。

社内に存在する膨大なテキストデータを何かに使えないかと思う。

格納場所もあるよねと思う。

そういえば、 Solrやってたから形態素は Lucene 使えば…、辞書の単語にはwikipedia追加すればいい。

クラスタリングとか分類はとりあえずMahoutで。

事業の状況や課題をこれまでの打ち合わせなどから想定。デモを作成して相談。

30

取り掛かり中の技術紹介

取り掛かり中（一部やりたい）のテーマ紹介

31

Titan

グラフ画像解析テキスト解析

ストリーム分散SQL

注意

32

http://ha-chi.biz/big.php?no=303

これから話す内容はあくまでも開発中のため、実際にサービス化されるまで詳細はお話できません。世に出てからのお楽しみとしてください。

社内に眠るデータの可能性

33

543 TB （レプリケート時）

Hadoop に格納されているデータはまだわずか。リクルート内はまだまだ大量のデータがさまざまな場所に散在している。

・原稿情報・営業日報・商品・店舗画像・位置情報・議事録etc

ただ、貯めるというだけでもコスト。利用用途をある程度想定し、技術的にも扱えることを想起しておかなければならない。

画像解析

34

自然語解析の概念Bag of words

テキストから重要単語頻出度を算出しベクトル化する。

Bag of keypoints

画像の局所特徴量を抽出しベクトル化する。また RGF などの色の概念

もベクトル化する。

一般物体認識：将来的な実装図

35

画像格納基本処理・下処理・サイズ調整・ホワイトニングetc

特徴量抽出学習・予測

・スパースコーディングwith scikit-learn

・ SVMlibSVM 、 R 、 MLIB

一般物体認識：スパースコーディング

36

K-means, Sparse Coding,OMP, RBM, Auto Encoder…

一般物体認識：スパースコーディング

37

Encoding Pooling

fn(x) 先のページで作った

エンコーダー適応

ΣやM

特徴ベクトル化

y（1,1） y（1,2）

k次元

先のページで作ったエンコーダーを用いて画像を特徴ベクトルの変換する。

投入イメージ画像表現特徴量

スパースコーディング

38

Normalization,Whitening

Encoding

Pooling

Standardization

AutoEncoder(option)

この特徴抽出を一段階，あるいは二段階に渡り行う．得られた特徴を用いて一般物体認識 (SVM…) を行う。

利用展開予定

39

画像に自動でタグをつけることで検索効率をあげる。※往々にして人手で入力するのはコストがかかる。

類似画像を検索できる。

カラーヒストグラムなどをベクトル演算に加え、「色」や「形状」による検索をできるようにする。

テキスト解析の NEXT

40

これまで様々なテキスト分析を行ってきた。

・ TF-IDF⇒LDA による Topic クラスタリング・ TF-IDF⇒SVM 、 RandomForest による分類・係り受け分析・文章要約

割と一過性のレポートであったり、レコメンドの 1 変数作成程度の利用が多かった。まだまだテキストデータの可能性を出し切れておらず、もう少し機械学習チックに利用しサービスに役立てたいと考えている。（競合スタートアップも出始めているので。）

Skip-Gram の利用

41

各単語を表現するベクトルを学習単語から文書中でその単語の前後に現れる単語を予測できるような表現を学習単語を表す 1-of-ｋ表現のベクトルを入力とし、その単語の前後にある単語の出現確率を出力とするニューラルネットを学習させ、その中間層の値を単語を表現するベクトルとして用いる。

目的関数　

OUTPUT:

INPUT:単語の 1-of-k 表現

PROJECTION:単語

線形変換

階層的soft-max

1. Tomas Mikolov et al., ”Efficient Estimation of Word Representations in 　 Vector Space”, 2013

例：モデル・学習方法

42

クライアント企業を単語、ユーザが閲覧した企業を文書として企業の分散表現（ベクトル）を得る

分散表現の次元数 =300最大ウィンドウサイズ =5最小出現頻度の閾値 =2 (2未満の企業は使わない。 )エポック数 =1 or 50

・・・

300次元

・・・ 5単語

5単語

w(t)

w(t-1)

w(t+1)

w(t+5)

w(t-5)

必ずしも類似度が高い =共起が多いという訳ではない。

基本的には類似度が高い =共起する企業の重なりが多いであると考えられる。

利用展開予定

43

単語をベクトル表現できるところが大変面白い。

よってベクトル計算によるクラスタリングや距離計算ができる。

ベクトル化された単語の足し引きによって本人が気づきにくい潜在的なレコメンドができる…はず。

グラフ

44

※1 　 Hadoop summit 2014 からhttp://www.slideshare.net/Hadoop_Summit/t-235p230-ctang※2 　 http://hortonworks.com/blog/big-graph-data-on-hortonworks-data-platform/

※1 ※2

人同士のつながりや、クライアント店舗同士の近さ、単語間の近さなど、リクルート内でも「エッジ」と「ノード」で表せる事象がまだ眠っていると判断。今後レコメンド機能などの発展にも寄与すると考え、導入が容易でユーザー企業に実績がある Titan を試すことにした。

http://www.slideshare.net/Hadoop_Summit/t-235p230-ctang

http://www.slideshare.net/Hadoop_Summit/t-235p230-ctang

TitanHbase などの KVS をバックエンドストレージとして扱うことができる分散型グラフ DB

FaunusバッチプロセッシングHadoop に特化したグラフ分析エンジン

Java製の GraphAPI

グラフエンジン： Titan の利用

Graph アルゴリズムGraph操作言語

Hbase のうえにのせるだけで使える titan 、 API のBluePrintを使って簡単な Shortestpath などのロジックを実装。なんといっても非常に簡易なのが魅力。

46

Titan・Gremlin コンソール画面

サンプルデモ

グラフ（リアルタイム）のメリット・デメリット

・あるノードを選ぶだけで近傍探索で他のノードを随時表示できる　　ユーザーの嗜好や行動を素早く汲み取ることができる

・既存の機械学習で使われるスパース（ 0 が多い）なローデータよりもシンプルなデータ構造となる　　容量削減、計算量減

メリット

・現在のところ用途が限定的

・出口の表現が難しい。グラフ描画のライブラリなどを組み合わせる必要がある

デメリット

Hive の使用が多い

49

28,344

295

1 日あたりの全 JOB の数

1 日あたりの全 WebHive クエリの数

リクルートでもっとも使われているエコシステムは Hive である。 MapRedcue直書きは少ない。社内での SQL クエリとの親和性は高く、その高速化は課題である。※Spark よりも優先したい理由もここにある。

製品名 Presto Drill Impala

提供元 Facebook 社Apache プロジェクト（ MapR社） Cloudera 社

問合せ言語 SQLSQL 、 DrQL 、 MongoQL 、 DSL

HiveQL

データソース

Hive （ CDH4 、 Apache Hadoop 1.x/2.x ）、 Cassandra（プラガブル）

HDFS 、 Hbase 、 MapR 、 MongoDB 、 Cassandra 、 RDBMS 、等（プラガブル）

HDFS 、 Hbase

接続方法 JDBC REST 、 JDBC 、 ODBC JDBC 、 ODBC

実装言語 Java Java C++

ライセンス Apache License 2.0 Apache License 2.0 Apache License

所感

・そこまで早くない。小規模カウントなどは Hive に負けることがある。・ CREATE TABLEや大規模テーブルの自己結合でエラーが発生している・MapR の公式サポートなし。・独立で構築可能、かつプラガブルは柔軟性が高く、リクルートでは余剰リソース活用で相性がよいかもしれない。

・ β プログラム参加予定・米MapR 社から継続的に情報を入手しており、それを聞くぶんには正直一番期待している。

・ Hive を（一部を除いて）単純に移行できるのは敷居が低い。

・ Hive に対して 5～ 10倍程度、安定的に速い

・柔軟性にかける。

クラスタ環境 Hadoopとは独立で構築可能 Hadoopとは独立で構築可能 Hadoop クラスタ上に構築

分散 SQL比較

50

処理時間比較： Hive VS Presto 　検証環境

51

presto01 presto02 presto03 presto04 presto05 presto06

CLDB CLDB CLDB

Zookeeper Zookeeper Zookeeper JobTracker

TaskTracker TaskTracker TaskTracker TaskTracker TaskTracker

maprfs maprfs maprfs maprfs maprfs

NFSgateway NFSgateway NFSgateway NFSgateway NFSgateway

WebServer

metastore(MySQL)

Presto CLI

Worker Worker Worker Worker Coordinator

Discovery

Presto MapR

Hive Client

Worker

Client PrestoCLI 、または、 JDBC からクエリを発行。

Coordinator Client からクエリを受け取り、構文解析、クエリ実行計画の作成を行う Scheduler が、 Workerへ処理のアサイン・進捗の管理を行う

Worker Coordinator の Scheduler から受けた命令に従い、データ処理を行う

Discovery Server クラスタ内のノードを検出する。 Coordinator／Worker が起動時に、 Discovery Serverへリクエストを送り登録する

Coordinator／Worker に Discovery機能を持たせることも可能

処理時間比較： Hive VS Presto

52

処理番号処理名 Presto HiveHive / Presto 備考

1_2 クレンジング　 × 0:54:56.92 　 - データ作成。1_3_1 セッションテーブル作成　 × 0:26:09.96 　 - データ作成。 Hiveは UDFを使用。1_3_3 イベントテーブル作成　 × 3:52:04.17 　 - データ作成。 Hiveは UDFを使用。1_5 データマート作成　 × 0:24:42.69 　 - データ作成。2_1_1 イベント数カウント 0:03:46.86 0:04:04.44 1.08　2_1_2 イベント数カウント (日付ごと ) 0:05:37.20 0:08:54.61 1.59　2_1_3 イベント数カウント (期間指定 ) 0:04:08.27 0:09:47.85 2.37　2_1_4 イベント数カウント (期間指定、日ごと ) 0:04:31.15 0:11:16.66 2.50　2_2_1 セッション数カウント 0:00:21.02 0:00:47.05 2.24　2_2_2 セッション数カウント (日付ごと ) 0:00:28.63 0:01:31.79 3.21　2_2_3 セッション数カウント (期間指定 ) 0:00:17.50 0:01:40.44 5.74　2_2_4 セッション数カウント (期間指定、日ごと ) 0:00:19.76 0:02:05.14 6.33　2_3_1 ユニークユーザ数カウント 0:06:02.75 0:05:28.44 0.91　2_3_2 ユニークユーザ数カウント (日付ごと ) 0:09:36.95 0:11:13.27 1.17　2_3_3 ユニークユーザ数カウント (期間指定 ) 0:04:45.22 0:10:40.49 2.25　2_3_4 ユニークユーザ数カウント (期間指定、日付ごと ) 0:05:20.91 0:11:43.35 2.19　3_1_1 ページ数カウント (ドメイン毎 ) 0:04:32.04 0:04:39.42 1.03　3_2_1 セッション数カウント (ドメイン毎 ) 0:09:26.33 0:18:00.84 1.91　3_3_1 ユニークユーザ数カウント (ドメイン毎 ) 0:08:52.33 0:06:11.42 0.70　3_4_1 1セッションあたりの平均滞在時間 (ドメイン毎 ) × 0:54:40.27 　 - Hiveは UDFを使用。3_5_1 平均 PV数 (ドメイン毎 ) 0:10:18.22 0:23:30.27 2.28　3_5_3 平均 PV数 (ドメイン毎、 DM使用 ) 0:00:01.44 0:00:12.72 8.83　3_6_1 直帰率 0:08:55.82 0:36:08.33 4.05　3_7_1 閲覧の多かったページランキング × 0:10:38.40 　 - データ作成。3_8_1 特定期間の新規ユーザ数 0:07:36.64 0:51:22.93 6.75Hiveは UDFを使用。3_9_1 経路解析 (2つ先の遷移先 ) × 2:06:00.64 　 - データ作成。 Hiveは UDFを使用。4_1_1 ページ数カウント (ドメイン毎、ユーザセグメンテーション ) 0:15:30.93 0:42:31.54 2.74Hiveは UDFを使用。

4_2_1

1セッションあたりの平均滞在時間 (ドメイン毎、ユーザセグメンテーション ) × 1:26:56.65 -　 Hiveは UDFを使用。

5_1_1 ページごとのユーザ数 0:06:21.43 0:06:32.76 1.03　5_2_1 RF分析 0:24:52.94 1:30:31.13 3.64Hiveは UDFを使用。

単純な COUNT などでは Hive の方が速いケースもあるが、総じて Presto の方が速い（最大 8.8倍、平均 3倍）

※「 ×」はエラー発生で実行できず

検証したけど一旦封印したもの

53

Azkabanは 3 年前に使用。当時は商用スケジューラに比べまだ機能が少なく難があった。ただ Hadoop summit2014 で紹介がされており、 VerUP により機能拡大がされたことを知った現在多少気になっている。

1 年前に Hbase に対するクエリ候補として検証。当時はJOIN ができず見送ったが Ver4.0 で JOIN が可能に。HortonWorks もサポートしていることを知り、また気になっている。

2014 年 2月に自ローカルで動かしたのみ。GUI で分析が可能だということが分かったが、まだ動作が甘く、 R以上の使いやすさを見いだせなかった。

オープンソースの進化は日進月歩なことに関心するとともに少しでも検証し、アンテナを張っておくことが重要と実感。

54

まとめと今後

案件適応に関して

55

目的をしっかり持ち、事業とともに新しい手法・技術にチャレンジする。その際はお互い多少リスクをのみ、少し無理をする。

新技術に関してはビジネス適応イメージ（勘違いでも多少可）をもったうえで検証を行う。

無駄な工数削減、チューニングの高速化のために共通化、型化をする。

非構造データ

DataLake 構造

56

DataBases

外部データIPGeoTV メタetc

JOBScheduler

Ingestion Process

Metadata Management

リアルタイム情報・クリックログ・位置情報etc

DWH

各種DataBases

Interactive

Analytics

施策接続Realtime

Batch

Repoting

Mlib 、GraphX

戦友をさがしています。

57

石川　信行

Nobuyuki 　Ishikawa

ビジネスを踏まえて泥臭くかつアグレッシブに分析・エンジニアリングができる方。ご連絡ください。

Yes, We Are Hiring!

ご清聴ありがとうございました

リクルートテクノロジーズ

Technology

Hadoopカンファレンス20140707