ScaleJoin: a Deterministic, Disjoint-Parallel and Skew-Resilient Stream Join
Download as PPTX, PDF0 likes536 views
The document introduces ScaleJoin, a solution for deterministic and efficient stream joins that addresses challenges like scalability, high throughput, and low latency. It emphasizes the necessity for continuous data stream processing in applications such as sensor networks and outlines the procedural framework for handling incoming tuples. With a benchmark demonstrating 4 billion comparisons per second and low latency, ScaleJoin effectively manages the difficulties of parallel stream joins.
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
- 23. ScaleJoin Scalability – comparisons/second 2015-10-31 23 Number of PUs
- 24. ScaleJoin latency – milliseconds 2015-10-31 24 Number of PUs
- 25. ScaleJoin skew-resilience Constant distinct rates with peaks 2015-10-31 25
- 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
- 28. ScaleJoin: a Deterministic, Disjoint-Parallel and Skew-Resilient Stream Join Vincenzo Gulisano, Yiannis Nikolakopoulos, Marina Papatriantafilou, Philippas Tsigas Thank you! Questions? 2015-10-31 28
Editor's Notes
- #2: Welcome…
- #3: Agenda for this talk
- #4: Since this is about stream joins, it is legitimate to start asking ourselves what is data streaming?
- #5: 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
- #7: So, why are we in need of scalable parallelization approaches for stream joins? Present example
- #9: …
- #10: OK then, why Scalejoin? Let’s look in detail at what is the state of the art and what we did
- #11: So, let’s see how stream joins are actually implemented Example But wait, what happens if we get tuples in another order? Mmmmhhh
- #12: So, let’s see how stream joins are actually implemented Example But wait, what happens if we get tuples in another order? Mmmmhhh
- #14: 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
- #15: 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?
- #16: The queues! We parallelized the computation, but overlooked the communication We are still using a queue with its methods enqueue and dequeue
- #17: 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?
- #19: Then we can do something like that…
- #21: 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!
- #23: 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?)…
- #24: 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!
- #25: 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!
- #26: 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!