Learning From the Past: Automated Rule Generation for CEP - DEBS 2014

Learning From the Past:
Automated Rule Generation for CEP
G. Cugola
Politecnico
Milano
A. Margara
USI
Lugano
G. Tamburrelli
USI
Lugano

Complex Event Processing (CEP)
Complex Event
Processing
Complex Event
Processing
sources sinksrules

The Learning Problem
• Given a composite event CE
• Given a set of historical traces
– Positive traces: CE occurs at the end of the trace
– Negative traces: CE does not occur in the trace
• Derive a rule that describes the causal relation
between:
– A pattern of primitive events
– The occurrence of CE

Event Model
Temperature @10
(room=123, value=24.5)

Rule Languages
Oracle CEPOracle CEP
Microsoft
Stream Insight
Microsoft
Stream Insight
StreamStream
CayugaCayuga
IBM WSBEIBM WSBE
Stream MillStream Mill
AuroraAurora
BorealisBorealis
SASE+SASE+
PadresPadres
EsperEsper
Telegraph
CQ
Telegraph
CQ
NextCEPNextCEP
TESLATESLA
ETALISETALIS
TIBCO Business
Events
TIBCO Business
Events
Progress
Apama
Progress
Apama

CEP Operators
Define FIRE:
within 5 min
{ Smoke(area = $a) and Temp(value>40, area = $a)
and not Rain (mm>2, area = $a) }
where { Temp -> Smoke }
SelectionSelectionCombinationCombination
NegationNegation SequenceSequence
WindowWindow
ParameterParameter
AggregatesAggregates

Solution Strategy
• Modular architecture
– Ad-hoc learning components for each operator
– Easy to modify/replace a component
• Possibly with hints from domain experts
– Easy to add new types of operators
ParameterParameterSelectionSelection
CombinationCombination
NegationNegation
SequenceSequence
WindowWindow
AggregatesAggregates

Learning Algorithm
• Key idea:
– Each operator defines a set of constraints
• E.g., the selection operator defines:
– Which event types must appear
– Which attribute values they must include
– A positive trace satisfies all the constraints in a
rule (for each operator)
– We can learn the constraints in a rule by
intersecting the constraints satisfied in each
positive trace

Learning Algorithm
• Rule: A and B must occur
ZBA CE
Y XA B CE
X
YA B CE
1
2
1
3
A
B
1
2 3
ZX
YZYW W
K K

Learning Algorithm
• Rule: A and B must occur
ZBA CE
Y XA B CE
X
YA B CE
1
2
1
3
A
B
1
2 3
X
YZYW W
K K
Z
Z
• What we learn can be a superset of the actual
constraints
• Limited impact in practice

Machine Learning
• Our initial prototype relied on supervised
machine learning algorithms and tools
• Lessons learned
– Some operators (e.g., parameters) were difficult to
encode
• Need to explicitly allocate one variable for each possible
constraint
• Space explosion
– (Significantly) higher execution time
– Lower precision
• Intersection prevents this!

iCEP
• One module for each operator
• Filtering architecture
– Positive traces are “cleaned” at each step
– Pruning “unrequired” elements
Window
(Win) Learner
Events/Attributes
(Ev) Learner
Constraints
(Constr) Learner
Aggregates
(Aggr) Learner
Parameters
(Param) Learner
Sequences (Seq)
Learner
Negations (Neg)
Learner
Negative Traces
PositiveTraces

iCEP
Window
(Win) Learner
Events/Attributes
(Ev) Learner
Constraints
(Constr) Learner
Aggregates
(Aggr) Learner
Parameters
(Param) Learner
Sequences (Seq)
Learner
Negations (Neg)
Learner
Negative Traces
PositiveTraces

Events and Attributes Learner
• Assumes the size of the evaluation window is
known
• Extracts the set of relevant event types and
attributes
– By intersecting the types and attributes that
appear in all positive traces
• Only selected types and attributes are
considered in the following modules

Window Learner
• Assumes that the set of relevant types is
known
• Detects the smallest window that contains
such types in all positive traces

Events and Window Learners
• In absence of domain knowledge about event types and
window …
• … Events and Win learners work together iteratively
– Increasing the size of the window
– Computing the set of relevant types at each step
– The process stops when the number of relevant types stabilizes

Constraints and Aggregates Learners
• Extract constraints on the value of attributes
– Of individual events
– Of aggregations
• E.g., Maximum, Average value
• Users can specify a set of aggregation functions

Constraints and Aggregates Learners
1. Equality constraints
– Learn by intersection
• The same value appears in all positive traces
1. Inequality constraints (≠,<,>) for numeric
attributes
– Unknown relations / operators
• Min and Max values appearing in all positive traces
– Known relations / operators (from users)
• Learning algorithm base on Support Vector Machines

Parameters and Sequences Learners
• Learn by intersection
– Parameters constraints satisfied by all positive
traces
• Both equality and inequality relations
– Ordering constraints satisfied by all positive traces

Negation Learner
• Only component that looks into negative
traces
– Selects traces that satisfy all the constraints
identified so far
– Extracts common elements in such traces
• These elements may constribute to prevent the
occurrence of the composite event
• They will be negated in the derived rule

Evaluation
• Synthetic workloads
• Real data

Synthetic Workload
Number of Event Types 25
Distribution of Types Uniform
Number of Attributes per Event 3
Number of Constraints per Event 3
Average Window Size 10s
Average Distance Between Events 1s
Number of Parameter Constraints 0
Number of Sequence Constraints 0
Number of Aggregate Constraints 0
Number of Negation Constraints 0
Number of Positive Traces 1000
Recall Precision
0.98 0.94

Introducing Additional Constraints
Sequences Parameters
Aggregates

Presence of Negations
• We learn negation by intersection
– Looking at “common” elements in negative traces
• Multiple negations
– One negated element is sufficient for preventing the
occurrence of CE
– They are not possible to detect by intersection

Real Data
• Traffic monitoring system for public
transportation
• Rules to detect: delays from multiple bus lines
in a small time window
• Noisy data
– Not only exceptional events (delays) …
– … but also continuous operational information
from each and every bus line

Real Data
• Results in terms of precision and recall are
confimed
• Derived rules are noisy
– Include frequent events present in every trace
• A cleaning step could improve the quality of
rules

Conclusions - Lessons Learned
• First approach to automated rule generation
• Large solution space
– Many parameters to consider
• Difficult to encode in traditional machine learning
algorithms
• Modular approach
– Improved performance
– Improved accuracy
– Easier to add/replace single modules
• Integration with hints from domain experts

Future Work
• Address open problems
– Multiple negations
– Composite events that could be triggered by
multiple patterns (disjunction)
• Integrate additional operators
– E.g., detection of trends
• Develop techniques for rule cleaning
– Remove “noise”

www.inf.usi.ch/postdoc/margara

Learning From the Past: Automated Rule Generation for CEP - DEBS 2014

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Learning From the Past: Automated Rule Generation for CEP - DEBS 2014

Similaire à Learning From the Past: Automated Rule Generation for CEP - DEBS 2014 (20)

Dernier

Dernier (20)

Learning From the Past: Automated Rule Generation for CEP - DEBS 2014

Notes de l'éditeur