Workshop on TelegraphCQ: Concept of Data Stram Management System. TelegraphCQ: the DSMS developped at Berkley, internal architecture. Differences between tradition database. Adaptive QUery Processing using the new concept of Eddies like a routing operator. Troubles about join Streams (with no statistical data) and Relations; and the two solution: STAIR and SteMs. STAIR: a join operator that allow internal state changing using primite function visible to eddies. SteMs: helf-join operator that keep homogeneous tuples, internal state is decision-indipendent. Eddies Routing Policy implemented with the (Waldspurger & Weihl [1994]) Lottery Scheduling.

1. Berkley’sTelegraphCQ Generalità di TelegraphCQ Adattività con Eddies, SteMs e STAIR Routing Policy: Lottery Scheduling 1 lunedì 18 luglio 2011 Alberto Minetti Advanced Data Management @ DISI Università degli Studi di Genova

2. Data Stream Management System Continuous, unbounded, rapid, time-varying streams of data elements Occur in a variety of modern applications Network monitoring and traffic engineering Sensor networks, RFID tags Telecom call records Financial applications Web logs and click-streams Manufacturing processes DSMS = Data Stream Management System 2

3. L’inizio del progetto:Telegraph Molte continuous query e molti data stream Inizialmente in Java Poi in C basato su PostgreSQL No Scheduling distribuito Non varia il livello di adattività per sovraccarichi Non considera le risorse del sistema Gestione dei dati completamente in memoria 3

4. ReDesign:TelegraphCQ Sviluppato alla Berkeley University Scritto in C/C++ LicenzaOpenBSD Basatosulcodice di PostgreSQL Versionecorrente: 0.6 suPostgreSQL7.3.2 Progettochiusonel 2006 Importantipunti di interesse e caratteristiche Software http://telegraph.cs.berkeley.edu Papers http://db.cs.berkeley.edu/telegraph Spinoff commercialeTruviso 4

5. TelegraphCQ Architecture PostgreSQL backends Molti TelegraphCQ front-end Un solo TelegraphCQ back-end Front-End Fork ad ogni connessione client Non si occupa degli stream Parsing query continue e le mette nella shared memory Back-End ha un Eddy che combina i query plans in uno Può essere condiviso tra le query Mette i risultati nella shared memory 5

6. TelegraphCQ Architecture Shared Memory Query Plan Queue TelegraphCQBack End TelegraphCQBack End TelegraphCQ Front End Eddy Control Queue Planner Parser Listener Modules Modules Query Result Queues Split Mini-Executor Proxy CQEddy CQEddy } Split Split Catalog Scans Scans Shared Memory Buffer Pool Wrappers TelegraphCQ Wrapper ClearingHouse Disk 6 Taken from Michael Franklin, UC Berkeley

7. Tipologie di Moduli Ingresso e Caching (Relazioni e Stream) Interfaccia con i datasource esterni Wrapper per HTML, XML, FileSystem, proxy P2P Database remoti con supporto caching Esecuzione di Query Versioni non bloccanti di operatori classici (sel, proj) SteMs, STAIRs Routing adattivo Per riottimizzare il piano durante l’esecuzione Eddies: decidono routing tupla per tupla Juggle: ordinamento al volo (per value o timestamp), Flux: instradamento tra macchine di cluster 7 Fjords Framework

8. Fjords Framework in Java for Operators on Remote Data Streams Interconnette i moduli Supporta le code tra i moduli Non-blocking Supporto a Relazioni e a Stream 8

9. Stream in TelegraphCQ Unarchived Stream Mai memorizzati su disco Usano la shared memory tra executor e wrapper Archived Stream Append-only per passare tuple al sistema No update, insert, delete; query aggregate con window tcqtime di tipo TIMESTAMP per le window query Con constraint TIMESTAMPCOLUMN 9

