the design of the borealis stream processing engine n.
Download
Skip this Video
Download Presentation
The Design of the Borealis Stream Processing Engine

Loading in 2 Seconds...

play fullscreen
1 / 33

The Design of the Borealis Stream Processing Engine - PowerPoint PPT Presentation


  • 134 Views
  • Uploaded on

The Design of the Borealis Stream Processing Engine. CIDR 2005 Brandeis University, Brown University, MIT. Kang, Seungwoo 2005.3.15. Ref. http://www-db.cs.wisc.edu/cidr/presentations/26 Borealis.ppt. One-line comment.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'The Design of the Borealis Stream Processing Engine' - kamal


Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
the design of the borealis stream processing engine

The Design of the Borealis Stream Processing Engine

CIDR 2005

Brandeis University, Brown University, MIT

Kang, Seungwoo

2005.3.15

Ref. http://www-db.cs.wisc.edu/cidr/presentations/26 Borealis.ppt

one line comment
One-line comment
  • This paper presents an overview of the design for Borealis distributed stream processing engine with new features and mechanisms
outline
Outline
  • Motivation and Goal
  • Requirements
  • Technical issues
    • Dynamic revision of query results
    • Dynamic query modification
    • Flexible and scalable optimization
    • Fault tolerance
  • Conclusion
motivation and goal
Motivation and Goal
  • Envision the second-generation SPE
    • Fundamental requirements of many streaming applications not supported by first-generation SPE
    • Three fundamental requirements
      • Dynamic revision of query results
      • Dynamic query modification
      • Flexible and scalable optimization
  • Present the functionality and preliminary design of Borealis
requirements
Requirements
  • Dynamic revision of query results
  • Dynamic query modification
  • Flexible and highly scalable optimization
changes in the models
Changes in the models
  • Data model
    • Revision support
      • Three types of messages
  • Query model
    • Support revision processing
      • Time travel, CP views
    • Support modification of Op box semantic
      • Control lines
  • QoS model
    • Introduce QoS metrics in tuple basis
      • Each tuple (message) holds VM (Vector of Metrics)
      • Score function
architecture of borealis
Architecture of Borealis

Modify and extend both systems, Aurora and Medusa, with a set of features and mechanisms

dynamic revision of query results
Dynamic revision of query results
  • Problem
    • Corrections of previously reported data from data source
    • Highly volatile and unpredictable characteristics of data sources like sensors
      • Late arrival, out-of-order data
    • Just accept approximate or imperfect results
  • Goal
    • Support to process revisions and correct the previous output result
causes for tuple revisions

(3pm,$11)

(2pm,$12)

(2:25,$9)

(4:15,$10)

(4:05,$11)

(1pm,$10)

Average

price

1 hour

Causes for Tuple Revisions
  • Data sources revise input streams:

“On occasion, data feeds put out a faulty price [...] and send a correction within a few hours” [MarketBrowser]

  • Temporary overloads cause tuple drops
  • Data arrives late, and miss its processing wnd
new data model for revisions
New Data Model for Revisions

header

data

  • time: tuple timestamp
  • type: tuple type
    • insertion, deletion, replacement
  • id: unique identifier of tuple on stream

(time,type,id,a1,...,an)

revision processing in borealis

(3pm,$11)

(2pm,$11)

(2pm,$12)

(3pm,$11)

(2:25,$9)

(1pm,$10)

(2pm,$12)

Average

price

Average

price

1 hour

1 hour

Revision Processing in Borealis
  • Closed model: revisions produce revisions
revision processing in borealis1
Revision Processing in Borealis
  • Connection points (CPs) store history (diagram history with history bound)
  • Operators pull the history they need

Input queue

Operator

Stream

S

CP

Most recent tuple in history

Oldest tuple

in history

Revision

discussion
Discussion
  • Runtime overhead
    • Assumption
      • Input revision msg < 1%
      • Revision msg processing can be deferred
    • Processing cost
    • Storage cost
  • Application’s needs / requirements
    • Whether it is interested in revision msg or not
    • What to do with revision msg
      • Rollback, compensation ??
    • Application’s QoS requirement
    • Delay bound
dynamic query modification
Dynamic query modification
  • Problem
    • Change certain attributes of the query at runtime
      • E.g. network monitoring
    • Manual query substitutions – high overhead, slow to take effect (starting with an empty state)
  • Goal
    • Low overhead, fast, and automatic modifications
  • Dynamic query modification
    • Control lines
      • Provided to each operator box
      • Carry messages with revised box parameters (window size, filter predicate) and new box functions
    • Timing problem
      • Specify precisely what data is to be processed according to what control parameters
      • Data is ready for processing too late or too early
        • old data vs. new parameter -> buffered old parameters
        • new data vs. old parameter -> revision message and time travel
time travel
Time travel
  • Motivation
    • Rewind history and then repeat it
    • Move forward into the future
  • Connection Point (CP)
  • CP View
    • Independent view of CP
    • View range
      • Start_time
      • Max_time
    • Operations
      • Undo: deletion message to roll back the state to time t
      • Replay
    • Prediction function for future travel

1

2

3

4

5

6

2

3

4

3

4

5

6

discussion1
Discussion
  • How to determine whether timing problem occurs or not
    • Too early: Lookup data buffered in CP
    • Too late: Checking timestamp of the tuple
    • Checking overhead
  • “Performed on a copy of some portion of the running query diagram, so as not to interfere with processing of the running query diagram”
    • Who makes a copy, when, how to make? How to manage?
  • Future time travel
    • When is it useful?
    • E.g alarming ?
