BlinkDB: Queries with Bounded Errors and Bounded Response Times on Very Large Data Authored by Sameer Agarwal, et. al. Presented by Atul Sandur

Motivation 2 Traditional SQL queries Can we support interactive SQL-like aggregate queries over massive datasets?

Motivation 100 TB on 1000 machines 3 Query execution on samples of data ½ - 1 Hour1 - 5 minutes1 second ?

Query Execution on Samples What is the average latency in the table? IDCityBuff Ratio Sampling Rate 2NYC381/2 3SLC341/2 5SLC371/2 7NYC321/2 8NYC381/2 12LA341/2 IDCityLatency 1NYC30 2NYC38 3SLC34 4LA36 5SLC37 6SF28 7NYC32 8NYC38 9LA36 10SF35 11NYC38 12LA34 Full data: Rate ¼: ± 2.18 Rate ½: 35.5 ± 1.02 Uniform Sample 4

What is BlinkDB? A framework built on Apache Hive that … -Creates and maintains a variety of uniform and stratified samples from underlying data (offline) -Returns fast, approximate answers by executing queries on samples of data selected dynamically (online) -Compatible and integrated with Apache Hive, supports Hive’s SQL style query structure 5

Design considerations Query-column-set (QCS): Appears in query filtering/groupby clause, data expected to be stable over time Targets predictable query-column-set (QCS) style workloads Enables pre-computing samples that generalize to future workloads 6

Queries Supports COUNT, AVG, SUM and QUANTILE Relies on closed form error estimation for these aggregates Can be annotated with error bound/time constraint Selects appropriate sample type and size 7

High level architecture Table Sample creation module Uniform Stratified on C1 Stratified on C2 Query with error/latency bound Query plan Sample selection module Updated Query plan Execute 8

U 1.FILTER rand() < 1/3 2.Adds per-row Weights 3.(Optional) ORDER BY rand() IDCityLatencyWeight 2NYC381/3 6SF281/3 8NYC381/3 12LA341/3 Sample creation (uniform) IDCityLatency 1NYC30 2NYC38 3SLC34 4LA36 5SLC37 6SF28 7NYC32 8NYC38 9LA36 10SF35 11NYC38 12LA34 9

S1S1 S2S2 CityCountRatio NYC72/7 SF52/5 S2S2 JOIN Sample creation (stratified) SPLIT GROU P IDCityLatency 1NYC34 2NYC32 3SF36 4NYC28 5NYC37 6SF33 7NYC31 8NYC30 9SF32 10SF34 11NYC35 12SF36 10

S1S1 S2S2 S2S2 U IDCityDataWeight 2NYC322/7 8NYC302/7 6SF332/5 12SF362/5 Sample creation (stratified) 11

Sample creation (stratified) 12 Stratified sample size per group

Sample creation for multiple queries Multiple queries sharing QCS, different values of n (#rows to satisfy query) Sample depends on n (error/time bound) and selectivity of query Requires maintaining one sample per family of stratified samples S n 13 Sample for multiple queries with shared QCS

Sample creation (optimization) Multi-dimensional stratified samples Objective function Constraints 14 Weighted sum of coverage of QCSs of historical queries Storage cost for the samples Sample’s coverage probability for query QCS

Sample selection (runtime) Selecting the sample type Query’s column-set is subset of stratified sample QCS? Select, else Run query across all samples to pick ones with high selectivity Selecting sample size Error-Latency profile by running query on smaller samples Project profile for larger sample sizes Error profile Estimate query selectivity, sample variance, input data distribution Use standard closed form statistical error estimate Latency profile: Assumes latency scales linearly with input size 15

Evaluation BlinkDB vs. No sampling Conviva error comparison TPC-H error comparison 16 Expected error minimized

Evaluation Response time bounds Relative error bounds Scaleup 17 Smaller sample sizes Low communication cost

Conclusion Sampling based approximate query engine that supports query error and response time constraints Uses multi-dimensional stratified sampling with runtime sample selection strategy Can answer queries within 2 seconds on upto 17 TB of data with 90-98% accuracy 18

Thoughts Novel concepts introduced with grounding in statistics/sampling theory to build upon Can be integrated to existing query processing frameworks like Hive & Shark Follow up work such as supporting more generic aggregates and UDFs Potentially crucial aspects not addressed properly: M and K values are fixed, optimization space could be huge (heuristics unclear), sample replacement period, etc. What if ELP estimates are not accurate? And do we verify error estimates, query feasibility? 19

Thank you! 20

Extra slides 21

Speed/Accuracy Trade-off Enable exploring speed- accuracy tradeoff curve for performance Real time analysis Pre-existing noise from data collection already 22

Apache Hive Built on top of Hadoop to query/manage large datasets Imposes structure on variety of data formats SQL-like query language, can be extended to write UDF’s Batch jobs over large sets with scalability, extensibility, fault tolerance and loose coupling with input formats 23

BlinkDB Architecture Hadoop Storage (e.g., HDFS, Hbase, Presto) Meta store Meta store Hadoop/Spark/Presto SQL Parser Query Optimizer Physical Plan SerDes, UDFs Execution Driver Command-line Shell Thrift/JDBC 24

Error Estimation Closed Form Aggregate Functions -Central Limit Theorem -Applicable to AVG, COUNT, SUM, VARIANCE and STDEV 25

Error Estimation Closed Form Aggregate Functions -Central Limit Theorem  Applicable to AVG, COUNT, SUM, VARIANCE and STDEV 26