10. DDL: Create Stream 10 CREATE STREAM measurements ( tcqtime TIMESTAMP TIMESTAMPCOLUMN, stationid INTEGER, speed REAL) TYPE ARCHIVED; CREATE STREAM tinydb ( tcqtime TIMESTAMP TIMESTAMPCOLUMN, light REAL, temperature REAL) TYPE UNARCHIVED; DROP STREAM measurements;

11. Acquisizione di Dati Le sorgenti devono identificarsi prima di inviare dati Wrapper: funzioni user-defined Come devono essere processati i dati All’interno del Wrapper Clearinghouse process Push sources Iniziano una connessione con TelegraphCQ Pull sources Il wrapper inizia la connessione Dati da Wrapper differenti possono confluire nello stesso stream Heartbeat: tupla Punctuated senza dati, solo timestamp Quando arriva una tupla Punctuated non arriveranno dati antecedenti 11

12. Wrappers nel WCH Non-process-blocking over network socket (TCP/IP) Wrapper funct chiamata quando ci sono dati sul socket O quando ci sono dati nel buffer se ritorna una tupla per volta (iteratore classico) Ritorna array di PostgreSQL Datum Init(WrapperState*) alloca risorse e lo stato Next(WrapperState*) tuple in campo di WrapperState Done(WrapperState*) libera risorse e distrugge lo stato Usano la memoria di infrastruttura di PostgreSQL 12

13. DDL: Create Wrapper 13 CREATE FUNCTION measurements_init(INTEGER) RETURNS BOOLEAN AS ‘libmeasurements.so,measurements_init’ LANGUAGE ‘C’; CREATE WRAPPER mywrapper ( init=measurements_init, next=measurements_next, done=measurements_done);

14. HtmlGet and WebQueryServer HtmlGet allows the user to execute a series of Html GET or POST requests to arrive at a page, and then to extract data out of the page using a TElegraph Screen Scrapperdefinition file. Once extracted, this data can be output to a CSV file. Welcome to the TESS homepage. TESS is the TElegraph Screen Scrapper. It is part of The Telegraph Project at UC Berkeley. TESS is a program that takes data from web forms (like search engines or database queries) and turns it into a representation that is usable by a database query processor. http://telegraph.cs.berkeley.edu/tess/ 14

15. self-monitoring capability Tre stream speciali: info sullo stato del sistema Supporto a query introspettive Dynamic catalog Interrogato come se fosse un qualsiasi stream tcq_queries(tcqtime, qrynum, qid, kind, qrystr) tcq_operators(tcqtime, opnum, opid, numqrs, kind, qid, opstr, opkind, opdesc) tcq_queues(tcqtime, opid, qkind, kind) 15

16. Esempio 16 Welcome to psql 0.2, the PostgreSQL interactive terminal. # CREATE SCHEMA traffic; # CREATE STREAM traffic.measurements (stationid INT, speed REAL, tcqtime TIMESTAMP TIMESTAMPCOLUMN ) TYPE ARCHIVED; # ALTER STREAM traffic.measurements ADD WRAPPER csvwrapper; $ cat tcpdump.log | source.pl localhost 5533 csvwrapper,network.tcpdum Script di default TelegraphCQ scritto in Perl per simulare sorgenti che inviano dati CSV Porta di default

17. Load Shedding CREATE STREAM … TYPE UNARCHIVED ON OVERLOAD ???? BLOCK: si ferma (default) DROP: scarta le tuple KEEP COUNTS: mantiene il numero di tuple scartate REGHIST: costruisce un fixed-grid istog. delle shedded MYHIST: costruisce un MHIST (multidimensionale) WAVELET wavelet params Costruisce un istogramma wavelet SAMPLE: mantiene un Reservoir Sample 17

18. LoadShedding:SummaryStream Per uno stream con il nome schema.stream Vengono creati automaticamente due stream schema.__stream_dropped schema.__stream_kept Per WAVELET, MYHIST, REHIST, COUNTS Schema contenente: Dati del summary Intervallo del summary Per i SAMPLE Lo schema è lo stesso con la colonna __samplemult Contiene il numero di tuple reali rappresentate 18

