BlinkDB: Queries with Bounded Errors and Bounded Response Times on Very Large Data (EuroSys'13, Best paper) の紹介

1. 論文紹介
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回 システム系論文輪読会

2. 自己紹介
Masafumi Oyamada (@stillpedant / id:mooz)
普段はデータベースの研究をしています
 Query Optimization
 Indexing
 DB w/ Machine Learning
趣味でコードを書いています
 http://github.com/mooz

3. 論文の紹介に入る前に – AMPLab について
AMPLab – BlinkDB を生み出した UCB の研究室
 データベース、システム、機械学習などの分野におけるビッグネー
ムが多数在籍
 データ分析の上から下まで、各レイヤでトップレベルの研究
 リソース仮想化、分散ストレージ、問合せエンジン、データ分析技術
 OSS として研究成果を公開することに積極的
AMPLab 発の技術
 Apache Spark
 Apache Mesos
 GraphX
 Sparrow
 CrowdDB
今最もアツい “システム系” 研究室のひとつ！

4. 本日ご紹介するもの - 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 の論文をベースにご紹介

5. 背景: 巨大データに対するクエリが遅い！
SELECT AVG(jobtime)
FROM very_big_log
WHERE src = ‘hadoop’
「Hadoop のジョブ実行時間の平均値を
超巨大なログに対して計算したい」
遅すぎて結果が全然返ってこない orz

6. BlinkDB なら、すぐに結果を返せます
234.23 ± 15.32
「とりあえずざっくりした値が知りたいから、
２秒以内に結果を返して」
SELECT AVG(jobtime)
FROM very_big_log
WHERE src = ‘hadoop’
WITHIN 2 SECONDS
指定した時間内に、誤差の保証付きで結果を返してくれる！

7. キーとなる技術: データのサンプリング
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
誤差（真の結果からのズレ）

8. BlinkDB はサンプリングを活用
データを“事前に”様々なサイズでサンプリングしておく
 クエリが来たら、ユーザの指定した“制約”を達成するのに適したサ
ンプリング結果を選び、そいつに対してクエリを実行
元のテーブル
小さなサイズでのサンプリング
 処理は速いが誤差は大きい
大きなサイズでのサンプリング
 処理は遅いが誤差は小さい

9. 制約に応じて、適切なサイズのサンプルを選ぶ
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
誤差
誤差
“１秒以内に処理して”
“10秒以内に処理して”
小さなサンプルを選択
大きなサンプルを選択

10. ユーザの指定可能な制約
処理時間: 「処理は絶対５秒以内に終わらせて」
最大誤差: 「処理結果が 95% の確信度で正確な値から最大
でも 10% までしかズレないことを保証して」

11. 最大誤差: 中心極限定理から導ける
特徴: 誤差は元のデータ（母集団）の数ではなく、サンプル
したデータの数 𝒏 に左右される！
 つまり、サンプル数 𝑛 が直に誤差に影響する

12. サンプリングについて
サンプリング？
データをランダムサンプリングして、
その結果に対して元々のクエリを実行
すればいいんじゃないの？
そんなに単純な話ではない

13. ランダムサンプリングの問題
データの分布に偏りがあると、うまく動かない
 データ数が少ないグループの値を“軽視”してしまう
  “川崎” についてはほとんどサンプリングされないので、サンプル
数が少なくなり、誤差が大きくなってしまう！
 中心極限定理を思い出す（サンプル数が少ない  誤差がデカい）
川崎 東京 横浜
Group By “居住地”
レコード数

14. BlinkDB は Stratified Sampling を利用
Stratified Sampling: データの分布に応じたサンプリング
 データ数の少ないグループは重点的にサンプリング
 どのグループも同程度にサンプリングされ、グループによる誤差の
バラつきがなくなる
川崎 東京 横浜
Group By “居住地”
レコード数
川崎 東京 横浜
Group By “居住地”
レコード数

15. 問題: Stratified Sampling は “グループ毎” に必要
クエリの Group-by 属性によって、得られるグループ（の
分布）は異なる
Group By の属性ごとに、別々に Stratified Sampling を
した結果を保持しておく必要がある
 つまり、あらかじめユーザが実行しそうなクエリの Group-by 属性
について、事前にサンプリングをやっておく必要がある！
川崎 東京 横浜
Group By “居住地”
男性 女性
Group By “性別”
レコード数
レコード数

16. 問題: どの属性で Stratified Sampling する？
課題: すべての属性（カラム）について Stratified
Sampling するのは現実的でない
 大量のサンプルが出来てしまい、ストレージを喰いまくるので
アプローチ: “どのカラムについてサンプルを作成すればよ
いか”を最適化問題として定義し、解く
 混合整数計画問題になるので、ソルバで解く！
詳細は論文参照（逃げ）
C: ストレージ容量

17. というわけで、やっと BlinkDB のアーキテクチャ
(1) データを事前に Stratified Sampling しておくモジュール
少ないサンプル量で高い精度を得ること（高速化）を実現
(2) クエリの実行に必要なサンプルを選ぶモジュール
ユーザの指定した制約（時間、精度）を満たすのに最も
適切なサイズのサンプルを選択する

18. 実装  Hive を改変
17 TB のデータに対するクエリ 90-98% の精度で 2 秒で
返した
 従来の Hive/Hadoop と比べると二桁は高速

19. まとめ
 最適化問題を解くことで“よい” 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 化できる
ことをきちんと示した

20. 参考: サンプリングベースの 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]
（この場合、事前にサンプリングをしておく必要もない）