ビッグデータ処理データベースの全体像と使い分け

(C) Recruit Technologies Co.,Ltd. All rights reserved.
ビッグデータ処理データベースの
全体像と使い分け
2016/7/15
株式会社リクルートテクノロジーズ
ビッグデータ部
渡部徹太郎

BIG DATA Department自己紹介
{"ID" ："fetaro",
"名前"："渡部徹太郎",
"所属"："リクルートテクノロジーズビッグデータ部"
"研究"："東京工業大学で情報検索の研究（日本データベース学会）"
"仕事"：{前職:["証券会社のWeb基盤",
"オープンソース全般,主にMongoDB,NoSQL"],
現職:["リクルート横断のデータ分析基盤,
"ExadataとHadoopの両刀使い"]}
"エディタ"："emacs派"
"趣味" ："自宅サーバ"
"属性" : ["ギーク","スーツ"]}
1

BIG DATA Department発表をしようと思った背景
 ビッグデータ処理技術がありすぎる
2
DynamoDB
Kinesis
EMR
Redshift
BigQuery
Oracle
Exadata
Impala

BIG DATA Department発表をしようと思った背景
 リクルートのサービスはたくさんある
 日々次々と新しいサービスが生まれる
 ケースドリブンで最適なもの最速で提供する必要がある
 →いろいろな技術を知る必要がある！
3
・・・１００以上のサービス

BIG DATA Department本発表の目的
 ビッグデータのデータベースのニュースを見た時に、
 「どの辺」のデータベースか分かるようにする
 ベンダの誇大広告を見抜けるようにする
4

BIG DATA Departmentアジェンダ
 ビッグデータ処理データベースの分類
 各分類と代表製品の説明
 その他のビッグデータキーワードの説明
 Spark/Elastic Search/マイクロバッチ/インメモリデータグリッド/グ
ラフDB/
 ブロックチェーン/分散OLTP 急遽追加！
 リクルートテクノロジーズビッグデータ部における
データベース使い分け
 まとめ
5

ビッグデータ処理データベースの分類
6
目標到達時間 13:03

BIG DATA Departmentデータベースを分類する軸：重視する性能
7
 レスポンスを重視 →主にオペレーション用途
 スループットを重視 →主に分析用途
アプリケーションサーバ
オペレーション
用途
データベース
登録画面
参照画面
編集画面
マスタ
データベース
ＢＩツール
分析用途
データベース
レポート生成ジョブＣＳV レポート

BIG DATA Departmentデータベースを分類する軸：性能拡張方式
 データベースの代表的なボトルネックを解消
 ディスクIO
 CPU
 ネットワーク帯域
 共有リソースの開放待ち
 ネットワークラウンドトリップ
8
スケールアップ
集約
スケールアウト
分散
app app app app app appapp app app
一般的なハードウェアを複
数並べて並列処理
単一HWハードウェアを強化
性能限界
CPU↑
ディスク↑
NW↑
 データベースの性能拡張方式
←主にこの辺のボトルネックを解消

BIG DATA Departmentデータベースの分類
9
DB
( ) )
Hadoop
RDB(OLTP)
KVS
/
/
RDB(DWH)
NoSQLと
呼ばれている

BIG DATA Department
DB
データベースの分類
10
( ) )
RDB(OLTP)
KVS
RDB(DWH)
DynamoDB
BigQuery
Exadata Redshift
EMR
Hadoop
Exadata

各分類と代表製品の説明
11

スケールアップ型RDB(DWH)
12
DB
Hadoop
RDB(OLTP)
KVS
RDB(DWH)
オペレーション分析

BIG DATA Department
オンプレサービス
アプライアンスソフトウェア
 ひとことで言うと
 データの抽出・集計に特化したRDB
 アーキテクチャの特徴
1. データをパーティショニングして複数ディスクから同時に読む
(製品によっては)ハードウェアを最適化して、アプライアンスとして提供
2. 列志向で圧縮してデータ格納
13
Redshift
Exadata
DB
Hadoop
RDB(OLTP)
KVS
RDB(DWH)

BIG DATA Department
ストレージノードストレージノードストレージノード
 データをパーティショニングして複数ディスクから同時に読む
(製品によっては)ハードウェアを最適化して、アプライアンス
14
データベースノード
HDD
SSD
絞込み処理
HDD
HDD HDD
HDD
SSD
絞込み処理
HDD
HDD HDD
HDD
SSD
絞込み処理
HDD
HDD HDD
データベースノード
CPU
WHERE句を解釈し、
読み込むブロックを最小化
ディスクIOを削減
キャッシュして
ディスクIOを削減
CPUを多数搭載し、CPUボト
ルネックを軽減
40Gbpsのラック内SANによりネッ
トワークボトルネックを軽減
CPU CPUCPU CPU CPU
40G bps
Oracle Exadataの例

