Обработка сложных событий: технологии и применение.

Введение

Обработка событий — это метод отслеживания и анализа (обработки) потоков информации (данных) о происходящих событиях и получения на их основе выводов. Комплексная обработка событий (CEP) представляет собой набор концепций и методов, разработанных в начале 1990-х годов для обработки событий в реальном времени и извлечения информации из потоков событий по мере их поступления. Целью комплексной обработки событий является выявление значимых событий (таких как возможности или угрозы) в ситуациях реального времени и реагирование на них как можно быстрее. Эти события могут происходить на различных уровнях организации в виде лидов продаж, заказов или обращений в службу поддержки клиентов. Или это могут быть новости, текстовые сообщения, публикации в социальных сетях, данные фондового рынка, сводки о дорожном движении, прогнозы погоды или другие виды данных. С тех пор CEP стала ключевой технологией во многих системах, используемых для немедленного реагирования на поступающие потоки событий. Применение CEP в настоящее время (2018 г.) можно найти во многих секторах бизнеса, включая системы торговли на фондовом рынке, мобильные устройства, интернет-операции, обнаружение мошенничества, транспортную отрасль и сбор разведывательной информации государственными органами. Огромный объем информации, доступной о событиях, иногда называют «облаком событий». Колокола, мужчина и женщина в свадебных нарядах и рис, летящий по воздуху. CEP опирается на ряд методов, включая:

* Обнаружение шаблонов событий
* Абстракция событий
* Фильтрация событий
* Агрегация и преобразование событий
* Моделирование иерархий событий
* Выявление взаимосвязей (таких как причинно-следственная связь, принадлежность или временные рамки) между событиями
* Абстрагирование процессов, управляемых событиями

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

История

Область CEP берет начало в дискретном моделировании, области активных баз данных и некоторых языках программирования. Активность в индустрии была предварена волной исследовательских проектов в 1990-х годах. Первым проектом, который подготовил почву для создания универсального языка и модели исполнения CEP, был проект Rapide в Стэнфордском университете под руководством Дэвида Лакхэма. Параллельно велись два других исследовательских проекта: Infospheres в Калифорнийском технологическом институте под руководством К. Мани Чанди и Apama в Кембриджском университете под руководством Джона Бейтса. Коммерческие продукты были основаны на концепциях, разработанных в этих и некоторых последующих исследовательских проектах. Объединение усилий сообщества началось с серии симпозиумов по обработке событий, организованных Техническим обществом обработки событий, а затем серией конференций ACM DEBS. Одним из результатов этих усилий стало создание манифеста по обработке событий.

Связанные понятия

CEP используется в продуктах оперативной разведки (OI) для получения информации о бизнес-операциях путем проведения анализа запросов к потоковым данным и данным о событиях. OI собирает данные в реальном времени и сопоставляет их с историческими данными для предоставления информации и аналитики. Для создания единой операционной картины, использующей актуальные данные, можно объединять несколько источников данных. В управлении сетями, системами, приложениями и сервисами чаще говорят о корреляции событий. Как и движки CEP, движки корреляции событий (корреляторы событий) анализируют большой объем событий, выявляют наиболее значимые и инициируют действия. Однако большинство из них не генерируют новые выведенные события, а устанавливают связь между событиями высокого и низкого уровня. Движки вывода, например, системы логического вывода на основе правил, обычно генерируют выведенную информацию в области искусственного интеллекта, но редко создают новую информацию в форме сложных (т.е. выведенных) событий.

Пример

