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 ¡

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend