1. 1 Continuously Adaptive Continuous Queries (CACQ) over Streams Samuel Madden SIGMOD 2002 June 4, 2002 With Mehul Shah, Joseph Hellerstein, and Vijayshankar Raman

2. 2 CACQ Introduction Proposed continuous query (CQ) systems are based on static plans – But, CQs are long running – Initially valid assumptions less so over time – Static optimizers at their worst! CACQ insight: apply continuous adaptivity of eddies to continuous queries – Dynamic operator ordering avoids static optimizer danger – Process multiple queries simultaneously – Interestingly, enables sharing of work & storage

3. 3 Outline Background – Motivation – Continuous Queries – Eddies CACQ – Contributions - Example driven explanation Results & Experiments

4. 4 Outline Background – Motivation – Continuous Queries – Eddies CACQ – Contributions - Example driven explanation Results & Experiments

5. 5 Motivating Applications “Monitoring” queries look for recent events in data streams – Sensor data processing – Stock analysis – Router, web, or phone events In CACQ, we confine our view to queries over ‘recent- history’ Only tuples currently entering the system Stored in in-memory data tables for time-windowed joins between streams

6. 6 Continuous Queries Long running, “standing queries”, similar to trigger systems Installed; continuously produce results until removed Lots of queries, over the same data sources – Opportunity for work sharing! – Global query optimization problem: hard! – Idea: adaptive heuristics not quite as hard? Bad decisions are not final – Future work: finding an optimal plan (adaptively)

7. 7 CACQ Query Model Monotonic queries, from point when query is registered Terry et al., SIGMOD 1992 Streaming answers Non-blocking operators Windowed Symmetric Joins Windows in tuples or time

8. 8 Eddies & Adaptivity Eddies (Avnur & Hellerstein, SIGMOD 2000): Continuous Adaptivity No static ordering of operators Policy dynamically orders operators on a per tuple basis done and ready bits encode where tuple has been, where it can go

9. 9 Outline Background – Motivation – Continuous Queries – Eddies CACQ – Contributions - Example driven explanation Results & Experiments

10. 10 CACQ Contributions Adaptivity – Policies for continuous queries – Single eddy for multiple queries Tuple Lineage – In addition to ready and done, encode output history in tuple in queriesCompleted bits Enables flexible sharing of operators between queries Grouped Filter – Efficiently compute selections over multiple queries Join Sharing through State Modules (SteMs)

11. 11 Explication By Example First, example with just one query and only selections Then, add multiple queries Then, (briefly) discuss joins

12. 12 Eddies & CACQ : Single Query, Single Source Use ready bits to track what to do next All 1’s in single source Use done bits to track what has been done Tuple can be output when all bits set Routing policy dynamically orders tuples R  (R.a > 10) Eddy  (R.b < 15) R1R1 R1R1 R1R1 R1 a5 b25 R2 a15 b0 1 1 0 01 1 0 11 1 0 01 1 1 01 1 11 Rea dy Don e aa bb aa bb R  (R.a > 10) Eddy  (R.b < 15) R2R2 R2R2 R2R2 R2R2 R2R2 R2R2 SELECT * FROM R WHERE R.a > 10 AND R.b < 15

13. 13 aa bb R aa bb R aa bb R Q1Q2Q3 Multiple Queries R.a > 10 R.a > 20 R.a = 0 R.b < 15 R.b = 25 R.b <> 50 bb aa R R1R1 R1R1 R1R1 R1R1 R1R1 Grouped Filters R1 a5 b25 SELECT * FROM R WHERE R.a > 10 AND R.b < 15 Q1 SELECT * FROM R WHERE R.a > 20 AND R.b = 25 Q2 SELECT * FROM R WHERE R.a = 0 AND R.b <> 50 Q3 R1R1 R1R1 R1R1 R1R1 R1R1 R1R1 R1R1 R1R1 0 0 0 0 00 0 1 0 00 1 1 0 00 1 1 1 11 1 1 1 1 aa bb Q1Q2Q3 DoneQueriesComplete d