19. Quering TelegraphCQ:StreaQuel 19 Query continue per: Relazioni standard ereditate da PostgreSQL Data stream windowed (sliding, hopping, jumping) RANGE BY specifica la dimensione della window SLIDE BY specifica quanto spesso si aggiorna START AT indica quando iniziare la query Opzionale SELECT stream.color, COUNT(*) FROM stream [RANGE BY ‘9’ SLIDE BY ‘1’] GROUP BY stream.color window START OUPUT! 1 1 1 1 1 2 2 1 2 1 2 2 1 2 1 2 1 2 1 Adapted from Jarle Søberg

20. Quering TelegraphCQ:StreaQuel (2) wtime(*) ritorna l’ultimo timestamp nella window Possiblità di query ricorsive con WITH [SQL 1999] StreaQuel non ammette sotto query 20 SELECT S.a, wtime(*) FROM S [RANGE BY ’10 seconds’ SLIDE BY ’10 second’], R [RANGE BY ’10 seconds’ SLIDE BY ’10 second’] WHERE S.a = R.a; Data Stream Window … 10 seconds 10 seconds

21. Net Monitor Windowed Query 21 SELECT (CASE when outgoing = true then src_ip else dst_ip end) as inside_ip , (CASE when outgoing = true then dst_ip else src_ip end) as outside_ip, sum(bytes_sent) + sum(bytes_recv) as bytes FROM flow [RANGE BY $w SLIDE BY $w] GROUP BY inside_ip, outside_ip Tutte le connessioni attive SELECT src_ip, wtime(*), COUNT(DISTINCT(dst_ip||dst_port)) AS fanout, FROM flow [RANGE BY $w SLIDE BY $w] WHERE outgoing = false GROUP BY src_ip ORDER BY fanout DESC LIMIT 100 PER WINDOW; 100 sorgenti con il massimo numero di connessioni SELECT sum(bytes_sent), src_ip, wtime(*) AS now FROM flow [RANGE BY $w SLIDE BY $w] WHERE outgoing = false GROUP BY src_ip ORDER BY sum(bytes_sent) DESC LIMIT 100 PER WINDOW; 100 most significant sources of traffic Taken from: İlkay Ozan Kay

22. Evolutionary Revolutionary Adaptive Query Processing:Evoluzione Static Late Inter Intra Per Plans Binding Operator Operator Tuple Traditional Dynamic QEP Query Scrambling Xjoin, DPHJ, Eddies DBMS Parametric Mid-query Reopt. Convergent QP Competitive Progressive Opt. Taken from: AmolDeshpande, Vijayshankar Raman 22

23. Adaptive Query Processing:Scenario Attuale Troppi piani possibili Query parametriche Query continue Focus su output incrementali Query complesse (10-20 relazioni in join) Data Stream e dati asincroni Statistiche non disponibile Query interattive e preferenze dell’utente Sharing dello stato Molti più operatori XML data e testo Wide area federations 23

24. Adaptive Query Processing:System R Repeat Osservare l’ambiente: daily/weekly (runstats) Scegliere il comportamento (optimizer) Se il piano attuale non è il migliore (analyzer) Attuare il piano (executor) Ottimizzazione basatasulcostodella query Runstats-optimize-execute -> alta granularità Adattività settimanale! Goal: adattare per tupla Unire le 4 funzioni Measure Actuate Analyze Plan Taken from: Avnur, Hellerstein 24

25. TelegraphCQ Executor:Eddy Concetto preso dalla dinamica dei fluidi continuously adaptive query processing mechanism Eddy è un routing operator Determina quali moduli devono essere visitati prima Dopo che una tupla visita tutti i moduli va in output Vede le tuple prima e dopo ogni operatore 25 Measure Eddy Analyze Actuate Plan Taken from: Amol Deshpande, Vijayshankar Raman

