A Big Data Fairy Tale

Meet Alice

Alice has a Store

Alice's store collects sales data

Alice wants to use her sales data to run a promotion

So Alice loads up her sales data in her trusty database/hadoop/spark/etc... server.

... asks her question ...

... and basks in the limitless possibilities of big data.

Why is this a fairy tale?

It's never this easy...

CSV Import

Run a SELECT on a raw CSV File

• File may not have column headers
• CSV does not provide "types"
• Lines may be missing fields
• Fields may be mistyped (typo, missing comma)
• Comment text can be inlined into the file

Merge Data From Two Sources

UNION two data sources

• Schema matching
• Deduplication
• Format alignment (GIS coordinates, $ vs €)
• Precision alignment (State vs County)

JSON Shredding

Run a SELECT on JSON or a Doc Store

• Separating fields and record sets:
  (e.g., { A: "Bob", B: "Alice" })
• Missing fields (Records with no 'address')
• Type alignment (Records with 'address' as an array)
• Schema matching$^2$

We have tools that can solve these problem!

... most of the time

Problem: It's hard to trust tools that can be wrong!

Options

1. Ignore the Problem

In the name of Codd
Thou shalt not give the user a wrong answer.

... but this assumes that we start with perfect data.

Options

1. Ignore the Problem
2. Heresy

On representing incomplete information in a relational data base

T. Imielinski & W. Lipski Jr.(VLDB 1981)

But...

1. ProbDBs Produce Probability Distributions as Outputs

2. ProbDBs Require Probability Distributions as Inputs

Probabilistic Databases...

1. ... require probabilities as inputs
2. ... produce probabilities as outputs
3. ... are slow

Options

1. Ignore the Problem
2. Heresy
3. ?

Declarative Uncertainty

The Uncertainty Management System

http://mimirdb.info

At each step, Mimir tracks ambiguity and potential errors.

• A row that may or may not exist.
• An attribute value that is missing or ambiguous.
• A table with multiple possible schemas.
• A violated constraint.

Declarative uncertainty requires...

1. ... uncertainty capture
2. ... query processing over uncertain data
3. ... intuitive and qualitative presentation of uncertainty

Uncertainty-Annotated Databases

(Joint work with Boris Glavic, Su Feng, Aaron Huber)

Background

1. Possible Worlds
2. $K$-Relations
3. $K^W$-Relations

$K$-Relations

Provenance Semirings

T.J. Green & G. Karvounarakis & V. Tannen(PODS 2007)

The relational view

The functional view

$$R(1, 2) \mapsto 1$$ $$R(1, 3) \mapsto 1$$ $$R(4, 3) \mapsto 1$$ $$S(2, 5) \mapsto 1$$ $$S(3, 6) \mapsto 2$$

$$R(4, 5) \mapsto 0$$

$K^W$-Relations

Summarizing Possible Worlds

Annotation in World $i$

$\texttt{PW}_i(\vec k) \equiv \vec k_i$

Certain Annotation

$\mathcal C(\vec k) \equiv min(\vec k)$

Possible Annotation

$\mathcal P(\vec k) \equiv max(\vec k)$

Correct/Possible mirrors "Correctness of SQL Queries on Databases with Nulls" [Guagliardo, Libkin 2017]

A quick step back into reality...

Standard practice: "Just use the best option."

What's in between these extremes?

Use the best option, but mark potential errors.

(Computing $PW_{i}(Q(\mathcal D))$ is cheap!)

Can we do the same thing for $\mathcal C(Q(\mathcal D))$?

$$C(Q(\mathcal D)) \stackrel{?}{=} Q(\mathcal C(\mathcal D))$$

No.

Compute $\pi_B(R)$

$=1+0+0=1$ $\neq C([2,2])$

So what can we do with $\mathcal C$?

We can Approximate

(C-) Soundness

$Q(\mathcal C(\mathcal D)) \leq \mathcal C(Q(\mathcal D))$

We can efficiently compute a conservative approximation of $\mathcal C$.

Completeness (for some queries)

$Q(\mathcal C(\mathcal D)) = \mathcal C(Q(\mathcal D))$ ...if $Q$ is safe

... also attribute level uncertainty

(but not today)

We implemented it...

Defining Possible Worlds

Mimir allows users to define special UDFs called Models.

    CREATE MODEL TYPE Geocoder AS mimir.models.GeocodingModel;

    CREATE MODEL INSTANCE Text_To_Loc USING Geocoder('Google');

    SELECT C.name, C.id, Text_To_Loc(C.address) AS address 
      FROM Customer C;
          

(Not actual Mimir-SQL. Language adapted for your viewing pleasure.)

Models...
... return one best guess
... define the space of alternatives

Example Models

• Geocoding Addresses
• Imputation using a SparkML classifier
• Heuristic detection of order-by columns for interpolation
• Schema matching based on edit-distance
• MayBMS-style probabilistic repair-key
• And more...

Convenience Operators: Lenses

Lenses instantiate/train a model and wrap a query

• Domain Constraint Repair / Missing Value Imputation
• Schema Matching
• Sequence Repair
• Key Repair
• Arbitrary Choice
• Type Detection *
• Header Detection *
• JSON Shredder *

Evaluation handled by a DBMS or Spark
via query rewriting using GProM.

    SELECT C.name, C.id, Text_To_Loc(C.address) AS address 
      FROM Customer C;
          

becomes...

    SELECT C.name, C.id, Text_To_Loc(C.address) AS address,
           1 AS name_certain,    1 AS id_certain, 
           0 AS address_certain, 1 AS row_certain
      FROM Customer C;
          

Adaptive Schemas

• Domain Constraint Repair / Missing Value Imputation
• Schema Matching
• Sequence Repair
• Key Repair
• Arbitrary Choice
• Type Detection *
• Header Detection *
• JSON Shredder *

Adaptive Schemas

• Domain Constraint Repair / Missing Value Imputation
• Schema Matching
• Sequence Repair
• Key Repair
• Arbitrary Choice
• Type Detection *
• Header Detection *
• JSON Shredder *

      LOAD 'customers.csv';

      SELECT name FROM customers WHERE last_purchase < LAST_WEEK();
          

How does the system know...

... which column is 'name'?

Guess that row 1 is headers.

... that 'last_purchase' is a date?

All rows look like YYYY-MM-DD

This is all guesswork!

Idea: Make the System Catalog a Probabilistic Table

Probabilistic Query Compilers

Sampling from ProbDBs is Sloooow

Trivial Sampling

Evaluate the query $N$ times.
Plug in samples instead of best guesses.

Sparse Encoding

Tuple Bundles

Idea: Let the compiler pick the right representation
(or combination)