CrowdDB: Answering Queries with CrowdsourcingAuthors: Michael Franklin, Donald Kossmann, Tim Kraska, Sukriti Ramesh, Reynold Xin

Publication Date: June 2011

Conference: ACM SIGMOD Conference

Viviana MurelloScienze delle Reti

a.a. 2010/2011

Riassunto 1

Alcune query non possono essere soddisfatte dai database tradizionali

l’elaborazione di tali query hanno bisogno di input da parte delle persone per Snellire l’elaborazione Per i confronti Per la classificazione O aggregazione dei risultati

Riassunto 2

I CrowdDB usano l’input umano fornito tramite crowsorcing per rispondere alle query

Descriviamo alcune caratteristiche di un CrowdDB e alcuni esperimenti fatti usando Amazon Mechanical Turk

RDBMS

Le assunzioni di base dei RDBMS sono: Correttezza Completezza Non ambiguitàDei dati.

Quando queste assunzioni mancano il sistema fornisce risposte sbagliate oppure non ne fornisce affatto.

Potere alle persone

Il sistema fornisce risposte sbagliate Es. SELECT market_capitalization FROM company WHERE name = "I.B.M.";

I.B.M. non è stato inserito I.B.N. International Business Machine

Altro esempio di queries che non trovano risposte con gli attuali RDBMS: Es. stabilire quanto un’immagine è rilevante

per un certo argomento

Potere alle persone 2

2 problemi Close World Assuption: le informazioni

che non sono inserite nel DB sono considerate false o innesistenti

RDBMS sono estremamente letterali: si aspettano valori validi

CrowdDB

Sfruttare Human Computation per risolvere problemi

AMT (Amazon’s Mechanical Turk)

Trovare nuovi dati RDBMS: limitato dalla Closed World Assuption Persone: aiutate da strumenti sono brave nel

trovare nuove informazioni Confrontare dati

RDBMS: algoritmi di confronto sono difficili o impossibili

Persone: sono qualificate a fare confronti

Crowdsourcing

Amazon’s Mechanical Turk Assignment (compito) HIT HIT Group

API di Mechanical Turk createHIT(title, description, question, keywords, reward,

duration,maxAssignments, lifetime) HitID getAssignmentsForHIT(HitID)list(asnId, workerId ,

answer) approveAssignment(asnID) / rejectAssignment(asnID) forceExpireHIT(HitID)

Considerazione sulla progettazione del CrowdDB

La progettazione del CrowdDB è influenzata da: Prestazioni e variabilità: le persone e le macchine

differiscono in velocità e qualità. Attività di progettazione e ambiguità: le persone

richiedono UI per evitare che certe istruzioni vengano interpretate in modo sbagliato.

Affinità ed apprendimento: l’insieme dei lavoratori sviluppa relazioni con i richiedenti e competenze per certi HITs

Quantità di lavoratori relativamente piccola: Mondo chiuso vs Mondo aperto: ogni operazione

potrebbe ritornare un numero illimitato di risposte influenzando così l’ottimizzazione della query, i costi di esecuzioni e la qualità della risposta.

Progettazione ed implementazione del CrowdDB 1

crowdDB usa i dati memorizzati quando possibile altrimenti usa interroga la folla

Risultati ottenuti vengono memorizzati

Progettazione ed implementazione del CrowdDB 2

Sulla sx ci sono i componenti tradizionali

Sulla dx i nuovi componenti per interagire con la folla Turker Relationship

Management User Interface

Management Hit manager:

controlla iterazioni tra CrowdDB e piattaforma di crowdsourcing (AMT)

CrowdSQL

CrowdSQL è un’estensione dell’SQL che supporta il crowdsourcing nei casi d’uso che coinvolgono dati mancanti e comparazioni soggettive.

Attributi specifici di una tupla, intere tuple o intere tabelle possono essere crowdsourced.

Gestiamo i casi di dati mancanti con la parola chiave CROWD.

Per i confronti soggettivi e ordinamenti usiamo rispettivamente le parole chiave CROWDEQUAL e CROWDORDER

CrowdSQL – esempi

Crowdsorced Colum CREATE TABLE Department ( university STRING, name

STRING, url CROWD STRING, phone STRING, PRIMARY KEY (university,name) );

Se un nuovo dipartimento viene creato automaticamente spesso non viene inserita direttamete l’url, ma questa è disponibile in altra forma (crowdsourced)

Crowdsorced Table CREATE CROWD TABLE Professor (name STRING PRIMARY

KEY, email STRING UNIQUE, university STRING, department STRING, FOREIGN KEY (university, department) REF Department(university,name));

CrowdDB si aspetta che ci possono essere altri professori per il dipartimento che possono essere reperiti tramite crowdsourcing.

CrowdSQL – esempi e considerazioni

CROWDEQUAL Questa funzione prende 2 parametri in input

(lvalue,rvalue) e viene usata per decidere se 2 valori sono uguali ~=. La seguente query richiede nomi diversi per identificare “computer science” nel DB

SELECT profile FROM department WHERE name ~= "CS";

CROWDORDER Questa funzione è usata per classificare o ordinare i

