複合イベント処理
[Wikipedia|▼Menu]

イベント処理は、発生した事象(イベント)に関する情報(データ)のストリームを追跡して分析(処理)し、何らかの結論を得る手法である。[1] 複合イベント処理(CEP)は、複数のソースからのデータを組み合わせ、[2]より複雑な状況を示唆するイベントやパターンを推論するイベント処理である。複合イベント処理のゴールは、意味のあるイベント(例えば何らかの機会または脅威)を明らかにして、[3] できるだけ速やかに対処することである。

これらのイベントは営業の引き合いや受注、お客様からの問い合わせ電話など、組織のさまざまな層で発生している。また、それらはニュース記事[4] やテキストメッセージ、SNSへの投稿、株式市況、交通情報、天気予報やその他の種類のデータかもしれない。 イベントは測定値が時刻や温度その他の、あらかじめ定義されていたしきい値を超えた「状態の変化」として定義されることもある。CEPは組織にリアルタイムでパターンを分析する新たな手法を与え、ビジネスサイドがITとサービス部門とのより良いコュミニケーションを実現するとアナリストは提唱している。[5]

イベントとして利用可能な膨大な情報はイベントクラウドという名称で参照されることがある。
概念

入力される数千ものイベントの中で、例えば監視システムは次のような三つの情報を同じソースから受け取るかもしれない。
教会の鐘が鳴っている。

タキシードを着た男性と流れるような白いドレスを身にまとった女性が現れる。

米粒が空に撒かれる。

これらのイベントから、監視システムは「結婚式」とい複合イベントを推論する。鐘、結婚式の盛装をした男女、空に撒かれる米粒などにCEPの技法を適用し、分析したりほかのイベントとの相関をとることで、複合イベントの発見を手助けする。[6]

CEPは次のような技術に依存している。[7]

イベントのパターン検知

イベント抽出

イベントフィルタリング

イベントの集約と変換

イベント階層のモデル化

イベント間の関連の検知(例えば因果関係、メンバーシップ、タイミングなど)

イベント駆動処理の抽象化

CEPの商用アプリケーションは、株式のアルゴリズム取引[8] クレジットカード不正使用検知、ビジネスアクティビティモニタリング、セキュリティモニタリングなど幅広い業界で使われている。
歴史

CEPは離散イベントシミュレーションや、アクティブデータベースとその他のプログラミング言語をルーツに持つ。この業界での活動に先立って1990年代に一連の研究プロジェクトがあった。資料[9] によると、一般的なCEP言語と実行モデルに道を開いた最初のプロジェクトはスタンフォード大学のRapideプロジェクトである。並行して次の三つの研究プロジェクトがあった。それらはK. Mani Cahandyが率いたカリフォルニア工科大学のInfosphere、John Batesが率いたケンブリッジ大学のApama、Opher Etzionが率いたIBMハイファ研究所のAmitである。商用製品はこれらのプロジェクトとその後の研究プロジェクトからの概念に依存している。Event Processing Technial Societyによって組織されたイベント処理シンポジウムが開催され、これは後にACM DEBSカンファレンスとなった。組織活動からの結果の一つとしてエベント処理宣言がある。[10]
関連概念

CEPはオペレーショナルインテリジェンス(OI)ソリューションで使用され、ライブな入力データやイベントデータに対するクエリを実行し、ビジネスオペレーションへの知見を提供する。OIソリューションはリアルタイムデータを収集し、ヒストリカルデータと相関をとることで、現在の状況に対する知見や分析を提供する。異なる組織サイロからの複数のソースからのデータは集約され、現在の情報を使用した共通のオペレーティングピクチャを提供する。リアルタイムの知識が重要な場面では、OIソリューションが必要な情報を引き出すために使用される。

ネットワーク管理システム管理、アプリケーション管理、サービス管理では、イベントの相関関連を参照する。CEPエンジンではイベント相関エンジン(イベントコリレーター)が大量のイベントを分析し、最も重要なものを特定し、アクションのトリガーを起こす。しかし、それらからは推測された新たなイベントが発生することはほとんどない。その代り、低レベルのイベントと高レベルのイベントとの関連付けを行う。[11]

ルールベースの推論エンジンでは、人工知能から推測された情報を生成する。しかし、それらは一般に複合(推測された)イベントの形では情報生成しない。

CEPのよりシステム的な例として、いくつかのセンサーや各種のイベントとリアクターからなる自動車がある。タイヤの空気圧センサー、速度センサー、シートに人が座っているかどうかを検知するセンサーを想像してみてほしい。

最初の状況では、自動車は走行中であり15分の間にタイヤの空気圧が45PSIから41PSIに落ちたとする。タイヤの空気圧が下がるとタイヤ空気圧に関するいくつかのイベントが生成される。自動車のイベントプロセッサーは、比較的長い時間にタイヤ空気圧が失われた状況を検知し、"LossOfTirePressure"イベントを生成する。この新たなイベントは自動車のメンテナンスログに空気圧の喪失を記録するプロセスを発生させ、ダッシュボードを通じて運転者にタイヤの空気圧が失われたことを通知する。

2番目の状況では自動車は走行中でありタイヤの空気圧が5秒間の間に45PSIから20PSIに落ちる。短期間にタイヤの空気圧が失われたか、それぞれのイベントの値が定義されてあった制限よりも大きな値なので、異なるシチュエーションが検知される。異なるシチュエーションは"blowOutTire"というあらたなイベントを生成する。この新たなイベントは異なる反応プロセスを起こし、運転者に即時の警告を発し、スリップして自動車の制御を失わずに停車するよう運転手をアシストする車載コンピューターのルーチンを開始する。

さらに、検知された状況を表すイベントは、さらに複雑な状況を検知するために、他にベントと組み合わされる。例えば、上記自動車の例での最後の状況では、自動車は通常走行中にタイヤがパンクして、道路から外れて木に激突して運転手が車から放り出されてしまう。一連の異なる状況が素早く検知される。"blownOutTire"と"zeroSpeed"、"driverLeftSeat"が非常に短い時間に発生したならば、"occupantThrownAccident"という新たなイベントが検知されることになる。運転手が車外に放り出されたとか、事故が発生したということを結論づける直接的な検知はされていなくても、イベントの組み合わせによりその状況が検知されたことと、その状況を重要づける新たなイベントが作成される。これは複合(混合)イベントの基礎である。直接的に状況を検知することはなく、他のイベントとの組み合わせでその状況の発生を推論したり演繹しなければならないので、複雑である。
種類

多くのCEPソリューションと概念は次の二つのカテゴリーに分類することができる。
集計指向のCEP

検知指向のCEP

集計指向のCEPはシステムに入力されるイベントデータへの反応として、オンラインのアルゴリズムを実行することに焦点を当てている。入ってくるイベントにあるデータの平均を計算し続けるというのが簡単な例である。

検知指向のCEPではイベントパターンや状況と呼ばれるイベントの組み合わせを検知することに焦点を当てている。イベントが特定の順番で並んでいる状況を検知するというのが簡単な例である。

両方が交じり合ったアプローチもある。
ビジネスプロセス管理との統合


次ページ
記事の検索
おまかせリスト
▼オプションを表示
ブックマーク登録
mixiチェック!
Twitterに投稿
オプション/リンク一覧
話題のニュース
列車運行情報
暇つぶしWikipedia

Size:30 KB
出典: フリー百科事典『ウィキペディア(Wikipedia)
担当:undef