Distributed Scheduling of Event Analytics across Edge and Cloud

TL;DR

This paper presents a genetic algorithm-based approach for energy-efficient, low-latency placement of complex event processing queries across edge and cloud resources in IoT environments, validated through extensive real-world benchmarks and simulations.

Contribution

It introduces a novel optimization framework using a genetic algorithm for distributed CEP query placement across edge and cloud, improving performance and cost-efficiency.

Findings

GA achieves near-optimal solutions within seconds

Method reduces end-to-end latency significantly

Validated on diverse real-world and simulated scenarios

Abstract

Internet of Things (IoT) domains generate large volumes of high velocity event streams from sensors, which need to be analyzed with low latency to drive decisions. Complex Event Processing (CEP) is a Big Data technique to enable such analytics, and is traditionally performed on Cloud Virtual Machines (VM). Leveraging captive IoT edge resources in combination with Cloud VMs can offer better performance, flexibility and monetary costs for CEP. Here, we formulate an optimization problem for energy-aware placement of CEP queries, composed as an analytics dataflow, across a collection of edge and Cloud resources, with the goal of minimizing the end-to-end latency for the dataflow. We propose a Genetic Algorithm (GA) meta-heuristic to solve this problem, and compare it against a brute-force optimal algorithm (BF). We perform detailed real-world benchmarks on the compute, network and energy capacity of edge and Cloud resources. These results are used to define a realistic and comprehensive simulation study that validates the BF and GA solutions for 45 diverse CEP dataflows, LAN and WAN setup, and different edge resource availability. We compare the GA and BF solutions against random and Cloud-only baselines for different configurations, for a total of 1764 simulation runs. Our study shows that GA is within 97% of the optimal BF solution that takes hours, maps dataflows with 4 - 50 queries in 1 - 26 secs, and only fails to offer a feasible solution <= 20% of the time.