26. Eddies:Correttezza Ogni tupla ha due BitVector Ogni posizione corrisponde ad un operatore Ready: identifica se la tupla è pronta per un operatore Eddy può decidere quali tuple mandare ad un operatore Done: identifica se una tupla ha subito un operatore Eddy evita di inviare due volte ad un operatore Quando tutti i bit di Done sono attivi -> output Tuple joined hanno Ready e Done in bitwise-OR SempliciselectionhannoReady=complement(Done) 26

27. Eddies:Simple Selection Routing 27 S SELECT *FROM SWHERE S.a > 10 AND S.b < 15 AND S.c = 15 σa σb S.b < 15 S.a > 10 Eddy σc S.c = 15 σaσbσc σaσbσc 15 ; 0 ; 15 S1 0 0 0 1 1 1 1 0 0 01 1 1 1 0 0 0 1 1 1 1 0 0 0 a 15 b 0 Ready Done c 15 Adapted from Manuel Hertlein

28. S >< T Relation Binary Join:R >< S >< T Ordine di join (R >< S) >< T Va bene se si ha accesso diretto ai dati (indici o seq.) 28 R >< S T R S Taken from Jarle Søberg

29. Stream Binary JoinR >< S >< T 29 Ordine di join (R >< S) >< T Ma se i dati sono inviati direttamente dalla sorgente... S >< T R >< S Bloccare o gettare via delle tuple è inevitabile! Taken from Jarle Søberg

30. Necessaria una riottimizzazione al volo… S >< T 30 Stream Binary JoinR >< S >< T Possono esserci molti cambiamenti in uno stream Riottimizzare può richiedere molto tempo Non abbastanza dinamica! R >< S Taken from Jarle Søberg

31. Stream Binary Join:Eddies Usando un Eddy Modello iniziale di Telegraph 31 S >< T eddy R >< S Adattività tuple-based Considera cambiamenti dinamici nello stream Taken from Jarle Søberg

32. Eddies:Sheduling Join problem Sheduling sulla selettività dei join non funziona Esempio 32 |S E| |EC| >> E and Carrive early; Sis delayed S E C time Taken from Amol Deshpande

33. 33 |S E| |E C| SE HashTable E.Name HashTable S.Name Eddy S E Output C HashTable C.Course HashTable E.Course Eddy decides to route E to EC EC >> E and Carrive early; Sis delayed S0 sent and received suggest S Join E is better option S S E S0 S –S0 E C time C SE S0E (S –S0)E Eddy learns the correct sizes Too Late !! Taken from Amol Deshpande

34. 34 State got embedded as a result of earlier routing decisions |S E| |EC| SE HashTable E.Name HashTable S.Name EC Eddy S E Output C HashTable C.Course HashTable E.Course SE EC >> E and Carrive early; Sis delayed S E C C SE S E Execution Plan Used Query is executed using the worse plan! Too Late !! Taken from Amol Deshpande

35. STAIRStorage, Transformation and Access for Intermediate Results 35 S.Name STAIR Build into S.Name STAIR HashTable E.Name STAIR HashTable Eddy S Output E C HashTable HashTable E.Course STAIR C.Course STAIR Probe into E.Name STAIR Mostra lo stato interno del join all’eddy Fornisce primitive di management dello stato Demotion Promotion Operazioni per Inserimento (build) Lookup (probe) s1 s1 s1 s1 Taken from Amol Deshpande

36. STAIR: Demotion 36 e1 e1 e2c1 e2 s1e1 e2c1 e2 s1e1 S.Name STAIR HashTable E.Name STAIR s1 Demoting di e2c1ae2: Semplice proiezione HashTable e1 e2c1 e2 Eddy S s1e1 E Output C HashTable e2 s1e1 e2c1 HashTable c1 Può essere pensato come un lavoro disfatto E.Course STAIR C.Course STAIR Adapted from Amol Deshpande

