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

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

BIG DATA Department自己紹介
{"ID" ："fetaro"
"名前"："渡部徹太郎"
"研究"："東京工業大学でデータベースと情報検索の研究
(@日本データベース学会)"
"仕事"：{前職:["証券会社のオンライントレードシステムのWeb基盤",
"オープンソースなら何でも。主にMongoDB,NoSQL"],
現職:["リクルート分析基盤,Exadata,Hortonworks,EMR"]
副業:["MongoDBコンサルタント" ]}
"エディタ"："emacs派",
"趣味"： ["自宅サーバ","麻雀"]
}
1

BIG DATA Departmentリクルートテクノロジーズビッグデータ部
 リクルートのサービス
 ビジネスモデル
 「リボンモデル」
2
カスタマ
（ユーザ）
クライアント
（企業）
 主業務
 分析：KPIの測定/競合分析
 施策：マッチング/ユーザ属性推
定/ターゲッティング
 ミッション
 ビッグデータ処理を駆使して
売上向上・コスト削減
 いろんなユースケースに併せて
適材適所の基盤を用意
・・・１００以上のサービス

BIG DATA Department発表をしようと思った背景
 適材適所をするためには、ビッグデータ処理技術全体を把握必要がある
3
Amazon
DynamoDB
Kinesis
Amazon
EMR
Amazon
Redshift
Google
BigQuery
Oracle
Exadata
Impala
Google
Cloud Spanner
Cloud
Dataproc
Azure
HDInsight

BIG DATA Department目次
1. データベースの分類
2. データベースの紹介
3. その他のビッグデータキーワードの説明
4. リクルートテクノロジーズにおける使い分け
5. まとめ
4

5

BIG DATA Departmentデータベースを分類する軸：重視する性能
6
 レスポンスを重視
 主にオペレーション用途
 少量のデータに対するランダムアクセス
 行志向アクセス
アプリケーションサーバ
オペレーション
用途
データベース
登録画面
リクエスト参照
更新
挿入
参照画面
編集画面
即時応答
1 1982年生
2 1967年生
3 2000年生
4 2000年生
男
女
女
男
ID 年齢性別
ID=2のデータを取り出すのは高速
年齢の集計は低速
1 1982年生男 2 1967年生女 3 2000年生女 4 2000年生男
1 2 3 4
index
この方向のアクセスが高速
インデックス
ディスク上の配置

BIG DATA Departmentデータベースを分類する軸：重視する性能
7
 スループットを重視
 主に分析用途
 大量のデータに対するレンジアクセス
 列志向アクセス
マスタ
データベース
ＢＩツール
集計
バッチ
ロード
分析用途
データベース
レポート生成
ジョブ
抽出
ＣＳV
バッチ
ロード
レポート
２０分で全件集計
１０秒で全件取得
1 1982年生
2 1967年生
3 2000年生
4 2000年生
男
女
女
男
ID 年齢性別
メモリ
性別
男女
1男 4 女 1982年生 1967年生 2000年生1 2 3 42 3
年齢
1982年生 1967年生 2000年生
ディスク上の配置この方向のアクセスが高速
ID=2のデータ取り出すのは低速
年齢の集計は高速
インデックス

BIG DATA Department
 スケールアップ型(整合性重視)
 ハードウェアのスペックを向上させる
 トランザクションの提供など、強い整合性を提供するために、
スケールアップせざるを得ない
 特別なハードウェアが必要になり、一般的に高価
データベースを分類する軸：性能向上の方法
8
app app app
app app app
スケールアップ
性能限界
CPU↑
ディスク↑
メモリ
N/W↑
1 2
3 4
1 2
3 4
5 6
7 8

BIG DATA Department
 スケールアウト型（拡張性重視）
 一般的なハードウェアを複数台用意し、負荷を分散
 結果整合性。トランザクションは提供しない。
データベースを分類する軸：性能向上の方法
9
スケールアウト性能限界
app app app
1 2
3 4
app app app
1 2
3
5
6
7 84
Master

BIG DATA Departmentデータベースの分類
10
レスポンス重視
(オペレーション用途)
スループット重視
（分析用途)
スケールアップ（整合性重視）
RDB(OLTP)
NoSQL Hadoop
RDB(DWH)
スケールアウト（拡張性重視）

BIG DATA Department
BigQuery
データベースの分類
11
オペレーション用途
分析用途
DynamoDB
Redshift
EMR
Exadata
Athena
RDS
RDB(OLTP)
NoSQL
Hadoop
RDB(DWH)
スケールアウト
Cloud
Dataproc
Azure
HDInsight
Azure
SQL Database
Cloud Spanner

BIG DATA Department
BigQuery
データベースの分類
12
オペレーション用途
分析用途
DynamoDB
Redshift
EMR
Exadata
Athena
RDS
RDB(OLTP)
NoSQL
Hadoop
RDB(DWH)
Cloud
Dataproc
Azure
HDInsight
Azure
SQL Database
Cloud Spanner
越えられない壁
BigDataの事例の大半はココ