optimization in a distributed spe
Optimization in a Distributed SPE
  • Goal: Optimized resource allocation
  • Challenges:
    • Wide variation in resources
      • High-end servers vs. tiny sensors
    • Multiple resources involved
      • CPU, memory, I/O, bandwidth, power
    • Dynamic environment
      • Changing input load and resource availability
    • Scalability
      • Query network size, number of nodes
quality of service
Quality of Service
  • A mechanism to drive resource allocation
  • Aurora model
    • QoS functions at query end-points
    • Problem: need to infer QoS at upstream nodes
  • An alternative model
    • Vector of Metrics (VM) carried in tuples
      • Content: tuple’s importance, or its age
      • Performance: arrival time, total resource consumed, ..
    • Operators can change VM
    • A Score Function to rank tuples based on VM
    • Optimizers can keep and use statistics on VM
example application warfighter physiologic status monitoring wpsm

State

Confidence

Area

Thermal

Hydration

Cognitive

Life Signs

Wound Detection

90%

60%

100%

90%

80%

Physiologic

Models

S

S

S

Example Application: Warfighter Physiologic Status Monitoring (WPSM)
slide20

VM

([age, confidence], value)

HRate

Model1

RRate

Merge

Model2

Temp

Sensors

Models may change confidence.

SF(VM) = VM.confidence x ADF(VM.age)

Score Function

age decay function

borealis optimizer hierarchy
Borealis Optimizer Hierarchy

End-point Monitor(s)

Global Optimizer

Neighborhood Optimizer

Local Monitor

Local Optimizer

Borealis Node

statistics

trigger

decision

optimization tactics
Optimization Tactics
  • Priority scheduling - Local
  • Modification of query plans - Local
    • Changing order of commuting operators
    • Using alternate operator implementations
  • Allocation of query fragments to nodes - Neighborhood, Global
  • Load shedding - Local, Neighborhood, Global
priority scheduling
Priority scheduling
  • Highest QoS Gradient box
    • Evaluate the predicted-QoS score function on each message with values in VM
    • average QoS Gradient for each box
      • By comparing average QoS-impact scores between the inputs and outputs of each box
  • Highest QoS-impact message from the input queue
    • Out-of-order processing
    • Inherent load shedding behavior
correlation based load distribution

A

C

B

D

S1

S2

A

B

S1

Connected Plan

Cut Plan

C

D

r

r

S2

2cr

2r

2r

4cr

3cr

3cr

Correlation-based Load Distribution
  • Under the situation that network BW is abundant and network transfer delays are negligible
  • Goal: Minimize end-to-end latency
  • Key ideas:
    • Balance load across nodes to avoid overload
    • Group boxes with small load correlation together
    • Maximize load correlation among nodes
load shedding
Load Shedding
  • Goal: Remove excess load at all nodes and links
  • Shedding at node A relieves its descendants
  • Distributed load shedding
    • Neighbors exchange load statistics
    • Parent nodes shed load on behalf of children
    • Uniform treatment of CPU and bandwidth problem
  • Load balancing or Load shedding?
local load shedding

Node A

Node B

4C

C

r1

r2

App1

3C

C

r1

r2

App2

Local Load Shedding

Goal:

Minimize

total loss

r2’

25%

58%

CPU Load = 5Cr1, Cap = 4Cr1

CPU Load = 4Cr2, Cap = 2Cr2

CPU Load = 3.75Cr2, Cap = 2Cr2

No overload

No overload

A must shed 20%

B must shed 50%

A must shed 20%

A must shed 20%

B must shed 47%

slide27

Node A

Node B

4C

C

r1

r2

App1

3C

C

r1

r2

App2

Distributed Load Shedding

Goal:

Minimize

total loss

r2’

9%

r2’’

64%

CPU Load = 5Cr1, Cap = 4Cr1

CPU Load = 4Cr2, Cap = 2Cr2

No overload

No overload

A must shed 20%

B must shed 50%

A must shed 20%

A must shed 20%

smaller

total loss!

extending optimization to sensor nets

data

Proxy

control

Sensors

control message from the optimizer

Extending Optimization to Sensor Nets
  • Sensor proxy as an interface
  • Moving operators in and out of the sensor net
  • Adjusting sensor sampling rates
discussion2
Discussion
  • QoS-based optimization
    • QoS score calculations, statistics maintaining
      • tuple basis
      • Fine-grained but lots of processing
    • Application’s burden
      • QoS specifications
      • How to facilitate the task?
fault tolerance through replication

Node 3

U

m

U

S

m

Node 3’

Node 1’

Node 2’

U

m

s3’

Fault-Tolerance through Replication
  • Goal: Tolerate node and network failures

s3

Node 1

Node 2

U

S

m

s1

s2

s4

fault tolerance approach
Fault-Tolerance Approach
  • If an input stream fails, find another replica
  • No replica available, produce tentative tuples
  • Correct tentative results after failures

STABLE

UPSTREAM

FAILURE

Missing or tentative inputs

Failure heals

Another upstream failure in progress

Reconcile state

Corrected output

STABILIZING

conclusions
Conclusions
  • Next generation streaming applications require a flexible processing model
    • Distributed operation
    • Dynamic result and query modification
    • Dynamic and scalable optimization
    • Server and sensor network integration
    • Tolerance to node and network failures
  • http://nms.lcs.mit.edu/projects/borealis
discussion3
Discussion
  • Distributed environment
    • Load management
    • Fault tolerance
    • How about data routing / forwarding issue ??
  • Other problems not tackled?