BlinkDB 紹介

BlinkDB 紹介

• 1.
  論文紹介 BlinkDB: Queries withBounded 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) FROMvery_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-110-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 WHEREcity=‘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 は StratifiedSampling を利用 Stratified Sampling: データの分布に応じたサンプリング  データ数の少ないグループは重点的にサンプリング  どのグループも同程度にサンプリングされ、グループによる誤差の バラつきがなくなる 川崎 東京 横浜 Group By “居住地” レコード数 川崎 東京 横浜 Group By “居住地” レコード数
• 15.
  問題: Stratified Samplingは “グループ毎” に必要 クエリの Group-by 属性によって、得られるグループ（の 分布）は異なる Group By の属性ごとに、別々に Stratified Sampling を した結果を保持しておく必要がある  つまり、あらかじめユーザが実行しそうなクエリの Group-by 属性 について、事前にサンプリングをやっておく必要がある！ 川崎 東京 横浜 Group By “居住地” 男性 女性 Group By “性別” レコード数 レコード数
• 16.
  問題: どの属性で StratifiedSampling する？ 課題: すべての属性（カラム）について Stratified Sampling するのは現実的でない  大量のサンプルが出来てしまい、ストレージを喰いまくるので アプローチ: “どのカラムについてサンプルを作成すればよ いか”を最適化問題として定義し、解く  混合整数計画問題になるので、ソルバで解く！ 詳細は論文参照（逃げ） C: ストレージ容量
• 17.
  というわけで、やっと BlinkDB のアーキテクチャ (1)データを事前に Stratified Sampling しておくモジュール 少ないサンプル量で高い精度を得ること（高速化）を実現 (2) クエリの実行に必要なサンプルを選ぶモジュール ユーザの指定した制約（時間、精度）を満たすのに最も 適切なサイズのサンプルを選択する
• 18.
  実装  Hiveを改変 17 TB のデータに対するクエリ 90-98% の精度で 2 秒で 返した  従来の Hive/Hadoop と比べると二桁は高速
• 19.
  まとめ  最適化問題を解くことで“よい” Stratifiedsample 群を作成す る方式を提案した  ※ これまでのサンプリングベースのシステムはテーブルごとに“ひとつ の”サンプルしかつくらなかった (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] （この場合、事前にサンプリングをしておく必要もない）