RDB(DWH)
13
オペレーション分析用途
RDB(OLTP)
NoSQL
Hadoop
RDB(DWH)
BigQuery
Cloud Spanner

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

BIG DATA DepartmentRDB(DWH)の用途
 処理イメージ
 レスポンス：数秒、数分
 データサイズ：直近１３ヶ月（1T〜数10T)
 計算：SQLベース
 UPDATE,DELETE,トランザクションはできるが遅い
 ユースケース
 アドホック分析、OLAP
 レポート
 BIツールのデータソース
 EDW(Enterprise Data Warehouse)ともよばれる
15

BIG DATA Department
ストレージノードストレージノードストレージノード
RDB(DWH)の注目プロダクト (1/2)
 Oracle Exadata
 ソフトウェアとハードウェアを密結合して、高いパフォーマンスを発揮
 基本はオペレーション用途だが、分析もできる
• →「二兎追うものは一兎も得ず」な部分はある
16
データベースノード
HDD
SSD
絞込み処理
HDD
HDD HDD
HDD
SSD
絞込み処理
HDD
HDD HDD
HDD
SSD
絞込み処理
HDD
HDD HDD
データベースノード
CPU
WHERE句を解釈し、
読み込むブロックを最小化
ディスクIOを削減
キャッシュして
ディスクIOを削減
CPUを多数搭載
40Gbpsのラック内SAN
CPU CPUCPU CPU CPU
40G bps

BIG DATA DepartmentRDB(DWH)の注目プロダクト (2/2)
 Amazon Redshift Spectrum
 RedShiftの裏にS3のデータをフィルタするSpectrum Layerを用意
 IOのスループットを向上
17
Spectrum Layer
(不可視領域)
Data
Catalog
L C
C
C
SQL
S3 Get
S
S
S
S
・
・
・
S3
RedShift

Hadoop
18
RDB(OLTP)
Hadoop
RDB(DWH)
BigQuery
NoSQL
Cloud Spanner

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

BIG DATA DepartmentHadoopのプロダクト
 SQL on Hadoopとは
 Hadoop上の分散集計を
SQLで表現できる
 基本はSELECTとLOAD
のみ
 UPDATE,DETELEは出
来ない
 トランザクションがない
20
プロダクト分散ファイルシ
ステム
分散処理エンジン
オンプレ
MapR-FS
マネージ
ド
Hadoop
クエリ
サービス
EMR S3 Impala
Cloud
Dataproc GCS
Athena
SQL on Hadoop
S3
Azure BLOB
Storage
Azure
HDInsight

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

BIG DATA DepartmentクラウドのHadoop
 特徴
 分散処理エンジンとストレージの分離
 データはオブジェクトストレージに格納
 計算ノードは使い捨て。
負荷に応じて計算ノードの台数変更
 Hortonworks, Clouderaも対応
22
Slave Slave Slave
HDFS(MapR-FS) オブジェクトストレージ
Master
データデータ
コンテナ
データデータ
コンテナ
データデータデータデータ
計算
コンテナ
Master
コンテナ
計算
コンテナ
計算
コンテナ
オンプレのHadoop クラウドのHadoop
NEWNEW
データ移動
が必要
データ移動
不要
0:00 12:00 0:00 12:00
ク
ラ
ス
タ
起
動
台
数
オンプレ
クラウド
計算に必要なリソース

BigQuery
23
RDB(OLTP)
Hadoop
RDB(DWH)
BigQuery
NoSQL
Cloud Spanner

BIG DATA DepartmentBigQuery
 BigQueryとは
 GoogleがHadoop(Hive)を進化させて作った分散SQLエンジン
 クエリ課金
 速度が別格（1TBを1秒でスキャン）
 GROUP BYやJOIN等の重い処理は、処理量に合わせて計算ノードを動
的に割り当てて実行。利用できるノードは1000台
24
分散ストレージ Colossus File System
シャードシャードシャードシャードシャード
ミキサーミキサーミキサー
ルート
ミキサー
参考)オライリー・ジャパン社「BigQuery」

NoSQL
25
RDB(OLTP)
Hadoop
RDB(DWH)
BigQuery
NoSQL
Cloud Spanner

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

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

BIG DATA DepartmentNoSQLがなぜスケールできるか
 レガシーな手法(2PC)では整合性を保証するとスケールアウトが困難
 整合性を緩めればスケールアウトできる
28
アプリケーションアプリケーション
整合性は
保証される
②準備Ｏ
Ｋ
④コミッ
ト
②準備Ｏ
Ｋ
④コミッ
ト
②準備Ｏ
Ｋ
④コミッ
ト
①コミット準備の確認
③コミット指示
アプリケーション
待たされ
る
ＡＢＣ
分散トランザクションで
ＡＢＣを一括更新
待たされ
る
待たされる
スケールアウト構成
更新
一括更新はできないので
Ａ→Ｂ→Ｃの順番で更新
ＡＢＣ
更新
更新
更新
更新
待たない
更新更新
割り込まれて
整合性が
崩れる
可能性あり

BIG DATA DepartmentNoSQLとHadoopの違い
 NoSQL
