modeling informa9on flow processing systems
play

Modeling Informa9on Flow Processing Systems G. Cugola - PowerPoint PPT Presentation

Stream and Complex Event Processing Modeling Informa9on Flow Processing Systems G. Cugola E. Della Valle A. Margara


  1. Our ¡goal ¡ We ¡would ¡like ¡to ¡compare ¡different ¡systems ¡in ¡a ¡precise ¡way ¡ • We ¡would ¡like ¡to ¡compare ¡different ¡approaches ¡in ¡a ¡precise ¡way ¡ • We ¡would ¡like ¡to ¡help ¡people ¡coming ¡from ¡different ¡areas ¡communicate ¡ • and ¡compare ¡their ¡work ¡with ¡others ¡ We ¡would ¡like ¡to ¡isolate ¡the ¡open ¡issues ¡from ¡those ¡already ¡solved ¡ • We ¡would ¡like ¡to ¡precisely ¡iden9fy ¡the ¡challenges ¡ • We ¡would ¡like ¡to ¡isolate ¡the ¡best ¡part ¡of ¡the ¡various ¡approaches… ¡ • … ¡finding ¡a ¡way ¡to ¡combine ¡them ¡ • We ¡need ¡a ¡ modeling ¡framework ¡ that ¡could ¡accommodate ¡all ¡the ¡proposals ¡ ¡ ¡ G. ¡Cugola, ¡A. ¡Margara: ¡"Processing ¡Flows ¡of ¡Informa>on: ¡From ¡Data ¡Stream ¡to ¡Complex ¡ Event ¡Processing”. ¡ ACM ¡Compu)ng ¡Surveys , ¡44(3), ¡ACM ¡Press, ¡June ¡2012 ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 13 ¡

  2. Forget ¡your ¡own ¡vocabulary ¡ (temporarily) ¡ • CEP, ¡DSMSs, ¡Stream ¡reasoning, ¡Ac9ve ¡ DBMSs… ¡ ¡ • All ¡these ¡terms ¡hide ¡a ¡peculiar ¡view ¡of ¡the ¡domain ¡ we ¡have ¡in ¡mind ¡ • With ¡subtle, ¡“unsaid” ¡(and ¡oYen ¡unclear) ¡ differences ¡ • Before ¡learning ¡something ¡new ¡we ¡have ¡to ¡ forget ¡what ¡we ¡already ¡know ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 14 ¡

  3. The ¡Informa9on ¡Flow ¡Processing ¡domain ¡ The ¡ IFP ¡engine ¡processes ¡incoming ¡ flows ¡of ¡informa(on ¡ according ¡to ¡a ¡set ¡of ¡ • processing ¡rules ¡ • Processing ¡is ¡“on ¡line” ¡ Sources ¡produce ¡the ¡incoming ¡informa9on ¡flows, ¡ sinks ¡consume ¡the ¡results ¡of ¡ • processing, ¡ rule ¡managers ¡ add ¡or ¡remove ¡rules ¡ Informa9on ¡flows ¡are ¡composed ¡of ¡ informa(on ¡items ¡ • Items ¡part ¡of ¡the ¡same ¡flow ¡are ¡neither ¡necessarily ¡ordered ¡nor ¡of ¡the ¡same ¡kind ¡ • • Processing ¡involve ¡filtering, ¡ combining, ¡and ¡aggrega9ng ¡ flows, ¡item ¡by ¡item ¡as ¡they ¡ Sources ¡ Sinks ¡ IFP ¡Engine ¡ enter ¡the ¡engine ¡ Informa(on ¡Flows ¡ Informa(on ¡Flows ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Rules ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Rule ¡managers ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 15 ¡

  4. IFP: ¡One ¡name ¡several ¡incarna9ons ¡ A ¡lot ¡of ¡applica9ons ¡ • • Environmental ¡monitoring ¡through ¡sensor ¡networks ¡ • Financial ¡applica9ons ¡ • Fraud ¡detec9on ¡tools ¡ • Network ¡intrusion ¡detec9on ¡systems ¡ • RFID-­‑based ¡inventory ¡management ¡ • Manufacturing ¡control ¡systems ¡ • … ¡ Several ¡technologies ¡ • • Ac9ve ¡databases ¡ • DSMSs ¡ • CEP ¡Systems ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 16 ¡

  5. One ¡model, ¡several ¡models ¡ • Different ¡models ¡to ¡capture ¡different ¡ viewpoints ¡ • Func9onal ¡model ¡ • Processing ¡model ¡ • Deployment ¡model ¡ • Interac9on ¡model ¡ • Time ¡model ¡ • Data ¡model ¡ • Rule ¡model ¡ • Language ¡model ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 17 ¡

  6. Func9onal ¡model ¡ • Implements the transport protocol to move information items along the net • Implements the transport protocol to • Acts as a multiplexer move information items along the net Knowledge ¡ base ¡ • Acts as a demultiplexer Seq ¡ A ¡ A ¡ A ¡ History ¡ History ¡ History ¡ Forwarder Producer ¡ Receiver Decider ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Clock ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Rules ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 18 ¡

  7. A ¡short ¡digression ¡ We ¡assume ¡rules ¡can ¡be ¡(logically) ¡ • decomposed ¡in ¡two ¡parts: ¡C ¡→ ¡A ¡ Knowledge ¡ base ¡ • C ¡is ¡the ¡ condi(on ¡ Seq ¡ A ¡ A ¡ A ¡ • A ¡is ¡the ¡ ac(on ¡ History ¡ History ¡ History ¡ Forwarder Producer ¡ Receiver Decider ¡ Example ¡(in ¡CQL): ¡ • -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Clock ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ ac9on ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Select IStream(Count(*)) -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Rules ¡ From F1 [Range 1 Minute] condi9on ¡ Where F1.A > 0 This ¡way ¡we ¡can ¡split ¡processing ¡in ¡two ¡phases: ¡ • • The ¡ detec(on ¡phase ¡ determines ¡the ¡items ¡that ¡trigger ¡the ¡rule ¡ • The ¡ produc(on ¡phase ¡ use ¡those ¡items ¡to ¡produce ¡the ¡output ¡of ¡the ¡ rule ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 19 ¡

  8. Func9onal ¡model ¡ • Some systems allows rules to combine flowing items with items previously stored into a (read only) storage • Implements the detection phase • If present models the ability of performing recursive processing • Accumulates partial results into the history building hierarchies of items • When a rule fires passes to the producer its Knowledge ¡ action part and the triggering items base ¡ • Implements the production phase • Uses the items in Seq as stated in action A • Optional component Seq ¡ • Periodically creates special information A ¡ items holding current time A ¡ A ¡ History ¡ History ¡ • Its presence models the ability of History ¡ Forwarder Producer ¡ Receiver performing periodic processing of inputs • Some systems allow rules to be Decider ¡ added or removed at processing time -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Clock ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Rules ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 20 ¡

  9. Func9onal ¡model: ¡Considera9ons ¡ The ¡detec9on-­‑produc9on ¡cycle ¡ • • Fired ¡by ¡a ¡new ¡item ¡ I ¡entering ¡the ¡engine ¡through ¡the ¡Receiver ¡ • Including ¡those ¡periodically ¡produced ¡by ¡the ¡Clock, ¡if ¡present ¡ • Detec9on ¡phase: ¡Evaluates ¡all ¡the ¡rules ¡to ¡find ¡those ¡enabled ¡ • Using ¡item ¡ I ¡plus ¡the ¡data ¡into ¡the ¡Knowledge ¡base, ¡if ¡present ¡ • The ¡item ¡ I ¡can ¡be ¡accumulated ¡into ¡the ¡History ¡for ¡par9ally ¡enabled ¡rules ¡ • The ¡ac9on ¡part ¡of ¡the ¡enabled ¡rules ¡together ¡with ¡the ¡triggering ¡items ¡(A+Seq) ¡is ¡ passed ¡to ¡the ¡producer ¡ • Produc9on ¡phase: ¡Produces ¡the ¡output ¡items ¡ • Combining ¡the ¡items ¡that ¡triggered ¡the ¡rule ¡with ¡data ¡present ¡in ¡the ¡Knowledge ¡ base, ¡if ¡present ¡ • New ¡items ¡are ¡sent ¡to ¡subscribed ¡sinks ¡(through ¡the ¡Forwarder)… ¡ • …but ¡they ¡could ¡also ¡be ¡sent ¡internally ¡to ¡be ¡processed ¡again ¡(recursive ¡processing) ¡ • In ¡some ¡systems ¡the ¡ac9on ¡part ¡of ¡fired ¡rules ¡may ¡also ¡change ¡the ¡set ¡of ¡deployed ¡ rules ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 21 ¡

  10. Func9onal ¡model: ¡Considera9ons ¡ Maximum ¡length ¡of ¡Seq ¡a ¡key ¡aspect ¡ • • 1 ¡ ≈ ¡PubSub ¡ • Bounded ¡ ⇒ ¡ ¡ • CQL ¡like ¡languages ¡without ¡9me ¡based ¡windows ¡ • Pahern ¡based ¡languages ¡without ¡a ¡Kleene+ ¡operator ¡ Other ¡key ¡aspects ¡that ¡impact ¡expressiveness ¡ • • Presence ¡of ¡the ¡Clock ¡ • Models ¡the ¡ability ¡to ¡process ¡rules ¡ periodically ¡ Knowledge ¡ base ¡ • Available ¡in ¡almost ¡half ¡of ¡the ¡systems ¡ reviewed ¡ Seq ¡ A ¡ A ¡ A ¡ • Most ¡Ac9ve ¡DBMSs ¡and ¡DSMSs ¡but ¡ History ¡ History ¡ History ¡ Forwarder Producer ¡ Receiver Decider ¡ few ¡CEP ¡systems ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Clock ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Rules ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 22 ¡

  11. Func9onal ¡model: ¡Considera9ons ¡ • Presence ¡of ¡the ¡Knowledge ¡base ¡ • Only ¡available ¡in ¡systems ¡coming ¡from ¡the ¡database ¡community ¡ • Presence ¡of ¡the ¡looping ¡flow ¡exi9ng ¡ the ¡Producer ¡ • Models ¡the ¡ability ¡of ¡performing ¡recursive ¡ processing ¡ • Half ¡CEP ¡systems ¡have ¡it ¡ Knowledge ¡ base ¡ • All ¡Ac9ve ¡DBMSs ¡but ¡very ¡few ¡DSMSs ¡ Seq ¡ have ¡it ¡ A ¡ A ¡ A ¡ History ¡ History ¡ – They ¡have ¡nested ¡rules ¡ History ¡ Forwarder Producer ¡ Receiver Decider ¡ • Support ¡to ¡dynamic ¡rule ¡change ¡ -­‑-­‑-­‑-­‑-­‑ ¡ • Few ¡systems ¡support ¡it ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Clock ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ • Can ¡be ¡implemented ¡externally… ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Rules ¡ – Through ¡sinks ¡ac9ng ¡also ¡as ¡rule ¡managers ¡ • …but ¡we ¡think ¡it ¡is ¡nice ¡to ¡have ¡it ¡internally ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 23 ¡

  12. The ¡seman9cs ¡of ¡processing ¡ What ¡determines ¡the ¡output ¡of ¡each ¡detec9on-­‑produc9on ¡cycle? ¡ • • The ¡new ¡item ¡entering ¡the ¡engine ¡ Knowledge ¡ Knowledge ¡ • The ¡set ¡of ¡deployed ¡rules ¡ base ¡ base ¡ • The ¡items ¡stored ¡into ¡the ¡History ¡ Seq ¡ A ¡ A ¡ A ¡ • The ¡content ¡of ¡the ¡Knowledge ¡Base ¡ History ¡ History ¡ History ¡ History ¡ History ¡ History ¡ Producer ¡ Decider ¡ Is ¡this ¡enough? ¡ • -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Example ¡(in ¡Padres ¡and ¡CQL): • -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Rules ¡ • Smoke && Temp>50 • Select IStream(Smoke.area) From Smoke[Rows 30 Slide 10], Temp[Rows 50 Slide 5] Where Smoke.area = Temp.area AND Temp.value > 50 Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 24 ¡

  13. Processing ¡model ¡ • Three ¡policies ¡affect ¡the ¡behavior ¡of ¡the ¡ system ¡ • The ¡ selec(on ¡policy ¡ • The ¡ consump(on ¡policy ¡ • The ¡ load ¡shedding ¡policy ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 25 ¡

  14. Selec9on ¡policy ¡ • Determines ¡if ¡a ¡rule ¡fires ¡once ¡or ¡mul9ple ¡ 9mes ¡and ¡the ¡items ¡actually ¡selected ¡from ¡the ¡ History ¡ • Example: ¡ A 0 ¡ ¡B ¡ R ¡ mul9ple ¡ ? ¡ A 1 ¡ ¡B ¡ A B R ¡ A 0 ¡A 1 ¡ A ¡A ¡ A ¡ Receiver Decider ¡ A 0 ¡ ¡B ¡ A 1 ¡ ¡B ¡ single ¡ or ¡ R ¡ R ¡ A ¡ ∧ B ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 26 ¡

  15. Selec9on ¡policy: ¡Considera9ons ¡ • Most ¡systems ¡adopt ¡a ¡mul9ple ¡selec9on ¡policy ¡ • It ¡is ¡simpler ¡to ¡implement ¡ • Is ¡it ¡adequate? ¡ • Example: ¡Alert ¡fire ¡when ¡smoke ¡and ¡high ¡temperature ¡in ¡a ¡short ¡ 9me ¡frame ¡ – If ¡10 ¡sensors ¡read ¡high ¡temperature ¡and ¡immediately ¡aYerward ¡one ¡ detects ¡smoke ¡I ¡would ¡like ¡to ¡receive ¡a ¡single ¡alert, ¡not ¡10 ¡ • A ¡few ¡systems ¡allow ¡this ¡policy ¡to ¡be ¡programmed… ¡ • …some ¡of ¡them ¡on ¡a ¡per-­‑rule ¡base ¡ • E.g., ¡Amit, ¡T-­‑Rex ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 27 ¡

  16. Selec9on ¡policy: ¡The ¡TESLA ¡case ¡ TESLA ¡(Trio-­‑based ¡Event ¡Specifica9on ¡Language): ¡the ¡T-­‑Rex ¡language ¡ • • A ¡rule ¡language ¡for ¡CEP. ¡Tries ¡to ¡combine ¡expressiveness ¡and ¡efficiency ¡ • Has ¡a ¡formally ¡defined ¡seman9cs ¡ • Expressed ¡in ¡Trio, ¡a ¡Metric ¡Temporal ¡Logic ¡(see ¡DEBS ¡2010) ¡ Allows ¡rule ¡managers ¡to ¡choose ¡their ¡own ¡selec9on ¡policy ¡on ¡a ¡per ¡rule ¡base ¡ • • Example: ¡Mul9ple ¡selec9on ¡ • Alternatively you may use: define Fire(area: string, measuredTemp: double) from Smoke(area=$a) and • first … within each Temp(area=$a and val>50) within 1min. from Smoke • n-first … within n-last … within where area=Smoke.area and measuredTemp=Temp.value • Example: ¡Single ¡selec9on ¡ define Fire(area: string, measuredTemp: double) from Smoke(area=$a) and last Temp(area=$a and val>50) within 1min. from Smoke where area=Smoke.area and measuredTemp=Temp.val ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 28 ¡

  17. Consump9on ¡policy ¡ • Determines ¡how ¡the ¡history ¡changes ¡aYer ¡ firing ¡of ¡a ¡rule ¡ ⇒ ¡what ¡happens ¡when ¡new ¡ items ¡enter ¡the ¡Decider ¡ • Example: ¡ zero ¡ A ¡ ¡ ¡ ¡B ¡ R ¡ ? ¡ A B A ¡ ¡ ¡ ¡B ¡ R ¡ A ¡ Receiver Decider ¡ selected ¡ A ¡ ∧ B ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 29 ¡

  18. Consump9on ¡policy: ¡Considera9ons ¡ • Most ¡systems ¡couple ¡a ¡mul9ple ¡selec9on ¡policy ¡with ¡a ¡zero ¡ consump9on ¡policy ¡ • This ¡is ¡the ¡common ¡case ¡with ¡DSMSs, ¡which ¡use ¡(sliding) ¡ windows ¡to ¡select ¡relevant ¡events ¡ • Example ¡(in ¡CQL) ¡ Select IStream(Smoke.area) From Smoke[Range 1 min], Temp[Range 1 min] Where Smoke.area = Temp.area AND Temp.val > 50 • The ¡systems ¡that ¡allow ¡the ¡selec9on ¡policy ¡to ¡be ¡programmed ¡ oYen ¡allow ¡the ¡consump9on ¡policy ¡to ¡be ¡programmed, ¡too ¡ • E.g., ¡Amit, ¡T-­‑Rex ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 30 ¡

  19. Consump9on ¡policy: ¡The ¡TESLA ¡case ¡ Zero ¡consump9on ¡policy ¡ • • define Fire(area: string, measuredTemp: double) from Smoke(area=$a) and each Temp(area=$a and val>50) within 1min. from Smoke where area=Smoke.area and measuredTemp=Temp.value Fire! ¡ Fire! ¡ Fire! ¡ Fire! ¡ Fire! ¡ Fire! ¡ Fire! ¡ Fire! ¡ S ¡ S ¡ T ¡ T ¡ T ¡ T ¡ Selected ¡consump9on ¡policy ¡ • • define Fire(area: string, measuredTemp: double) from Smoke(area=$a) and each Temp(area=$a and val>50) within 1min. from Smoke where area=Smoke.area and measuredTemp=Temp.value consuming Temp Fire! ¡ Fire! ¡ Fire! ¡ Fire! ¡ S ¡ T ¡ T ¡ T ¡ T ¡ T ¡ T ¡ T ¡ T ¡ S ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 31 ¡

  20. Load ¡shedding ¡policy ¡ Problem: ¡How ¡to ¡manage ¡bursts ¡of ¡input ¡data ¡ • It ¡may ¡seem ¡a ¡system ¡issue ¡ • • i.e., ¡an ¡issue ¡to ¡solve ¡into ¡the ¡ Knowledge ¡ base ¡ Receiver ¡ Seq ¡ But ¡it ¡strongly ¡impacts ¡the ¡results ¡ • A ¡ A ¡ A ¡ History ¡ History ¡ Forwarder History ¡ Producer ¡ Receiver produced ¡ Decider ¡ • i.e., ¡the ¡“seman9cs” ¡of ¡the ¡rules ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Clock ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Accordingly, ¡some ¡systems ¡allows ¡this ¡issue ¡to ¡be ¡determined ¡on ¡a ¡per-­‑ • -­‑-­‑-­‑-­‑-­‑ ¡ Rules ¡ rule ¡basis ¡ • e.g., ¡Aurora ¡allows ¡rules ¡to ¡specify ¡the ¡expected ¡QoS ¡and ¡sheds ¡input ¡ to ¡stay ¡within ¡limits ¡with ¡the ¡available ¡resources ¡ • Conceptually ¡the ¡issue ¡is ¡addressed ¡into ¡the ¡decider ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 32 ¡

  21. Deployment ¡model ¡ • IFP ¡applica9ons ¡may ¡ include ¡a ¡large ¡number ¡of ¡ sources ¡and ¡sinks ¡ • Possibly ¡dispersed ¡over ¡a ¡ wide ¡geographical ¡area ¡ • It ¡becomes ¡important ¡to ¡ consider ¡the ¡ deployment ¡ architecture ¡of ¡the ¡engine ¡ • How ¡the ¡components ¡of ¡ the ¡func9onal ¡model ¡can ¡ be ¡distributed ¡to ¡achieve ¡ scalability ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 33 ¡

  22. Deployment ¡model ¡ Sources ¡ Sinks ¡ IFP ¡Engine ¡ Informa(on ¡Flows ¡ Informa(on ¡Flows ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Rules ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ -­‑-­‑-­‑-­‑-­‑ ¡ Rule ¡managers ¡ Centralized ¡ Clustered ¡ Networked ¡ Distributed ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 34 ¡

  23. Deployment ¡Model ¡ • Most ¡exis9ng ¡systems ¡adopt ¡a ¡centralized ¡ solu9on ¡ • When ¡distributed ¡processing ¡is ¡allowed, ¡it ¡is ¡ usually ¡based ¡on ¡clustered ¡solu9ons ¡ • A ¡few ¡systems ¡have ¡recognized ¡the ¡importance ¡of ¡ networked ¡deployment ¡for ¡some ¡applica9ons ¡ • E.g. ¡MicrosoY ¡StreamInsight ¡(part ¡of ¡SQLServer) ¡ • Filtering ¡near ¡sources ¡ • Aggrega9on ¡and ¡correla9on ¡in-­‑network ¡ • Analy9cs ¡and ¡historical ¡data ¡in ¡a ¡centralized ¡server/cluster ¡ • In ¡most ¡cases, ¡deployment/configura9on ¡is ¡not ¡ automa9c ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 35 ¡

  24. Deployment ¡model ¡ • Automa9c ¡distribu9on ¡of ¡ processing ¡introduces ¡the ¡ operator ¡placement ¡ problem ¡ • Given ¡a ¡set ¡of ¡rules ¡(composed ¡ of ¡operators) ¡and ¡a ¡set ¡of ¡ nodes ¡ • How ¡to ¡split ¡the ¡processing ¡ load ¡ • How ¡to ¡assign ¡operators ¡to ¡ available ¡nodes ¡ • In ¡other ¡words ¡(Event ¡ Processing ¡in ¡Ac9on) ¡ • Given ¡an ¡ event ¡processing ¡ network ¡ • How ¡to ¡map ¡it ¡onto ¡the ¡ physical ¡network ¡of ¡nodes ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 36 ¡

  25. Operator ¡placement ¡ • The ¡operator ¡placement ¡problem ¡is ¡s9ll ¡open ¡ • Several ¡proposals ¡ • OYen ¡adop9ng ¡techniques ¡coming ¡from ¡the ¡ Opera9onal ¡Research ¡ • Difficult ¡to ¡compare ¡solu9ons ¡and ¡results ¡ • Even ¡in ¡its ¡simplest ¡form ¡the ¡problem ¡is ¡NP-­‑hard ¡ [more ¡on ¡this ¡later ¡during ¡the ¡course] ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 37 ¡

  26. More ¡on ¡deployment ¡model ¡ • Operator ¡placement ¡is ¡only ¡part ¡of ¡the ¡problem ¡ • Other ¡issues ¡ • How ¡to ¡build ¡the ¡network ¡of ¡nodes? ¡ • How ¡to ¡maintain ¡it? ¡ • How ¡to ¡gather ¡the ¡informa9on ¡required ¡to ¡solve ¡the ¡ operator ¡placement ¡problem? ¡ • How ¡to ¡actually ¡“place” ¡the ¡operators? ¡ • How ¡to ¡“replace” ¡them ¡when ¡the ¡situa9on ¡changes? ¡ • New ¡rules ¡added, ¡old ¡rules ¡removed… ¡ • …new ¡sources/sinks ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 38 ¡

  27. Deployment ¡model ¡and ¡dynamics ¡ • How ¡to ¡cope ¡with ¡mobile ¡nodes? ¡ • Mobile ¡sinks ¡and ¡sources… ¡ • …but ¡also ¡mobile ¡“processors” ¡ • The ¡issue ¡is ¡relevant ¡ • We ¡leave ¡in ¡a ¡mobile ¡world ¡ • Very ¡few ¡proposals ¡ • A ¡lot ¡of ¡work ¡in ¡the ¡area ¡of ¡pure ¡publish/subscribe ¡ • Several ¡works ¡published ¡in ¡DEBS, ¡not ¡to ¡men9on ¡other ¡ major ¡conferences/journals ¡ • May ¡we ¡reuse ¡some ¡of ¡this ¡work? ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 39 ¡

  28. Interac9on ¡Model ¡ Sources ¡ IFP ¡Engine ¡ Sinks ¡ • It ¡is ¡interes9ng ¡to ¡study ¡the ¡characteris9cs ¡of ¡the ¡ interac9ons ¡among ¡the ¡main ¡component ¡of ¡an ¡ IFP ¡system ¡ • Who ¡starts ¡the ¡communica9on? ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 40 ¡

  29. Interac9on ¡Model ¡ Sources ¡ IFP ¡Engine ¡ Sinks ¡ Observation Model Forwarding Model Notification Model Push ¡ Push ¡ Push ¡ • • • Pull ¡ Pull ¡ Pull ¡ • • • Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 41 ¡

  30. Time ¡Model ¡ • Rela9onship ¡between ¡informa9on ¡items ¡and ¡ passing ¡of ¡9me ¡ • Ability ¡of ¡an ¡IFP ¡system ¡to ¡associate ¡some ¡kind ¡of ¡ happened-­‑before ¡ (ordering) ¡rela9onship ¡to ¡ informa9on ¡items ¡ • We ¡iden9fied ¡4 ¡classes: ¡ 1. Stream-­‑only ¡ 2. Causal ¡ 3. Absolute ¡ 4. Interval ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 42 ¡

  31. Stream-­‑Only ¡Time ¡Model ¡ • Used ¡in ¡original ¡DSMSs ¡ CQL/Stream Select DStream(*) • Timestamps ¡may ¡be ¡present ¡ From F1[Rows 5], or ¡not ¡ F2[Range 1 Minute] • When ¡present, ¡they ¡are ¡used ¡ Where F1.A = F2.A only ¡to ¡order ¡items ¡before ¡ entering ¡the ¡engine, ¡then ¡they ¡ are ¡forgohen ¡ • They ¡are ¡not ¡exposed ¡to ¡the ¡ language ¡ Stream Stream • With ¡the ¡excep9on ¡of ¡ S2R R2S windowing ¡constructs ¡ • Ordering ¡in ¡output ¡streams ¡is ¡ Relational Tables conceptually ¡separate ¡from ¡ the ¡ordering ¡in ¡input ¡streams ¡ R2R Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 43 ¡

  32. Causal ¡Time ¡Model ¡ • Each ¡item ¡has ¡a ¡label ¡ Gigascope Select count(*) reflec9ng ¡some ¡kind ¡of ¡ From A, B causal ¡rela9onship ¡ Where A.a-1 <= B.b and • Par9al ¡order ¡ A.a+1 > B.b A.a, B.b monotonically • E.g. ¡Rapide ¡ increase • An ¡event ¡is ¡causally ¡ A ¡ ordered ¡aYer ¡all ¡events ¡ that ¡led ¡to ¡its ¡occurrence ¡ B ¡ C ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 44 ¡

  33. Absolute ¡Time ¡Model ¡ • Informa9on ¡items ¡have ¡ TESLA/T-Rex an ¡associated ¡ Define Fire(area: string, measuredTemp: double) 9mestamp ¡ From Smoke(area=$a) and last • Defining ¡a ¡single ¡point ¡ Temp(area=$a and value>45) within 5 min. from Smoke in ¡9me ¡w.r.t. ¡a ¡ Where area=Smoke.area and (logically)unique ¡clock ¡ measuredTemp=Temp.value • Total ¡order ¡ • Timestamps ¡are ¡fully ¡ exposed ¡to ¡the ¡language ¡ • Informa9on ¡items ¡can ¡ be ¡9mestamped ¡at ¡ source ¡or ¡entering ¡the ¡ engine ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 45 ¡

  34. Interval ¡Time ¡Model ¡ • Used ¡for ¡events ¡to ¡include ¡“dura9on” ¡ • SnoopIB, ¡Cayuga, ¡NextCEP, ¡… ¡ • At ¡a ¡first ¡sight, ¡it ¡is ¡a ¡simple ¡extension ¡of ¡the ¡ absolute ¡9me ¡model ¡ • Timestamps ¡with ¡two ¡values: ¡start ¡9me ¡and ¡end ¡ 9me ¡ • However, ¡it ¡opens ¡many ¡issues ¡ • What ¡is ¡the ¡successor ¡of ¡an ¡event? ¡ • What ¡is ¡the ¡9mestamp ¡associated ¡to ¡a ¡composite ¡ event? ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 46 ¡

  35. Interval ¡Time ¡Model ¡ • Which ¡is ¡the ¡immediate ¡ successor ¡of ¡A? ¡ A • Choose ¡according ¡to ¡end ¡9me ¡only: ¡ B B ¡ • But ¡it ¡started ¡before ¡A! ¡ C • Exclude ¡B: ¡C, ¡D ¡ • Both ¡of ¡them? ¡ D • Which ¡of ¡them? ¡ • No ¡other ¡event ¡strictly ¡between ¡A ¡ E and ¡its ¡successor: ¡C, ¡D, ¡E ¡ • Seems ¡a ¡natural ¡defini9on ¡ • Unfortunately ¡we ¡loose ¡associa9vity! ¡ – X à (Y à Z) ¡≠ ¡(X ¡ à Y) à Z ¡ • May ¡impede ¡some ¡rule ¡rewri9ng ¡for ¡ processing ¡op9miza9ons ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 47 ¡

  36. Interval ¡Time ¡Model ¡ • “What ¡is ¡“Next” ¡in ¡event ¡processing?” ¡by ¡White ¡ et. ¡Al ¡ • Proposes ¡a ¡number ¡of ¡desired ¡proper9es ¡to ¡be ¡ sa9sfied ¡by ¡the ¡“Next” ¡func9on ¡ • There ¡is ¡one ¡model ¡that ¡sa9sfies ¡them ¡all ¡ • Complete ¡History ¡ • It ¡is ¡not ¡sufficient ¡to ¡encode ¡9mestamps ¡using ¡a ¡ couple ¡of ¡values ¡ • Timestamps ¡of ¡composite ¡events ¡must ¡embed ¡the ¡ 9mestamps ¡of ¡all ¡the ¡events ¡that ¡led ¡to ¡their ¡ occurrence ¡ • Possibly, ¡9mestamps ¡of ¡unbounded ¡size ¡ • In ¡case ¡of ¡unbounded ¡Seq ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 48 ¡

  37. Data ¡Model ¡ Data • Studies ¡how ¡the ¡different ¡ Data Items systems ¡ Nature of Items • Represent ¡single ¡data ¡items ¡ Generic ¡Data ¡ • Event ¡No9fica9ons ¡ • • Organize ¡them ¡into ¡data ¡ Format flows ¡ Records ¡ • Tuples ¡ • Objects ¡ • … ¡ • Support for Uncertainty Data Flows Homogeneous ¡ • Heterogeneous ¡ • Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 49 ¡

  38. Nature ¡of ¡Items ¡ Data • The ¡meaning ¡we ¡associate ¡to ¡ Data Items informa9on ¡items ¡ Nature of Items • Generic ¡data ¡ Generic ¡Data ¡ • • Event ¡no9fica9ons ¡ Event ¡No9fica9ons ¡ • • Deeply ¡influences ¡several ¡ Format other ¡aspects ¡of ¡an ¡IFP ¡system ¡ Records ¡ • Tuples ¡ • • Time ¡model ¡!!! ¡ Objects ¡ • … ¡ • • Rule ¡language ¡ Support for Uncertainty • Seman9cs ¡of ¡processing ¡ Data Flows • Heritage ¡of ¡the ¡ Homogeneous ¡ • heterogeneous ¡backgrounds ¡ Heterogeneous ¡ • of ¡different ¡communi9es ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 50 ¡

  39. Nature ¡of ¡Items ¡ CQL/Stream ¡(Generic ¡Data) ¡ TESLA/T-­‑Rex ¡(Event ¡No>fica>ons) ¡ Select IStream(*) Define Fire (area: string, From F1[Rows 5], measuredTemp: double) F2[Range 1 Minute] From Smoke(area=$a)and last Where F1.A = F2.A Temp(area=$a and value>45) ¡ within 5 min. from Smoke Where area=Smoke.area and Stream Stream measuredTemp=Temp.value S2R R2S Relational Tables R2R Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 51 ¡

  40. Format ¡of ¡Items ¡ Data • How ¡informa9on ¡is ¡ Data Items represented ¡ Nature of Items • Influences ¡the ¡way ¡items ¡ Generic ¡Data ¡ • Event ¡No9fica9ons ¡ • are ¡processed ¡ Format Records ¡ • E.g., ¡Rela9onal ¡model ¡ • Tuples ¡ • requires ¡tuples ¡ Objects ¡ • … ¡ • Support for Uncertainty Data Flows Homogeneous ¡ • Heterogeneous ¡ • Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 52 ¡

  41. Support ¡for ¡Uncertainty ¡ Data • Ability ¡to ¡associate ¡a ¡degree ¡of ¡ Data Items uncertainty ¡to ¡informa9on ¡items ¡ Nature of Items • To ¡the ¡content ¡of ¡items ¡ Generic ¡Data ¡ • • Imprecise ¡temperature ¡reading ¡ Event ¡No9fica9ons ¡ • • To ¡the ¡presence ¡of ¡an ¡item ¡ Format (occurrence ¡of ¡an ¡event) ¡ Records ¡ • • Spurious ¡RFID ¡reading ¡ Tuples ¡ • Objects ¡ • • When ¡present, ¡probabilis9c ¡ … ¡ • informa9on ¡is ¡usually ¡exploited ¡ Support for Uncertainty in ¡rules ¡during ¡processing ¡ Data Flows Homogeneous ¡ • Heterogeneous ¡ • [more ¡on ¡this ¡later] ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 53 ¡

  42. Data ¡Flows ¡ • Homogeneous ¡ Data Data Items • Each ¡flow ¡contains ¡data ¡with ¡the ¡ same ¡format ¡and ¡“kind” ¡ Nature of Items • E.g. ¡Tuples ¡with ¡iden9cal ¡ Generic ¡Data ¡ • structure ¡ Event ¡No9fica9ons ¡ • • OYen ¡associated ¡with ¡ Format “database-­‑like” ¡rule ¡languages ¡ Records ¡ • • Heterogeneous ¡ Tuples ¡ • Objects ¡ • • Informa9on ¡flows ¡are ¡seen ¡as ¡ … ¡ • channels ¡connec9ng ¡sources, ¡ Support for Uncertainty processors, ¡and ¡sinks ¡ Data Flows • Each ¡channel ¡may ¡transport ¡ Homogeneous ¡ items ¡with ¡different ¡kind ¡and ¡ • Heterogeneous ¡ • format ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 54 ¡

  43. Rule ¡Model ¡ • Rules ¡are ¡much ¡more ¡complex ¡ en99es ¡than ¡data ¡items ¡ Rule • Large ¡number ¡of ¡different ¡ Type of Rules approaches ¡ Transforming ¡Rules ¡ • Detec9ng ¡Rules ¡ • • Already ¡observed ¡in ¡the ¡ Support for Uncertainty previous ¡slides ¡ • Looking ¡back ¡to ¡our ¡func9onal ¡ model, ¡we ¡classify ¡them ¡into ¡ two ¡macro ¡classes ¡ • Transforming ¡rules ¡ • Detec9ng ¡rules ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 55 ¡

  44. Transforming ¡Rules ¡ Do ¡not ¡present ¡an ¡explicit ¡dis9nc9on ¡ • between ¡detec9on ¡and ¡produc9on ¡ Rule Define ¡an ¡execu9on ¡plan ¡combining ¡ • primi(ve ¡ operators ¡ Type of Rules Each ¡operator ¡transforms ¡one ¡or ¡more ¡ • input ¡flows ¡into ¡one ¡or ¡more ¡output ¡ Transforming ¡Rules ¡ • flows ¡ Detec9ng ¡Rules ¡ • The ¡execu9on ¡plan ¡can ¡be ¡defined ¡ • Support for Uncertainty explicitly ¡(e.g., ¡through ¡graphical ¡ • nota9on) ¡ implicitly ¡(using ¡a ¡high ¡level ¡language) ¡ • OYen ¡used ¡with ¡homogeneous ¡ • informa9on ¡flows ¡ To ¡take ¡advantage ¡of ¡the ¡predefined ¡ • structure ¡of ¡input ¡and ¡output ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 56 ¡

  45. Detec9ng ¡Rules ¡ • Present ¡an ¡explicit ¡ dis9nc9on ¡between ¡ Rule detec9on ¡and ¡produc9on ¡ Type of Rules • Usually, ¡the ¡detec9on ¡is ¡ Transforming ¡Rules ¡ • Detec9ng ¡Rules ¡ • based ¡on ¡a ¡logical ¡predicate ¡ Support for Uncertainty that ¡captures ¡ paKerns ¡ of ¡ interest ¡in ¡the ¡history ¡of ¡ received ¡items ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 57 ¡

  46. Support ¡for ¡Uncertainty ¡ • Two ¡orthogonal ¡aspects ¡ Rule • Support ¡for ¡uncertain ¡input ¡ • Allows ¡rules ¡to ¡deal ¡with/ Type of Rules reason ¡about ¡uncertain ¡input ¡ Transforming ¡Rules ¡ • data ¡ Detec9ng ¡Rules ¡ • • Support ¡for ¡uncertain ¡output ¡ Support for Uncertainty • Allows ¡rules ¡to ¡associate ¡a ¡ degree ¡of ¡uncertainty ¡to ¡the ¡ output ¡produced ¡ [more ¡on ¡this ¡later] ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 58 ¡

  47. Language ¡Model ¡ • Following ¡the ¡rule ¡ • Specify ¡opera9ons ¡to ¡ model, ¡we ¡define ¡two ¡ • Filter ¡ classes ¡of ¡languages: ¡ • Join ¡ • Transforming ¡languages ¡ • Aggregate ¡ • Declara9ve ¡languages ¡ • input ¡flows ¡… ¡ • Impera9ve ¡languages ¡ • … ¡to ¡produce ¡one ¡or ¡ • Detec9ng ¡languages ¡ more ¡output ¡flows ¡ • Pahern-­‑based ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 59 ¡

  48. Language ¡Model ¡ • Following ¡the ¡rule ¡ • Specify ¡the ¡expected ¡ model, ¡we ¡define ¡two ¡ result ¡rather ¡than ¡the ¡ desired ¡execu9on ¡flow ¡ classes ¡of ¡languages: ¡ • Usually ¡derive ¡from ¡ • Transforming ¡languages ¡ rela9onal ¡languages ¡ • Declara9ve ¡languages ¡ • Rela9onal ¡algebra ¡/ ¡SQL ¡ • Impera9ve ¡languages ¡ CQL/Stream: • Detec9ng ¡languages ¡ Select IStream(*) • Pahern-­‑based ¡ From F1[Rows 5], F2[Rows 10] Where F1.A = F2.A Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 60 ¡

  49. Language ¡Model ¡ • Following ¡the ¡rule ¡ • Specify ¡the ¡desired ¡ model, ¡we ¡define ¡two ¡ execu9on ¡flow ¡ classes ¡of ¡languages: ¡ • Star9ng ¡from ¡primi9ve ¡ • Transforming ¡languages ¡ operators ¡ • Declara9ve ¡languages ¡ • Can ¡be ¡user-­‑defined ¡ • Impera9ve ¡languages ¡ • Usually ¡adopt ¡a ¡ • Detec9ng ¡languages ¡ graphical ¡nota9on ¡ • Pahern-­‑based ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 61 ¡

  50. Impera9ve ¡Languages ¡ Aurora (Boxes & Arrows Model) Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 62 ¡

  51. Hybrid ¡Languages ¡ Oracle CEP Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 63 ¡

  52. Language ¡Model ¡ • Following ¡the ¡rule ¡ • Specify ¡a ¡firing ¡ model, ¡we ¡define ¡two ¡ condi9on ¡as ¡a ¡pahern ¡ classes ¡of ¡languages: ¡ • Select ¡a ¡por9on ¡of ¡ • Transforming ¡languages ¡ incoming ¡flows ¡through ¡ • Declara9ve ¡languages ¡ • Logic ¡operators ¡ • Impera9ve ¡languages ¡ • Content ¡/ ¡9ming ¡ • Detec9ng ¡languages ¡ constraints ¡ • Pahern-­‑based ¡ • The ¡ac9on ¡uses ¡ selected ¡items ¡to ¡ produce ¡new ¡ knowledge ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 64 ¡

  53. Detec9ng ¡Languages ¡ TESLA / T-Rex Define Fire(area: string, measuredTemp: double) From Smoke(area=$a) and last Temp(area=$a and value>45) within 5 min. from Smoke Where area=Smoke.area and measuredTemp=Temp.value Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 65 ¡

  54. Language ¡Model ¡ • Different ¡syntaxes ¡/ ¡constructs ¡/ ¡operators ¡ • Comparison ¡of ¡ languages ¡seman9cs ¡and ¡ expressiveness ¡s9ll ¡an ¡open ¡issue ¡ • Our ¡approach: ¡ • Review ¡all ¡operators ¡encountered ¡in ¡the ¡analysis ¡ of ¡systems ¡ • Specifying ¡the ¡classes ¡of ¡languages ¡adop9ng ¡them ¡ • Trying ¡to ¡capture ¡some ¡seman9cs ¡rela9onship ¡ • Among ¡ operators ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 66 ¡

  55. Language ¡Model ¡ Single-­‑Item ¡operators ¡ Present ¡in ¡all ¡languages ¡ • • • Selec9on ¡operators ¡ Defined ¡as ¡primi9ve ¡operators ¡in ¡ • impera9ve ¡languages ¡ • Filter ¡items ¡according ¡to ¡their ¡ content ¡ Declara9ve ¡languages ¡inherit ¡ • • Elabora9on ¡operators ¡ selec9on, ¡projec9on, ¡and ¡ • Projec9on ¡ renaming ¡from ¡rela9onal ¡algebra ¡ – Extracts ¡a ¡part ¡of ¡the ¡content ¡ of ¡an ¡item ¡ • Renaming ¡ – Changes ¡the ¡name ¡of ¡a ¡field ¡in ¡ Renaming languages ¡based ¡on ¡records ¡or ¡ Select RStream tuples ¡ (I.Price as HighPrice) Projection From Items[Rows 1] as I Where I.Price > 100 Selection Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 67 ¡

  56. Language ¡Model ¡ Single-­‑Item ¡operators ¡ • Pahern-­‑based ¡languages ¡ • • Selec9on ¡operators ¡ • Selec9on ¡inside ¡the ¡condi9on ¡ • Filter ¡items ¡according ¡to ¡their ¡ part ¡(pahern) ¡ content ¡ • Elabora9on ¡as ¡part ¡of ¡the ¡ • Elabora9on ¡operators ¡ ac9on ¡ • Projec9on ¡ – Extracts ¡a ¡part ¡of ¡the ¡content ¡ of ¡an ¡item ¡ • Renaming ¡ Projection – Changes ¡the ¡name ¡of ¡a ¡field ¡in ¡ Define ExpensiveItem languages ¡based ¡on ¡records ¡or ¡ (highPrice: double) tuples ¡ From Item(price>100) Selection Where highPrice = price Renaming Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 68 ¡

  57. Language ¡Model ¡ • Logic ¡Operators ¡ • Explicitly ¡present ¡in ¡pahern-­‑ based ¡languages ¡ • Conjunc9on ¡ • Disjunc9on ¡ • Repe99on ¡ • Nega9on ¡ PADRES (A & B) || (C & D) Disjunc9on Conjunction Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 69 ¡

  58. Language ¡Model ¡ • Logic ¡Operators ¡ Some ¡logic ¡operators ¡are ¡blocking ¡ • • Express ¡pahern ¡whose ¡validity ¡ • Conjunc9on ¡ cannot ¡be ¡decided ¡into ¡a ¡ • Disjunc9on ¡ bounded ¡amount ¡of ¡9me ¡ • Repe99on ¡ • E.g., ¡Nega9on ¡ • Nega9on ¡ • Used ¡in ¡conjunc9on ¡with ¡ windows ¡ Define Fire() From Smoke(area=$a) and not Rain(area=$a) Nega9on within 10 min from Smoke Window Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 70 ¡

  59. Language ¡Model ¡ • Logic ¡Operators ¡ Tradi(onally , ¡logic ¡operators ¡ • were ¡not ¡explicitly ¡offered ¡by ¡ • Conjunc9on ¡ declara9ve ¡and ¡impera9ve ¡ • Disjunc9on ¡ languages ¡ • Repe99on ¡ However, ¡they ¡could ¡be ¡ • • Nega9on ¡ expressed ¡as ¡transforma9on ¡of ¡ input ¡flows ¡ Conjunc9on ¡of ¡A ¡and ¡B Select IStream (F1.A, F2.B) From F1 [Rows 10], F2 [Rows 20] Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 71 ¡

  60. Language ¡Model ¡ • Sequences ¡ • Present ¡in ¡almost ¡all ¡ pahern-­‑based ¡ • Similar ¡to ¡logic ¡operators ¡ languages ¡ • Based ¡on ¡9ming ¡ rela9ons ¡among ¡items ¡ Define Fire() From Smoke(area=$a) and last Temp(area=$a and value>45) Sequence ¡(9me-­‑bounded) within 5 min. from Smoke Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 72 ¡

  61. Language ¡Model ¡ • Sequences ¡ • Tradi(onally , ¡transforming ¡ languages ¡did ¡not ¡provide ¡ • Similar ¡to ¡logic ¡operators ¡ sequences ¡explicitly ¡ • Based ¡on ¡9ming ¡ • Could ¡be ¡expressed ¡with ¡an ¡ rela9ons ¡among ¡items ¡ explicit ¡reference ¡to ¡ 9mestamps ¡ • If ¡present ¡inside ¡items ¡ Select IStream (F1.A, F2.B) From F1 [Rows 10], F2 [Rows 20] Where F1.timestamp < F2.timestamp Impose ¡9mestamp ¡order Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 73 ¡

  62. Language ¡Model ¡ • Itera9ons ¡ • Express ¡possibly ¡unbounded ¡sequences ¡of ¡items ¡… ¡ • … ¡sa9sfying ¡an ¡ itera(ng ¡condi9on ¡ • Implicitly ¡defines ¡an ¡ordering ¡among ¡items ¡ Itera9on ¡(Kleene ¡+) SASE+ PATTERN SEQ(Alert a, Shipment+ b[ ]) WHERE skip_till_any_match(a, b[ ]) { a.type = ’contaminated’ and b[1].from = a.site and b[i].from = b[i-1].to } WITHIN 3 hours Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 74 ¡

  63. Language ¡Model ¡ • Logic ¡operators, ¡ Esper sequences, ¡and ¡ Select A.price From pattern itera9ons ¡ tradi(onally ¡ [every (A à (B or C))] not ¡offered ¡by ¡ Where A.price > 100 transforming ¡languages ¡ • And ¡now? ¡ • IMO: ¡difficult ¡to ¡write ¡/ ¡ • Current ¡trend: ¡ understand ¡ • Embed ¡paherns ¡inside ¡ declara9ve ¡languages ¡ • Mailing ¡list ¡of ¡Esper! ¡ • Especially ¡adopted ¡in ¡ commercial ¡systems ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 75 ¡

  64. Language ¡Model ¡ • Windows ¡ Logical • Kind: ¡ Select IStream(Count(*)) • Logical ¡(Time-­‑Based) ¡ From F1[Range 1 Minute] • Physical ¡(Count-­‑ Based) ¡ Physical • User-­‑Defined ¡ Select IStream(Count(*)) From F1[Rows 50 Slide 10] Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 76 ¡

  65. Language ¡Model ¡ • Windows ¡are ¡used ¡to ¡limit ¡the ¡scope ¡of ¡blocking ¡operators ¡ • They ¡are ¡generally ¡available ¡in ¡declara9ve ¡and ¡impera9ve ¡ languages ¡ • They ¡are ¡not ¡present ¡in ¡all ¡pahern-­‑based ¡languages ¡ • Some ¡of ¡them ¡do ¡not ¡include ¡blocking ¡operators ¡ • Some ¡of ¡them ¡“embed” ¡windows ¡inside ¡operators ¡ • Making ¡them ¡unblocking ¡ CEDR EVENT Test-Rule WHEN UNLESS(A, B, 12 hours) WHERE A.a < B.b Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 77 ¡

  66. Language ¡Model ¡ • Windows ¡movement ¡ • Fixed : ¡do ¡not ¡move ¡at ¡all ¡ • Landmark : ¡have ¡a ¡fixed ¡lower ¡bound, ¡while ¡the ¡upper ¡ bound ¡advances ¡every ¡9me ¡a ¡new ¡informa9on ¡item ¡ enters ¡the ¡system ¡ • E.g., ¡all ¡items ¡since ¡1/1/2013 ¡ • Sliding : ¡have ¡a ¡fixed ¡size, ¡both ¡lower ¡and ¡upper ¡ bounds ¡advance ¡when ¡new ¡items ¡enter ¡the ¡system ¡ • Pane : ¡both ¡the ¡lower ¡and ¡the ¡upper ¡bounds ¡move ¡by ¡ k ¡elements, ¡as ¡k ¡elements ¡enter ¡the ¡system ¡ • K ¡is ¡smaller ¡than ¡the ¡window ¡size ¡ • Tumble : ¡same ¡as ¡above ¡ • K ¡is ¡greater ¡or ¡equal ¡to ¡the ¡window ¡size ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 78 ¡

  67. Language ¡Model ¡ • Flow ¡management ¡operators ¡ • Required ¡by ¡declara9ve ¡and ¡impera9ve ¡languages ¡to ¡ merge, ¡split, ¡organize, ¡and ¡process ¡incoming ¡flows ¡of ¡ informa9on ¡ Flow Management Operators Join Order By Group By Union Flow Creation Except Bag Operators Intersect Duplicate Remove-duplicates Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 79 ¡

  68. Language ¡Model ¡ Cartesian ¡ • Parameteriza9on ¡ product • Allows ¡the ¡binding ¡of ¡ CQL / Stream Select IStream (F1.A, F2.B) different ¡informa9on ¡ From F1 [Rows 10], F2 [Rows 20] items ¡based ¡on ¡their ¡ Where F1.A > F2.B content ¡ Selec9on • Offered ¡implicitly ¡by ¡ declara9ve ¡and ¡ impera9ve ¡languages ¡ Explicit ¡Parameter TESLA / T-Rex • Through ¡a ¡combina9on ¡of ¡ Define Fire() join ¡and ¡selec9on ¡ From Smoke(area=$a) and last Temp(area=$a and value>45) • Offered ¡as ¡an ¡explicit ¡ within 5 min. from Smoke operator ¡in ¡pahern-­‑ based ¡languages ¡ ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 80 ¡

  69. Language ¡Model ¡ Detec9on ¡ Define Fire(area: string, Aggregates Aggregate measuredTemp: double) From Smoke(area=$a) and Scope 45 < Avg(Temp(area=$a).value Detec9on ¡Aggregates ¡ within 5 min. from Smoke) • Produc9on ¡Aggregates ¡ • Where area=Smoke.area and measuredTemp=Temp.value Definition Define Fire(area: string, measuredTemp: double) Predefined ¡ • From Smoke(area=$a) and User-­‑defined ¡ • last Temp(area=$a and value>45) within 5 min. from Smoke) Where area=Smoke.area and measuredTemp=Avg(Temp(area=$a).value) within 1 hour from Smoke Produc9on ¡ Aggregate Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 81 ¡

  70. Discussion ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 82 ¡

  71. Abstrac9on ¡ • IFP ¡languages ¡and ¡ systems ¡offer ¡a ¡level ¡of ¡ abstrac9on ¡over ¡flowing ¡ Applications informa9on ¡ • Similar ¡to ¡the ¡role ¡SQL ¡/ ¡ DBMSs ¡play ¡for ¡sta9c ¡data ¡ • The ¡heterogeneity ¡of ¡ API (Including Rules) solu9ons ¡suggests ¡that ¡ finding ¡the ¡“right” ¡ IFP System abstrac9on ¡is ¡s9ll ¡an ¡open ¡ issue ¡ • Several ¡open ¡ques9ons ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 83 ¡

  72. Abstrac9on ¡ • Which ¡are ¡the ¡requirements ¡of ¡applica9ons? ¡ • According ¡to ¡the ¡results ¡of ¡EPTS ¡survey ¡(2010) ¡ • Simple ¡opera9ons ¡(mainly ¡aggregate ¡/ ¡join) ¡ • Few ¡sources ¡(mainly ¡1-­‑10, ¡and ¡10-­‑100) ¡ • Low ¡rates ¡(mainly ¡10-­‑100, ¡and ¡100-­‑1000 ¡event/s) ¡ • Data ¡coming ¡from ¡DBMSs ¡/ ¡files ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 84 ¡

  73. Abstrac9on ¡ • How ¡can ¡we ¡explain ¡these ¡answers? ¡ • IFP ¡systems ¡used ¡as ¡“enhanced” ¡DBMSs ¡ • IMO, ¡companies ¡are ¡using ¡the ¡technology ¡they ¡know ¡ – E.g. ¡Language: ¡no ¡need ¡for ¡paherns ¡or ¡no ¡knowledge ¡about ¡ paherns? ¡ • Features ¡vs ¡Simplicity/Integra9on ¡ • This ¡is ¡the ¡“consolidated” ¡part ¡of ¡IFP ¡systems ¡ • IMO, ¡raising ¡the ¡level ¡of ¡abstrac9on ¡would ¡make ¡IFP ¡ systems ¡more ¡appealing ¡for ¡a ¡larger ¡audience ¡ – Is ¡it ¡possible ¡to ¡combine ¡advanced ¡features ¡and ¡ease ¡of ¡use? ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 85 ¡

  74. Abstrac9on ¡ • Other ¡details ¡are ¡present ¡in ¡the ¡EPTS ¡survey ¡ • Most ¡of ¡the ¡people ¡was ¡referring ¡to ¡technologies ¡that ¡ were ¡“already ¡deployed” ¡or ¡“in ¡development” ¡ • The ¡systems ¡were ¡chosen ¡based ¡on ¡the ¡trust ¡on ¡the ¡ vendor ¡ • This ¡suggests ¡that ¡the ¡last ¡(research) ¡ advancements ¡in ¡event ¡processing ¡may ¡be ¡s9ll ¡ unknown ¡ • They ¡lack ¡a ¡solid ¡implementa9on ¡… ¡ • … ¡that ¡can ¡easily ¡work ¡side ¡by ¡side ¡with ¡exis9ng ¡data ¡ processing ¡systems ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 86 ¡

  75. Abstrac9on ¡ • How ¡many ¡kinds ¡of ¡languages ¡/ ¡abstrac9ons? ¡ • Tradi9onally, ¡two ¡ • Transforming ¡rules ¡ – Based ¡on ¡the ¡Stream ¡model ¡ • Detec9ng ¡rules ¡ – Based ¡on ¡paherns ¡ • OYen ¡merged ¡together ¡in ¡commercial ¡systems ¡ • “Merged ¡together” ¡does ¡not ¡mean ¡“organically ¡combined” ¡ • The ¡underlying ¡model ¡is ¡usually ¡derived ¡from ¡the ¡Stream ¡ model ¡ – Good ¡integra9on ¡with ¡rela9onal ¡languages ¡ – Difficult ¡to ¡integrate ¡with ¡paherns ¡ – Difficult ¡to ¡understand ¡the ¡seman9cs ¡of ¡rules ¡ • Can ¡we ¡offer ¡a ¡beher ¡model ¡/ ¡formalism? ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 87 ¡

  76. Abstrac9on ¡ • Do ¡we ¡really ¡need ¡“One ¡abstrac9on ¡to ¡rule ¡‘em ¡all”? ¡ • Again, ¡we ¡need ¡to ¡beher ¡understand ¡applica9on ¡ requirements ¡… ¡ • … ¡but ¡we ¡also ¡need ¡to ¡beher ¡analyze ¡the ¡expressiveness ¡ and ¡seman9cs ¡of ¡languages! ¡ • In ¡our ¡survey, ¡we ¡offer ¡a ¡descrip9on ¡of ¡exis9ng ¡ operators ¡ • Open ¡issues: ¡ • How ¡do ¡operators ¡contribute ¡to ¡the ¡overall ¡expressiveness ¡ of ¡languages? ¡ • Is ¡it ¡possible ¡to ¡find ¡a ¡“minimal ¡set” ¡of ¡operators ¡to ¡ organically ¡combine ¡the ¡capabili9es ¡of ¡transforming ¡and ¡ detec9ng ¡rules? ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 88 ¡

  77. Our ¡Proposal: ¡TESLA ¡ • “One ¡size ¡fits ¡all” ¡language ¡does ¡not ¡exist ¡ • At ¡least, ¡we ¡have ¡to ¡find ¡it ¡yet ¡ • We ¡started ¡from ¡the ¡following ¡requirements ¡ • Focus ¡specifically ¡on ¡events ¡ • Not ¡generic ¡data ¡processing ¡ • Define ¡a ¡clear ¡and ¡precise ¡seman9cs ¡ • Issues ¡of ¡selec9on ¡and ¡consump9on ¡policies ¡ • General ¡issue ¡of ¡formal ¡seman9cs ¡ • Be ¡expressive ¡ • Useful ¡for ¡applica9ons ¡ • Keep ¡it ¡simple ¡ • Easy ¡to ¡read ¡and ¡write ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 89 ¡

  78. TESLA ¡ Define CE(Att 1 : Type 1 , …, Att n : Type n ) From Pattern Where Att 1 = f 1 (..), …, Att n = f n (..) Consuming e 1 , …, e m Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 90 ¡

  79. Paherns ¡in ¡TESLA ¡ CE ¡ • Selec9on ¡of ¡a ¡single ¡event ¡ A ¡ (X=15) ¡ ¡ B ¡ B • A(x>10) 5 ¡min ¡ • Timer() • Selec9on ¡of ¡sequences ¡ CE ¡ CE ¡ • A(x>10) and each B A ¡ B ¡ B ¡ within 5 min from A (X=15) ¡ • A(x>10) and last B CE ¡ within 5 min from A • A(x>10) and first B A ¡(X=15) ¡ B ¡ B ¡ within 5 min from A • Generaliza9on ¡ CE ¡ • n-­‑first ¡/ ¡n-­‑last ¡ B ¡ ¡ B A ¡(X=15) ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 91 ¡

  80. Paherns ¡in ¡TESLA ¡ • TESLA ¡allows ¡*-­‑within ¡operators ¡to ¡be ¡composed ¡ with ¡each ¡other: ¡ • In ¡chains ¡of ¡events ¡ • A and each B within 3 min from A and last C ¡ C B ¡ A ¡ within 2 min from B • In ¡parallel ¡ • A and each B within 3 min from A and last C within 4 min from A C ¡ B ¡ A ¡ • Parameters ¡can ¡be ¡added ¡between ¡events ¡in ¡a ¡ pahern ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 92 ¡

  81. Nega9ons ¡and ¡Aggregates ¡ • Two ¡kinds ¡of ¡nega9ons: ¡ • Interval ¡based: ¡ • A and last B within 3 min from A and not C between B and A • Time ¡based: ¡ • A and not C within 3 min from A • Similarly, ¡two ¡kinds ¡of ¡aggregates ¡ • Interval ¡based ¡ • Use ¡values ¡appearing ¡between ¡two ¡events ¡ • Time ¡based ¡ • Use ¡values ¡appearing ¡in ¡a ¡9me ¡interval ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 93 ¡

  82. Itera9ons ¡ • We ¡believe ¡that ¡explicit ¡operators ¡for ¡ repe99ons ¡are ¡difficult ¡to ¡use/understand ¡ • Especially ¡when ¡different ¡selec9on/consump9on ¡ policies ¡are ¡allowed ¡ • We ¡achieve ¡the ¡same ¡goal ¡using ¡hierarchies ¡of ¡ events ¡ • Complex ¡events ¡can ¡be ¡used ¡to ¡define ¡(more) ¡ complex ¡events ¡ • Recurring ¡schemes ¡of ¡repe99ons ¡ • Macros! ¡ ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 94 ¡

  83. Formal ¡Seman9cs ¡ • The ¡seman9cs ¡of ¡each ¡TESLA ¡operator ¡/ ¡rule ¡is ¡formally ¡ defined ¡through ¡a ¡set ¡of ¡TRIO ¡metric ¡temporal ¡logic ¡ formulas ¡ • They ¡define ¡an ¡equivalence ¡between ¡the ¡presence ¡of ¡a ¡given ¡ pahern ¡and ¡the ¡occurrence ¡of ¡one ¡or ¡more ¡complex ¡events, ¡ specifying: ¡ • The ¡ occurrence ¡(me ¡ of ¡complex ¡events ¡ • The ¡ content ¡ of ¡complex ¡events ¡ • The ¡set ¡of ¡ consumed ¡ events ¡ • The ¡language ¡is ¡unambiguous ¡ • A ¡user ¡can ¡in ¡advance ¡check ¡the ¡seman9cs ¡of ¡her ¡rules ¡ • This ¡makes ¡it ¡possible ¡to ¡check ¡the ¡correctness ¡of ¡an ¡event ¡ detec9on ¡engine ¡using ¡a ¡model ¡checker ¡ • Given ¡a ¡history ¡of ¡events ¡and ¡a ¡set ¡of ¡TESLA ¡rules ¡… ¡ • … ¡does ¡the ¡engine ¡sa9sfy ¡all ¡the ¡formulas ¡? ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 95 ¡

  84. Abstrac9on ¡ • Support ¡for ¡uncertainty ¡ • Many ¡applica9ons ¡deal ¡with ¡imprecise ¡(or ¡even ¡ incorrect) ¡data ¡from ¡sources ¡ • E.g., ¡sensors, ¡RFID, ¡… ¡ • Uncertain ¡rules ¡may ¡increase ¡the ¡expressiveness ¡/ ¡ usefulness ¡of ¡an ¡IFP ¡system ¡ [more ¡on ¡this ¡later] ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 96 ¡

  85. Abstrac9on ¡ • Support ¡for ¡QoS ¡policies ¡ • Allow ¡users ¡to ¡define ¡applica9on-­‑dependent ¡policies ¡ • Which ¡data ¡is ¡more ¡important? ¡ • Which ¡items ¡is ¡it ¡beher ¡to ¡discard ¡in ¡case ¡of ¡system ¡ overload? ¡ • Which ¡QoS ¡metric ¡is ¡more ¡significant ¡for ¡the ¡applica9on? ¡ – Completeness ¡of ¡results ¡ – Latency ¡ – … ¡ • Tradi9onally ¡offered ¡only ¡by ¡DSMSs ¡ • Most ¡systems ¡simply ¡adopt ¡a ¡best-­‑effort ¡strategy ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 97 ¡

  86. Abstrac9on ¡ • Support ¡for ¡a ¡ Knowledge ¡Base ¡ • Some ¡systems ¡offer ¡special ¡opera9ons ¡to ¡read ¡ from ¡persistent ¡storage ¡ • Possibly ¡a ¡key-­‑feature ¡for ¡the ¡integra9on ¡with ¡ exis9ng ¡DBMSs ¡ • Support ¡for ¡periodic ¡evalua9on ¡of ¡rules ¡ • As ¡opposed ¡to ¡purely ¡reac9ve ¡evalua9on ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 98 ¡

  87. Abstrac9on ¡ • Capability ¡to ¡dynamically ¡change ¡the ¡set ¡of ¡ deployed ¡rules ¡ • Add ¡/ ¡Remove ¡ • Ac9vate ¡/ ¡Deac9vate ¡ • Context ¡awareness ¡ • Tutorial ¡at ¡DEBS ¡2010 ¡ • Could ¡be ¡used ¡to ¡increase ¡the ¡expressiveness ¡of ¡IFP ¡… ¡ • … ¡but ¡also ¡to ¡simplify ¡/ ¡speedup ¡processing ¡ • Context ¡/ ¡Situa9on ¡used ¡to ¡reason ¡on ¡the ¡status ¡of ¡the ¡ system ¡/ ¡applica9on ¡ • Possibly ¡combined ¡with ¡the ¡possibility ¡to ¡ac9vate ¡/ ¡ deac9vate ¡rules ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 99 ¡

  88. Abstrac9on ¡ • Where ¡to ¡offer ¡the ¡IFP ¡abstrac9on? ¡ • As ¡a ¡standalone ¡product/system ¡ • Similar ¡to ¡DBMSs ¡ • As ¡a ¡middleware ¡component ¡ • Similar ¡to ¡a ¡Publish/Subscribe ¡system ¡ • To ¡guide ¡the ¡interac9on ¡of ¡other ¡components ¡ • As ¡part ¡of ¡a ¡programming ¡language ¡ • Similar ¡to ¡what ¡LINQ ¡(Language-­‑Integrated ¡Query) ¡ offers ¡to ¡C# ¡and ¡to ¡the ¡.Net ¡Framework ¡ • Explored ¡in ¡EventJava ¡ – Extension ¡of ¡Java ¡for ¡event ¡correla9on ¡ Stream ¡& ¡Complex ¡Event ¡Processing ¡-­‑ ¡Models ¡ 100 ¡

Recommend


More recommend