1 Continuously Adaptive Continuous Queries (CACQ) over Streams Samuel Madden, Mehul Shah, Joseph Hellerstein, and Vijayshankar Raman Presented by: Bhuvan Urgaonkar

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 Outline Background – Motivation – Continuous Queries – Eddies CACQ – Contributions - Example driven explanation Results & Experiments

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

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 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! – Idea: adaptive heuristics

7 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

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

9 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)

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

11 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 b 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

12 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 R1R aa bb Q1Q2Q3 DoneQueriesComplete d

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 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 Q bb aa R bb aa R bb aa R Q1Q2Q3 R2R2 R2R2 R2R aa bb Q1Q2Q3 DoneQueriesComplete d R1R1 R1R1 R2R2 Reorder Operators!

14 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

15 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 > >7>1 Q1 Q2Q3

16 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

17 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

18 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.

19 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!

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

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

22 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

23 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

24 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

25 CACQ vs. NiagaraCQ Graph

26 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)