Slider is a system that enables incremental sliding window analytics over data streams in a transparent and efficient manner. It takes an unmodified batch-based data analytics application and automatically adapts it to perform incremental updates for sliding window computations. Slider uses self-adjusting contraction trees to break down reduce tasks and allow fine-grained change propagation, achieving speedups of up to 3.8x over basic contraction trees. It also leverages split processing to perform background pre-processing concurrently with foreground processing, improving performance by up to 30%. The initial overhead of Slider is modest, ranging from 2-38% for the first batch.

1. Slider
Incremental Sliding Window Analytics
Pramod Bhatotia
bhatotia@mpi-sws.org
MPI-SWS
Umut Acar
CMU
Flavio Junqueira
MSR Cambridge
Rodrigo Rodrigues
NOVA University of Lisbon
Hadoop Summit 2015

2. Data analytics systems
2
Raw data
Data analytics
system
Information
E.g. Web-crawl
E.g. computing PageRank
E.g. search
Spark Naiad Storm S4Hadoop

3. Design requirements
3
Recent trends
Sliding window
Streaming data
Incremental updates
+
Incremental sliding window analytics for data stream

4. State-of-the-art: Stream processing
4
mutable state
node 1
node 3
input
records
node 2
input
records Batch-based systems
Stream
Batch# nBatch# 1 Batch# 2 ……..
……..
M
M
M
M
M
M
M
M
M
R
R
R
R
Output
Input
Single
batch
Classification based on
programming model
E.g. Storm, S4, Naiad E.g. D-Streams
Trigger-based systems

5. Trade-offs for incremental updates
5
(+) efficient
(-) hard to design
(-) inefficient
(+) easy to design
Slider
(require dynamic algorithms) (re-compute from scratch)
Trigger-based systems Batch-based systems

6. Goals
1. Retain the advantages/simplicity of batch-based
approach
2. Achieve the efficiency of incremental processing for
sliding window analytics
6

7. Outline
• Motivation
• Basic design
• Slider design
• Evaluation
7

8. Our approach
• Take an unmodified data-parallel application
written assuming unchanging data
• Automatically adapt it for incremental sliding
window analytics
8

9. Behind the scenes
9
computation sub-computations dependence
graph
change
propagation
We follow this high-level approach for
batch-based stream processing
Step#1
divide
Step#2
build
Step #3
perform

10. Batch-based sliding window analytics
10
M M M M
R R R
Stream.…..
Window
Step#1: Divide the computation
Map & Reduce tasks
Step#2: Build the dependence graph
Data-flow graph of MapReduce

11. Step#3: Change propagation
11
B4B3B2B1… … Stream
M1 M2 M3 M4
R1 R2 R3
B5
addedremoved
window
M1 M5M5
Contraction
tree # 3
Contraction
tree # 1
Contraction
tree # 2
Replace Reduce tasks
with contraction trees

12. Outline
• Motivation
• Basic design
• Slider design
• Contraction tree
• Self-adjusting contraction tree
• Split processing
• Evaluation
12

13. Contraction tree
What: Breaks down the work done by a Reduce task
to allow fine-grained change propagation
How: Leverages Combiners at the Reducer site
13

14. “Zoom IN” with a single Reducer
14
M2 M3 M4 M1
B4B3B2B1 B5 Stream
window
M1
removed added
Contraction tree
Replace
M5
R

15. Example of contraction tree
15
Reduce task
Tree of
combiners
Map outputs

16. “Zoom IN” with a single Reducer
16
M2 M3 M4 M1
B4B3B2B1 B5 Stream
window
M1
removed added
Contraction tree
Replace
M5
R

17. Basic design w/ contraction tree
17Pramod Bhatotia
M2 M3 M4 M1
B4B3B2B1 B5 Stream
window
M1
removed added
M5
Path affected
by M1
Path affected
by M5

18. Limitation of the contraction tree
Naïve grouping of Combiner tasks may lead to
sub-optimal reuse of the memoized result
18
Self-adjusting contraction tree

19. Outline
• Motivation
• Basic design
• Slider design
• Contraction tree
• Self-adjusting contraction tree
• Split processing
• Evaluation
19

20. Self-adjusting contraction tree
The tree should have low depth
(implies short path length for re-computation)
Key ingredients:
• Balanced tree: sublinear updates w.r.t. window size
• Self-adjusting capability after change propagation
20

21. Self-adjusting contraction tree(s)
21
General case Fixed-width Append-only
Different modes of operation
Fixed-width

22. Fixed-width window slides
22

23. Rotating contraction tree
23

24. Rotating contraction tree
24
B4
Update path
for bucket 4
Memoized results
are reused

25. Outline
• Motivation
• Basic design
• Slider design
• Contraction tree
• Self-adjusting contraction tree
• Split processing
• Evaluation
25

26. Split processing
26
Background
pre-processing
Foreground
processing
Change propagation

27. Change propagation for bucket#4
27
Update path
for bucket 4
Memoized results
are reused

28. Split processing for bucket#4
28
Foreground
processing
Background
pre-processing

29. Outline
• Motivation
• Basic design
• Slider design
• Evaluation
29

30. Evaluating Slider
Goal: Determine how Slider works in practice
1. What are the performance benefits?
2. How effective is split processing?
3. What is the overhead for the initial run?
Case studies @ MPI-SWS
30
more results
in the paper

31. Q1: Performance gains
31
Speedup up to 3.8X w.r.t. basic contraction tree
0
0.5
1
1.5
2
2.5
3
3.5
4
Top-K Sub-string Matrix K-means KNN
Speedup
5% fixed-width change 25% fixed-width change

32. Q2: Split processing
32
Foreground processing is faster by 30% on avg.
0
0.2
0.4
0.6
0.8
1
K-means Top-K KNN Matrix Sub-string
Normalized
execution time
w/o split processing Background Foreground

33. Q3: Performance overheads
33
Overheads 2% to 38% for the initial run
0
5
10
15
20
25
30
35
40
K-means Top-K KNN Matrix Sub-string
Initial run
overhead (%)

34. Case studies
• Online Social Networks [IMC’11]
• Information propagation in Twitter
• Networked Systems [NSDI’10]
• Glasnost: Detecting traffic shaping
• Hybrid CDNs [NSDI’12]
• Reliable client accounting
34
Details in
the paper

35. Information propagation in Twitter
35
Speedup > 13X for ~5%window change
1
3
5
7
9
11
13
15
1
2
3
4
5
6
7
8
Week-1 Week-2 Week-3 Week-4
Speedup
Change(%)
Window change (%) Speedups

36. Summary
Slider enables incremental sliding window analytics
Transparently & efficiently
Slider design includes
Self-adjusting contractions trees for sub-linear updates
Split processing for background pre-processing
Multi-level trees for general data-flow programs (didn’t
cover in the talk!)
36

37. Incremental Sliding Window Analytics
Transparent + Efficient
More details in the paper published at
ACM/USENIX Middleware 2014
bhatotia@mpi-sws.org
37
Thanks!