38. Un joinHashTable e1 e1c1 e2c1 Eddy S E Output C HashTable e2 s1e1 HashTable c1 e1 Può essere pensato come una precomputazione di lavoro E.Course STAIR C.Course STAIR Adapted from Amol Deshpande

39. Demotion OR Promotion 38 Taken from Lifting the Burden of History from Adaptive Query Processing Amol Deshpande and Joseph M. Hellerstein

40. Demotion AND Promotion Taken from Lifting the Burden of History from Adaptive Query Processing Amol Deshpande and Joseph M. Hellerstein 39

41. 40 S.Name STAIR HashTable |S E| |EC| S0 E E E HashTable E E E C C C S0E Eddy decides to route E to EC E.Course STAIR >> E and Carrive early; Sis delayed S0 E.Name STAIR HashTable S E E Eddy S C E Output C time E HashTable C Eddy decides to migrateE Eddy learns the correct selectivities By promoting E using EC C.Course STAIR Adapted from Amol Deshpande

42. 41 |S E| |EC| HashTable E C S0E E.Course STAIR >> E and Carrive early; Sis delayed S.Name STAIR HashTable S S0 E.Name STAIR HashTable S S –S0 S –S0 E Eddy S C (S –S0) EC E Output C time E HashTable C C.Course STAIR Adapted from Amol Deshpande

43. 42 EC SE C S – S0 SE EC S0 E E C HashTable E C SE E.Course STAIR S.Name STAIR HashTable S E.Name STAIR HashTable UNION Eddy S E Output C E HashTable C Most of the data is processed using the correct plan C.Course STAIR Adapted from AmolDeshpande

44. STAIR:Correttezza Theorem [3.1]: An eddy with STAIRs always produces the correct query result in spite of arbitrary applications of the promotion and demotion operations. STAIRs producono tutte le tuple Non ci sono duplicati aggiunti 43 Taken from Lifting the Burden of History from Adaptive Query Processing Amol Deshpande and Joseph M. Hellerstein

45. State Module Una sorta di repository temporaneo di dati Operatore di Half-Join che memorizza tuple omogenee Decisioni independenti Supporta le operazioni Inserimento (build) Ricerca (probe) Cancellazione (eviction) utili per le window Simili a Mjoin ma più adattivi Sharing dello stato tra altre query continue Non memorizza i risultati intermedi Aumento del costo di computazione 44

46. Eddies Join with SteMs 45 T R S eddy R T S Maggiore adattività Eddy vede half-join Diversi access method Index access Scan access Simulano diversi join In caso di sovraccarico? Hash join (veloce) Index join (mem limit) Tipologie di Join? Hash join (equi-join) B-tree join (<, <=, >) Query parametrica può essere vista come un join Adapted from Jarle Søberg

47. SteMs:Correttezza 46 R S Problema di correttezza Possibili duplicati!! Sequence number globale unico Solo le più giovani possono fare il match Taken from Jarle Søberg

48. SteMs sliding Window 47 SELECT * FROM Str [RANGE BY 5 Second SLIDE BY 2 Second], Relation, WHERE Relation.a = Str.a A|…….|18:49:36 R B|…….|18:49:36 C|…….|18:49:37 A|…….|18:49:38 Mantenere lo stato per le sliding window (eviction) Siamo al tempo 40, cosa succede al tempo 42? Invece che ricreare tutta l’hash table vengono rimosse solo tuple vecchie e aggiunte le nuove B|…….|18:49:39 C|…….|18:49:39 A|…….|18:49:40 B|…….|18:49:40 C|…….|18:49:40 Eviction!18:49:37 A|…….|18:49:41 B|…….|18:49:41

