blinkdb 紹介
TRANSCRIPT
論文紹介
BlinkDB: Queries with Bounded Errors and
Bounded Response Times on Very Large Data
Sameer Agarwal, BarzanMozafari, Aurojit Panda,HenryMilner,
Samuel Madden, Ion Stoica (UCB, MIT, Conviva)
Masafumi Oyamada / @stillpedant
Some figures and examples are gratefully copied from original paper/slides
第5回 システム系論文輪読会
自己紹介
Masafumi Oyamada (@stillpedant / id:mooz)
普段はデータベースの研究をしています
Query Optimization
Indexing
DB w/ Machine Learning
趣味でコードを書いています
http://github.com/mooz
論文の紹介に入る前に – AMPLab について
AMPLab – BlinkDB を生み出した UCB の研究室 データベース、システム、機械学習などの分野におけるビッグネームが多数在籍
データ分析の上から下まで、各レイヤでトップレベルの研究
リソース仮想化、分散ストレージ、問合せエンジン、データ分析技術
OSS として研究成果を公開することに積極的
AMPLab 発の技術
Apache Spark
Apache Mesos
GraphX
Sparrow
CrowdDB
今最もアツい “システム系” 研究室のひとつ!
本日ご紹介するもの - BlinkDB
BlinkDB とは
UCB AMPLab で研究されている SQL 処理系
「精度を犠牲にし高速に処理結果を返す」というコンセプトがウケて、一世を風靡
BlinkDB に関する論文
[Agarwal, NSDI’12 (Extended Abstract)] BlinkDB: Queries with
Bounded Errors and Bounded Response Times on Very Large Data
[Agarwal, VLDB’12 (Demo)] Blink and It’s Done: Interactive
Queries on Very Large Data
[Agarwal, EuroSys’13] BlinkDB: Queries with Bounded Errors
and Bounded Response Times on Very Large Data
[Agarwal, SIGMOD’14] Knowing When You’re Wrong: Building Fast
and Reliable Approximate Query Processing Systems
[Kleiner , KDD’14] A General Bootstrap Performance Diagnostic
本日は EuroSys’13 の論文をベースにご紹介
背景: 巨大データに対するクエリが遅い!
SELECT AVG(jobtime)FROM very_big_logWHERE src = ‘hadoop’
「Hadoop のジョブ実行時間の平均値を超巨大なログに対して計算したい」
遅すぎて結果が全然返ってこない orz
BlinkDB なら、すぐに結果を返せます
234.23 ± 15.32
「とりあえずざっくりした値が知りたいから、2秒以内に結果を返して」
SELECT AVG(jobtime)FROM very_big_logWHERE src = ‘hadoop’WITHIN 2 SECONDS
指定した時間内に、誤差の保証付きで結果を返してくれる!
キーとなる技術: データのサンプリング
0
100
200
300
400
500
600
700
800
900
1000
1 10-1 10-2 10-3 10-4 10-5
サンプリング後のデータ量(元データ比)
クエリの実行時間
103
18 13 10 8
(0.02%)
(0.07%) (1.1%) (3.4%) (11%)
データをサンプリングすると、実行時間は大幅に減る。一方で、誤差はそれほど大きくならない。
1020
誤差(真の結果からのズレ)
BlinkDB はサンプリングを活用
データを“事前に”様々なサイズでサンプリングしておく クエリが来たら、ユーザの指定した“制約”を達成するのに適したサンプリング結果を選び、そいつに対してクエリを実行
元のテーブル
小さなサイズでのサンプリング 処理は速いが誤差は大きい
大きなサイズでのサンプリング 処理は遅いが誤差は小さい
制約に応じて、適切なサイズのサンプルを選ぶ
SELECT avg(sessionTime)
FROM Table
WHERE city=‘San Francisco’
WITHIN 1 SECONDS 234.23± 15.32
SELECT avg(sessionTime)
FROM Table
WHERE city=‘San Francisco’
WITHIN 10 SECONDS 239.46± 1.12
誤差
誤差
“1秒以内に処理して”
“10秒以内に処理して”
小さなサンプルを選択
大きなサンプルを選択
ランダムサンプリングの問題
データの分布に偏りがあると、うまく動かない
データ数が少ないグループの値を“軽視”してしまう
“川崎” についてはほとんどサンプリングされないので、サンプル数が少なくなり、誤差が大きくなってしまう!
中心極限定理を思い出す(サンプル数が少ない 誤差がデカい)
川崎 東京 横浜
Group By “居住地”
レコード数
BlinkDB は Stratified Sampling を利用
Stratified Sampling: データの分布に応じたサンプリング
データ数の少ないグループは重点的にサンプリング
どのグループも同程度にサンプリングされ、グループによる誤差のバラつきがなくなる
川崎 東京 横浜
Group By “居住地”
レコード数
川崎 東京 横浜
Group By “居住地”
レコード数
問題: Stratified Sampling は “グループ毎” に必要
クエリの Group-by 属性によって、得られるグループ(の分布)は異なる
Group By の属性ごとに、別々に Stratified Sampling をした結果を保持しておく必要がある つまり、あらかじめユーザが実行しそうなクエリの Group-by 属性について、事前にサンプリングをやっておく必要がある!
川崎 東京 横浜
Group By “居住地”
男性 女性
Group By “性別”
レコード数
レコード数
問題: どの属性で Stratified Sampling する?
課題: すべての属性(カラム)について Stratified
Sampling するのは現実的でない 大量のサンプルが出来てしまい、ストレージを喰いまくるので
アプローチ: “どのカラムについてサンプルを作成すればよいか”を最適化問題として定義し、解く 混合整数計画問題になるので、ソルバで解く!
詳細は論文参照(逃げ)
C: ストレージ容量
というわけで、やっと BlinkDB のアーキテクチャ
(1) データを事前に Stratified Sampling しておくモジュール少ないサンプル量で高い精度を得ること(高速化)を実現
(2) クエリの実行に必要なサンプルを選ぶモジュールユーザの指定した制約(時間、精度)を満たすのに最も適切なサイズのサンプルを選択する
まとめ
最適化問題を解くことで“よい” Stratified sample 群を作成する方式を提案した ※ これまでのサンプリングベースのシステムはテーブルごとに“ひとつの”サンプルしかつくらなかった (AQUA [6], STRAT [10])
BlinkDB は以下を考慮して最適な stratified sample を算出
(i) the frequency of rare subgroups in the data
(ii) the column sets in the past queries
(iii) the storage overhead of each sample
エラーとレイテンシの関係をプロファイルする方法を提案 各サンプル(異なる stratified sample されたもの)毎に、クエリを実行した際の誤差 or レイテンシを見積もるためのプロファイルを作成
ユーザの指定した誤差 / レイテンシ制約を満たすため、最も適したサンプルを選ぶためにつかわれる
Hive などの既存のシステムを少ない拡張で BlinkDB 化できることをきちんと示した
参考: サンプリングベースの DB のカテゴライズ
完全に将来のクエリがわかってる場合そのクエリに特化したデータを保持しておける
Lossless synopsis [12], Lossy sketch [14]
過去の Predicate の頻度を確認し、その確率で将来にも同じクエリが来ると予測。Predicate にマッチする tuple 群がわかるので、そこからサンプリングして保持しておく
START [10], SciBORQ [21]
Group-by/Where に登場するカラム群は仮定するが、その値までは仮定しないBlinkDB, AQUA [4], OLAP 高速化[20]
クエリを全く仮定しない賢いサンプリングはできず、ランダムサンプリングをすることになるHellerstein の Online Aggregation [15]
(この場合、事前にサンプリングをしておく必要もない)