29
分散ファイルシステム
(HDFS等)
分散処理フレームワーク
(MapReduce, Spark等)
ABC
A B C
クライアント
計算
ノード
計算
ノード
計算
ノー
コーディネータ
①データの配
②提出
③計算
計算
結果
プログラム
プログラム
クライアント
プログラムプログラム
NoSQL
シャードシャードシャード
A
クエリルータ
B C
アプリケー
ション２
アプリケー
ション１
クエリA
クエリB
 Hadoop

BIG DATA DepartmentNoSQLの用途
 大規模Webのバックエンド
• ユーザセッションの格納
• ユーザ属性格納
• 事前計算データのキャッシュ
 メッセージングシステム
 できないこと
 トランザクション
 集計
 JOIN
 セカンダリインデックス（無いものもある）
30

BIG DATA DepartmentNoSQLはバズワード
 NoSQL ≠ スキーマレス
 スキーマ定義が必須
 ドキュメントバリデーション機能あり
 NoSQL ≠ SQLが使えない
 多くのNoSQLはSQLライクなクエリ言語を採用
 NoSQL ≠ スケールアウト
 JSONが入るRDBはたくさんある
31

Google Cloud Spanner
32
RDB(OLTP)
Hadoop
RDB(DWH)
BigQuery
NoSQL
Cloud Spanner

BIG DATA DepartmentGoogle Cloud Spanner
 一言で言うと
 トランザクションを提供でき、かつワールドワイドで分散できるRDB
 どうやっているか
 トランザクションで「読み取り専用」か「ロック型読み書き」を宣言
 読み取り専用の場合は、ロックを取らず、タイムスタンプで読むデータを判断す
る
 ノード間で時刻を正確に同期する必要があるが、それは不可能
 代わり、コミットを待つこと(よりロックを長くとる)により、
ノード間の時間の差を吸収できるよう待つにする
 各データセンタに電子時計を配置し、ノード間の時刻の差を最小化
→コミットの待ち時間を最小化
33
tx2
tx1
tx3
t
tx1完了時点のタイムスタンプの
データを読み取る

34

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

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

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

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

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

BIG DATA Departmentその他のビッグデータキーワードをマッピングすると
40
(オペレーション用途)
（分析用途)
RDB(OLTP)
NoSQL
グラフデータベース
マイ
クロ
バッ
チElasticSearch
インメモリ
データ
グリッド
Hadoop
RDB(DWH)
BigQueryCloud Spanner

4.リクルートテクノロジーズにおける使い分け
41

BIG DATA Departmentビッグデータ処理の主な活用先
 データドリブンな意思決定支援
 KPIの測定
 レポート
 Webマーケティング
 ターゲティングメール/広告
 UI改善
 画面のパーソナライズ
 アイテムのレコメンド
42

BIG DATA Departmentデータドリブンな意思決定支援
 目的
 KPIを測定するために、データを集計する
 DBの要件
 BIツールとの接続
 アドホックな分析クエリがメイン
 SQLによる集計がメイン
 SLAは低い：停止しても直接的な利益影響なし
 選択
 BI接続、アドホック分析はBigQuery
 データ前処理・加工・マート作成はHadooop
43
Amazon
Redshift Impala← ← ← ←BigQuery
15ヶ月分(１年＋1四半期)の
データに対する
数秒〜数分のクエリ

BIG DATA Department
 目的
 個人に最適化されたメール/広告を出すことにより、集客コストを下げる
 DBの要件
 統計解析・機械学習が出来る
 バッチ処理がメイン
 SLAは高い：メール・広告が出せないと売上棄損が有る可能性がある
 選択
 豊富な計算力を求める場合はHadoop
 特に高いSLAを求める場合かつ SQLで十分ならばRDB(DWH)
Webマーケティングターゲティングメール・広告
44
EMR
Exadata

BIG DATA DepartmentUI改善
 目的
 個人の属性を推定して、UIをパーソナライズし、コンバージョンレートを上げる
 DBの要件
 統計解析・機械学習が処理できること
 バッチ処理メイン
 計算した推定結果を、Webサイトに提供する
 SLAは中程度：バッチに失敗した場合ユーザ推定の精度が下がる
 選択
 ユーザ推定計算はHadoop
 Webサイトへの提供はNoSQL
45
EMR
DynamoDB
Kinesis
Streams
Cloud PubSub
 ユーザの滞在中にアクションする場
合はマイクロバッチ

5. まとめ
46

BIG DATA Departmentまとめ
 スケールアウト／スケールアップ
 オペレーション用途／分析用途 →越えられない壁
2. データベースの紹介
 RDB(DWH),Hadoop,NoSQLの代表プロダクトを説明
 Google製の飛び抜けた二つのプロダクトを説明
 Spark／マイクロバッチ／インメモリデータグリッド／Elastic／グラフDB
4. リクルートテクノロジーズにおける使い分け
 ３つの代表的なユースケースに対して、DBの選択を説明
47

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (15)

Similaire à ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -

Similaire à ビッグデータ処理データベースの全体像と使い分け - 2017年 Version - (20)

Plus de Tetsutaro Watanabe

Plus de Tetsutaro Watanabe (18)

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