Building User-defined Runtime Adaptation Routines for Stream Processing Applications

System S Project | IBM Research

© 2012 IBM Corporation – All Rights Reserved

Building User-defined Runtime Building User-defined Runtime Adaptation Routines forAdaptation Routines forStream Processing ApplicationsStream Processing Applications

Gabriela Jacques-Silva, Bugra Gedik, Gabriela Jacques-Silva, Bugra Gedik, Rohit Wagle, Kun-Lung Wu, Rohit Wagle, Kun-Lung Wu, Vibhore KumarVibhore Kumar



Outline

Motivation

Challenge for orchestration

Building a management policy

Use case

2



In System S, users build streaming applications as data flow graphs

3

operator

stream connection

composite

processing element (PE)



Streaming applications have single deployment mode

4

Application Manager

Application Manager

start PEs

submitapplication



Users want adaptability, but currently this requires ad-hoc solutions

5

Application Manager

Application Manager

submitapplication

start PEs

sleep, cat,grep, cut, …



Orchestrator controls the life-cycle of an application via event handling

6

Application Manager

Application Manager

submitorchestrator

submit application

onStart:

submitJob(MyApp);

onOperatorMetric:

…

onPEFailure:

…

onUserEvent:

…

orchestrator

Use cases-Recovery coordination on operator failures-Operator adaptation due to metric measurement values-Incremental job deployment based on runtime learning

Use cases-Recovery coordination on operator failures-Operator adaptation due to metric measurement values-Incremental job deployment based on runtime learning



Events and actions occur at the physical level, but users are familiar with logical view

7

composite1

composite2

op3’’ op6’’

op4’’

op5’’

op4’

op5’

op6’op3’

Logical view

op1

op2

op2

op3’’ op6’’

op4’’

op5’’

op4’

op5’

op6’op3’

Physical view

op1

op2

op2

PE 1

PE 2

PE 3

PE 4

Host A

Host B

Orchestrator maintains an in-memory application representation to disambiguate logical and physical views when necessary.

Orchestrator maintains an in-memory application representation to disambiguate logical and physical views when necessary.



Developers register events of interest based on the logical view of the application

8

void MyOrca::handleOrcaStart(

const OrcaStartContext & context) {

PEFailureScope greenS(“green”);

PEFailureScope blueS(“blue”);

greenS.addCompositeInstanceFilter(“sample::greenComp”);

_orca->registerEventScope(greenS);

blueS.addOperatorInstanceFilter(“sample::blueOp”);

_orca->registerEventScope(blueS);

id = submitJob(sample::MyMainComp);

}



On event delivery, we provide a context to understand logical and physical views

9

void MyOrca::handlePEFailure(

const PEFailureContext & context)

if(context.hasScope(“green”)) {

list<PEID> pes = new list<PEID>();

_orca->getPEsWithCompositeInstance(

pes, “sample::greenComp”);

_orca->restartPEs(pes);

} else {

_orca->executeCommand(“./myRecoveryHelper”);

_orca->restartPE(context.getPEId());

}

}

PE failure context: - Matched scopes - Application name - Job ID - PE ID - Reason

PE failure context: - Matched scopes - Application name - Job ID - PE ID - Reason



Orchestrator allows management of multiple streaming applications

10

- Dependency relations- Uptime requirements- Garbage collectable

- Dependency relations- Uptime requirements- Garbage collectable



Developer configures application requirements and specifies its dependency

11



AppConfig fb(“Facebook”, “sample::Facebook”,

true, 60.0);

AppConfig tw(“Twitter”, “sample::Twitter”,

false);

AppConfig sc(“Social”, “sample::SNetwork”,

true, 60.0);

_orca->registerDependency(sc, fb, 10.0);

_orca->registerDependency(sc, tw, 10.0);

_orca->submitJob(sc);

}

T, 60

F, 0

T, 60

10.0

10.0



Orchestrator starts applications according to their dependencies and uptime requirements

12

T, 60

F, 0

T, 60

10.0

10.0

Orchestrator log-10:00:00 AM – “Facebook” submitted-10:00:02 AM – “Twitter” submitted-10:00:12 AM – “Social” submitted

Orchestrator log-10:00:00 AM – “Facebook” submitted-10:00:02 AM – “Twitter” submitted-10:00:12 AM – “Social” submitted



…

_orca->registerDependency(sc, fb, 10.0);

_orca->registerDependency(sc, tw, 10.0);

_orca->submitJob(sc);

}



Unused applications are automatically cancelled according to their configurations and dependencies

13

void MyOrca::handleSomeEvent(

const SomeEventContext & context) {

…

_orca->cancelJob(sc);

}

T, 60

F, 0

T, 60

10.0

10.0

Orchestrator log-11:00:00 AM – “Social” cancelled-11:01:00 AM – “Facebook” cancelled

Orchestrator log-11:00:00 AM – “Social” cancelled-11:01:00 AM – “Facebook” cancelled



Example demonstrator uses custom operator metrics to adapt a Sentiment Analysis applications

14

SentimentAnalysis

SentimentAnalysis

Product Cause Sentiment

iPhone screen -

iPhone AppStore +

iPhone ? -

iPhone camera -

iPhone ? -Model computation



Orchestrator helped streaming application to adapt to the incoming data distribution

15

Actuation threshold

new stream oftweets injected

MapReducejob submitted

New modelloaded



Summary

System S hides the complexity of parallel and distributed systems

– Orchestrator must open this abstraction to allow appropriate event handling and actuation

APIs for event registration based on logical view

Event delivery includes context to understand physical view

Future work

– Add orchestrator concepts to SPL

– Use static analysis to automatically infer event scope

16



Building User-defined Runtime Building User-defined Runtime Adaptation Routines forAdaptation Routines forStream Processing ApplicationsStream Processing Applications

Gabriela Jacques-Silva, Bugra Gedik, Gabriela Jacques-Silva, Bugra Gedik, Rohit Wagle, Kun-Lung Wu, Rohit Wagle, Kun-Lung Wu, Vibhore KumarVibhore Kumar

Building User-defined Runtime Adaptation Routines for Stream Processing Applications

Documents

Transcript of Building User-defined Runtime Adaptation Routines for Stream Processing Applications