BIG DATA Departmentスケールアップ型RDB(DWH)
 列志向で圧縮してデータ格納
15
ID=2
1 1982年生男 2 1967年生女 3 2000年生女 4 2000年男
1 2 3 4
index
ID=2
1 1982年生
2 1967年生
3 2000年生
4 2000年生
男
女
女
男
ID 年齢性別
性別
男女
1男 4 女 1982年生 1967年生 2000年生1 2 3 42 3
年齢
1982年生 1967年生 2000年生

BIG DATA Departmentスケールアップ型RDB(DWH)
 処理イメージ
 レスポンス：数秒、数分
 データサイズ：直近１３ヶ月（1T〜数10T)
 計算：SQLベース
 ユースケース
 自由検索
 レポート
 BIツールのデータソース
 苦手なこと
 データの更新(INSET,UPDATE,DELETE)は非常に遅い
 トランザクションも遅い
16

スケールアウト型RDB(DWH)
17
DB
Hadoop
RDB(OLTP)
KVS
RDB(DWH)

BIG DATA Department
Hadoop系独自
オンプレサービス
スケールアウト型RDB(DWH)
 SELECTしか提供しないRDB
 SQLライクなクエリを提供
 INSERT, UPDATE, DELETEはない
 トランザクションを提供しない
 データの書き込みは一括ロードおよび全件削除のみ
18
BigQueryImpala
＋
→

BIG DATA Department伝えたいこと
 RDBやSQLだから分散できないわけではない
 整合性を保った更新（トランザクション）は処理の並列数を上げにくい
 スキーマレスとスケールアウトは関係ない
 スキーマがある（リレーショナルデータ)でも、単一ノードで処理されるのであれ
ばスケールアウトする
 JOINやSORTはスケールアウトは難しい
 単一ノードで完結できないため、どんなデータベースであっても難しい
 ブログ「RedShiftよりもBigQueryが速い！」
→戦う相手が違う
19

Hadoop
20
DB
Hadoop
RDB(OLTP)
KVS
RDB(DWH)

BIG DATA DepartmentHadoop
 分散したファイルに、様々
な分散処理をできるソフト
ウェア群
 データはファイル
 ストレージと処理が分離
 途中でノードがダウンして
も処理を継続
2121
分散ファイルシステム
分散処理エンジン
ABC
A B C
クライアント
計算
ノード
計算
ノード
計算
ノード
コーディネータ
計算
結果
プログラム
プログラム
クライアント
プログラムプログラム

22
プロダクト分散ファイルシ
システム
分散処理エンジン
オン
プレ
OSSベースでいろいろ使
る
MapR-FS
サー
ビス
?
EMR S3
Impala
Cloud
Dataproc
GCS

 処理のイメージ
 レスポンス：数十分〜数時間
 データサイズ：全データ(10T〜数P)
 計算：分散できる計算なら何でも
 長期的なビジネストレンド分析
 RDB(DWH)に入れる前のデータ加工
 機械学習によるクラスタリング、レコメンド
 分散自然言語処理
23

 クラウドのHadoop
 分散処理エンジンとストレージの分離
 計算ノードの台数を即時増減可能
 クラスタは使った分だけ払えば良い
24
core core core
HDFS(MapR-FS) S3
Master
データデータ
コンテナ
データデータ
コンテナ
データデータデータデータ
core
コンテナ
Master
コンテナ
core
コンテナ
core
コンテナ
Hadoop EMR
NEWNEW
データ移動
が必要
データ移動
不要
0:00 12:00 0:00 12:00
ク
ラ
ス
タ
起
動
台
数
オンプレ
クラウド
計算に必要なリソース

 Hadoopでも列志向を活用
 Hadoopは通常ファイルをデータとして扱う
• CSVのイメージ
 ファイルの中身を列志向に変えることで、さらなる抽出速度の向上ができ
る
• ORC(列持ちフォーマット) + Snappy(圧縮)

KVS
26
DB
Hadoop
RDB(OLTP)
KVS
RDB(DWH)

BIG DATA DepartmentKVS
 分散して、シンプルなオペレーションができるデータベース
 RDB(OLTP)とは異なり、
