Your SlideShare is downloading. ×

BlinkDB 紹介

140

Published on

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

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

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
140
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 「とりあえずざっくりした値が知りたいから、 2秒以内に結果を返して」 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 誤差 誤差 “1秒以内に処理して” “10秒以内に処理して” 小さなサンプルを選択 大きなサンプルを選択
  • 10. ユーザの指定可能な制約 処理時間: 「処理は絶対5秒以内に終わらせて」 最大誤差: 「処理結果が 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] (この場合、事前にサンプリングをしておく必要もない)

×