Более системный пример CEP включает автомобиль, несколько датчиков и различные события и реакции. Представьте, что автомобиль оснащен несколькими датчиками — один измеряет давление в шинах, другой — скорость, а третий — определяет, сидит ли кто-то на сиденье или покинул его. В первой ситуации автомобиль движется, и давление в одной из шин снижается с 45 до 41 psi в течение 15 минут. По мере снижения давления в шине генерируется серия событий, содержащих данные о давлении в шине. Одновременно генерируется серия событий, содержащих данные о скорости автомобиля. Процессор событий автомобиля может обнаружить ситуацию, когда постепенная потеря давления в шине в течение относительно длительного периода времени приводит к созданию события "lossOfTirePressure". Это новое событие может запустить процесс реагирования, который зафиксирует потерю давления в журнале технического обслуживания автомобиля и предупредит водителя через бортовой интерфейс о снижении давления в шине. Во второй ситуации автомобиль движется, и давление в одной из шин падает с 45 до 20 psi за 5 секунд. Обнаружена иная ситуация — возможно, из-за того, что потеря давления произошла за более короткий промежуток времени, или из-за того, что разница в значениях между последовательными событиями превысила заданный предел. В результате обнаружения новой ситуации генерируется новое событие "blowOutTire". Это новое событие запускает другой процесс реагирования, который немедленно предупреждает водителя и активирует бортовые компьютерные алгоритмы, помогающие водителю остановить автомобиль, не теряя управления из-за заноса. Кроме того, события, представляющие обнаруженные ситуации, могут комбинироваться с другими событиями для выявления более сложных ситуаций. Например, в заключительной ситуации автомобиль движется нормально, происходит взрыв шины, в результате чего автомобиль съезжает с дороги и врезается в дерево, а водитель вылетает из машины. Быстро обнаруживается ряд различных ситуаций. Комбинация событий "blowOutTire", "zeroSpeed" и "driverLeftSeat" в течение очень короткого периода времени приводит к обнаружению новой ситуации: "occupantThrownAccident". Даже если нет прямого измерения, которое могло бы однозначно определить, что водитель был выброшен из автомобиля, или что произошла авария, комбинация событий позволяет обнаружить ситуацию и создать новое событие, сигнализирующее об обнаруженной ситуации. Это суть сложного (или составного) события. Оно сложно, потому что ситуацию нельзя обнаружить напрямую; необходимо сделать вывод о том, что ситуация произошла, на основе комбинации других событий.

A more systemic example of CEP involves a car, some sensors and various events and reactions. Imagine that a car has several sensors—one that measures tire pressure, one that measures speed, and one that detects if someone sits on a seat or leaves a seat. In the first situation, the car is moving and the pressure of one of the tires moves from 45 psi to 41 psi over 15 minutes. As the pressure in the tire is decreasing, a series of events containing the tire pressure is generated. In addition, a series of events containing the speed of the car is generated. The car's Event Processor may detect a situation whereby a loss of tire pressure over a relatively long period of time results in the creation of the "lossOfTirePressure" event. This new event may trigger a reaction process to note the pressure loss into the car's maintenance log, and alert the driver via the car's portal that the tire pressure has reduced. In the second situation, the car is moving and the pressure of one of the tires drops from 45 psi to 20 psi in 5 seconds. A different situation is detected—perhaps because the loss of pressure occurred over a shorter period of time, or perhaps because the difference in values between each event were larger than a predefined limit. The different situation results in a new event "blowOutTire" being generated. This new event triggers a different reaction process to immediately alert the driver and to initiate onboard computer routines to assist the driver in bringing the car to a stop without losing control through skidding. In addition, events that represent detected situations can also be combined with other events in order to detect more complex situations. For example, in the final situation the car is moving normally and suffers a blown tire which results in the car leaving the road and striking a tree, and the driver is thrown from the car. A series of different situations are rapidly detected. The combination of "blowOutTire", "zeroSpeed" and "driverLeftSeat" within a very short period of time results in a new situation being detected: "occupantThrownAccident". Even though there is no direct measurement that can determine conclusively that the driver was thrown, or that there was an accident, the combination of events allows the situation to be detected and a new event to be created to signify the detected situation. This is the essence of a complex (or composite) event. It is complex because one cannot directly detect the situation; one has to infer or deduce that the situation has occurred from a combination of other events.

Интеграция с управлением бизнес-процессами

Естественным направлением для CEP стало управление бизнес-процессами (BPM). BPM фокусируется на сквозных бизнес-процессах, чтобы непрерывно оптимизировать и согласовывать их с операционной средой. Однако оптимизация бизнеса не зависит исключительно от его отдельных, сквозных процессов. Казалось бы, разрозненные процессы могут существенно влиять друг на друга. Рассмотрим следующий сценарий:
В аэрокосмической отрасли хорошей практикой является мониторинг поломок техники для выявления тенденций (определения потенциальных недостатков в производственных процессах, материалах и т. д.). Другой отдельный процесс отслеживает жизненные циклы действующей техники и выводит ее из эксплуатации по мере необходимости. Одно из применений CEP – связать эти отдельные процессы, чтобы в случае обнаружения неисправности, вызванной усталостью металла (значимое событие) в процессе мониторинга поломок, можно было создать задачу для использования второго процесса (жизненного цикла) с целью отзыва техники, изготовленной из той же партии металла, которая была признана дефектной в первоначальном процессе. Интеграция CEP и BPM должна осуществляться на двух уровнях: на уровне понимания бизнеса (пользователи должны осознавать потенциальные комплексные преимущества своих отдельных процессов) и на технологическом уровне (должен существовать механизм взаимодействия CEP с реализацией BPM). Для получения обзора современных подходов к интеграции CEP и BPM, часто называемой Event Driven Business Process Management, обратитесь к. Роль CEP, ориентированной на вычисления, можно рассматривать как пересекающуюся с технологией бизнес-правил. Например, центры обслуживания клиентов используют CEP для анализа потока кликов и управления клиентским опытом. Программное обеспечение CEP способно обрабатывать информацию в реальном времени о миллионах событий (кликов или других взаимодействий) в секунду для бизнес-аналитики и других приложений поддержки принятия решений. Эти "рекомендательные приложения" помогают агентам предоставлять персонализированное обслуживание, основываясь на опыте каждого клиента. Приложение CEP может собирать данные о том, что клиенты делают в данный момент во время телефонного разговора, или как они недавно взаимодействовали с компанией по различным каналам, включая посещение офиса, веб-сайты с функциями самообслуживания, мгновенные сообщения и электронную почту. Затем приложение анализирует общий клиентский опыт и рекомендует сценарии или следующие шаги, которые помогают агенту во время разговора и, надеемся, обеспечивают удовлетворенность клиента.