risultati. CREATE TABLE picture (p IMAGE, subject STRING);

SELECT p FROM picture WHERE subject = "Golden Gate Bridge“ ORDER BY CROWDORDER(p,"Which picture visualizes better %subject");

CrowdSQL

CNULL è equivalente al NULL del SQL standard ma indica che il valore può essere crowdsourced quando viene usato per la prima volta.

CNULL è generato automaticamente per le istruzioni di INSERT (è il valore di default per le colonne crowd)

Se un attributo viene inizializzato a NULL il crowdsourcing non avrà effetto.

CrowdSQL

SELECT * FROM Professor WHERE email LIKE “%berkeley%” AND dept = “Math”;

La query richiede email e il dipartimento (se hanno valore CNULL) di tutti i professori individuati dalla condizione where

Le specifiche del CrowdSQL prevedono che le tabelle siano aggiornate quando vengono interrogate le persone.

Gli aggiornamenti e gli inserimenti fanno parte della stessa transazione e vengono eseguiti prima dell’interrogazione.

CrowdDB – in pratica

Dato che si passa all’assunzione di mondo aperto il costo per ogni query potrebbe essere illimitato Non è chiaro il numero di tuple che possono essere

coinvolte per eseguire completamente la query Clausola LIMIT per limitare il numero di tuple che

possono essere ritornate dalle interrogazioni Una futura estensione del CrowdDB potrebbe

includere il controllo della derivazione dei dati (ad esempio

per escludere i dati forniti da un utente che si sa essere uno spammer, o per sapere la data di inserimento per sapere quando un dato non è più valido)

controllo sulla pulizia dei dati in quanto in una tabella di tipo crowd può succedere che la chiave primaria si un dato crowdsourced.

Generazione delle interfaccia utente

La chiave del successo per il crowdsourcing è avere delle interfacce utenti efficaci.

Alla compilazione il crowdDB crea i template per richiedere alle persone i dati mancanti per le tabelle crowd e gli attributi crowd.

I template possono comunque essere estesi dai programmatori .

Interfacce di base

In generale UI sono generate copiando i dati conosciuti mentre tutti i dati che hanno valore CNULL diventano campi di input del form

Se il CrowdDB prevede il vincolo CHECK questo limita il dominio del valore richiesto.

Un’ottimizzazione è quella di raggruppare (batch) le tuple.

Assunzione: conviene inserire 2 parti di informazione dello stesso tipo in un unico form che 2 parti in form separati

Altra ottimizzazione è prefetching (richiedere prima) gli attributi di una stessa tupla. Ad esempio se manca sia la email che il dipartimento chiedo entrambi. La versione attuale non implementa questa possibilità

Interfacce di base

Queste sono le interfacce per il confronto e l’ordinamento

Entrambi possono essere raggruppate

Nell’attuale implementazione sono supportati solo i confronti binari.

Interfacce di base – relazioni con chiavi esterne

Nel caso più semplice la chiave esterna punta a una tabella non crowd, viene quindi visualizzato un menù a tendina con i valori possibili

Nel caso in cui la chiave esterna punti a una tabella crowd i possibili valori non si conoscono a priori e quindi possono essere richieste tuple in più rispetto a quella richiesta

Elaborazione della query

Il parse del crowdDB è stato esteso per analizzare CrowdSQL

L’ottimizzatore del crowdDB è stato implementato in modo da tenere conto dei nuovi operatori.

I nuovi operatori

CrowdProbe: usato per inserire nuovi informazioni o creare nuovo tuple. L’operatore forza il controllo di qualità selezionando la risposta che è stata data più volte. Nel caso di nuove tuple i valori inseriti possono differire nella chiave primaria in questo caso il task viene riproposto lasciano vuoti tutti i dati non confermati a parte la chiave primaria.

CrowdJoin: per ogni tupla della relazione più esterna, l’operatore crea uno o più HITs al fine di crowdsourcing nuove tuple dalla relazione interna che corrispondano alla relazione più esterna. Il controllo di qualità è quello usato nel CrowdProbe.

CrowdCompare: questo operatore implementa CROWDEQUAL e CROWDORDER. Il controllo di qualità viene fatto a maggioranza.

Esperimenti

AMT (ottobre 2010) 25000 HITs Vari parametri come prezzo, jobs per HIT

e ora. Sono stati misurati tempo di risposta e

qualità delle risposte fornite dalle persone Obiettivo dell’esperimento: esaminare il

comportamento delle persone per i vari tipi di compiti richiesti dal CrowdDB non che di ottenere intuizioni per ottimizzare i costi di esecuzione delle queries.

Base dell’esperimento

Tabella: CREATE TABLE businesses ( name VARCHAR PRIMARY KEY, phone_number CROWD VARCHAR(32), address CROWD VARCHAR(256));

Richiesta: SELECT phone_number, address FROM businesses;

Dato che le competenze e le persone non sono equamente distribuite nei vari fusi orari, l’ora può incidere sui tempi di risposta e la qualità

In questo articolo riportiamo solo i risultati ottenuti tra le 0600 e 1500 PST per ridurre la variabilità