49. Binary Join, STAIR, SteMconfronti 48 select * from customer c, orders o, lineitem l where c.custkey = o.custkey and o.orderkey = l.orderkey and c.nationkey = 1 and c.acctbal > 9000 and l.shipdate > date ’1996-01-01’ Recomputation necessaria Non si adatta lineitemarriva con shipdate crescente Routing iniziale (O >< L) >< C Taken from Lifting the Burden of History from Adaptive Query Processing Amol Deshpande and Joseph M. Hellerstein

50. Eddies:Routing Policy Come scegliere il piano? Usando il Routing Ogni tupla è instradata individualmente Routing policy determina l’efficienza del sistema Eddy ha un buffer di tuple con priorità Inizialmente hanno bassa priorità Quando escono da un operatore hanno alta priorità Una tupla va in output il più presto possibile Evita di congestionare il sistema Permette un basso consumo di memoria 49

51. Eddies’ Routing Policy:(old) Back-Pressure Approccio Naive: operatore più veloce prima 50 sel(s1) = sel(s2) cost(s2) = 5 cost(s1) varia cost(s1) = cost(s2) sel(s2) = 50% sel(s1) varia Taken from: Avnur, Hellerstein

52. Eddies’ Routing Policy:Lottery Scheduling Waldspurger& Weihl nel 1994 Algoritmo per schedulare risorse condivise « rapidlyfocus availableresources» Ogni operatore inizia con un numero di ticket fissato Operatore riceve un ticket quando prende una tupla Favorisce gli operatori che consumano tuple velocemente Operatore perde un ticket quando ritorna una tupla Favorisce gli operatori con bassa selettività Cioè quelli che ritornano poche tuple e ne processano tante Quando due operatori concorrono per una tupla La tupla viene assegnata all’operatore che vince la lotteria Mai lasciare op senza ticket + randomexploration 51

53. Eddies’ Routing Policy:Lottery Scheduling Lottery Scheduling è meglio del Back-Pressure 52 cost(s1) = cost(s2) sel(s2) = 50% sel(s1) varia Taken from: Avnur, Hellerstein

54. Experiment 53 Stream: x con media 40 e deviazione standard 10

55. 54 Experiment: variazione Stream Stream: x con media 10 e deviazione standard 0

56. 55 Experiment: variazione Stream (2) Stream: x con media 10 e deviazione standard 0

57. Other Works Distribuited Eddies Freddies: DHT-Based Adaptive Query Processing via Federated Eddies Content-based Routing Partial Results for Online Query Processing Flux: An Adaptive Partitioning Operator for Continuous Query Systems Java Support for Data-Intensive Systems: Experiences Building the Telegraph Dataflow System Ripple Join for Online Aggregation Highly Available, Fault-Tolerant, Parallel Dataflows 56

58. Bibliografia TelegraphCQ: An Architectural Status Report Continuous Dataflow Processing for an Uncertain World Enabling Real-Time Querying of Live and Historical Stream Data Declarative Network Monitoring with an Underprovisioned Query Processor Lifting the Burden of History from Adaptive Query Processing [STAIRs] Eddies: Continuously Adaptive Query Processing Using State Modules for Adaptive Query Processing E altri… http://telegraph.cs.berkeley.edu/papers.html Telegraph team @ UC Berkley: Mike Franklin, Joe Hellerstein, Bryan Fulton, Sirish Chandrasekaran, Amol Deshpande, Ryan Huebsch, Edwin Mach, Garrett Jacobson,Sailesh Krishnamurthy, Boon Thau Loo, Nick Lanham, Sam Madden, Fred Reiss, Mehul Shah, Eric Shan, Kyle Stanek, Owen Cooper, David Culler, Lisa Hellerstein, Wei Hong, Scott Shenker, Torsten Suel, Ion Stoica, Doug Tygar, Hal Varian, Ron Avnur, David Yu Chen, Mohan Lakhamraju, Vijayshankar Raman Lottery Scheduling: Flexible Proportional-Share Resource Management Carl A. Waldspurger & William E. Weihl @ MIT 57