Обработка сложных событий

Среди тысяч входящих событий система наблюдения может, к примеру, получить следующие три из одного и того же источника:

1. звонят колокола церкви.
2. появление мужчины в смокинге с женщиной в белом платье.
3. в воздух бросают рис.

По этим событиям система наблюдения может вывести «сложное событие»: свадьбу. Технология CEP помогает обнаруживать сложные события методом анализа и корреляции других событий:[1] колоколов, мужчины и женщины в свадебном наряде и риса, подбрасываемого в воздух.

CEP основана на ряде технологий,[2] включая:

• обнаружение паттернов событий;
• абстракции событий;
• моделирования иерархии событий;
• определения соотношений (таких как причинность, членство или временная зависимость) между событиями;
• абстракции процессов, управляемых событиями.

Коммерческие приложения CEP включают алгоритмическую торговлю, выявление случаев отмывания денег, мошенничества с платежными картами, мониторирование бизнес-активности и мониторирование безопасности.[3]

CEP в первую очередь применяется в управлении бизнес-процессом (BPM) и относящихся к нему областях.

В управлении компьютерной сетью, управлении системами, управлении жизненным циклом приложения и управлении службами обычно ссылаются на корреляцию событий. В архитектуре CEP средства корреляции событий (корреляторы событий) анализируют массу событий, определяют наиболее важные из них и инициируют действия. Однако, большинство из них не выводят новых событий. Вместо этого, они соотносят высокоуровневые события с низкоуровневыми.[4]

В искусственном интеллекте, выводимая информация обычно создается машиной вывода, например системой на основе правил. Однако, новая информация обычно не производится в форме сложных (выводимых) событий.

Более строгий пример использования CEP включает в себя автомобиль, несколько сенсоров и различные события и реакции на них. Представьте себе, что автомобиль имеет несколько датчиков: один для измерения давления в шинах, другой для измерения скорости, и третий, который определяет, сидит ли кто-то на сиденье или покинул его.

В первом случае, автомобиль движется и давление в одной из шин снижается с 45 до 41 фунтов на квадратный дюйм в течение 15 минут. Поскольку давление в шине падает, генерируется серия событий, отражающих давление в шинах. Кроме того, генерируется ряд событий, содержащих скорость автомобиля. Процессор событий автомобиля может обнаружить ситуацию, при которой потеря давления в шине в течение относительно длительного периода времени приводит к созданию события «lossOfTirePressure». Это новое событие может вызвать процесс реакции, отмечающий потерю давления в журнале обслуживания автомобиля, а также предупреждающий водителя с помощью компьютера автомобиля, что давление в шинах снизилось.

Во второй ситуации, автомобиль движется, и давление одной из шин снижается с 45 до 20 фунтов на квадратный дюйм за 5 секунд. Обнаруживается иная ситуация — может быть потому, что потеря давления произошла за короткий период времени, или, возможно, потому, что разница в значениях между каждым событием была больше, чем предопределенный предел. Иная ситуация вызывает генерацию нового события «blowOutTire». Это новое событие вызывает другой процесс реакции, сразу предупреждающий водителя и инициирующий процедуры бортового компьютера, помогающие водителю замедлить автомобиль до полной остановки, не теряя контроля над ним при заносе.

Кроме того, события, которые представляют обнаруженные ситуации, могут быть объединены с другими событиями с целью выявления более сложных ситуаций. Например, в последней ситуации автомобиль двигался нормально, но возник разрыв шины, в результате чего автомобиль вылетел с дороги и ударился в дерево и водителя выбросило из автомобиля. Быстро обнаруживается серия различных ситуаций. Сочетание «blowOutTire», «zeroSpeed» и «driverLeftSeat» в очень коротком промежутке времени приводит к обнаружению новой ситуации: «occupantThrownAccident». Даже несмотря на отсутствие прямых измерений, которые могут окончательно определить, что водителя выбросило, или что произошел несчастный случай, комбинация событий позволяет обнаружить ситуацию и создать новое событие для обозначения обнаруженной ситуации. Это сущность сложного (или композитного) события. Оно сложное, потому что нельзя непосредственно обнаружить ситуацию; нужно сделать вывод, что ситуация произошла из комбинации других событий.

Большинство реализаций и концепций CEP можно классифицировать в двух категориях:

1. CEP, ориентированные на вычисления
2. CEP, ориентированные на обнаружение

Реализация CEP, ориентированная на вычисления, сконцентрирована на онлайн выполнении алгоритмов в ответ на данные событий, входящих в систему. Простой пример — непрерывное вычисление средного значения, основываясь на данных входящих событий.

CEP, ориентированная на обнаружение, сконцентрирована на обнаружении комбинаций событий, называемых паттернами событий или ситуациями. Простой пример определения ситуации — поиск определённой последовательности событий.

Конечно, приложение новой технологии редко существует в изоляции. Естественным является внедрение CEP в управление бизнес-процессом[5]. Управление бизнес-процессом сильно сфокусировано на конечных бизнес-процессах с целью непрерывной оптимизации и подстройки к операционному окружению.

Однако, оптимизация бизнеса не основана исключительно на его индивидуальных, конечных процессах. Часто разрозненные, как кажется, процессы могут значительно влиять друг на друга. Рассмотрим такой сценарий: в аэрокосмической промышленности хорошей практикой является мониторинг аварий транспортных средств для поиска тенденций (определения потенциально слабых мест в производственных процессах, материалах и т. д.) Другой отдельный процесс отслеживает текущий цикл эксплуатации транспортных средств и при необходимости списывает их в конце срока полезного использования. При использовании CEP необходимо связать эти отдельные процессы, при этом в случае, когда начальный процесс (мониторинг поломок) обнаруживает неисправность на основе усталости металла (значимое событие), может быть создано действие, использующее второй процесс (жизненный цикл), чтобы отозвать автомобили, использующие металл той же партии, в которой первым процессом обнаружены неисправности.

Интеграция CEP и управления бизнес-процессом может выполняться в двух уровнях, как на уровне бизнес осведомленности (пользователи должны понимать потенциальные целостные преимущества их индивидуальных процессов), так и на технологическом уровне (должен быть метод, посредством которого CEP может взаимодействовать с реализацией управления бизнес-процессом).

Роль CEP, ориентированных на вычисления, перекрывается технологией бизнес правил.

• Событийно-ориентированная архитектура — (EDA) шаблон архитектуры программного обеспечения, продвигающий создание, обнаружение, потребление и реакцию на события.
• Обработка потоков событий — (ESP) близкая технология, сконцентрированная на обработке потоков соотносящихся данных.

• K. Mani Chandy, W. Roy Schulte. Event Processing: Designing IT Systems for Agile Companies. — McGraw-Hill, 2009. — 251 с. — ISBN 978-0-07-163349-9.
• Martin Atzmueller, Samia Oussena, Thomas Roth-Berghofer. Enterprise Big Data Engineering, Analytics, and Management. — IGI Global, 2016. — 272 с. — ISBN 978-1-5225-0293-7.
• David C. Luckham. Event Processing for Business: Organizing the Real-Time Enterprise. — John Wiley & Sons, 2011. — 288 с. — ISBN 0-470534-85-0.