以下の2つによりスケーラビリティを獲得
1. 「強い整合性」を犠牲にして「結果整合性」を採用
2. 分散しやすいデータモデルと、分散しやすいクエリだけを提供する 27
データモデルキーバリューワイドカラム
データ構造
オンプレ
クラウド
ElastiCache
DynamoDB

 整合性を保証するとスケールアウトが困難
 整合性を緩めればスケールアウトできる
28
アプリケーションアプリケーション
アプリケーション
待たされ
る
ＡＢＣ
分散トランザクションで
待たされ
る
待たされる
→ →
ＡＢＣ

 KVS
29
分散ファイルシステム
(HDFS等)
分散処理フレームワーク
(MapReduce, Spark等)
ABC
A B C
クライアント
計算
ノード
計算
ノード
計算
ノー
コーディネータ
計算
結果
プログラム
プログラム
クライアント
プログラムプログラム
KVS/ドキュメントDB
シャードシャードシャード
A
クエリルータ
B C
アプリケー
ション２
アプリケー
ション１
 Hadoop

 分散しやすいデータモデル
 データ間の参照関係を定義させない
 分散しやすいクエリ
 一つのデータでクエリが完結するようにする
• トランザクションを提供しない
• (トランザクショナルな)JOINを提供しない
30
ユーザ１
取引１
取引２
ユーザ１取引１
取引２

 大規模Webのバックエンド
• ユーザセッションの格納
• ユーザ属性格納
• 事前計算データのキャッシュ
 メッセージングシステム
 大量書き込みが必要なケース(IoT)
 できないこと
 トランザクション
 集計
 JOIN
 セカンダリインデックスが無いものもある
31

ドキュメントDB
32
DB
Hadoop
RDB(OLTP)
KVS
RDB(DWH)

BIG DATA Department
オン
プレ
クラ
ウド
ドキュメントDB
33
 KVSよりもクエリが豊富で使いやすい
 アーキテクチャ上の特徴
 データモデルにJSONを扱う
 集計を提供している物が多い

BIG DATA DepartmentドキュメントDB
 分散処理を活かしたユースケース
 大規模Webのバックエンド
 オンラインゲーム
 カタログ管理
 JSONを使いたいだけのユースケース ←日本ではこちらが多い
 プロトタイプ開発
 データハブ
 JSONログ保管
34

 ドキュメントDBの集計機能は「おまけ」！
 小規模データの同期集計はできるが、バッチには不向き
 BIベンダはドキュメントDBは相手にしていない
 ベンダ
「ACIDトランザクションを提供するドキュメントDBです！」
 →何かを犠牲にしています
 非構造データ処理と半構造データ処理は違う
 半構造データ＝JSON,XML
 非構造データ＝自然言語、音声、画像、動画 →パーサー次第
35

BIG DATA Department伝えたいこと NoSQLはバズワード
 NoSQL ≠ スキーマレス
 スキーマ定義が必須
 ドキュメントバリデーション機能あり
 NoSQL ≠ SQLが使えない
 SQLライクなクエリ言語を採用しているNoSQL
 NoSQL ≠ 分散処理
 JSONが入るRDB
36

その他のビッグデータキーワードの説明
37

BIG DATA DepartmentSpark
 データサイエンティストのために作られた分析ライブラリ群
 Hadoopが無くても動く
 データベースではない
 データ蓄積はHadoopのHDFSでもよいし、そうでなくても良い
 以下の様なものが含まれる
 Spark 本体：メモリベースで集計などをする
 Spark MLLib：機械学習
 Spark SQL：SQLライクなインターフェース
 Spark Stream：マイクロバッチ
38

BIG DATA Departmentマイクロバッチ
 続々と流れてくるデータに対して、短い期間で集計を行う処理
 データベースではない。データを永続化しない。
 使いドコロ
 初回来訪者の属性推定
 デバイス異常値検出
39
Kinesis
Analytics
Kinesis
Streams
マイクロバッチ
マイクロバッチ
PUB
（出版)
SUB
(購読)
分散キュークライアント
クライアント
クライアント
クライアント

BIG DATA Department
ディスク
ディスク
インメモリデータグリッド
 KVSに似ているが、アプリケーションのローカルに置かれるキャッシュ
 メモリ上での処理を前提として、永続化はオプション
 金融の取引処理
 ミリ秒以下の応答時間
40
JavaアプリインメモリDB
JavaアプリインメモリDB
メモリ
同期

BIG DATA DepartmentElasticsearch
 検索エンジン
 ドキュメントデータベースに非常に近い
 JSONが入る
 レプリケーションできる
 シャーディング出来る
 ドキュメントデータベースとの違い
 Kibanaと連携できる
 全文検索が強力
 かなり集計できる
