1 / 19

Integrating Scale Out and Fault Tolerance in Stream Processing using Operator State Management

Integrating Scale Out and Fault Tolerance in Stream Processing using Operator State Management. with Raul Castro Fernandez* Matteo Migliavacca + and Peter Pietzuch * * Imperial College London, + Kent Univerisity. Big data ….  processing infrastructure for big data analysis.

kashley
Download Presentation

Integrating Scale Out and Fault Tolerance in Stream Processing using Operator State Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Integrating Scale Out and Fault Tolerance in Stream Processing using Operator State Management with Raul Castro Fernandez* MatteoMigliavacca+ and Peter Pietzuch* *Imperial College London, +Kent Univerisity

  2. Big data …  processing infrastructure for big data analysis … in numbers: • 2.5 billions on gigabytes of data every day (source IBM) • LSST telescope, Chile 2016, 30 TB nightly … come from everywhere: • web feeds, social networking • mobile devices, sensors, cameras • scientific instruments • online transactions (public and private sectors) … have value: • Global Pulse forum for detecting human crises internationally • real-time big data analytics in UK £25 billions  £216 billions in 2012-17 • recommendation applications (LinkedIn, Amazon)

  3. A black-box approach for big data analysis Stream Processing System time • users issue analysisquerieswith real-time semantics • streamsof data updates, time-varying rates, generated in real-time • streams of result data • processing in near real-time

  4. Distributed Stream Processing System • queries consist of operators (join, map, select, ..., UDOs) • operators form graphs • operators process streams of tuples on-the-fly • operators span nodes

  5. Elastic DSPSs in the Cloud Real-time big data analysis challenge traditional DSPS: ? what about continuous workload surges? ? what about real-time resource allocation to workload variations? ? keeping the state correct forstateful operators? Massively scalable , cloud-based DSPSs [SIGMOD 2013] • gracefully handles stateful operators’ state • operator state management for combined scale out and fault tolerance • SEEP system and evaluation • related work • future research directions

  6. Stream Processing in the Cloud ? How do we build a stream processing platform in the Cloud? • Intra-query parallelism: • provisioning for workload peaks unnecessarily conservative • Failure resilience: • active fault-tolerance needs 2x resources • passive fault-tolerance leads to long • recovery times • dynamic scale out: increase resources when peaks appear • hybrid fault-tolerance: low resource overhead with fast recovery  Both mechanisms must support stateful operators clouds provide infinite pools of resources

  7. Stateless vsStateful Operators operator state: a summary of past tuples’ processing 7 9 7 1 5 9 filter > 5 stateless: • failure recovery • scale out 9 9 filter filter (the, 10) (with, 5) (the, 2) !=12 (with, 1) !=6 (the, …) (the, 10) (with, 5) the with the counter with stateful: • failure recovery • scale out (with, …) counter counter

  8. State Management processing state: (summary of past tuples’ processing) routing state: (routing of tuples) B A buffer state: (tuples) C • operator state is an external entity managed by the DSPS • primitives for state management • mechanisms (scale out, failure recovery) on top of primitives • dynamic reconfiguration of the dataflow graph

  9. State Management Primitives • checkpoint takes snapshot of state and makes it externally available • backup moves copy of state from one operator to another • restore • partition A A splits state in a semantically correct fashion for parallel processing B B

  10. State Management Scale Out, Stateful Ops periodically, stateful operators checkpoint and back up state to designated upstream backup node, in memory backup node already has state of operator to be parallelised • backup A • checkpoint A A A A A A’ B upstream ops send unprocessed tuples to update checkpointed state • restore A’ • partition scale out A A’ new operator  How do we partition stateful operators?

  11. Partitioning Stateful Operators buffer state t=1, key=c, “computer” t=3, key=c, “cambridge” processing state t=3, (c, computer:1, cambridge:1) t=1, “computer” t=2, “laboratory” t=3, “cambridge” counter A splitter counter (a  k), A (l  z), A’ routing state A’ t=2, (l, laboratory:1) t=2, key=l, “laboratory” 1. Processing state modeled as (key, value) dictionary 2. State partitioned according to key k of tuples 3. Tuples will be routed to correct operator as of k

  12. Passive Fault-Tolerance Model ACKs data C A B D d a b c • recreate operator state by replaying tuples after failure: • upstream backup: sends acks upstream for tuples processed downstream • may result in long recovery times due to large buffers: • system is reprocessing streams after failure  inefficient

  13. Recovering using State Management (R+SM) A A A A A change routingstate A A’ new instance state is restored and unprocessed tuples are replayed from buffer • same primitives for parallel recovery • Benefit from state management primitives: • use periodically backed up state on upstream node to recover faster • trim buffers at backup node • same primitives as in scale out

  14. State Management in Action: SEEP dynamic Scale Out: detect bottleneck , add new parallelised operator (2) failure Recovery: detect failure, replace with new operator (1) (2)

  15. Dynamic Scale Out: Detecting bottlenecks 85% 35% 30% CPU utilisation report 35% 30% 85% bottleneckdetector logical infrastructure view

  16. The VM Pool: Adding operators monitoring information fault detector bottleneckdetector VM2 VM2 VM3 VM1 (dynamic pool size) virtual machine pool provision VM from cloud (order of mins) add new VM to pool Cloud provider problem: allocating new VMs takes minutes...

  17. Experimental Evaluation • Goals: • investigate effectiveness of scale out mechanism • recovery time after failure using R+SM • overhead of state management • Scalable and Elastic Event Processing (SEEP): • implemented in Java; Storm-like data flow model • Sample queries + workload • Linear Road Benchmark (LRB) to evaluate scale out [VLDB’04] • provides an increasing stream workload over time • query with 8 operators, 3 are stateful; SLA: results < 5 secs • Windowed word count query (2 ops) to evaluate fault tolerance • induce failure to observe performance impact • Deployment on Amazon AWS EC2 • sources and sinks on high-memory double extra large instances • operators on small instances

  18. Scale Out: LRB Workload • scales to load factor L=350 with 50 VMs on Amazon EC2 • (automated query parallelisation, • scale out policy at 70%) • L=512 highest result [VLDB’12] • (hand-crafted query on cluster) scale out leads to latency peaks, but remains within LRB SLA • SEEP scales out to increasing workload in the Linear Road Benchmark

  19. Conclusions • Stream processing will grow in importance: • handling the data deluge • enables real-time response and decision making • Integrated approach for scale out and failure recovery: • operator state an independent entity • primitives and mechanisms • Efficient approach extensible for additional operators: • effectively applied to Amazon EC2 running LRB • parallel recovery

More Related