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 II: conceptos básicos
- Introducción al procesamiento de Eventos Complejos III: puntos clave
Un gran número de sistemas informáticos están construidos en base a un esquema de orden–control-respuesta, es decir, un método llama a otro método y le da una orden para llevar a cabo una acción o recuperar algún tipo de información. Pero a menudo el mundo real funciona de un modo bien distinto: una empresa recibe una nueva orden, un servidor web recibe una petición para una página Web, un evento político desequilibra repentinamente los índices bursátiles, etc.
Ninguna de estas acciones acostumbra a ocurrir de una forma programada u ordenada. En lugar de eso, se produce un evento debido en una acción o actividad externa. La pregunta es, ¿disponemos de soluciones de arquitectura que nos permitan responder a los eventos según llegan?
Eventos por doquier
Un evento es simplemente algo que ocurre: la llegada de un correo, una señal en un sensor, un semáforo que se pone en rojo, una transferencia bancaria. Hay eventos pequeños como un mensaje SMS, u otros más grandes como puede ser la dimisión de un presidente de gobierno. Una dimisión debida, entre otros motivos, a la concatenación de muchos de estos pequeños eventos. Hay eventos más importantes que otros, como es lógico. Un mismo evento puede ser muy relevante en el momento en el que se produce y carecer de todo interés pasado un determinado periodo de tiempo. A la inversa también puede suceder, aunque con menos frecuencia. Puede existir un evento que pasa desapercibido en el momento de producirse, que se puede transformar en crucial o, al menos, ganar en importancia si la ventana de tiempo en la que se mide es lo suficientemente grande.
Los eventos poseen atributos como el momento en el que se produjeron, el tiempo que duraron, o el evento que a su vez los desencadenó, como el efecto mariposa (la mariposa que aletea en un extremo de la celda y provoca un tsunami a miles de kilómetros de distancia, o de metros). Las posibles consecuencias de un evento pueden ser reemplazadas por eventos posteriores quedando totalmente invalidadas. Una imagen vale más que mil palabras:
Realmente, ¿de qué va este tema de los eventos complejos?
Veamos con un pequeño ejemplo en qué consiste el procesamiento de eventos complejos. Una persona que va al trabajo se levanta por las mañanas, pone la radio o la televisión y escucha a un chico que se pasa todo el año contando el estado de las carreteras, posteriormente consulta en su móvil el estado del tráfico mediante Google Maps, se mete en el coche, enciende la radio y comienzan a hablarle de crisis económica, sobres y guerras. El chico del tráfico, 10 minutos después vuelve a actualizar la información. De repente un autobús escolar aparece bloqueando carril y medio de la calle, lo que recuerda que ya hay tráfico escolar y lo que eso conlleva. Cuando esta persona va a incorporarse a la entrada de la M-30 recuerda lo que ha dicho el chico del tráfico mientras su propia vista le informa de que los coches que entran lo hacen muy despacio. En ese instante recuerda también los trazos rojos de Google Maps y decide que se irá por el centro de la ciudad evitando el camino habitual. Esa persona ha llevado a cabo un procesamiento CEP (Complex Event Processing).
El procesamiento de eventos es una actividad que se lleva a cabo en cientos de sistemas. Si pensamos por ejemplo en los millones (o billones) de mensajes que se generan diariamente en aplicaciones mundialmente utilizadas como WhatsApp, Line, Facebook o Twitter, y la velocidad que se producen, podemos extraer varias conclusiones:
- Si un sistema quiere sacar partido, positivo o negativo de esa información, le tocará lidiar con volúmenes enormes de información.
- Salvo que se quiera llevar a cabo meros análisis estadísticos, deberá utilizar mecanismos capaces de procesar información prácticamente en tiempo real.
- Tendrá que enfrentarse a otros problemas de elevada complejidad. Cómo y dónde buscar más información que complete la que te ha dado un evento previo, qué criterios utilizar para dar por buenas unas fuentes y por no fiables otras, detectar y desechar falsos positivos, tratar con situaciones excepcionales o inesperadas, etc.
Antes de otras consideraciones es recomendable analizar un conjunto de principios básicos a tener en cuenta cuando nos introducimos en el mundo de los eventos complejos.
Principio 1: Los eventos no son islas. Los patrones de Eventos permiten obtener información que tiene sentido en conjunto, que puede ser procesada. |
Cada evento contiene solamente una pequeña cantidad de información. Si conseguimos agregar en base a un patrón esos trozos de información y sus respectivos contextos será posible realizar acciones muy útiles, tanto reactivas como predictivas.
No es lo mismo que se presente el día 07/01/2011 en urgencias del hospital 12 de Octubre un paciente con síntomas de Gripe A y hasta 5 meses después no se presente otro paciente con los mismos síntomas, a que la presencia de ese paciente sea la número 20 en el hospital 12 de Octubre desde el día 05/01/2011. Y que además este evento coincida con que en México D.F. aparecieron casos de gripe la víspera de Nochebuena y en el aeropuerto de Barajas se detectaron varios pacientes con síntomas genéricos de gripe poco después de Año Nuevo.
El contexto y los patrones importan.
Principio 2: El negocio no espera. Se deben diseñar los procesos de tal modo que hagan uso de la información procesada en cuanto se disponga de ella. |
Según crece el uso de las tecnologías de la información, ya no sólo hay que preocuparse de que los sistemas funcionen correctamente, sino se ha de entender qué está sucediendo. La nube de eventos contiene un montón de información que puede ser útil. Pero esta información no viene con manual de usuario, sencillamente llega.
En algunas aplicaciones, los eventos llegan con tasas de miles de datos por segundo. Antes de CEP, los intentos de obtener business intelligence de la nube de eventos pasaban por almacenarlos en un data warehouse y posteriormente hacer data mining. Esta aproximación, muy habitual en los últimos 20 años, adolece de la inmediatez necesaria.
El principio de la inmediatez es básico en CEP, pero evidentemente complicado. Gran parte de la información necesaria es dinámica. Su utilidad suele ser de muy corta duración. Pensemos por ejemplo en un sistema de gestión de una flota de camiones que han de entregar y recoger mercancía a lo largo de España. ¿Sería nuestro sistema capaz de cambiar los itinerarios de forma inmediata en función de cambios en las condiciones meteorológicas, cortes de carreteras, averías de dos o tres camiones de la flota, atascos kilométricos debidos a un accidente?
Principio 3: ¡Por favor: analizad la información procesable de forma organizada! |
La información objetivo de la monitorización se debe separar en distintos niveles, huyendo de aproximaciones monolíticas.
P.ej.: Supongamos que una empresa de tecnología desea hacer uso del procesamiento de eventos complejos para mejorar su funcionamiento, su rendimiento, sus ganancias. Parece lógico que por un lado trate de detectar patrones de eventos que le digan si está funcionando bien como empresa y por otro lado monitorice el mercado en busca de las últimas tendencias tecnológicas y los pasos que está dando la competencia en el mismo área de negocio.
Principio 4: Vigilancia Constante. Es necesario monitorizar 24×7 los eventos, internos y externos. Estos eventos pueden contener información que probablemente indique la necesidad de cambios en los procesos de negocio. |
Imaginemos una compañía en la que hay mucho tráfico de red interno, pero los sistemas que lo generan no están convenientemente monitorizados. Si se produce un tráfico importante de mensajes desde la red interna de la compañía hacia fuera, hacia un destino no identificado en Internet, esto podría deberse a la presencia de spyware, incluso al robo de información confidencial.
Existen patrones de eventos que pueden identificar situaciones de este tipo: transferencias de datos confidenciales robados y posteriormente eliminados. En el peor de los casos, pero no el menos probable, tales patrones de eventos pueden aparecer de forma muy rápida justo después de que los datos ya han sido robados. Sin embargo la actividad delictiva puede suceder de forma lenta y pasar inadvertida si la compañía en cuestión no ha monitorizado sus sistemas IT a lo largo de todas las horas del día.
Supongamos una regla del tipo:
Si ha habido algún intento de transferencia de datos hacia fuera en los últimos 15 minutos y ninguna de esas transferencias era autorizada, entonces Generar una alerta de seguridad.
Obsérvese que este ejemplo contiene dos patrones y que concretamente el segundo patrón se corresponde con la ausencia de un evento autorizado. La ausencia de determinados tipos de eventos es difícil de detectar y sin embargo puede ser muy significativa.
Supongamos ahora otra regla, que aplica a otro tipo de negocio, como la que sigue:
Si la clasificación de la persona L es amenaza de corrupción y el informe Inf recibido de L dice que depositó más de X millones en el banco B y la cuenta de L en B tiene movimientos en los últimos 10 días y el informe Inf pasó el test de credibilidad entonces Generar una alerta de seguridad a nivel nacional sobre L con respecto a su cuenta en B.
Obsérvese que en este caso la ventana de tiempo tiene una magnitud diferente. El tiempo necesario para obtener una información significativa a partir del contenido de varios eventos varía mucho en función del tipo negocio. Pero una vez que la información se considere creíble (pasó el test de credibilidad), se debe reaccionar de forma inmediata, independientemente del negocio al que aplique.
La habilidad para detectar y reconocer de forma inmediata patrones de eventos que tengan implicaciones directas en la toma de decisiones es la base del procesamiento de eventos complejos.
Principio 5: Renovarse o morir. Las tecnologías de procesamiento de eventos complejos evolucionan y mejoran continuamente. |
Un brote epidémico en una parte del mundo está solamente a unas horas de convertirse en una amenaza inminente en cualquier otra parte del planeta. Los sistemas de alertas sobre epidemias mundiales deberían por tanto mejorar de tal modo que el tiempo que pasa desde la detección de la incubación de una posible epidemia en cualquier zona de la Tierra y la alerta pública a las distintas organizaciones de salud fuese muy corto, del orden de pocos días. Actualmente es de semanas e incluso meses.
Con esta necesidad en mente, los nuevos sistemas se apoyan en el tráfico de las redes sociales. Los rumores insistentes se han convertido en una fuente a priori fiable de indicadores de emergencias epidémicas, más rápidos que los propios informes médicos. Webs como Twitter están siendo monitorizadas para detectar brotes de enfermedades.
Las técnicas de “sentiment analysis” con soluciones Big Data se están empleando para el tratamiento de estos grandes volúmenes de información heterogénea1. En definitiva, estas fuentes de información, a todas luces novedosas, proporcionan eventos significativos mucho antes que las fuentes tradicionales.
Pero estas nuevas fuentes de información presentan otros problemas: el tráfico de información móvil está en muchos y distintos idiomas e incluye datos de muy diversos grados de exactitud y fiabilidad. Como mínimo estos datos deben ser filtrados, analizados y transformados teniendo en cuenta localizaciones geográficas, frecuencia, variabilidad, etc. Y por supuesto, por si todo esto no fuera suficientemente complejo, es preciso evitar a toda costa las falsas alarmas (intencionadas o no) porque normalmente tienen consecuencias económicas desastrosas.
Principio 6: Implementemos CEP mediante arquitecturas EDA. Una arquitectura dirigida por eventos (EDA) se puede implementar como una arquitectura orientada a servicios (SOA) en la que todas las comunicaciones son por eventos y todos los servicios son independientes, concurrentes y reaccionan a eventos de entrada produciendo eventos de salida. |
Echando la vista hacia atrás sabemos que las tecnologías utilizadas para el procesamiento de eventos han ido evolucionando de forma muy desigual. De hecho se puede decir que aún no estamos en un período de estabilidad.
Algunas de estas tecnologías, simulación de eventos discretos, bases de datos activas, middleware (tipo ESB) adaptado al procesamiento de eventos han evolucionado por caminos bien distintos. Ninguna de ellas es suficiente para llevar a cabo un procesamiento de eventos complejos adecuado. No es objetivo de este artículo diseccionar los problemas de estas tecnologías. Sí diremos que algunas de las deficiencias más importantes tienen que ver con las tareas de analizar la información, disparar acciones y la lógica de control más sofisticada en tiempo real. La clave está en la capacidad de dar una respuesta completa en tiempo real.
En cambio el procesamiento CEP basado en arquitecturas EDA permite obtener toda la información contenida en estos eventos e interpretarla de modo que se sepa cómo va a afectar al negocio y qué se puede hacer con ella poco después del instante en que sucede. CEP emplea técnicas de detección de patrones de eventos complejos, procesamiento de flujos de eventos, correlación y abstracción de eventos, jerarquías de eventos, relaciones de causalidad entre eventos, pertenencia y medidas de tiempo. Veremos con más detalle estos conceptos en el siguiente capítulo de este artículo.
Por ahora es suficiente quedarse con la idea de que una arquitectura EDA debe presentar al menos el siguiente conjunto de características:
Característica | Consideraciones |
Comunicación a muchos | En una arquitectura EDA los eventos se difunden a todos los participantes. Las comunicaciones no son, o no tienen por qué ser, bidireccionales. |
Inmediatez | Se publican los eventos según ocurren en lugar de almacenarlos y esperar para procesarlos, como hacen, por ejemplo, los procesos batch. |
Asincronismo | El sistema que publica un evento no espera a que los sistemas que lo reciben lo procesen. Publica y continúa. |
Eventos de Grano Fino | Es mejor publicar muchos eventos individuales más que un solo evento con toda la información. Esto facilita y da flexibilidad a la detección de patrones de eventos. |
Nomenclatura y categorización | Se debe definir una nomenclatura que permita clasificar eventos, y mejor aún si es en forma de jerarquía. |
Procesamiento de Eventos Complejos | El sistema interpretará y monitorizará las relaciones entre los eventos. Por ejemplo, la agregación de eventos (un patrón de eventos implica un evento de mayor nivel) o relación de causalidad (un evento es originado por un evento previo). |
Referencias
Programming Without a Call Stack – Event-driven Architectures Gregor Hohpe www.eaipatterns.com
“Event processing for Business”. David C. Luckham
Oracle Complex Event Processing (CEP) – Key Features and Benefits
Si quieres saber más sobre CEP o arquitectura software, contáctanos o síguenos en las redes sociales (Linkedin, Twitter, Youtube).