41
Elasticsearch Service
Kibana

BIG DATA DepartmentグラフDB
 グラフ演算に特化したDB
 RDB以上にスケールアウトできない
 最短経路探索
 金融取引の詐欺検出
 ソーシャルネットワークにおける人物間の計算
 RDBだとJOINの多重入れ子になるような計算
42

BIG DATA Department【急遽追加！】ブロックチェーン
 分散KVS
 台帳をP2Pで共有
 トランザクション提供
 コミットは、因数分解を最初に説いた人がみんなのトランザクションをまと
めてコミット
→つまり非常に遅い
43

BIG DATA Department【急遽追加！】分散OLTP
 今朝の神林さんの発表を聞いて急遽追加
 10万TPS
 前提とするHW:1000コア、10TBメモリ、高速バス
 既存のRDB(OLTP)とはアーキテクチャが異なる
44

BIG DATA Departmentデータベースの分類追記版
45
DB
(
)
)
RDB(OLTP)
KVS
ElasticSearch
Hadoop
RDB(DWH)
OLTP

BIG DATA Departmentデータベースの分類
46
DB
( ) )
RDB(OLTP)
KVS
RDB(DWH)
DynamoDB
BigQuery
Exadata
EMR
Hadoop
Kinesis
ブランド
Redshift
OLTP
Exadata

 IoTのデバイスログ収集はKVSが最適ではない
 書き込みは多いが、オペレーショナルではないため
 やりたいことは分析
 IoTはデバイスログ収集は
マイクロバッチ＋ Hadoop or RDB(DWH) が最適
47

リクルートテクノロジーズビッグデータ部における使い分け
48

BIG DATA Departmentリクルートテクノロジーズビッグデータ部での活用
49
DB
( ) )
RDB(OLTP)
KVS
RDB(DWH)
DynamoDB
BigQuery
Exadata
EMR
Hadoop
DB
Kinesis
ブランド
Redshift
OLTP

BIG DATA Departmentリクルートテクノロジーズビッグデータ部での活用
 リクルートのサービス
 ビジネスモデル
 「リボンモデル」
50
カスタマ
（ユーザ）
クライアント
（企業）
 主業務
 分析
• KPIの測定
• 競合分析
 施策
• マッチング
• ユーザ属性推定
• レコメンデーション
• ターゲッティング
 適材適所で高速にインプリ
・・・１００以上のサービス

 Hadoopの用途
 マッチング
 ユーザの属性推定
 レコメンデーション
 RDB(DWH)へのデー
タ事前加工
51
EMR
Impala
安定したオンプレ
Hadoop基盤
SQLベースで充分
リッチなUIを利用したい常時起動が必要ない
キャパシティが読めない
AWSが前提
最新技術の積極利用
計算

BIG DATA DepartmentRDB(DWH)
 RDB(DWH)の用途
 SQLベースの分析
 KPIの測定
 競合分析
 サイトアクセス解析
 加工済みデータをBIから
接続して自由に分析して
もらう
52
Exadata
Redshift
BigQuery
Impala
コストパフォーマンスがよい
金がある
オンプレから出せない
開発ツールの充実
Oracleとの連携
Hadoopにあるデータを
そのまま分析したい
＋
無限のスケーラビリティ

BIG DATA Departmentマイクロバッチ
 マイクロバッチの用途
 初回訪問ユーザの属性推定して、パーソナライゼーション
53
Kinesis
Analytics
Kinesis
Stream
＋
＋

BIG DATA DepartmentKVS ドキュメントDB グラフDB
 機械学習結果をWebフロントに返す
 アプリケーションの途中結果格納
 アプリケーションのプロトタイプ開発
 地理空間情報(GeoJSON)蓄積・加工
 ユーザと企業のマッチングに、駅のグラフデータを利用
54
DynamoDB

エンジニア募集中！
ベンチャーマインドあふれるリクルートで、
次々と溢れ出る新規ビジネスのアイデアを
高速にインプリしてみませんか？
適材適所でシステムを構築しましょう
55

まとめ
56

BIG DATA Departmentまとめ
 この図を頭に入れておくと、新しいデータベースが出てきても
なんとなくわかります
57
57
DB
( ) )
RDB(OLTP)
KVS
ElasticSearch
Hadoop
RDB(DWH)
OLTP

ビッグデータ処理データベースの全体像と使い分け

More Related Content

What's hot

Viewers also liked

Similar to ビッグデータ処理データベースの全体像と使い分け

More from Recruit Technologies

Recently uploaded

ビッグデータ処理データベースの全体像と使い分け