Wednesday, December 31, 2008

On Event Reduction

The new year is going to arrive in less than three hours (local time), we don't really celebrate the new year, as our new year has already started in September, we celebrate our holidays according to the "Hebrew Calendar", but the daily life is handled according to the Gregorian Calendar, so I am mentioning that date. The mood here is not a celebration mood, various locations in the universe have their own natural disasters: The east coast of the USA and the Caribbean Islands have Hurricanes, parts of Asia have Tsunamis, the west coast of the USA and some other places have earthquakes, and we in Israel have periods of fightingwith one of our neighbors. Some are viewing it as the natural disaster of the middle east, like hurricanes; however, unlike hurricanes, I strongly believe that human violence can be avoided, but will not get in this Blog into the very complex situation. For those who were asking me about my personal safety -- this time we are (so far) quite far from the combat area, and in general -- I have better feeling of personal safety here than in many other places in the universe.

An interesting comment about my previous posting made by Richard Veryard
Richard referred to the comment I've made about being more productive in a Cafe, and asked whether this is a result of getting less interrupts, and what we can project to event processing in the enterprise level.

I think that this is a good point, actually, one the more marketed benefit of event processing systems are their ability to help not missing any event that requires reaction (I think that the term identifying "threats" and "opportunities" is much over-statement of most detected situations, but will write about it another time), in some cases, the business benefit of event processing system is actually reducing the number of events, and focus the decision makers on the important events.

Some examples:

  • In Network Management there is a phenomenon knows as "event storm", e.g. when some network segment is out, many devices send "time-out" alerts, which are just the symptoms of the real problem. What we want is to reduce this event storm to a single event that need to be reacted upon.
  • I would like to get alert when my investment portfolio is up by 5% within a single day (as you can see, I am still optimistic). Here I don't care about any of the many raw events about any of my investments, but about the situation defined above.
The conclusion (not very surprising) is that sometimes less is more --- the event processing system can eliminate events in various ways:

  • Filtering out unnecessary events
  • Aggregating multiple events to one
  • Report on derived event when some pattern is detected.
I'll blog more about this issue, but remember -- some times less is more and more is less...

5 comments:

woolfel said...

I like the idea of event reduction, but how does that fit into the larger picture of events as defined by Dr. Luckham? I keep coming back to this question, and get the impression many products on the market today save all events in the system.

If we only care about some events, and reduce the event storm to a few important derived events, how does a system know which events to persist? Assuming the system is able to intelligently persist the events we care about and discard events that are useless. A related question is should the event language define the semantics for persisting the events we "really" want to save.

Opher Etzion said...

Hi Woolfel.

There are two distinct issues: events that are brought to the attention of the decision makers and events that are retained in the system for longer terms. I was talking about the first one.
The second issue -- which events to persist and to what period, is a distinct issue and I'll write about it at some point.

BTW -- David Luckham's book talked about hierarchy of events where higher level events are created from lower level ones.

cheers,

Opher

david said...

Question: "I like the idea of event reduction, but how does that fit into the larger picture of events as defined by Dr. Luckham?"

One way to reduce the number of events one has to deal with is by abstraction. So in Opher's example there are many ways to define events that signify abstractions of the portfolio activity, e.g., one way is by means of trends in % of total value over time windows, or "% jumps" in total value over time windows.
The use of time windows decreases the number of events. And if one then places a guard on the jump number to say +5%, one might even reduce the events to zero!
So "fewer events" does not necessarily mean "event happiness".
Also, events signifying a +5% change in value may have only a small time window of validity.
When you think about it, this is a very tricky example!
As the Romans use to say, "all profit is fleeting"!

But the answer to your question is "abstraction hierarchies".
Now another Roman saying: "all hierachies are fleeting"
which in modern CEP terminology means "all hierarchies are flexible and open to redefinition".
See chpt 7 POE, esply p142, final para. - David

Opher Etzion said...

Thanks David. Indeed there are cases in which we would like to reduce the events to zero or almost zero, when we are looking for a rare event that needs reaction, this can be as in the example -- looking for significant increase in stock's quote, or condition that signify suspicion for fraud and other anomalies that in most cases don't happen, but are important to be discovered.

cheers,

Opher

Richard Veryard said...

So the total behaviour of the enterprise system may be affected by the quantity and variety of events that get through to the business applications. Too many events, and the decision-makers may be unable to focus on the important ones. Too few events, and the enterprise may lack requisite variety. A good cybernetic systems design would therefore include feedback loops, so that the quantity and variety of events can be adjusted until the enterprise works to the maximum efficiency and effectiveness.

So an event processing architecture needs some kind of variety regulator (“regulator” in the engineering sense, not the legal compliance sense) – some kind of monitoring and control. For example, changing the frequency of some measurement, or changing the filtering or aggregation rules.

See my blog on event reductionn.