1. Chain: Operator Scheduling for Memory Minimization in Data Stream Systems Authors: Brian Babcock, Shivnath Babu, Mayur Datar, and Rajeev Motwani (Dept. Computer Science, Stanford University) SIGMOD 2003, June 9-12, San Diego, CA. This following slides were downloaded as is from: http://www.stanford.edu/~babcock/papers/chain.ppt Sincere thanks to all who made the slides!

2. Chain: Operator Scheduling for Memory Minimization in Data Stream Systems Brian Babcock, Shivnath Babu, Mayur Datar, and Rajeev Motwani

3. Data Streams are Bursty Data stream arrival rates are often: Fast Irregular Examples: Network traffic (IP, telephony, etc.) E-mail messages Web page access patterns Peak rate much higher than average rate 1-2 orders of magnitude Impractical to provision system for peak rate

4. Bursts Create Backlogs Arrival rate temporarily exceeds throughput Queues of unprocessed elements build up Two options when memory fills up Page to disk Slows system, lowers throughput Admission control (i.e. drop packets) Data is lost, answer quality suffers Our goal: reduce memory needed for queueing

5. Outline Problem Definition Intuition Behind the Solution Chain Scheduling Algorithm Near-Optimality of Chain Scheduling Open Problems

6. Problem Definition Inputs: Data flow path(s) consisting of sequences of operators For each operator we know: Execution time (per block) Selectivity σ Σ Query #1 σ σ Query #2 Stream Time: t 1 Selectivity: s 1 Time: t 2 Selectivity: s 2 Time: t 3 Selectivity: s 3 Time: t 4 Selectivity: s 4

7. Progress charts (0,0)(6,0) Time Block Size (0,1) (1,0.5) (4,0.25) Opt1 Opt2 Opt3 σ σ σ

8. Problem Definition Inputs: Data flow path(s) consisting of sequences of operators For each operator we know: Execution time (per block) Selectivity At each time step: Adversary may add blocks of tuples to initial input queue(s) Scheduler selects one block of tuples Selected block moves one step on its progress chart Objective: Minimize peak memory usage (sum of queue sizes) σ Σ Query #1 σ σ Query #2 Stream Time: t 1 Selectivity: s 1 Time: t 2 Selectivity: s 2 Time: t 3 Selectivity: s 3 Time: t 4 Selectivity: s 4

9. Main Solution Idea Fast, selective operators release memory quickly Therefore, to minimize memory: Give preference to fast, selective operators Postpone slow, unselective operators Greedy algorithm: Operator priority = selectivity per unit time (s i /t i ) Always schedule the highest-priority available operator Greedy doesn’t quite work… A “good” operator that follows a “bad” operator rarely runs The “bad” operator doesn’t get scheduled Therefore there is no input available for the “good” operator

10. Bad Example for Greedy Opt1 Opt2 Opt3 Time Block Size Tuples build up here

11. Chain Scheduling Algorithm Opt1 Opt2 Opt3 Lower envelope Time Block Size

12. Chain Scheduling Algorithm Calculate lower envelope Priority = |slope of lower envelope segment| Always schedule highest-priority available operator Break ties using operator order in pipeline Favor later operators

13. FIFO: Example (0,0)(6,0) (0,1) (1,0.5) (4,0.25) Opt1 Opt2 Opt3 Time Block Size

14. Chain: Example (0,0)(6,0) (0,1) (1,0.5) (4,0.25) Opt1 Opt2 Opt3 Lower envelope Time Block Size

15. Memory Usage

16. Chain is Near-Optimal Memory within constant factor of optimal offline algorithm Proof sketch: Greedy scheduling is optimal for convex progress charts “Best” operators are immediately available Lower envelope is convex Lower envelope closely approximates actual progress chart Proof on next slide… Theorem: Given a system with k queries, all operator selectivities ≤ 1, Let C(t) = # of blocks of memory used by Chain at time t. At every time t, any algorithm must use ≥ C(t) - k memory.

17. Lemma: Lower Envelope is Close to Actual Progress Chart At most one block in the middle of each lower envelope segment Due to tie-breaking rule (Lower envelope + 1) gives upper bound on actual memory usage Additive error of 1 block per progress chart Difference

18. Performance Comparison spike in memory due to burst

19. Open Problems Avoid starvation Introduce deadlines (maximum allowable latency) Handle sharing between query plans Shared computation Shared data (queues store pointers) Sliding-window joins between streams Time synchronization complicates scheduling Heuristics proposed in SIGMOD ‘03 paper

20. Thanks for Listening! http://www-db.stanford.edu/stream