A natural fit for CEP has been with business process management (BPM). BPM focuses on end to end business processes, in order to continuously optimize and align for its operational environment. However, the optimization of a business does not rely solely upon its individual, end to end processes. Seemingly disparate processes can affect each other significantly. Consider this scenario:
In the aerospace industry, it is good practice to monitor breakdowns of vehicles to look for trends (determine potential weaknesses in manufacturing processes, material, etc.). Another separate process monitors current operational vehicles' life cycles and decommissions them when appropriate. One use for CEP is to link these separate processes, so that in the case of the initial process (breakdown monitoring) discovering a malfunction based on metal fatigue (a significant event), an action can be created to exploit the second process (life cycle) to issue a recall on vehicles using the same batch of metal discovered as faulty in the initial process. The integration of CEP and BPM must exist at two levels, both at the business awareness level (users must understand the potential holistic benefits of their individual processes) and also at the technological level (there needs to be a method by which CEP can interact with BPM implementation). For a recent state of the art review on the integration of CEP with BPM, which is frequently labeled as Event Driven Business Process Management, refer to. Computation oriented CEP's role can arguably be seen to overlap with Business Rule technology. For example, customer service centers are using CEP for click stream analysis and customer experience management. CEP software can factor real time information about millions of events (clicks or other interactions) per second into business intelligence and other decision support applications. These "recommendation applications" help agents provide personalized service based on each customer's experience. The CEP application may collect data about what customers on the phone are currently doing, or how they have recently interacted with the company in other various channels, including in branch, or on the Web via self service features, instant messaging and email. The application then analyzes the total customer experience and recommends scripts or next steps that guide the agent on the phone, and hopefully keep the customer happy.

Интеграция с базами данных временных рядов

База данных временных рядов — это программная система, оптимизированная для обработки данных, организованных по времени. Временные ряды — это конечные или бесконечные последовательности элементов данных, где каждый элемент имеет связанную временную метку, а последовательность временных меток не убывает. Элементы временного ряда часто называют тиками. Временные метки не обязательно должны быть строго возрастающими (достаточно, чтобы они не убывали), поскольку на практике временное разрешение некоторых систем, таких как источники финансовых данных, может быть очень низким (миллисекунды, микросекунды или даже наносекунды), поэтому последовательные события могут иметь одинаковые временные метки. Данные временных рядов предоставляют исторический контекст для анализа, обычно связанного с обработкой сложных событий. Это применимо к любой отраслевой вертикали, например, к финансам, и может использоваться совместно с другими технологиями, такими как BPM. В идеале, для анализа CEP исторические временные ряды и потоковые данные в реальном времени следует рассматривать как единый временной континуум. События вчерашнего дня, прошлой недели или месяца — это просто продолжение того, что происходит сегодня и может произойти в будущем. Например, можно сравнивать текущие объемы торгов с историческими объемами, ценами и волатильностью для логики исполнения сделок. Или, для принятия решений на основе текущих рыночных цен, может потребоваться сравнение с бенчмарками, включающими динамику секторов и индексов, чьи внутридневные и исторические тренды позволяют оценить волатильность и сгладить выбросы.

Интернет вещей и интеллектуальные киберфизические системы

Комплексная обработка событий является ключевым компонентом в системах Интернета вещей (IoT) и интеллектуальных киберфизических системах (CPS). Обработка плотных и разнородных потоков данных от различных датчиков и выявление закономерностей в этих потоках – типичная задача в таких сценариях. Большинство этих методов основаны на том, что представление состояния системы IoT и ее изменений в виде потока данных более эффективно, чем использование статической, материализованной модели. Логические выводы на основе таких потоковых моделей принципиально отличаются от традиционных методов рассуждений и обычно требуют комбинации преобразований моделей и CEP.