Esta entrada forma parte de una serie de artículos sobre Introducción al Procesamiento de Eventos Complejos. Puedes leer el resto de artículos aquí:
- Introducción al procesamiento de Eventos Complejos I: qué es y principios
- Introducción al procesamiento de Eventos Complejos III: puntos clave
Conceptos básicos
En la primera parte de este artículo «Introducción al procesamiento de Eventos Complejos I: qué es y principios» vimos algunos de los principios más importantes de CEP. Trataremos de completar la foto inicial analizando en detalle los conceptos fundamentales sobre los que se sustenta el procesamiento de eventos complejos.
Eventos y causalidad
Un evento es un objeto que representa o registra una actividad que está ocurriendo, o se considera que está ocurriendo. |
El resultado de la predicción meteorológica que se obtiene al ejecutar un proceso simulador del tiempo, la confirmación de una compra que se registra en la web de Carrefour, la lectura de datos mediante sensores RFID que informa de que las maletas están pasando por la ruta adecuada dentro del sistema de gestión de equipaje de un aeropuerto, la ausencia de dicha señal que indica una posible pérdida de alguna maleta.
Esta definición habla de objetos evento que describen eventos reales o virtuales y son procesados en sistemas de información. Estos objetos son cualquier clase de estructura de datos desde strings a tipos de datos complejos. A veces se habla de eventos y mensajes de forma indistinta, pero lo cierto es que un evento contiene más información que un mero mensaje. A saber, la actividad que ha ocurrido, cuándo ha ocurrido, cuánto tiempo duró y cómo está relacionada con otras actividades.
La siguiente tabla representa un pequeño subconjunto de eventos relacionados entre sí:
Happening | Start time | End time | Triggered by other events |
Evento 1: Tokio anuncia que debido a distintos motivos socio económicos no puede hacer frente a los Juegos Olímpicos de 2020. | 1 de Agosto de 2014, a las 20:35 | 1 de Agosto de 2014, a las 20:45 | Evento 0: Súbito aumento en 200 puntos de la prima de riesgo japonesa. |
Evento 2: El COI celebra una reunión de urgencia para definir una nueva sede de entre las finalistas. | 2 de Agosto de 2014, a las 09:00 | 2 de Agosto de 2014, a las 20:45 | Evento 1 |
Evento 3: Se detecta un incremento exponencial en la demanda de café con leche en los bares de la Plaza Mayor de Madrid. | 3 de Agosto de 2014, a las 07:00 | 12 de Agosto de 2014, a las 22:45 | Evento 2 |
No siempre es necesario manejar timestamps para inicio y fin de un evento; dependerá del tipo de procesamiento a realizar.
Veamos otro ejemplo que representa los polémicos conceptos de correlación y causalidad de eventos:
Happening | Start time | End time | Triggered by other events |
Evento1: Conocidos representantes de la cultura se manifiestan por el centro de Madrid en contra de los recortes | 19 de Julio de 2012, a las 17h 00’ 00’’ | 19 de Julio de 2012, a las 20h 01’ 00’’ | Evento 0 |
Evento2: La prima de riesgo española se dispara a los 579 puntos | 19 de Julio de 2012, a las 18h 00’ 00’’ | 19 de Julio de 2012, a las 18h 01’ 00’’ | ¿Evento 1? |
Evento 3: Un periódico que no nombraré superpone ambas imágenes en su portada del día siguiente estableciendo una relación de causalidad. | 20 de Julio de 2012, a las 06h 00’ 00’’ | 20 de Julio de 2012, a las 06h 00’ 00’’ | ¿Evento 2 y Evento 1? |
La causalidad entre eventos no siempre es objetiva. Éste es un claro ejemplo de lo que ocurre cuando un sistema confunde correlación y causalidad de eventos por el hecho de que ambos comparten ventana de tiempo.
Es muy importante hacer análisis minuciosamente objetivos de la causalidad entre eventos porque establecer relaciones causales que no reflejan la realidad puede dar lugar a que un sistema de procesamiento de eventos complejos genere conclusiones incoherentes.
Nubes de eventos
Esta imagen muestra una nube de eventos relacionada con las acciones de los clientes de una web de un banco cualquiera. Cada secuencia linear de eventos representa las acciones de los clientes cuando acceden a las cuentas y realizan distintas transacciones bancarias en el orden que sea.
El término nube de eventos global se suele utilizar para referirse al conjunto de todos los eventos que pueden llegar a una empresa, a un negocio, junto con la medida de tiempo de los mismos, relaciones de causalidad y cualquier otro tipo de relaciones significativas. |
Las nubes de eventos llegan a una empresa a través de sus sistemas de información y de su capa de comunicaciones. El número de formatos de datos de entrada puede ser arbitrariamente alto. De nuevo es más útil recurrir a las imágenes.
Es precisamente esta jungla de datos, sistemas de información, protocolos de comunicaciones los que dan la potencia de los eventos. Pero también se pueden convertir en un río revuelto del que ganen ciertos pescadores.
Pensemos por ejemplo qué pasaría si se empiezan a detectar secuencias de movimientos como la siguiente: “Un usuario entra en la web, cambia su password y de forma inmediata ejecuta una orden de pago automática a una cuenta externa”, todo ello en un período de tiempo de 5 minutos. Cada uno de estos eventos por sí mismo es normal, pero la secuencia de los mismos incluyendo la variable tiempo hace sospechoso al conjunto, al patrón. ¿Por qué cambiar la password justo antes de retirar dinero?
Pero podría ocurrir perfectamente que alguien regrese de las vacaciones del verano y decida pagar el gimnasio una vez que ha cambiado su password porque lleva tiempo considerando que no es lo suficientemente segura.
La detección de patrones de eventos es todo un desafío, al que se dedicará más tiempo en posteriores artículos. Un ejemplo claro son los sistemas actuales de detección del fraude pues han sido históricamente demasiado rígidos, desarrollados mediante software con un montón de sentencias condicionales que simplemente controlan los casos especiales de fraude ya conocidos. Esto los convertía en sistemas inflexibles y difíciles de cambiar; y por supuesto, propensos a inexactitudes e incluso a errores de bulto.
Los motores de reglas que son capaces de procesar eventos permiten desarrollar sistemas más flexibles y fáciles de actualizar en el mundo de la detección de fraude y en tantos otros.
Niveles de Eventos
Volviendo a la imagen anterior se puede pensar que la nube de eventos es una masa de información deslavazada. Pero lo cierto es que los eventos se pueden organizar en estructuras muy simples, por ejemplo, en capas o niveles.
La idea de organizarlos por capas es similar a la organización de la torre OSI en telecomunicaciones. El nivel más bajo, el de la capa física, transporta eventos llamados paquetes (secuencias de bits). Un conjunto determinado de estas secuencias de bits forman un evento de un nivel superior en la capa de enlace de datos, que a su vez se organizan para formar otro evento en la capa del nivel de red y así hasta generar eventos de la capa más alta, la del nivel de aplicación, que pueden dar lugar, por ejemplo, al envío de mensajes de WhatsApp y éstos a complicarnos tremendamente la vida.
La idea de niveles de eventos es aplicable también a los eventos de negocio. Parece lógico descomponer eventos de negocio de alto nivel en eventos de nivel inferior.
Un ejemplo sería el evento “contratación de Gareth Bale por el Real Madrid” que dependerá de un montón de eventos de nivel inferior: negociación de los representantes de ambos jugadores, negociación entre los presidentes de los clubs, elaboración de comunicados de prensa para añadir presión a las negociaciones, búsqueda de financiación bancaria, no escuchar el clamor social que cataloga la operación de inmoral,…
Un evento de nivel superior puede descomponerse en eventos de nivel inferior, ya sea por presencia o ausencia de los mismos.
Estos eventos a su vez implican otros eventos de nivel inferior, tales como el uso de software de contabilidad, software de gestión bancaria, software de edición de texto (para elaborar el contrato). Si seguimos esa línea de descomposición lo más lógico es que terminemos desgranando eventos correspondientes a la capa IT habiendo partido de la capa de negocio. Una descomposición típica de los eventos de negocio tiene el siguiente aspecto:
Capa de Procesos de Negocio 1 → Capa de procesos de negocio 2 → … → Capa de aplicaciones → Capa de middleware → Capa de software base.
La organización en capas de eventos facilita el análisis y la trazabilidad de los procesos de negocio.
Si nos hemos preocupado de definir las dependencias entre eventos que están en diferentes niveles, posteriormente será más fácil seguir ese rastro para analizar errores de negocio que nos conduzcan a problemas en la base de datos o incluso en la capa de comunicaciones.
Los responsables de negocio obviamente solamente se preocupan por los eventos de la capa de negocio. Si es necesario analizar lo que ocurrió en capas inferiores, lo normal es que esta tarea recaiga en los informáticos como bien sabemos todos.
Flujos de Eventos
Las primeras aplicaciones CEP que trataban con los eventos de bolsas de valores procesaban los eventos en el mismo orden en el que llegaban. La ventaja de estos sistemas era la simplicidad de su implementación. Con este procesamiento tan simple se podían alcanzar tasas de procesamiento cercanas al tiempo real puesto que la lógica era bien sencilla.
Pero a razonamientos tan simplistas, resultados habitualmente pobres. Si el 11 de Septiembre de 2001 a las 16:00 h GMT+1 empiezan a llegar al mismo tiempo caídas espectaculares de las bolsas de Tokio, Londres, París y Frankfurt, este sistema no hubiese sido capaz de detectar que entre todos esos eventos que llegaron al mismo tiempo había algún tipo de relación candidata a convertirse en un patrón. ¡Cómo para tirar del hilo hasta Bin Laden!
Un flujo de eventos es una secuencia linear ordenada de eventos que ocurren dentro de una ventana de tiempo determinada. |
La nube de eventos incluye el concepto de flujo de eventos como un caso especial en el que los eventos se ajustan a un orden linear, uno detrás de otro.
Cuando los eventos son procesados en el mismo orden en el que llegan estamos hablando de procesamiento de tipo ESP (Event Streams Processing). El objetivo es proporcionar a un sistema la capacidad de procesar tasas de eventos muy altas en ventanas de tiempo muy cortas. Se buscaba, y se sigue buscando, llevar a cabo un procesamiento sobre los datos que produzca resultados en cuestión de segundos. Pero es lógico pensar que no se puede perder por el camino información tan importante como la posible relación entre estos eventos más allá del factor tiempo.
Lo interesante es procesar la nube de eventos
Es más habitual tener que tratar con varios flujos de eventos de forma simultánea, de tal modo que los eventos de cada uno de los flujos se relacionen con el resto de formas muy diversas.
Como ya hemos visto, los eventos que pertenecen al mismo flujo se relacionan entre ellos por su fecha de llegada; sin embargo también sucede que los eventos de un flujo sean las causas de los eventos de otro flujo o formen patrones con los eventos de otros flujos. Esto conduce a la conclusión básica de que los flujos de eventos no deben ser procesados de forma independiente. Incluso la aproximación de mezclarlos en un único flujo secuencialmente ordenado se considera insuficiente.
La relación de causalidad no tiene por qué ser siempre secuencial. Imaginemos una cadena de mensajes de WhatsApp en los que un jefe de proyecto y uno de sus programadores están discutiendo alegremente la funcionalidad de una pantalla que saca un informe de la aplicación. El jefe de proyecto manda un mensaje WM1 proponiendo un gráfico en 2D con diagramas de tarta. El programador responde con un mensaje WM2 diciendo que los diagramas sean en 3D, porque está “chupao”. El jefe de proyecto se anima y responde un mensaje WM3 diciendo que además de 3D tenga valores resaltados en cada una de las piezas de la tarta. El programador añade un mensaje WM4 con una leyenda detallada en la parte superior derecha del gráfico.
Mientras tanto, el jefe de proyecto recibe por email un mensaje EM1 del responsable de sistemas del cliente diciéndole que el informe ha de estar incluido en la aplicación esa misma tarde. El jefe de proyecto responde un mensaje EM2 asegurando que estará sin falta. El jefe de proyecto manda un mensaje WM5 al programador informándole de que basta con que saque un informe en modo texto y rapidito.
Vemos cómo los eventos de un segundo flujo pueden afectar claramente a los eventos del primer flujo saltándose la causalidad secuencial que se había establecido en primer término.
Entonces, ¿qué ideas son las importantes? Descúbrelo en el siguiente artículo
Referencias
“Event processing for Business”. David C. Luckham
Programming Without a Call Stack – Event-driven Architectures Gregor Hohpe www.eaipatterns.com
Oracle Complex Event Processing (CEP) – Key Features and Benefits
http://inteligencialinguistica.com/blog/causalidad-vs-correlacion-primera-parte/
Si quieres saber más sobre CEP o arquitectura software, contáctanos o síguenos en las redes sociales (Linkedin, Twitter, Youtube).