Your SlideShare is downloading. ×
0
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
CrowdDB: Answering Queries with Crowdsourcing
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

CrowdDB: Answering Queries with Crowdsourcing

275

Published on

Presentation Paper: CrowdDB: Answering Queries with Crowdsourcing …

Presentation Paper: CrowdDB: Answering Queries with Crowdsourcing
Authors: Michael Franklin, Donald Kossmann, Tim Kraska, Sukriti Ramesh, Reynold Xin

Publication Date: June 2011
Conference: ACM SIGMOD Conference

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

  • Be the first to like this

No Downloads
Views
Total Views
275
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
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. CrowdDB: Answering Querieswith CrowdsourcingAuthors: Michael Franklin, Donald Kossmann, Tim Kraska, SukritiRamesh, Reynold XinPublication Date: June 2011Conference: ACM SIGMOD Conference Viviana Murello Scienze delle Reti a.a. 2010/2011
  • 2. 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
  • 3. 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
  • 4. 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.
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. 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)
  • 9. Considerazione sulla progettazione delCrowdDB 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.
  • 10. Progettazione ed implementazione delCrowdDB 1 crowdDB usa i dati memorizzati quando possibile altrimenti usa interroga la folla Risultati ottenuti vengono memorizzati
  • 11. Progettazione ed implementazione delCrowdDB 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)
  • 12. 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
  • 13. 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.
  • 14. 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");
  • 15. 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.
  • 16. 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.
  • 17. 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.
  • 18. 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 .
  • 19. 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 Altra ottimizzazione è di raggruppare (batch) le prefetching tuple. (richiedere prima) gli  Assunzione: conviene attributi di una stessa inserire 2 parti di tupla. Ad esempio se informazione dello stesso manca sia la email tipo in un unico form che 2 che il dipartimento parti in form separati chiedo entrambi. La versione attuale non implementa questa possibilità
  • 20. 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.
  • 21. Interfacce di base – relazioni con chiaviesterne 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
  • 22. 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.
  • 23. 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.
  • 24. 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.
  • 25. 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 .
  • 26. Esperimento 1 – Tempo di risposta alvariare # 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.
  • 27. 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.
  • 28. 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.
  • 29. Queries complesse 3 esperimenti con interrogazioni che non possono essere fatte a DB tradizionali
  • 30. 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.
  • 31. 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.
  • 32. 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.
  • 33. 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 importanti3. I risultati sperimentali mostrano la complessità e le nuove sfide che si presentano per l’elaborazione delle query tramite crowdsourcing.
  • 34. 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
  • 35. FineLa combinazione di input umano con database ad alte prestazioni non solo estende la gamma dei database systems, ma che permette nuove applicazioni

×