Evaluating the integration of Esper complex event processing engine and message brokers

Abstract

El gran avance y asequibilidad de las tecnologías, las comunicaciones y la tecnología de sensores ha llevado a la generación de grandes cantidades de datos en el campo del Internet de las Cosas y los entornos inteligentes, así como una gran demanda de aplicaciones y servicios inteligentes adaptados a las necesidades específicas de cada individuo. Esto ha conllevado la necesidad de sistemas capaces de recibir, enrutamiento y procesamiento de grandes cantidades de datos para detectar situaciones de interés con baja latencia, pero a pesar de los muchos trabajos existentes en los últimos años, estudiar sistemas de procesamiento de datos altamente escalables y de baja latencia sigue siendo necesario. En esta área, la eficiencia de la tecnología de procesamiento de eventos complejos (CEP) es de particular importancia y se ha utilizado en una variedad de escenarios de aplicación. Sin embargo, en la mayoría de estos escenarios no hay una evaluación de rendimiento para mostrar cómo se desempeña el sistema bajo diversas cargas y, por lo tanto, el desarrollador se enfrenta al desafío de desarrollar tales sistemas basados en CEP en nuevos escenarios sin saber cómo el sistema será capaz de manejar diferentes tasas de datos de entrada y abordar la escalabilidad y la tolerancia a fallos. Este artículo tiene como objetivo llenar este vacío proporcionando una evaluación de las diversas versiones de uno de los motores CEP más reputados: Esper CEP, así como su integración con dos reconocidos brokers de mensajería para la ingesta de datos: RabbitMQ y Apache Kafka. Para este propósito, definimos un punto de referencia con una serie de patrones de eventos con algunos de los operadores más representativos del motor Esper CEP y realizamos una serie de pruebas con una tasa creciente de datos de entrada al sistema. Hicimos esto para tres arquitecturas de software alternativas: integrando Esper de código abierto y RabbitMQ, integrando una instancia de Esper edición empresarial con Apache Kafka, e integrando dos instancias distribuidas de Esper edición empresarial con Apache Kafka. Medimos el uso de CPU, memoria RAM, latencia y tiempo de rendimiento, buscando la tasa de entrada de datos con la que el sistema se sobrecarga para cada patrón de evento y comparamos los resultados de las tres arquitecturas propuestas. Los resultados han mostrado un consumo de CPU muy bajo para todas las opciones de implementación y tasas de datos de entrada; un uso equilibrado de la memoria, bastante similar entre las tres arquitecturas, hasta una tasa de entrada de 10,000 o 15,000 eventos por segundo, dependiendo de la arquitectura y el patrón de eventos, y un tiempo de respuesta bastante eficiente hasta 10,000 o 15,000 eventos por segundo, dependiendo de la arquitectura y el patrón de eventos. Basándonos en un análisis más exhaustivo de los resultados, hemos concluido que las diferentes opciones ofrecidas por Esper para CEP proporcionan soluciones muy eficientes para el procesamiento de datos en tiempo real, aunque cada una con sus limitaciones en términos de brokers a utilizar para la integración de datos, escalabilidad y tolerancia a fallos; se han extraído una serie de sugerencias para que el desarrollador tome como base para elegir qué motor CEP y qué broker de mensajería utilizar para la implementación dependiendo del sistema en cuestión.

The great advance and affordability of technologies, communications and sensor technology has led to the generation of large amounts of data in the field of the Internet of Things and smart environments, as well as a great demand for smart applications and services adapted to the specific needs of each individual. This has entailed the need for systems capable of receiving, routing and processing large amounts of data to detect situations of interest with low latency, but despite the many existing works in recent years, studying highly scalable and low latency data processing systems is still necessary. In this area, the efficiency of complex event processing (CEP) technology is of particular significance and has been used in a variety of application scenarios. However, in most of these scenarios there is no performance evaluation to show how the system performs under various loads and therefore the developer is challenged to develop such CEP-based systems in new scenarios without knowing how the system will be able to handle different input data rates and address scalability and fault tolerance. This article aims to fill this gap by providing an evaluation of the various versions of one of the most reputable CEP engines—Esper CEP, as well as its integration with two renowned messaging brokers for data ingestion—RabbitMQ and Apache Kafka. For this purpose, we defined a benchmark with a series of event patterns with some of the most representative operators of the Esper CEP engine and we performed a series of tests with an increasing rate of input data to the system. We did this for three alternative software architectures: integrating open-source Esper and RabbitMQ, integrating one instance of Esper enterprise edition with Apache Kafka, and integrating two distributed instances of Esper enterprise edition with Apache Kafka. We measured the usage of CPU, RAM memory, latency and throughput time, looking for the data input rate with which the system overloads for each event pattern and we compared the results of the three proposed architectures. The results have shown a very low CPU consumption for all implementation options and input data rates; a balanced memory usage, quite similar among the three architectures, up to an input rate of 10,000 or 15,000 events per second, depending on the architecture and event pattern, and a quite efficient response time up to 10,000 or 15,000 events per second, depending on the architecture and event pattern. Based on a more exhaustive analysis of results, we have concluded that the different options offered by Esper for CEP provide very efficient solutions for real-time data processing, although each with its limitations in terms of brokers to be used for data integration, scalability, and fault tolerance; a number of suggestions have been drawn out for the developer to take as a basis for choosing which CEP engine and which messaging broker to use for the implementation depending on the of the system in question