This is the presentation of the paper "ScaleJoin: a Deterministic, Disjoint-Parallel and Skew-Resilient Stream Join", presented by Vincenzo Gulisano, Yiannis Nikolakopoulos, Marina Papatriantafilou and Philippas Tsigas at the IEEE Big Data conference held in Santa Clara, 2015.
ScaleJoin: a Deterministic, Disjoint-Parallel and Skew-Resilient Stream Join
1. ScaleJoin: a Deterministic,
Disjoint-Parallel and Skew-Resilient
Stream Join
Vincenzo Gulisano, Yiannis Nikolakopoulos,
Marina Papatriantafilou, Philippas Tsigas
2015-10-31 1
Chalmers University
of technology
2. Agenda
• What is a stream join?
• Which are the challenges of a parallel stream join?
• Why ScaleJoin?
• How well does ScaleJoin addresses stream joins’
challenges?
• Conclusions
2015-10-31 2
3. Agenda
• What is a stream join?
• Which are the challenges of a parallel stream join?
• Why ScaleJoin?
• How well does ScaleJoin addresses stream joins’
challenges?
• Conclusions
2015-10-31 3
4. Motivation
Applications in sensor networks, cyber-physical
systems:
• large and fluctuating volumes of data generated
continuously
demand for:
• Continuous processing of data streams
• In a real-time fashion
Store-then-process is not feasible!!!
2015-10-31 4
5. What is a stream join?
2015-10-31 5
Data stream:
unbounded sequence of tuples
t1
t2
t3
t4
t1
t2
t3
t4
t1
t2
t3
t4
R S
Sliding
window Window
size WS
WSWR
Predicate P
6. Why parallel stream joins?
• WS = 600 seconds
• R receives 500 tuples/second
• S receives 500 tuples/second
• WR will contain 300,000 tuples
• WS will contain 300,000 tuples
• Each new tuple from R gets compared with
all the tuples in WS
• Each new tuple from S gets compared with
all the tuples in WR
… 300,000,000 comparisons/second!
t1
t2
t3
t4
t1
t2
t3
t4
R S
WSWR
2015-10-31 6
7. Agenda
• What is a stream join?
• Which are the challenges of a parallel stream join?
• Why ScaleJoin?
• How well does ScaleJoin addresses stream joins’
challenges?
• Conclusions
2015-10-31 7
8. Which are the challenges of a parallel stream join?
Scalability
High
throughput
Low latency
Disjoint
parallelism
Skew
resilience
Determinism
2015-10-31 8
9. Agenda
• What is a stream join?
• Which are the challenges of a parallel stream join?
• Why ScaleJoin?
• How well does ScaleJoin addresses stream joins’
challenges?
• Conclusions
2015-10-31 9
10. The 3-step procedure (sequential stream join)
For each incoming tuple t:
1. compare t with all tuples in opposite window given predicate P
2. add t to its window
3. remove stale tuples from t’s window
Add tuples to S
Add tuples to R
Prod
R
Prod
S
Consume resultsConsPU
2015-10-31 10
We assume each
producer delivers tuples
in timestamp order
11. The 3-step procedure, is it enough?
Scalability
High
throughput
Low latency
Disjoint
parallelism
Skew
resilience
Determinism
2015-10-31 11
t1
t2
t1
t2
R S
WSWR
t3
t1
t2
t1
t2
R S
WSWR
t4
t3
12. Enforcing determinism in sequential stream joins
• Next tuple to process = earliest(tS,tR)
• The earliest(tS,tR) tuple is referred to as the next ready tuple
• Process ready tuples in timestamp order Determinism
PU
tS tR
2015-10-31 12
13. Deterministic 3-step procedure
Pick the next ready tuple t:
1. compare t with all tuples in opposite window given predicate P
2. add t to its window
3. remove stale tuples from t’s window
Add tuples to S
Add tuples to R
Prod
R
Prod
S
Consume resultsConsPU
2015-10-31 13
14. Shared-nothing parallel stream join
(state-of-the-art)
Prod
R
Prod
S
PU1
PU2
PUN
… Cons
Add tuple to PUi S
Add tuple to PUi R
Consume results
Pick the next ready tuple t:
1. compare t with all tuples in opposite window given P
2. add t to its window
3. remove stale tuples from t’s window
Chose a PU
Chose a PU
Take the next
ready output tuple
Scalability
High
throughput
Low latency
Disjoint
parallelism
Skew
resilience
Determinism
2015-10-31 14
Merge
15. Shared-nothing parallel stream join
(state-of-the-art)
Prod
R
Prod
S
PU1
PU2
PUN
…
2015-10-31 15
enqueue()
dequeue()
ConsMerge
16. From coarse-grained to fine-grained synchronization
Prod
R
Prod
S
PU1
PU2
PUN
…
Cons
2015-10-31 16
17. ScaleGate
2015-10-31 17
addTuple(tuple,sourceID)
allows a tuple from sourceID to be merged by ScaleGate in the
resulting timestamp-sorted stream of ready tuples.
getNextReadyTuple(readerID)
provides to readerID the next earliest ready tuple that has not been
yet consumed by the former.
https://github.com/dcs-chalmers/ScaleGate_Java
18. ScaleJoin
Prod
R
Prod
S
PU1
PU2
PUN
…
Cons
Add tuple SGin
Add tuple SGin
Get next ready
output tuple
from SGout
Get next ready input tuple from SGin
1. compare t with all tuples in opposite window given P
2. add t to its window in a round-robin fashion
3. remove stale tuples from t’s window
2015-10-31 18
SGin SGout
Steps for PU
19. 2015-10-31 19
t1
t2
R S
WR
t3
t4
R S
t4
t1
WR
R S
t4
t2
WR
R S
t4
WR
t3
Sequential stream join:
ScaleJoin with 3 PUs:
ScaleJoin (example)
20. ScaleJoin
Prod
R
Prod
S
PU1
PU2
PUN
… Cons
Add tuple SGin
Add tuple SGin
Get next ready
output tuple
from SGout
2015-10-31 20
SGin SGout
Scalability
High
throughput
Low latency
Disjoint
parallelism
Skew
resilience
Determinism
Prod
S
Prod
S
Prod
R Get next ready input tuple from SGin
1. compare t with all tuples in opposite window given P
2. add t to its window in a round robin fashion
3. remove stale tuples from t’s window
Steps for PUi
21. Agenda
• What is a stream join?
• Which are the challenges of a parallel stream join?
• Why ScaleJoin?
• How well does ScaleJoin addresses stream joins’
challenges?
• Conclusions
2015-10-31 21
22. Evaluation setup
• Common benchmark
• Implemented in Java
• Evaluation platform
– NUMA architecture: 2.6 GHz AMD Opteron 6230 (48 cores over 4
sockets), 64 GB of memory
– Architecture with Hyper Threading: 2.0 GHz Intel Xeon E5-2650 (16
cores over 2 sockets), 64 GB of memory
2015-10-31 22
t1
t2
t3
t4
t1
t2
t3
t4
R S
R: <timestamp,x,y,z> S: <timestamp,a,b,c,d>
P: a−10≤x≤a+10 AND b−10≤y≤b+10
26. Agenda
• What is a stream join?
• Which are the challenges of a parallel stream join?
• Why ScaleJoin?
• How well does ScaleJoin addresses stream joins’
challenges?
• Conclusions
2015-10-31 26
27. Conclusions
• ScaleJoin: a Deterministic, Disjoint-Parallel and
Skew-Resilient Stream Join
• Challenges of parallel
stream joins
• Fine-grained synchronization (ScaleGate)
• 4 billion comparisons/second, with latency lower
than 60 milliseconds
Scalability
High
throughput
Low latency
Disjoint
parallelism
Skew
resilience
Determinism
2015-10-31 27
Since this is about stream joins, it is legitimate to start asking ourselves what is data streaming?
This is the IEEE Big Data conference, so I get you heard before about Big Data
What we know is the we have applications … and store-then-process is not always an option
Traditional way DB … replaced by data streaming, main memory first the query than the data continuously
So, why are we in need of scalable parallelization approaches for stream joins?
Present example
…
OK then, why Scalejoin? Let’s look in detail at what is the state of the art and what we did
So, let’s see how stream joins are actually implemented
Example
But wait, what happens if we get tuples in another order?
Mmmmhhh
So, let’s see how stream joins are actually implemented
Example
But wait, what happens if we get tuples in another order?
Mmmmhhh
Ok, so deterministic 3-step procedure looks like this
Now let’s try to parallelize this, and let’s do it as it has been done before
Ok, so deterministic 3-step procedure looks like this
Now let’s try to parallelize this, and let’s do it as it has been done before
First, we need to do more operations, this affects the latency for sure
But what’s worst is that we introduce a new bottleneck, the output thread and ready tuples
And this actually breaks disjoint parallelism too…
Finally, is not really skew-resilient
So, what’s the problem? Are we doing it in the wrong way or are we forgetting something?
Look at the data structures, we parallelize by parallelizing the computation, but what about the communication?
The queues!
We parallelized the computation, but overlooked the communication
We are still using a queue with its methods enqueue and dequeue
Let’s be creative, let’s assume they actually share something more powerful, that let’s them communicate and synchronize in a more efficient way
What do we want from such communication and synchronization ds?
Then we can do something like that…
Here we can basically discuss why this addresses the different challenges, one by one…
It gets even better, you can even have multiple physical producers for S and R!!!! And this is actually important because in the real world it will be like that!
OK, so this is the benchmark we used…
Implemented in Java
And we evaluated it with 2 different systems (SAY WHY TWO SYSTEMS IF THEY ASK OR JUST SAY IT?)…
Here we want to check the number of comparisons per second sustained by ScaleJoin
After checking the ones obtained for a single thread, we computed the expected max and then observed ones for 3 different window sizes
As you can see…
Up to 4 billion comparison/second!
This is the processing latency we get (in milliseconds)
As you can see, even when we have 48 PUs (and notice that this means more threads than cores, since we have also injectors and receivers…) less than 60 – Actually, when we do not spawn too many threads we are talking of 30 milliseconds
Might seem counterintuitive that latency grows with PU, but that’s because of determinism!
In this case we have two different rates for R and S (notice actually the multiple physical streams!) and then peaks over time
As you can see, comparisons of course increase when we have a peak, but nevertheless the overall work is very well balanced, the standard deviation among the Pus is less than 0.2% even during the spikes!!! Skew-resilience!