hadoopカンファレンス20140707
DESCRIPTION
7月8日に行われた、Hadoop Conference Japan 2014で弊社石川が講演した資料になります。TRANSCRIPT
株式会社リクルートテクノロジーズ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
CompactionCompression NONE
Blocksize 65536
Scope 0
BlockCacheEnable TRUE
InMemory FALSE
BloomFilterType NONE
テーブル属性パラメータ 設定値
FileSizeMax 4294967296
ReadOnly FALSE
MemStoreFlushSize 67108864
DefferedLogFlush 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
BlockCacheEnable TRUE
設定値
Blocksize
ReadOnly
NONE
FALSE
NONE
1
CompactionCompression
テーブル属性パラメータ 設定値
FileSizeMax 4294967296
TimeToLive 60480
67108864
FALSE
MemStoreFlushSize
ファミリー属性パラメータ
Scope 0
Compression
DefferedLogFlush
InMemory
BloomFilterType NONE
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
CompactionCompression NONE
Blocksize 65536
BlockCacheEnable TRUE
TimeToLive 604800
MaxVersions 1
Compression NONE
MemStoreFlushSize 67108864
DefferedLogFlush FALSE
ファミリー属性パラメータ 設定値
テーブル属性パラメータ 設定値
FileSizeMax 4294967296
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-k表現のベクトルを入力とし、その単語の前後にある単語の出現確率を出力とするニューラルネットを学習させ、その中間層の値を単語を表現するベクトルとして用いる。
目的関数
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 を試すことにした。
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!
ご清聴ありがとうございました
リクルートテクノロジーズ