blinkdb 紹介

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

Upload: masafumi-oyamada

Post on 29-Jul-2015

2.240 views

Category:

Technology


0 download

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秒以内に処理して”

小さなサンプルを選択

大きなサンプルを選択

ユーザの指定可能な制約

処理時間: 「処理は絶対5秒以内に終わらせて」

最大誤差: 「処理結果が 95% の確信度で正確な値から最大でも 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) クエリの実行に必要なサンプルを選ぶモジュールユーザの指定した制約(時間、精度)を満たすのに最も適切なサイズのサンプルを選択する

実装 Hive を改変

17 TB のデータに対するクエリ 90-98% の精度で 2 秒で返した 従来の Hive/Hadoop と比べると二桁は高速

まとめ

最適化問題を解くことで“よい” 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]

(この場合、事前にサンプリングをしておく必要もない)