14. 14 aa bb R aa bb R aa bb R Q1Q2Q3 Multiple Queries R.a > 10 R.a > 20 R.a = 0 R.b < 15 R.b = 25 R.b <> 50 bb aa R R2R2 R2R2 R2R2 R2R2 R2R2 R2R2 Grouped Filters R2 a15 b0 SELECT * FROM R WHERE R.a > 10 AND R.b < 15 Q1 SELECT * FROM R WHERE R.a > 20 AND R.b = 25 Q2 SELECT * FROM R WHERE R.a = 0 AND R.b <> 50 Q3 0 0 0 0 0 bb aa R bb aa R bb aa R Q1Q2Q3 R2R2 R2R2 R2R2 0 0 0 1 11 0 0 1 11 1 0 1 11 1 1 1 1 aa bb Q1Q2Q3 DoneQueriesComplete d R1R1 R1R1 R2R2 Reorder Operators!

15. 15 Outputting Tuples Store a completionMask bitmap for each query – One bit per operator – Set if the operator in the query To determine if a tuple t can be output to query q: – Eddy ANDs q’s completionMask with t’s done bits – Output only if q’s bit not set in t’s queriesCompleted bits Every time a tuple returns from an operator Q2: 0111 Q1: 1100 & Done == 1100 & Done == 0111 completionMasks && QueriesCompleted[0] == 0 SELECT * FROM R WHERE R.a > 10 AND R.b < 15 Query 1 SELECT * FROM R WHERE R.b < 15 AND R.c <> 5 AND R.d = 10 Query 2 completionMas ks  abcd Q11100 Q20111 Done QC aa Q1Q2 bb cc dd Tupl e 1 1 0 0 0 01 1 0 0 1 0

16. 16 Grouped Filter Use binary trees to efficiently index range predicates – Two trees (LT & GT) per attribute – Insert constant When tuple arrives – Scan everything to right (for GT) or left (for LT) of the tuple-attribute in the tree – Those are the queries that the tuple does not pass Hash tables to index equality, inequality predicates Greater-than tree over S.a S.a > 1 S.a > 7 S.a > 11 8 S.a >11 7 111 >7>1 Q1 Q2Q3

17. 17 Work Sharing via Tuple Lineage A B C D B A Data Stream S s scsc sBCsBC sDsD s BD Query 1 Query 2 Conventional Queries s s sCsC s CD s CDB CACQ - Adaptivity A C D B Data Stream S A C D B Query 1 Query 2 Shared Subexpressions sBsB s AB Reject ? s CDBA s Q1: SELECT * FROM s WHERE A, B, C Q2: SELECT * FROM s WHERE A, B, D Intersecti on of CD goes through AB an extra time! AB must be applied first! Lineage (Queries Completed) Enables Any Ordering! 0 | 0 QC 0 or 1 | 0 QC 1 | 1 QC 0 or 1 | 0 or 1 QC 0 or 1 | 0 or 1 QC CD 0 or 1 | 0 or 1 QC

18. 18 Tradeoff: Overhead vs. Shared Work Overhead in additional bits per tuple – Experiments studying performance, size in paper – Bit / query / tuple is most significant Trading accounting overhead for work sharing – 100 bits / tuple allows a tuple to be processed once, not 100 times Reduce overhead by not keeping state about operators tuple will never pass through

19. 19 Joins in CACQ Use symmetric hash join to avoid blocking Use State Modules (SteMs) to share storage between joins with a common base relation Detail about effect on implementation & benefit in paper See Raman, UC Berkeley Ph.D. Thesis, 2002.

20. 20 Routing Policies Previous system provides correctness; policy responsible for performance Consult the policy to determine where to route every tuple that: – Enters the system – Returns from an operator Basic Ticket Policy – Give operators tickets for consuming tuples, take away tickets for producing them – To choose the next operator to route, run a lottery – More selective operators scheduled earlier Modification for CACQ – Give more tickets to operators shared by multiple queries (e.g. grouped filters) – When a shared operator outputs a tuple, charge it multiple tickets – Intuition: cardinality reducing shared operators reduce global work more than unshared operators Not optimizing for the throughput of a single query!

21. 21 CACQ Review Efficient mechanism for processing multiple simultaneous monitoring queries over streaming data sources – Share work by processing all queries within a single eddy Continuous adaptivity via eddies & routing policy – Queries come & go, but performance adapts without costly multiquery reoptimization Maximize ability to work share by explicitly encoding lineage Share selections via grouped filter Share join state via SteMs