Gli esperimenti sono stati ripetuti 4 volte e fatto la media dei valori ottenuti.

Ricompensa di default: 1 centesimo/HIT e ogni HIT richiedeva numero di telefono e indirizzo .

Esperimento 1 – Tempo di risposta al variare # HIT/gruppo

Esaminiamo il tempo di risposta dei compiti in funzione del numero di HITs in un HIT Group.

Il # di HITs per HIT Group varia da 10 a 400, # di incarichi per HIT = 1 (4) mostra tempi di risposta, (5) # di HITs completati in 30 min. Risultato: le prestazioni per compiti semplici possono variare

notevolmente anche quando a variare è un unico parametro.

Esperimento 2 – Reattività / ricompensa Analizziamo quanto il tempo di

risposta varia in funzione della ricompensa

(6) mostra che la % di HITs completata è in funzione del tempo. Ovviamente più si aspetta e più compiti vengono completati.

(7) mostra la frazione di HITs che ricevono almeno una risposta in funzione del tempo.

Confronto: In 60 minuti la maggioranza di

HITs riceve almeno una risposta se il pagamento è 2/3/4 cent.Se anche una sola risposta è accettabile non c’è nessun incentivo a pagare più di 2cent.

Esperimento 3 – affidabilità e qualità

Focus sulla distribuzione del lavoro tra le persone e la qualità.

(8)mostra # di HITs fatti da ogni persona e il # di errori commessi. La distribuzione è asimmetrica e conferma gli studi che dicono che il richiedente acquisisce una comunity di lavoratori che si specializzano nei compiti proposti. Possibilità di creare delle communità

La percentuale di errori non migliora con l’aumentare dei HIT eseguiti.

Queries complesse

3 esperimenti con interrogazioni che non possono essere fatte a DB tradizionali

1)

Tabella con 2 attributi (company name, headquarter address) popolata con 100 aziende.

SELECT name FROM company WHERE name ~=“[a non-unifrom name of the company]”

(9) 4 diverse istanze. Ogni HIT mette a confronto 10 nomi di società con uno dei 4 nomi completi. Ogni HIT aveva 3 compiti e la ricompensa era di 1 cent./HIT. In tutti e 4 i casi la maggioranza ha prodotto la risposta corretta, ma solo in un caso c’è stata l’unanimità. Il tempo totale per completare i 40 HITs (120 compiti) è stato di 39 minuiti.

2) Ordinamento di immagini

CREATE TABLE picture (p IMAGE, subject STRING); SELECT p FROM picture WHERE subject = "Golden Gate Bridge“ ORDER BY CROWDORDER(p,"Which picture visualizes better %subject");

Abbiamo testato 30 soggetti e 8 foto per ogni soggetto. Ogni HIT prevedeva il confronto di 4 coppie di foto. Questa classificazione è stata fatta con 210 HITs ognuno con 3 compiti. 68 minuti per completare l’esperimento.

(10) mostra il numero di persone che hanno votato, il ranking della foto in base al voto di maggioranza e il ranking in base al voto di 6 esperti.

3) Join tra Professor e Departments

In questo esperimento vengono confrontati 2 modalità di esecuzione per un’operazione di join.

SELECT p.name, p.email, d.name,d.phone FROM Professor p, Department d WHERE p.department = d.name AND p.university = d.university AND p.name = “[name of a professor]”;

1) prima vengono richieste le informazioni per il professore e poi per il dipartimento a cui è associato facendo così il join(3d) – 206 minuti, $ 0.99

2) chiedere per il professore e il dipartimento nello stesso momento usando l’interfaccia (2e) – 173 minuti $ 0.75

Le 2 diverse procedure sono state simili nei tempi di esecuzione e nei costi ma significativamente diversi nella qualità, con il secondo sono stati forniti risultati sbagliati per tutti i numeri di dipartimento i soggetti infatti ha fornito il # di tel. del professore invece che quello del dipartimento.

Osservazioni

Gli esperimenti: 25817 compiti eseguiti da 718 diversi lavoratori.

1. La risorsa “folla” implica memoria a lungo termine che può influenzare le performace. Le persone e i richiedenti possono tenere traccia dei rispettivi comportamenti e questo influenza le relazioni future.

2. La progettazione delle interfacce e la precisione delle istruzioni sono importanti

3. I risultati sperimentali mostrano la complessità e le nuove sfide che si presentano per l’elaborazione delle query tramite crowdsourcing.

Conclusioni

Gli esperimenti effettuati con CrowdDB e AMT dimostrano che gli input delle persone possono essere sfruttati per estendere notevolmente le funzionalità del SQL

La qualità è fortemente influenzata dalle motivazioni e capacità delle persone.

Ci sono dei parametri chiavi per la progettazione: Ricompensa # di compiti per HIT

È importante creare una comunity di lavoratori e dare loro ricompensa adeguata o un feedback adeguato.

Lavoro futuro: Migliorare il controllo sulla qualità delle risposte Tecniche di ottimizzazione adattiva

Fine

La combinazione di input umano con database ad alte prestazioni non solo estende la gamma dei database systems, ma che permette nuove applicazioni