22. 22 Outline Background – Motivation – Continuous Queries – Eddies CACQ – Contributions - Example driven explanation Results & Experiments

23. 23 Evaluation Real Java implementation on top of Telegraph QP – 4,000 new lines of code in 75,000 line codebase Server Platform – Linux 2.4.10 – Pentium III 733, 756 MB RAM Queries posed from separate workstation – Output suppressed Lots of experiments in paper, just a few here

24. 24 Results: Routing Policy From S select index where a > 90 From S select index where a > 90 and b > 70 From S select index where a > 90 and b > 70 and c > 50 From S select index where a > 90 and b > 70 and c > 50 and d > 30 From S select index where a > 90 and b > 70 and c > 50 and d > 30 and e > 10 All attributes uniformly distributed over [0,100] Query 1 2 3 4 5

25. 25 CACQ vs. NiagaraCQ * Performance Competitive with Workload from NCQ Paper Different workload where CACQ outperforms NCQ: Stocks.sym = Articles.sym  UDF(stocks.sym) Articles Stocks Query 3 Stocks.sym = Articles.sym  UDF(stocks.sym) Articles Stocks Query 2 Stocks.sym = Articles.sym  UDF(stocks) Articles Stocks Query 1 |result| > |stocks| Expensive SELECT stocks.sym, articles.text FROM stocks,articles WHERE stocks.sym = articles.sym AND UDF(stocks) *See Chen et al., SIGMOD 2000, ICDE 2002

26. 26 CACQ vs. NiagaraCQ #2  UDF 1 Query 1  UDF 2 Query 2  UDF 3 Query 3 Niagara Option #2 S1S1 S1AS1AS2AS2A S2S2 S3S3 S3AS3A  UDF 3  UDF 2  UDF 1 CACQ S1S1 S 1|2 S 1|2|3 Stocks.sym = Articles.sym Articles Stocks |result| > |stocks| Expensive  UDF 1 Query 1Query 2 Query 3 Niagara Option #1  UDF 2  UDF 3 SA SA No shared subexpressions, so no shared work! Lineage Allows Join To Be Applied Just Once

27. 27 CACQ vs. NiagaraCQ Graph

28. 28 Conclusion CACQ: sharing and adaptivity for high performance monitoring queries over data streams Features – Adaptivity Adapt to changing query workload without costly multi-query reoptimization – Work sharing via tuple lineage Without constraining the available plans – Computation sharing via grouped filter – Storage sharing via SteMs Future Work – More sophisticated routing policies – Batching & query grouping – Better integration with historical results (Chandrasekaran, VLDB 2002)

29. 29 Questions? Shameless plug: check out my demo on query processing in sensor networks!

30. 30 S.bR.a RS Joins in CACQ CACQ uses Parallel Pipelined Joins – To avoid blocking Consider Symmetric Hash Join Buil d Probe

31. 31 Processing Joins Via State Modules Idea: Share join indices over base relations State Modules (SteMs) are: – Unary indexes (e.g. hash tables, trees) – Built on the fly (as data arrives) – Scheduled by CACQ as first class operators Based on symmetric hash join S.b = T.c Query 1 R.a = S.b Query 2 R S T S.bR.a T.c Buil d Prob e Buil d Prob e

32. 32 Experiment: Increased Scalability Workload, Per Query: 1-5 randomly selected range predicates of form ‘attr > x’ over 5 attributes. Predicates from the uniform distribution [0,100]. 50% chance of predicate over each attribute.

33. 33 Tuple & Query Data Structures Per tuple bitmaps: – queriesCompleted What queries has this tuple been output to or rejected by? – done What operators have been applied to this tuple? – ready What operators can be applied to this tuple? Per query bitmaps: – completionMask What operators must be applied to output a tuple to this query? Tuple [10, 1100, …] BitValue QueriesCompleted Query 11 Query 20 Done S.a Index1 S.b Index1 R.a – S.b Join0 UDF (R.a)0 Query [0110] BitValue completionMask S.a Index0 S.b Index1 R.a – S.b Join1 UDF (R.a)0

34. 34 n CACQ Query Model SELECT R.a, S.b from R, S where R.c = x and R.d[n] = S.e[m]  m S R Landmark queries Streaming answers Band Joins Windows in tuples or time n Probe into S