Live Adaptation of Dataflow Stream Processing for Hybrid Edge-Cloud Analytics

Live Adaptation of Dataflow Stream Processing for Hybrid Edge-Cloud Analytics Yuanli Wang1 , Prateek Jain1 , Lei Huang1 , Le Xu2 , Vasiliki Kalavri1 1 Boston University 2 University of Edinburgh

arXiv:2610.34658v1 [cs.DC] 26 Oct 2026

Abstract

to the edge can reliably sustain the target rate under dynamic WAN conditions and limited edge resources. Recent research has explored the use of compute-enabled edge resources for analytics. Systems like DART [26, 44], Frontier [52], and NebulaStream [25, 49, 67] proposed new architectures for pure-edge processing, offering robustness under churn and scalability to hundreds of edge nodes and concurrent queries. Others, like Falcon [50] and Shepherd [56], focus on hybrid, hierarchical wide-area deployments, with optimizations for regional data aggregation and strategies to handle limited resources and dynamic conditions.

Dataflow streaming systems, like Apache Flink and Spark Streaming, are integral to modern business analytics, providing real-time insights across industries. However, for emerging hybrid edge-cloud analytics pipelines, neither processing everything in the cloud nor static edge offloading can reliably sustain the target rate under dynamic WAN conditions and limited edge resources. In this paper, we explore how these datacenter-centric platforms can be extended to support such hybrid analytics pipelines. Our goal is to maintain full transparency for user applications, while retaining built-in fault tolerance, out-of-order processing, and existing ecosystem integrations. Achieving this is challenging because existing dataflow engines assume homogeneous resources, rely on static task placement, and do not support adaptation under dynamic network and edge conditions. We introduce Sluice, an adaptive data stream processing system for hybrid clouds, compatible with dataflow streaming engines. Sluice’s key contributions are: (i) an automatic query rewriter that decomposes applications into independent, faulttolerant segments, and (ii) a live routing mechanism that shifts computations between edge and cloud without pausing execution while preserving event-time semantics. We implement Sluice on Apache Flink and evaluate it on a physical testbed with Raspberry Pi devices, as well as on a large simulated testbed of 100 VMs. Across five real-world applications, our results show that Sluice seamlessly shifts computations between edge and cloud, while consistently achieving higher throughput than baseline systems.

1

As summarized in Table 1, although previous work proposes innovative mechanisms for WAN- and edge-aware live adaptation, they often lack support for fault tolerance, eventtime windows, monitoring and data connector integrations provided by mature engines such as Apache Flink [20, 22, 36], Spark Structured Streaming [14], and Kafka Streams [62]. Reimplementing these features and migrating existing applications require substantial engineering. In this paper, we investigate how to extend these datacenter-centric engines to hybrid edge–cloud deployments while preserving existing applications, familiar APIs, built-in features of fault tolerance, out-of-order processing, and ecosystem integration. We identify three major challenges in adapting dataflow streaming systems for hybrid edge–cloud deployments: (i) Resource homogeneity assumption: As descendants of MapReduce [30], dataflow engines assume uniform resources and do not distinguish between high-bandwidth intra-datacenter links and slow, variable edge-to-cloud connections. Consequently, out-of-the-box deployments may generate task placements that cause excessive WAN traffic, overload edge devices, and create performance bottlenecks. (ii) Static task scheduling: Most dataflow systems assign tasks to workers statically, assuming stable operating conditions [38, 65]. Hybrid edge–cloud applications, however, require continuous adaptation: WAN links exhibit variable bandwidth, edge devices vary in capacity, and event rates shift over time [41,56]. Under such dynamics, any static placement eventually becomes obsolete. Recent efforts at dynamic placement [50,56,65] either rely on stop-and-restart reconfiguration or lack automatic policies to detect when to adapt. (iii) Disruptive recovery: Cloud-centric dataflow systems rely on job-wide checkpoints [20,33,48,57] for fault tolerance, so a failure in a single task triggers re-

Introduction

The wide deployment of connected smart devices has enabled a new class of continuous analytics scenarios, such as traffic management systems, air quality monitoring, optimizing energy grid consumption, healthcare interventions, and video analytics [35,37,43,49,50,54,56,63]. These emerging applications ingest data from multiple edge locations (e.g., wearable devices, cameras, drones, and mobile sensors) and aggregate the results in the cloud to power web-based visualization dashboards or drive decision-making pipelines. However, for these types of applications, neither streaming all raw data to the cloud nor statically offloading operators 1

Table 1: Comparison with representative prior systems. Compatible with existing SPE

Live adaptation b

WAN-aware policy

No data loss c

Expressivity

Open source

DART [44] Edge Frontier [52] Edge NebulaStream [25, 49, 67] Edge / Fog

✗ ✗ ✗

N.S. ✓ N.S.

✗ ✓ ✗

N.S. ✓ N.S.

✓ (Partial) ✓ (Partial) ✓ (Partial)

✓ ✓ ✓

Shepherd [56] Falcon [50] WASP [41] CAPSys [65] Sluice

✗ ✗ ✓ : Apache Flink ✓ : Apache Flink ✓ : Apache Flink

✓ (Pause) ✓ (Pause) ✓ (Pause) ✗ ✓

✗ ✗ ✓ ✓ ✓

✗ ✓ ✓ ✓ ✓

✓ (Partial) ✓ (Partial) ✓ ✓ ✓

✗ ✓ ✗ ✓ ✓

System

Target setting

Hierarchical wide-area Hierarchical wide-area Geo-distributed Data center Hybrid edge-cloud

a N.S. : Not explicitly stated: the paper does not make a clear claim about this aspect. b Whether adaptation is performed without fully or partially pausing the job. c Event delivery guarantee.

covery of the entire job. This approach is ill-suited to edge environments, where hardware failures are more frequent. A single slow or failed edge task can stall the whole pipeline, causing downtime, input backlog, or source-side data loss. We address these challenges with Sluice, an adaptive data stream processing system for hybrid clouds, compatible with modern dataflow engines. Sluice dynamically reconfigures stateless preprocessing operators between edge and cloud, while stateful operators remain in the cloud. This design avoids state migration and supports common hybrid analytics pipelines, where lightweight preprocessing (e.g., filters and projections) reduces data volume before stateful computation [16, 27, 53]. Sluice makes three contributions: • An automatic query re-writer that transforms dataflow programs written for datacenter settings into independent, faulttolerant query segments that can be scheduled, deployed, monitored, and reconfigured in isolation. A major benefit of this design is that a failure or slowdown in one segment does not affect the others. • An adaptive routing mechanism that enables reconfiguration without downtime. The re-writer generates both edge and cloud task replicas for the stateless preprocessing operators and inserts routing controllers. A reference routing policy guides these controllers: it continuously monitors metrics to detect performance bottlenecks and dynamically adjusts routing decisions to sustain the required event rate under changing conditions. • Correctness and no data loss across segments. Sluice guarantees event-time correctness and no data loss even though its query segments run as independent jobs. It propagates watermarks along both edge and cloud paths and coordinates them across segments, so that live rerouting preserves event-time semantics. It also combines per-segment checkpoints with a persistent message broker to provide at-leastonce processing under transient edge and cloud failures (§4). We implement Sluice on Apache Flink and evaluate it in two environments: a physical hybrid testbed with Raspberry

Pi devices and a large-scale cloud testbed using 100 VMs to emulate edge nodes. Across five real-world applications, our results show that Sluice seamlessly shifts computations between edge and cloud, while its policy quickly converges to a configuration that achieves the target throughput under variable bandwidth, rate, and scarce compute conditions.

2

Background and motivation

We revisit fundamentals of dataflow stream processing and describe examples of analytics pipelines that ingest data at the edge to drive applications hosted in the cloud.

2.1

Streaming dataflow concepts

Streaming dataflow systems [12, 33] represent applications as directed acyclic graphs (DAGs), where vertices are operators performing transformations on streams and edges are data channels. Operators can be either stateless, if processing an event is independent of other events, or stateful, if processing an event depends on results of prior events. Filtering, data type transformations, and attribute projection are stateless, while aggregations, windows, and continuous joins are stateful. Every dataflow pipeline has at least one source operator that handles data ingestion and a sink that produces results to downstream applications. We say that the pipeline can sustain the target throughput, if it can process events faster than the source produces them. If an operator cannot sustain its input rate, it will stall its upstream stages and the pipeline will experience backpressure. If backpressure persists, the source will eventually need to buffer input, leading to backlog and data loss, if buffer size is exceeded. Event time. Streaming dataflow systems implement eventtime semantics [11, 12] to support correct processing of outof-order events generated at multiple distributed sources. For example, windowed aggregations group events into temporal intervals based on the timestamps that events carry. To track the progress of event time, source operators periodically emit 2

Target

Records/s

watermarks. A watermark with event time tw is a guarantee that no future events with t ≤ tw will arrive. Watermarks flow through the dataflow graph alongside data events, enabling distributed operators to coordinate their event-time progress. Fault tolerance. The de facto approach to fault tolerance in cloud-based streaming systems is via periodic consistent checkpoints [21, 22, 33, 57, 64]. The checkpoint frequency is determined by the checkpoint interval and can be tuned to trade off steady-state overhead over recovery duration. To achieve no data loss, sources must be replayable and include their input offset in their local checkpoint. Recovery reverts all operator states to the last successful checkpoint and replays the input streams from the corresponding offset.

2.2

Edge offloading

60

40 Network BW

Network BW (Mbps)

No offloading

Compute Contention

Operating Conditions 170 80 0

0

1800

3600 Time (s)

5400

7200

Figure 1: Throughput of the traffic monitoring application (Q5) under two static deployments (top) and the operating conditions applied over time (bottom). Edge offloading runs frame filtering and image compression at the edge. No offloading runs all operators except ingestion in the cloud.

Application scenarios

To understand the requirements of hybrid edge-cloud applications, we now examine five continuous analytics scenarios from prior work [18, 32, 39, 44, 56, 58, 59]. • Q1: Air quality monitoring continuously monitors PM2.5 sensor data [60] and generates alerts when air pollution levels are deemed to be potentially unhealthy. • Q2: Taxi route monitoring ingests streams of taxi trip reports [40] to continuously identify the most frequent routes. The results feed downstream applications, such as real-time traffic maps and pricing control of ridesharing platforms. • Q3: Smart grid anomaly detection monitors smart meter data [28] to detect household energy spikes. The results are transmitted to downstream energy grid optimization pipelines to trigger alerts when normal usage is exceeded. • Q4: Sentiment analysis processes geo-tagged social media posts [18, 41, 56] and feeds results into downstream advertising applications. • Q5: Video-assisted traffic monitoring analyzes continuous video feeds from smart cameras and applies object recognition models to detect traffic violations [18, 56]. We make two observations about these scenarios.

fluctuating conditions of hybrid edge–cloud deployments. As applications ingest data from distributed edge locations and forward results to the cloud, they must adapt to variable WAN bandwidth availability [19, 41, 68]. At the same time, event rates may change over time (for example, more taxis during rush hour), and edge devices can suffer interference from corunning processes or intermittent faults. To illustrate these challenges, we measure the throughput of Q5 under varying edge–cloud bandwidth, input rates, and edge compute contention on a hybrid testbed with a Raspberry Pi and a cloud server (see §5.1 for setting). Figure 1 compares two static configurations: (i) offloading the filtering and image compression stages to the edge and (ii) executing all operations, other than data ingestion, on the server. The results show that neither deployment sustains the target throughput throughout the experiment. Cloud-only processing cannot sustain the target during low-bandwidth periods. Edge offloading reduces network traffic, but cannot sustain the higher input rate when edge compute capacity is limited. These results underscore the need for dynamic operator placement that can shift computation between edge and cloud to meet performance objectives and prevent data loss.

Stateless-to-stateful processing pattern. The dataflow graphs implementing the applications above follow a consistent structure, where initial pipeline stages consist of lightweight data transformations (filtering, projection, data cleaning, format conversion, compression) that reduce data volume, while later stages involve resource-intensive stateful operations (joins, windowed aggregations) or complex analytics (ML inference) requiring substantial compute and memory. The observation that stateless transformations often occur early also underpins classic stream processing optimization techniques, like filter pushdown and operator reordering [16,27,53]. Prior work in edge-cloud analytics has argued that offloading such early-stage operations to edge devices can significantly lower WAN data transfer [13, 35, 37, 43, 63].

3

Sluice system design

In this section, we introduce the Sluice hybrid edge-cloud stream processing system and describe how it transforms monolithic dataflow applications into independent query segments to enable zero-downtime reconfiguration under dynamic network and workload conditions. We discuss Sluice’s correctness and fault tolerance guarantees in §4. System overview. As shown in Figure 2, user queries are parsed and transformed into segments by a Query Re-writer module ( 1 ). Next, Sluice’s Hybrid Scheduler deploys those

Workload and environment dynamics. Our second observation is that static operator offloading cannot cope with the 3

Client

1

Query Edge & Cloud Resources

(a) An example query G S1 Edge

Adaptive Routing

Hy brid Scheduler

2

Sluice

Query Re- w riter

Routing Controller

3

MBSink

Metric Collector

Cloud

Deploy

Routing controller

Broker

S3

MBSink

Edge

MBSrc

Edge S2

(b) The deployed query on hybrid edge-cloud resources

Figure 3: Sluice transforms query G into independent query segments S1, S2, and S3.

Cloud

3.1

Adaptive routing mechanism

Figure 2: Sluice system overview To enable live adaptation to dynamic operating conditions and workloads, Sluice deploys operator replicas on both edge and cloud resources, confining reconfiguration to dynamic routing decisions. Its routing mechanism seamlessly activates and deactivates replicas, effectively shifting computations between the edge and the cloud. Specifically, Sluice identifies all stateless operators occurring before the first stateful one in the original dataflow graph. It creates one replica task for each such operator and deploys these replicas in the cloud. This design decision is informed by the consistent stateless-to-stateful pattern in the motivating use cases of Section 2.2. Early-stage stateless operators are lightweight and reduce record size, making them good candidates for edge offloading in bandwidth-constrained settings. Sluice places stateful operators exclusively in the cloud, so their state can be checkpointed to persistent storage that edge devices may lack. By restricting adaptation to stateless operators, Sluice leverages edge resources and eliminates reconfiguration downtime by switching dataflow channels rather than moving tasks and state. Consider the example query graph of Figure 3a with stateless operators, v1 , v2 . Figure 3b shows the resulting deployment with adaptive routing, across two edge devices and cloud resources. Sluice decomposes the query into three segments, S1 , S2 , S3 . S1 and S2 span edge and cloud resources and include two replicas per stateless operator. We denote vEi as the edge-deployed task and vCi as its corresponding cloud replica. Both replicas implement the same logic as vi . Upstream of each (vEi , vCi ) pair, a routing operator CPi dynamically directs incoming events to either the edge or cloud replica, based on policy decisions from a centralized routing controller. The controller periodically issues routing-switch commands to CPi tasks via a separate control channel (shown with dashed red arrows).

Table 2: Notation used in this paper Notation G = (V, E) Q = |V | G1 = (V1 , E1 ) N = |V1 | Nk = N − 2 vi ∈ V1 v0 vN−1 G1R = (V1R , E1R ) vEi ∈ V1R vCi ∈ V1R CPi ∈ V1R G2 = (V2 , E2 ) T BW

Description Logical DAG of user’s original query Logical DAG of the stateless query segment The number of operators in G1 The number of movable operators in G1 Operators of G1 in topological order i ∈ [0, N − 1] Data source operator Message broker sink operator Logical DAG of the stateless query segment with dynamic routing mechanism Edge replica of operator vi ∈ V1 Cloud replica of operator vi ∈ V1 Routing choice operator between vEi and vCi Logical DAG of the stateful query segment Target throughput (source output rate) Outbound bandwidth from the edge device to the cloud

segments as separate jobs on the available edge and cloud resources ( 2 ). The Metric Collector continuously monitors performance metrics of the deployed jobs and feeds them to the Routing Controller, which triggers reconfiguration as necessary, according to Sluice’s adaptive routing policy ( 3 ). Table 2 summarizes paper notation. 4

MBSink

Algorithm 1 Transform G1 to G1R

MBSrc

Require: G1 = (V1 , E1 ) Ensure: G1R = (V1R , E1R ) 1: CS ← Routing Controller 2: V1R ← {CS}, E1R ← 0/ 3: Sort operators v0 , v1 , . . . , vN−1 ∈ V1 in topological order 4: ▷ v0 is data source, vN−1 is message broker sink 5: for each mobile operator vi ∈ V1 , i ∈ {1, . . . , N − 2} do 6: Create operator CPi 7: Create replica vEi and vCi from vi 8: V1R ← V1R ∪ {CPi , vEi , vCi } 9: Add control connections: 10: E1R ← E1R ∪ {(CS,CPi )} 11: Add data flow connections: 12: Connect upstream operator outputs to CPi ▷ From vEi−1 and vCi−1 if i > 1 13: E1R ← E1R ∪ {(CPi , vEi ), (CPi , vCi )} 14: E1R ← E1R ∪ {(vEi ,CPi+1 )} ▷ Edge output can route to either replica 15: E1R ← E1R ∪ {(vCi , vCi+1 )} ▷ Cloud output bypasses CPi+1 , goes directly to operator on cloud 16: end for 17: Add original source v0 and sink vN−1 to G1R with appropriate edges 18: return G̃1 = (V1R , E1R )

MBSink

Figure 4: Query re-writing steps.

Operator replicas are organized in a mutual exclusion group: each data event is processed by only one replica of each stateless operator, so deploying replicas at both locations does not duplicate data-processing work. Each query segment is controlled independently, allowing different execution paths across segments. Figure 3b shows an example of alternative paths with green solid arrows, where segment S1 has offloaded v1 and v2 to the edge, while segment S2 executes both in the cloud. Inactive replicas are deployed but idle. Since these are stateless operators, they hold no state and only occupy a task thread and their channels’ network buffers [4, 5], while forwarding the watermarks propagated along both paths (§4.2). The memory-intensive stateful operators are never replicated.

3.2

Query re-writer

To make Sluice compatible with existing user applications, we develop a query re-writer that automatically transforms the original query into individual segments, generates the adaptive routing mechanism components, and connects everything into an end-to-end deployment, like the one shown in Figure 3b. Let G = (V, E) denote the logical DAG of the original user query, where nodes v ∈ V are logical operators, and edges e ∈ E represent directed data stream channels between operators. The re-writer first partitions the user query G into two sub-queries at the boundary between stateless and stateful operators, as shown in Figure 4. Sub-query G1 contains the source and all stateless operators up to the first stateful operator. Sub-query G2 contains that first stateful operator and all its downstream operators. Next, the re-writer transforms G1 into G1R by creating replicas for stateless operators and inserting dynamic routing operators to enable adaptive selection of execution location. The two logical sub-queries are then connected via a message broker and sent to Sluice’s hybrid scheduler which deploys them on edge and cloud resources. Algorithm 1 details the transformation of G1 to G1R . After initializing the routing controller, the re-writer processes each non-source, non-sink operator vi in G1 in topological order (lines 5–16), marking it as mobile (i.e., capable of running on either edge or cloud). It then adds three components to V1R for each mobile operator (lines 6–8): (i) a routing operator CPi , (ii) an edge replica vEi , and (iii) a cloud replica vCi . Next, the algorithm establishes control channels from the routing controller to each CPi (line 10) and data channels between

CPi and its upstream and downstream replicas (lines 12–13). The re-writing algorithm ensures that once an event is routed to the cloud at any operator vi , all subsequent operators will also be executed in the cloud. This is structurally enforced by connecting edge replica outputs to the next CP operator (line 14), preserving routing flexibility, while cloud replica outputs bypass the next CP and connect directly to the following cloud replica (line 15). As a result, any return path from the cloud to the edge is prevented, avoiding unnecessary data movement. Finally, the algorithm completes the transformation by adding the original source and sink operators with appropriate connections (line 17).

3.3

Adaptive routing policy

After query rewriting, Sluice deploys the query segments on the available edge and cloud resources. Initially, Sluice places only the source operators at the edge, which are necessary to perform event ingestion. All other operators are placed in the cloud. During execution, the routing controller collects metrics at user-specified intervals to identify performance bottlenecks and dynamically adjusts routing to ensure the deployment can sustain the rate of events generated by all edge devices without causing backpressure. Sluice automatically adjusts routing decisions by periodically evaluating a reconfiguration policy that determines whether each mobile operator in the stateless query segment 5

should run on the edge or in the cloud. This policy is evaluated on a per-device basis and accounts for variations in input event rates, network conditions, and compute contention. We first formulate the adaptive routing policy as a constrained optimization problem and then describe the heuristic algorithm that Sluice employs to solve it.

use a solver. However, that would require accurate bandwidth measurements across wide-area links. Instead, Sluice employs a fast heuristic policy that relies solely on system metrics. First, it detects whether the current routing plan is suboptimal by monitoring backpressure at the source and checking if the target throughput is sustained. If not, Sluice iteratively adjusts the routing of one or more operators until it converges on a plan that sustains the target rate. The specific adjustment action depends on the type of bottleneck. According to our problem definition, backpressure can originate either from limited network bandwidth between edge and cloud or from constrained compute capacity at the edge. To decide on a routing adjustment, Sluice inspects the metrics of the boundary operators vi (deployed at the edge) and vi+1 (deployed in the cloud). We distinguish two cases: • Case 1: Network bottleneck. High backpressure at the edge-to-cloud boundary indicates that the WAN bandwidth is saturated. In this case, the effective bandwidth between edge and cloud equals the observed data transfer rate between vi and vi+1 . We therefore apply Equation 4 to all candidate operator pairs (vi , vi+1 ) and select a routing plan that satisfies the bandwidth constraint. If multiple such plans exist, Sluice chooses the one with the fewest operators at the edge, to reduce the compute load of edge devices. • Case 2: Compute bottleneck. Low backpressure at the edge-to-cloud boundary indicates sufficient bandwidth capacity. Hence, if the deployment cannot sustain the target throughput, the bottleneck must be the edge device’s compute capacity. To resolve this, Sluice initially shifts all mobile operators to the cloud. In the next decision interval, if the target throughput is still not met, the deployment has become network-constrained again. As a result, Sluice will move one or more operators back to the edge, as in the previous case. Since Sluice ’s mechanism incurs no downtime, taking multiple steps to converge is not a practical concern. Note that when all mobile operators are deployed in the cloud (i.e., xi = 1 for all i ∈ [1, Nk ]), the edge-to-cloud boundary lies immediately after the source operator v0 . If the target throughput is not met under this configuration, only Case 1 applies, since the source operator solely ingests data and cannot become a compute bottleneck.

Problem definition. We define a routing plan as a vector X = {x1 , x2 , . . . , xNk }, with each indicator xi ∈ {0, 1} corresponding to a mobile operator vi in G1 : xi = 0 means vi executes at the edge, and xi = 1 means it executes in the cloud. The objective is to dynamically identify an event routing plan X that satisfies the target throughput under current conditions. We assume that at any time there exists at least one routing plan capable of achieving the target throughput, although the optimization process may require several iterations to find it. We further assume that cloud resources are sufficient and can be scaled as needed, so that the stateful query segment will not become a bottleneck. Therefore, any observed bottleneck must arise from limited network bandwidth or constrained compute resources at the edge. Optimization objective. We formulate the routing plan decision as an optimization problem. We model the performance of the streaming dataflow using the concept of true and observed rates, as proposed in prior work [42]. Let λicloud and λiedge be the true processing rate of operator i, at the cloud and the edge respectively. ℓio is the observed output rate of operator i. Then, the true processing rate of operator i under the current routing plan X is given by the following equation: λiX = xi · λicloud + (1 − xi ) · λiedge

(1)

To achieve the target throughput, every mobile operator in G1 must sustain the observed output rate of its upstream operator. That is, the following inequality must hold: λiX − ℓi−1 o ≥ 0, ∀i ∈ [1, Nk ]

(2)

Accounting for all mobile operators, our optimization objective can be formulated as follows: Nk

λiX − ℓi−1 o i − ℓi−1 | |λ o i=1 X

maximize ∑

(3)

Constraints. Let bio be the size per output record of operator i. The first constraint states that the traffic from edge to cloud does not exceed the currently available bandwidth BW : Nk −1

∑

(1 − xi ) · xi+1 · ℓio · bio + (1 − xNk ) · ℓNo k · bNo k ≤ BW

4

Sluice aims for application transparency, enabling users to rely on familiar event-time and fault-tolerance semantics of dataflow systems. Preserving these guarantees is challenging because Sluice query segments are deployed as independent jobs and any guarantees the underlying engine provides within a single job do not extend across jobs. As a result, event time and processing semantics are not well-defined anymore, even within the same logical application. In this section, we describe the measures Sluice takes to mitigate these issues and ensure correctness (§4.2) and no data loss (§4.3).

(4)

i=1

The second constraint ensures that once the event is routed to the cloud, it will not be routed back to the edge: xi ≤ xi+1 , ∀i, i ∈ [1, k]

Sluice guarantees

(5)

Heuristic routing algorithm. The standard way to solve an optimization problem like the one we formulate above is to 6

4.1

Assumptions

··· 8 7 8 6 5 3 5 4 2 1

(a) An example stream with watermarks shown as blue diamonds

Sluice’s correctness guarantees rely on standard properties provided by modern stream processing systems and message brokers. Specifically, we assume the message broker ensures (i) per-partition event order, (ii) reliable delivery of events with no loss, (iii) high-availability via broker replication, and (iv) persistence-before-acknowledgment for produced messages. Additionally, we assume the dataflow engine implements checkpoint-based fault tolerance. These features are widely supported in systems like Apache Kafka [51, 62], Apache Pulsar [6], Amazon Kinesis Data Streams [2], Apache Flink [3, 36], and Spark Structured Streaming [7, 14].

4.2

··· 8 6 7 8 5 5 3 4 1 2

(b) An equivalent stream order under event-time semantics

Figure 5: A watermark tw guarantees all events with t ≤ tw have already been received. Events between watermarks may be reordered, as long as they respect watermark boundaries. event follows the same execution path as in G, with only the physical placement of stateless operators potentially differing. Watermark correctness. For pipelines composed only of stateless, time-agnostic operators, path equivalence would be sufficient for correctness. However, time-aware operators, such as windows, must also produce deterministic results based on event time. To be precise, events between two watermarks may be reordered arbitrarily but they must respect watermark boundaries. Figure 5 shows two stream orders that are equivalent under event time: a window firing at any timestamp would include the same set of events in both cases1 . Given that watermark wk is a guarantee that all events with (w ,w ] t(e) ≤ wk have arrived, let Ev k−1 k be the multiset of events with timestamps t(e) ∈ (wk−1 , wk ] that are processed by op(w ,w ] erator v in G and EvT k−1 k be the corresponding multiset of operator vT in GT . We define the Watermark Correctness property as follows: for any v, vT , the set of events processed and emitted by vT in the interval defined by any consecutive watermarks (wk−1 , wk ] is identical to that of v:

Semantic equivalence

Sluice’s rewriting module decomposes the original application graph into a system of query segments, where some operators are replicated to enable adaptive routing. Since each event can be processed by either replica, and potentially in a different order, this transformation raises a question of semantic equivalence: will the transformed query exhibit the same eventtime ordering guarantees as the original? Because Sluice only replicates stateless, order-agnostic operators, preserving correctness under event time reduces to two key properties: (1) ensuring that events will be processed by the same ordered sequence of operators and (2) correctly propagating watermarks across query segments. Execution path equivalence. Let S = (e1 , e2 , ..., en ) be an input stream consisting of a sequence of events, produced by a deterministic, replayable source. Let also πG (ei ) denote the execution path of event ei through a logical query graph G, defined as the ordered sequence of logical operators traversed by ei from source to sink. We define the Execution Path Equivalence property as follows: for every event ei at position i in the input stream S, the execution path πG (ei ) in the original graph G and the execution path πGT (ei ) in the transformed graph GT are identical: ∀i ∈ {1, 2, ..., n}, πG (ei ) = πGT (ei )

∀k,

Ev(wk−1 ,wk ] = Ev(wT k−1 ,wk ]

(7)

Figure 6 illustrates a correctness failure of naive live rerouting that Sluice prevents. Without this coordination, two problematic scenarios may occur: (i) when traffic is switched from the edge to the cloud, a watermark sent via the cloud path may reach downstream operators before prior events still in transit on the edge path, and (ii) as the stateful query source belongs to a separate job, it generates watermarks without considering the event-time progress of its upstream jobs. To address the first problem, Sluice propagates watermarks along both edge and cloud paths in the stateless query segment, regardless of which path is active, and introduces a special watermark union operator during rewriting. This operator is added before the message broker sink and ensures that event time advances only after the corresponding watermarks have been received from all upstream channels. To mitigate the second scenario and ensure end-to-end event-time correctness, Sluice records watermarks from edge query segments as special control events in the message broker sink partitions, alongside regular data events. The stateful segment, G2 , processes these control events, tracking the

(6)

In other words, no operator is omitted, duplicated, reordered, or introduced by the transformation. It is straightforward to see why Sluice preserves execution path equivalence between G and GT . First, consider any stateless operator v j (excluding the data source). In GT , each such operator has two replicas, vEj and vCj , both implementing identical logic, so for any event x, vEj (x) = vCj (x) = v j (x). Since exactly one routing operator (CPj ) is associated with each v j , every event x is exclusively processed by either vEj or vCj . Second, the routing policy enforces a monotonic transition: once event x is routed to the cloud at any operator, all subsequent operators also process x in the cloud. This guarantees that execution never switches back to the edge for the same event, preserving the sequence of logical operators traversed. As a result, each

1 This holds even for windows firing on non-watermark timestamps, as

they will only be evaluated upon receiving the subsequent watermark.

7

with unique record IDs, as in Millwheel [10] and Kafka Streams [62], though this is not yet implemented in Sluice.

3 2 1 ··· 3 2 5 5 4 1

Case 1: Edge job failure. If one or more edge jobs become stragglers or fail, they can be restarted independently without disrupting query segments running on other edge devices or in the cloud. Event loss is prevented by the combination of the message broker’s persistence guarantees and periodic checkpoints. Specifically, results are durably written to the message broker sink before acknowledgments are sent to the edge segment (the producers). Because a snapshot is only acknowledged after its barrier traverses the entire dataflow graph from the source to the sink, we know that for a snapshot taken at source offset x, all events processed before x have been successfully acknowledged and persisted in the message broker. When a failed edge segment recovers, it restarts from the last successful checkpoint offset x, which must be no later than the last acknowledged message offset in the broker sink. The edge source then replays all events from offset x onward, ensuring that each event is processed at least once.

8 6 5 5 4

Figure 6: Naive live rerouting without watermark coordination. The cloud path is activated after event 3; events 3 and 2 arriving after watermark 5 are incorrectly treated as late and dropped. Sluice prevents this correctness failure.

highest watermark w p per partition p to ensure monotonicity. The global watermark is computed as the minimum watermark across all upstream G1R jobs: wglobal = min p∈[1,P] w p (t), where P is the number of edge partitions. To prevent stalling of wglobal , each G1R job keeps emitting control events during inactivity. Only true partition silence (such as failure or connectivity loss) can delay event-time progress. We handle such cases separately as described in §4.4. Execution path equivalence and watermark correctness guarantee processing semantics during failure-free execution. Next, we discuss how Sluice prevents data loss under failures.

4.3

Case 2: Cloud job failure. In this scenario, the cloud segment fails while the edge segments continue to operate normally. Importantly, the message broker remains highly available and retains all events, regardless of consumer failures (cf. §4.1). When the cloud job restarts, it reprocesses all events from its last successful checkpoint offset, ensuring no data loss.

Correctness under failures

Most modern dataflow systems achieve no data loss during failures using persistent, replayable sources and consistent snapshot protocols [21, 22, 24, 33, 57, 64], where a special checkpoint barrier traverses the dataflow graph, coordinating state snapshots across tasks. However, when event sources run on low-resource devices, assuming persistent and replayable streams is unrealistic. Consequently, Sluice does not aim to tolerate permanent hardware failures. Instead, Sluice provides at-least-once processing (no data loss) under transient failures (e.g., process crashes or bugs), as long as the source device is able to buffer events during recovery. A key challenge is that barrier-based distributed snapshot protocols ensure consistency only within a single, connected dataflow graph. Extending the protocol across jobs would require waiting for barriers from all edge segments before taking a snapshot. In Sluice, we explicitly decide not to align checkpoint barriers across query segments to avoid a single slow or disconnected edge device holding up global checkpoint progress or potentially causing checkpoints to never complete. Additionally, maintaining separate checkpoints per segment gives us the flexibility to independently tune the checkpointing interval for different parts of the dataflow. For example, we can configure less frequent checkpoints at the edge to minimize resource consumption, and more frequent checkpoints in the cloud for faster recovery. Below, we informally show that Sluice guarantees at-leastonce semantics under failures, which is sufficient for supporting exactly-once when combined with deduplication at the cloud source. Deduplication can be easily achieved

Case 3: Simultaneous edge and cloud job failures. In this scenario, both edge and the cloud segments fail simultaneously, while the message broker continues to operate. Let xc denote the checkpoint offset of the cloud job and xe denote the checkpoint offset of the edge job. Since edge and cloud jobs checkpoint independently, their offsets may differ, which affects how recovery is coordinated. Without loss of generality, we focus on a single edge segment. 1. xe ≥ xc . The cloud job’s last checkpoint may be behind the edge’s. Suppose that before failing, the edge job has produced events up to offset xe + k to the broker. Upon recovery, events between xe and xe + k will be replayed, causing the cloud to reprocess them (xc < xe + k). 2. xe < xc . The cloud job has already processed and checkpointed events that the edge job has not yet checkpointed. This can happen due to independent checkpoint intervals. If the edge job has produced events up to offset xe + k before failing, events between xe and xe + k will appear as duplicates in the broker. After recovery, the cloud job will reprocess all duplicates in this range, as well as any duplicates between its own checkpoint offset xc and xe + k.

4.4

Availability under failures

Despite watermark correctness (cf. §4.2), computation progress can stall if an edge segment fails or becomes a straggler. To address this, Sluice introduces additional logic at the cloud source that advances the global watermark when 8

Records/s

5000

a user-specified period of inactivity is detected in a broker partition. If a partition does not emit a watermark within this period, it is marked as inactive. The global watermark is then calculated as the minimum of the maximum watermarks from active partitions only. This approach prevents a single inactive partition from stalling the entire pipeline.

5

Sluice

0

1000 2000 Time (s)

Figure 7: Comparison of Sluice’ and Flink’s reconfiguration mechanisms. Sluice shifts operators without interruption.

Evaluation

not change during the duration of our experiments. To ensure a fair comparison, we execute CAPSys plans directly on the Sluice runtime and not on vanilla Flink. For Sluice and CAPSys, all operators except the source are initially deployed in the cloud.

We implement Sluice on Apache Flink 1.20 and Apache Kafka 3.9.0. However, our adaptive techniques are agnostic to the underlying system and can be integrated with any dataflow stream engine that satisfies the requirements in Section 4.1. We discuss the implementation details in Appendix A. Our evaluation aims to answer four key questions: (1) Can Sluice reconfigure without pausing or restarting execution (§5.2)? (2) Can Sluice adapt to variable workloads and operating conditions to consistently sustain the target throughput (§5.3)? (3) How is Sluice’s performance impacted by individual parameters, including fluctuating input rates, network bandwidth, and compute contention (§5.4)? (4) Can Sluice scale to large hybrid deployments (§5.5)? We further evaluate Sluice’s availability under edge failures in Appendix B.1.

5.1

Vanilla Flink

Benchmarks. We evaluate all systems on the five hybrid edgecloud streaming queries described in §2.2. For each query, we ingest a publicly available dataset [1, 28, 29, 40, 60], at the source and replay it with configurable target input rates. Metrics collection. Unless otherwise stated, we run each experiment for 2 hours with 5min warm-up , using 5s metrics interval and 10min routing policy interval. To assess whether a pipeline can sustain its target throughput, we measure the output rate (in records/s) of sources at each edge node. A rate below the target indicates backpressure (cf. §2.1).

Experimental setting

5.2

We evaluate Sluice on two testbeds: (i) Testbed-RPi is a hybrid cluster consisting of five Raspberry Pi 4 Model B devices (4GB RAM, quad-core ARM Cortex-A72 1.8 GHz CPU) acting as edge nodes and one bare-metal cloud node equipped with an AMD EPYC 7713 64-Core Processor, 256GB memory, and 3.84TB SSD. (ii) Testbed-100VMs is a large-scale CloudLab [31] cluster with 100 VMs acting as edge devices and 45 physical nodes. Each VM emulates a resourceconstrained edge device with 4 CPU cores and 4GB memory, matching the compute-to-memory ratio of Raspberry Pi devices to ensure comparable resource constraints. Each cloud node is equipped with a 16-core AMD EPYC 7302P CPU, 128GB memory, and 480GB SSD. We deploy one Flink TaskManager per edge device, while the Flink JobManager and Kafka run in the cloud nodes.

Zero-downtime reconfiguration

We compare reconfiguration overhead of Sluice and vanilla Flink using Q2 on Testbed-RPi, triggering operator shifts every 10 minutes. In vanilla Flink, a placement change means stopping the job and restarting it with the new placement, which is also the mechanism CAPSys relies on. Figure 7 shows the throughput achieved over time for both systems. Every shift incurs approximately 3 minutes of downtime in vanilla Flink, while Sluice shows no visible throughput dips. The result shows that Sluice effectively avoids service interruptions.

5.3 Sluice under variable operating conditions We next evaluate Sluice’s ability to adapt to simultaneous changes in its environment: workload (target rate), network capacity (edge-to-cloud bandwidth), and edge compute capacity (compute contention). We run this experiment on Testbed-RPi. Figure 8 (bottom) shows how operating conditions change over a period of 3 hours. The target rate changes according to a step function every hour, as indicated by the gray line. We use Linux tc to shape the outbound bandwidth of each RPi to 80–170 Mbps, matching the range reported in WASP [41]. To make the setting even more challenging, we execute a background application that performs arithmetic computations to consume CPU cycles during the second hour of the experiment, imposing compute contention at the edge (red shaded region).

Baselines. We compare Sluice with three baselines: (i) AllEdge deploys the application as a single job that executes both stateless and stateful operators on edge nodes, with only the sink running in the cloud. This baseline maximizes edge processing to minimize WAN data transfer. (ii) All-Cloud deploys the application as a single job that executes all operators, except the source, in the cloud, maximizing cloud usage to avoid edge resource constraints. (iii) CAPSys [65] is a state-of-the-art task placement controller for Flink that uses a contention-aware cost model to balance resource usage across workers. Because CAPSys assumes homogeneous workers and stable operating conditions, its initial placement plan does 9

2 3 4 1000 2000 3000 4000 5000 6000 7000

Q2

Records/s

0

0

0

Figure 8: Comparison of Sluice and baselines under simultaneous changes in their operating environment, using Q1 and Q5 on Testbed-RPi. The plot shows the target rate and achieved throughput over time (top) under variable operating conditions (bottom).

1800 3600 5400

1800 3600 5400

50k 25k

25k

40 20 0

0

1800 3600 5400 Records/s

Q4

1000 2000 3000 4000 5000 6000 7000 Time (s)

0

100k

50k 0

1800 3600 5400

50k

1800 3600 5400

100k

Q3

2 3 4 1000 2000 3000 4000 5000 6000 7000

Network BW Compute Contention Operating Conditions 200

(Mbps)

Network BW

20 1

50k

Records/s

40

Q5

Q5

60

1800 3600 5400

0

1800 3600 5400

40 20 0

1800 3600 5400

Records/s

0

1

Records/s

20k

50k 25k 0 100k

Records/s

40k

50k 25k 0 100k

All-Edge

Records/s

Q1

Records/s

Q1

60k

CAPSys

Sluice

Records/s

Target All-Cloud

CAPSys

Records/s

All-Edge

Records/s

Sluice

Records/s

Target All-Cloud

1800 3600 5400 Time (s)

(a) gradual rate pattern

1800 3600 5400 Time (s)

(b) abrupt rate pattern

Figure 9: Comparison of Sluice and baselines under variable input rate patterns on Testbed-RPi. Figure 8 shows the results for Q1 and Q5. We plot throughput over time for one of the RPis and include the remaining results in Appendix C. Sluice rapidly reacts to dynamics and it is the only system that can sustain the target during the entire experiment. Four distinct phases are marked on the plot. (1): Initially, Sluice’s deployment is equivalent to the All-Cloud strategy, which cannot sustain the target throughput due to insufficient bandwidth. (2): Sluice triggers a policy decision (shown as a vertical dashed line). Sluice shifts one operator to the edge in Q1 and two operators in Q5. (3): When compute contention takes effect, operator processing at the edge becomes a bottleneck. Sluice’s policy detects the issue and shifts all operators back to the cloud. The new deployment meets the target, hence, Sluice does not trigger any further shifts in the next hour. After the compute contention is lifted and bandwidth drops, the edge-to-cloud data transfer becomes the bottleneck. (4): Sluice’ policy reacts quickly and shifts operators to the edge, once again achieving the target.

tors at the edge, however, it cannot meet the target rate when compute resources at the edge are limited.

5.4

Impact of individual parameters

Next, we evaluate the behavior of Sluice in a more controlled setting, where we vary a single parameter at a time: event rate, bandwidth, and compute contention. In this set of experiments, we run all five applications of §2.2 on Testbed-RPi. We report results for one of the RPis per query and include remaining in Appendix C. Impact of input rate. To understand the impact of variable event rate, we evaluate all systems under two patterns: (i) gradual pattern, where we start from a low rate, then gradually increase it every 20 minutes, and finally, decrease to its initial value, and (ii) abrupt pattern, where both the change interval and the rate value are chosen at random. To ensure realistic conditions, rate targets and interval periods are set independently on different RPis; that is, variations across edge devices are not synchronized. All other operating conditions are fixed to their default values during the experiment.

The All-Edge deployment is bottlenecked by the limited edge device capacity, particularly during the compute contention period. On the other hand, the All-Cloud strategy is clearly restricted by the available bandwidth. CAPSys is able to avoid the bandwidth bottleneck by placing first two opera10

Target All-Cloud

All-Edge Records/s

Records/s

50k

25k

50k 0

Records/s

Q3

Records/s 1800 3600 5400

1800 3600 5400

Records/s

Records/s

1800 3600 5400

Records/s

Q4 Q5

0 60k 40k

40 20

1800 3600 5400 150 Network Bandwidth 100 50 0 1800 3600 5400 Time (s)

20k 60

1800 3600 5400

40 20

1800 3600 5400 Compute Contention

Mbps

Operating Conditions

1800 3600 5400

100k

50k

20k

0

1800 3600 5400

40k

Impact of network bandwidth. We now evaluate all systems under fixed target rate and variable network conditions. We again use Linux traffic control (tc) to shape the outbound bandwidth of RPis. Figure 10a shows the throughput for all queries and the operating conditions (bottom). As bandwidth changes, only Sluice can consistently sustain the target rate. In Q1, Q2 and Q5, Sluice adapts by shifting operators to the edge. On the other hand, Q3 and Q4 are not network-intensive, requiring no shifts during the experiment. All-Edge cannot sustain the rate for any of the queries, while All-Cloud’s performance is clearly restricted by the bandwidth availability for Q1 and Q5. In the case of Q2 and Q3, backpressure from stateful operators propagates upstream and affects the source operator at the edge. CAPSys fails to sustain the throughput for Q1, since it places all operators on the cloud. In contrast, Sluice shifts the first operator to the edge, reducing the bandwidth usage by filtering out data early.

1800 3600 5400

50k

100k 0

0

1800 3600 5400 Records/s

Records/s

Q2

Q1

50k 0

CAPSys

Sluice

Records/s

Figure 9 shows the throughput over time. Sluice is the only system to meet the target rate across all queries and rate patterns. For Q1, Q2, and Q5, which generate large event records, Sluice shifts operators to the edge to reduce the network traffic. All-Edge is limited by the computational capacity of edge devices in all cases, while All-Cloud performs poorly for Q2, Q3, and Q5. Since All-Edge and All-Cloud execute the application as a single job, the performance of stateful operators affect the upstream stateless ones, incurring backpressure at the edge source. An example of this behavior is visible in Q3, where the window aggregation operator exhibits data skew, affecting the source rate of the All-Cloud strategy. In this instance, even though Sluice has also placed all operators in the cloud, its decomposed query deployment shields the edge sources from backpressure, achieving the target rate when All-Cloud cannot. CAPSys is also unaffected by data skew because we run it on Sluice’s runtime. However, its static policy fails to keep up for Q1, Q2, and Q3, during high rate periods.

(a) Network variations

1800 3600 5400 Time (s) (b) Compute contention

Figure 10: Comparison of Sluice and baselines under network and compute contention variations on Testbed-RPi. The bottom plots show operating conditions over time.

Impact of compute contention. To evaluate the impact of imposing compute contention at the edge, we run en experiment with the target rate fixed and set the edge-to-cloud bandwidth to 200 Mbps, to ensure the network will not become a bottleneck. To observe if Sluice can effectively react to compute contention, the initial deployment places the first operator at the edge. We do not compare with the All-Cloud baseline, as it is unaffected by compute availability at the edge. Figure 10b shows the results for Sluice, CAPSys, and All-Edge. Across all applications, only Sluice can always sustain the target rate. During periods of contention, Sluice quickly detects the problem and shifts operators to the cloud as necessary. In the case of Q5, Sluice’s initial policy is sufficient even under contention, hence, no shift occurs. All-Edge performs poorly across all queries, while CAPSys performs well only for Q1, when its strategy runs all operators on the cloud. In all other applications, CAPSys has placed several operators

at the edge and its performance is affected by contention.

5.5

Sluice scalability

We evaluate Sluice’s scalability running Q5 on Testbed100VMs. The outbound bandwidth of each edge device follows an individually-set variable pattern, with values between 80 and 200 Mbps, chosen at random every 20min. Figure 11 summarizes the performance across 100 devices, plotting the ratio of throughput over the target rate in a heatmap. Each point on the y-axis corresponds to the throughput-to-target ratio of an edge device, while time is shown on the x-axis. Bandwidth changes and policy triggers are shown with grey and red vertical lines, respectively. The initial deployment runs all operators on the cloud, and as a result, 39% of the devices cannot achieve the tar11

Bandwidth change

Trigger policy

ting, where data is produced at the edge but requires analysis results for downstream applications in the cloud. Rather than building a clean-slate system, Sluice reuses mature dataflow engines and adapts them to the hybrid setting.

100

Adaptive filtering and routing. Early works have explored adaptive query execution in single-node stream processing engines [15, 16, 23, 45, 53]. Recent research has revisited the concept of adaptive query processing in the context of edge computing. For example, Shepherd [56]’s late binding routing mechanism reroutes data tuples between operators and provides seamless adaptation with minimal downtime. Falcon [50] introduces a live key migration protocol to support stateful operator reconfiguration in such environments, and Frontier [52]’s per-batch routing mechanism dynamically forwards events to downstream operator replicas. Sluice takes these ideas a step further by making adaptive routing transparent to the application.

Device ID

80 60 40 20

Adaptive placement and scheduling. Various prior works study dynamic scheduling and reconfiguration for stream processing [46, 47, 61, 65, 66]. The systems closest to Sluice, CAPSys [65], Trisk [47], and WASP [41], propose adaptive task placement policies to handle network and compute bottlenecks. However, they still require at least partial job stopping, resulting in downtime, backlog accumulation, and potential source-side data loss during reconfiguration. In addition, homogeneous resource assumptions, like those in CAPSys, render existing placement policies ineffective in the hybrid cloud setting. APEROL [17] efficiently searches large placement plan spaces across heterogeneous edge devices and execution platforms, but assumes that workflows must stop ingesting and processing data during operator migration. In contrast, Sluice automatically rewrites queries into independent jobs and creates edge and cloud replicas for stateless preprocessing. It switches routing between these replicas without pausing execution while preserving watermark coordination and eventtime semantics.

1000 2000 3000 4000 5000 6000 7000 Time (s) 0.5 0.6 0.7 0.8 0.9 1.0 Throughput / Target Figure 11: Sluice’s scalability running Q5 on Testbed100VMs. Each point on the y-axis corresponds to an edge device. White color indicates the device can sustain the rate, while dark color indicates backpressure. get. When the policy triggers at 900s, Sluice shifts operators to the edge. Afterwards, all devices can sustain the target with an average throughput-to-target ratio of 99.8% At 1220s, the bandwidth changes, causing backpressure on 23% of the devices. The policy reconfigures routing again at 1500s, ensuring all devices meet the target. This pattern repeats a few times during the experiment. In all cases, Sluice converges to a backpressure-free configuration across all devices.

6

7

Conclusion

We presented Sluice, an adaptive stream processing system that extends datacenter-centric dataflow engines to support hybrid edge-cloud deployments without requiring application changes. Sluice enables dynamic offloading of computations to the edge, automatically adjusting to operational and workload dynamics. Sluice allows users to rely on familiar eventtime and fault-tolerance semantics of the underlying dataflow engine, ensuring correctness and no data loss.

Related Work

Edge stream processing engines. Many recent works [26, 34, 44, 49, 67] propose novel system designs for the edge setting and aim to address challenges related to restricted resources and dynamic deployment conditions, such as frequent failures and churn. DART [44] introduces a peer-to-peer system architecture that enables dynamic operators placement and scaling in volatile edge environments. EdgeWise [34] proposes a congestion-aware scheduler to optimize resource usage of a single device. Frontier [52] replicates the dataflow graph across devices for fault tolerance. In contrast to these edge-centric systems, Sluice explicitly targets the hybrid set-

References https:// www.kaggle.com/datasets/hiraddolatzadeh/

[1] English Tweets Mentioning Bitcoin.

12

bitcoin-tweets-2021-2022, 2022. Last accessed:

[13] Muhammad Ali, Ashiq Anjum, Omer Rana, Ali Reza Zamani, Daniel Balouek-Thomert, and Manish Parashar. Res: Real-time video stream analytics using edge enhanced clouds. IEEE Transactions on Cloud Computing, 10(2):792–804, 2022.

September 2026. [2] Amazon Kinesis. https://aws.amazon.com/ kinesis/, 2026. Last accessed: September 2026. [3] Apache Flink. https://flink.apache.org/, 2026. Last accessed: September 2026.

[14] Michael Armbrust, Tathagata Das, Joseph Torres, Burak Yavuz, Shixiong Zhu, Reynold Xin, Ali Ghodsi, Ion Stoica, and Matei Zaharia. Structured streaming: A declarative api for real-time applications in apache spark. In Proceedings of the 2018 International Conference on Management of Data, pages 601–613, 2018.

[4] Apache Flink Documentation: Flink Architecture. https://nightlies.apache.org/flink/ flink-docs-release-1.20/docs/concepts/ Last accessed: flink-architecture/, 2026.

September 2026.

[15] Ron Avnur and Joseph M Hellerstein. Eddies: Continuously adaptive query processing. In Proceedings of the 2000 ACM SIGMOD international conference on Management of data, pages 261–272, 2000.

[5] Apache Flink Documentation: Network Memory Tuning Guide. https://nightlies.apache. org/flink/flink-docs-release-1.20/docs/ deployment/memory/network_mem_tuning/,

[16] Shivnath Babu, Rajeev Motwani, Kamesh Munagala, Itaru Nishizawa, and Jennifer Widom. Adaptive ordering of pipelined stream filters. In Proceedings of the 2004 ACM SIGMOD international conference on Management of data, pages 407–418, 2004.

2026. Last accessed: September 2026. [6] Apache Pulsar. https://pulsar.apache.org/, 2026. Last accessed: September 2026. [7] Apache Spark Structured Streaming. https://spark. apache.org/streaming/, 2026. Last accessed: September 2026.

[17] Dimitrios Banelas, Alkis Simitsis, and Nikos Giatrakos. Aperol: Adaptive parallel edge-to-cloud runtime optimization for layered workflow execution. Proc. VLDB Endow., 19(2):156–169, October 2025.

https://nightlies. apache.org/flink/flink-docs-master/docs/ dev/datastream/event-time/generating_ watermarks/#dealing-with-idle-sources,

[8] Dealing with idle sources.

[18] Maycon Viana Bordin, Dalvan Griebler, Gabriele Mencagli, Cláudio FR Geyer, and Luiz Gustavo L Fernandes. Dspbench: A suite of benchmark applications for distributed data stream processing systems. IEEE Access, 8:222900–222917, 2020.

2026. Last accessed: September 2026. [9] JavaParser. https://javaparser.org/, 2026. Last accessed: September 2026. [10] Tyler Akidau, Alex Balikov, Kaya Bekiroğlu, Slava Chernyak, Josh Haberman, Reuven Lax, Sam McVeety, Daniel Mills, Paul Nordstrom, and Sam Whittle. Millwheel: Fault-tolerant stream processing at internet scale. Proceedings of the VLDB Endowment, 6(11):1033– 1044, 2013.

[19] Maria LL Brito, Maria CM Ferreira, Ariel LC Portela, and Rafael L Gomes. Ai-based estimation of bandwidth availability for data offloading in edge-cloud computing. IEEE Networking Letters, 2025. [20] Paris Carbone, Stephan Ewen, Gyula Fóra, Seif Haridi, Stefan Richter, and Kostas Tzoumas. State management in apache flink®: consistent stateful distributed stream processing. Proceedings of the VLDB Endowment, 10(12):1718–1729, 2017.

[11] Tyler Akidau, Edmon Begoli, Slava Chernyak, Fabian Hueske, Kathryn Knight, Kenneth Knowles, Daniel Mills, and Dan Sotolongo. Watermarks in stream processing systems: semantics and comparative analysis of apache flink and google cloud dataflow. Proceedings of the VLDB Endowment, 14(12):3135–3147, 2021.

[21] Paris Carbone, Marios Fragkoulis, Vasiliki Kalavri, and Asterios Katsifodimos. Beyond analytics: The evolution of stream processing systems. In Proceedings of the 2020 ACM SIGMOD international conference on Management of data, pages 2651–2658, 2020.

[12] Tyler Akidau, Robert Bradshaw, Craig Chambers, Slava Chernyak, Rafael J Fernández-Moctezuma, Reuven Lax, Sam McVeety, Daniel Mills, Frances Perry, Eric Schmidt, et al. The dataflow model: a practical approach to balancing correctness, latency, and cost in massivescale, unbounded, out-of-order data processing. Proceedings of the VLDB Endowment, 8(12):1792–1803, 2015.

[22] Paris Carbone, Asterios Katsifodimos, Stephan Ewen, Volker Markl, Seif Haridi, and Kostas Tzoumas. Apache flink: Stream and batch processing in a single engine. The Bulletin of the Technical Committee on Data Engineering, 38(4), 2015. 13

[23] Sirish Chandrasekaran, O Cooper, A Deshpande, MJ Franklin, JM Hellerstein, W Hong, S Krishnamurthy, S Madden, V Raman, F Reiss, et al. Continuous dataflow processing for an uncertain world. In Conference on Innovative Data Systems Research, 2003.

[32] Muhammad Faisal, Jerry Zhang, John Liagouris, Vasiliki Kalavri, and Mayank Varia. {TVA}: A multi-party computation system for secure and expressive time series analytics. In 32nd USENIX Security Symposium (USENIX Security 23), pages 5395–5412, 2023.

[24] K Mani Chandy and Leslie Lamport. Distributed snapshots: Determining global states of distributed systems. ACM Transactions on Computer Systems (TOCS), 3(1):63–75, 1985.

[33] Marios Fragkoulis, Paris Carbone, Vasiliki Kalavri, and Asterios Katsifodimos. A survey on the evolution of stream processing systems. The VLDB Journal, 33(2):507–541, November 2023.

[25] Xenofon Chatziliadis, Eleni Tzirita Zacharatou, Alphan Eracar, Steffen Zeuch, and Volker Markl. Nemo: Efficient placement of decomposable aggregation functions for stream processing over large geo-distributed topologies. Proceedings of the VLDB Endowment (PVLDB), 17(6):1501–1514, 2024.

[34] Xinwei Fu, Talha Ghaffar, James C. Davis, and Dongyoon Lee. Edgewise: A better stream processing engine for the edge. In 2019 USENIX Annual Technical Conference (USENIX ATC), pages 929–946, Renton, WA, 2019.

[26] Cheng-Wei Ching, Xin Chen, Chaeeun Kim, Tongze Wang, Dong Chen, Dilma Da Silva, and Liting Hu. Agiledart: An agile and scalable edge stream processing engine. IEEE Transactions on Mobile Computing, 24(5):4510–4528, May 2025.

[35] Anurag Ghosh, Srinivasan Iyengar, Stephen Lee, Anuj Rathore, and Venkata N Padmanabhan. React: Streaming video analytics on the edge with asynchronous cloud support. In Proceedings of the 8th ACM/IEEE Conference on Internet of Things Design and Implementation, pages 222–235, 2023.

[27] Gianpaolo Cugola and Alessandro Margara. Processing flows of information: From data stream to complex event processing. ACM Computing Surveys (CSUR), 44(3):1– 62, 2012. [28] Jean-Michel D.

Smart Meters in

London.

https://www.kaggle.com/datasets/ jeanmidev/smart-meters-in-london,

2022.

[36] Fabian Hueske and Vasiliki Kalavri. Stream processing with Apache Flink: fundamentals, implementation, and operation of streaming applications. O’Reilly Media, 2019. [37] David Hästbacka, Jari Halme, Laurentiu Barna, Henrikki Hoikka, Henri Pettinen, Martin Larrañaga, Mikael Björkbom, Heikki Mesiä, Antti Jaatinen, and Marko Elo. Dynamic edge and cloud service integration for industrial iot and production monitoring applications of industrial cyber-physical systems. IEEE Transactions on Industrial Informatics, 18(1):498–508, 2022.

Last accessed: September 2026. [29] I. O. de Oliveira, R. Laroca, D. Menotti, K. V. O. Fonseca, and R. Minetto. Vehicle-Rear: A new dataset to explore feature fusion for vehicle identification using convolutional neural networks. IEEE Access, 9:101065– 101077, 2021.

[38] Michael Isard, Mihai Budiu, Yuan Yu, Andrew Birrell, and Dennis Fetterly. Dryad: distributed data-parallel programs from sequential building blocks. In Proceedings of the 2nd ACM SIGOPS/EuroSys European conference on computer systems 2007, pages 59–72, 2007.

[30] Jeffrey Dean and Sanjay Ghemawat. Mapreduce: Simplified data processing on large clusters. In Eric A. Brewer and Peter Chen, editors, 6th Symposium on Operating System Design and Implementation (OSDI 2004), San Francisco, California, USA, December 6-8, 2004, pages 137–150. USENIX Association, 2004.

[39] Zbigniew Jerzak and Holger Ziekow. The debs 2015 grand challenge. In Proceedings of the 9th ACM International Conference on Distributed Event-Based Systems, DEBS ’15, page 266–268, New York, NY, USA, 2015. Association for Computing Machinery.

[31] Dmitry Duplyakin, Robert Ricci, Aleksander Maricq, Gary Wong, Jonathon Duerig, Eric Eide, Leigh Stoller, Mike Hibler, David Johnson, Kirk Webb, Aditya Akella, Kuangching Wang, Glenn Ricart, Larry Landweber, Chip Elliott, Michael Zink, Emmanuel Cecchet, Snigdhaswin Kar, and Prabodh Mishra. The design and operation of CloudLab. In Proceedings of the USENIX Annual Technical Conference (ATC), pages 1–14, July 2019.

[40] Zbigniew Jerzak and Holger Ziekow. The debs 2015 grand challenge. In Proceedings of the 9th ACM International Conference on Distributed Event-Based Systems, DEBS ’15, page 266–268, New York, NY, USA, 2015. Association for Computing Machinery. 14

[41] Albert Jonathan, Abhishek Chandra, and Jon Weissman. Wasp: Wide-area adaptive stream processing. In Proceedings of the 21st International Middleware Conference, pages 221–235, Delft, The Netherlands, 2020.

Falkensteiner, Kyle Krüger, Alexander Meyer, Tobias Röschl, and Svea Wilkending. Nebulastream: An extensible, high-performance streaming engine for multimodal edge applications. In Companion of the 2025 International Conference on Management of Data, SIGMOD/PODS ’25, page 195–198, New York, NY, USA, 2025. Association for Computing Machinery.

[42] Vasiliki Kalavri, John Liagouris, Moritz Hoffmann, Desislava Dimitrova, Matthew Forshaw, and Timothy Roscoe. Three steps is all you need: fast, accurate, automatic scaling decisions for distributed streaming dataflows. In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18), pages 783–798, Carlsbad, CA, October 2018. USENIX Association.

[50] Pritish Mishra, Nelson Bore, Brian Ramprasad, Myles Thiessen, Moshe Gabel, Alexandre Da Silva Veith, Oana Balmau, and Eyale De Lara. Falcon: Live Reconfiguration for Stateful Stream Processing on the Edge . In 2024 IEEE/ACM Symposium on Edge Computing (SEC), pages 234–248, Los Alamitos, CA, USA, December 2024. IEEE Computer Society.

[43] Yuanqi Li, Arthi Padmanabhan, Pengzhan Zhao, Yufei Wang, Guoqing Harry Xu, and Ravi Netravali. Reducto: On-camera filtering for resource-efficient realtime video analytics. In Proceedings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, architectures, and protocols for computer communication, pages 359–376, 2020.

[51] Neha Narkhede, Gwen Shapira, and Todd Palino. Kafka: the definitive guide: real-time data and stream processing at scale. " O’Reilly Media, Inc.", 2017. [52] Dan O’Keeffe, Theodoros Salonidis, and Peter Pietzuch. Frontier: resilient edge processing for the internet of things. Proc. VLDB Endow., 11(10):1178–1191, June 2018.

[44] Pinchao Liu, Dilma Da Silva, and Liting Hu. Dart: A scalable and adaptive edge stream processing engine. In 2021 USENIX Annual Technical Conference (USENIX ATC), pages 239–252, 2021.

[53] Chris Olston, Jing Jiang, and Jennifer Widom. Adaptive filters for continuous queries over distributed data streams. In Proceedings of the 2003 ACM SIGMOD international conference on Management of data, pages 563–574, 2003.

[45] Samuel Madden, Mehul Shah, Joseph M Hellerstein, and Vijayshankar Raman. Continuously adaptive continuous queries over streams. In Proceedings of the 2002 ACM SIGMOD international conference on Management of data, pages 49–60, 2002.

[54] Arthi Padmanabhan, Neil Agarwal, Anand Iyer, Ganesh Ananthanarayanan, Yuanchao Shu, Nikolaos Karianakis, Guoqing Harry Xu, and Ravi Netravali. Gemel: Model merging for {Memory-Efficient},{Real-Time} video analytics at the edge. In 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), pages 973–994, 2023.

[46] Luo Mai, Kai Zeng, Rahul Potharaju, Le Xu, Steve Suh, Shivaram Venkataraman, Paolo Costa, Terry Kim, Saravanan Muthukrishnan, Vamsi Kuppa, Sudheer Dhulipalla, and Sriram Rao. Chi: a scalable and programmable control plane for distributed stream processing systems. Proc. VLDB Endow., 11(10):1303–1316, June 2018.

[55] Renaud Pawlak, Martin Monperrus, Nicolas Petitprez, Carlos Noguera, and Lionel Seinturier. Spoon: A Library for Implementing Analyses and Transformations of Java Source Code. Software: Practice and Experience, 46:1155–1179, 2015.

[47] Yancan Mao, Yuan Huang, Runxin Tian, Xin Wang, and Richard T. B. Ma. Trisk: Task-centric data stream reconfiguration. In Proceedings of the ACM Symposium on Cloud Computing, SoCC ’21, page 214–228, New York, NY, USA, 2021. Association for Computing Machinery.

[56] Brian Ramprasad, Pritish Mishra, Myles Thiessen, Hongkai Chen, Alexandre da Silva Veith, Moshe Gabel, Oana Balmau, Abelard Chow, and Eyal de Lara. Shepherd: Seamless stream processing on the edge. In 2022 IEEE/ACM 7th Symposium on Edge Computing (SEC), pages 40–53, 2022.

[48] Yuan Mei, Rui Xia, Zhaoqian Lan, Kaitian Hu, Lei Huang, Paris Carbone, Yanfei Lei, Vasiliki Kalavri, Han Yin, and Feng Wang. Disaggregated state management in apache flink® 2.0. Proceedings of the VLDB Endowment, 18(12):4846–4859, 2025.

[57] George Siachamis, Kyriakos Psarakis, Marios Fragkoulis, Arie Van Deursen, Paris Carbone, and Asterios Katsifodimos. Checkmate: Evaluating checkpointing protocols for streaming dataflows. In 2024 IEEE 40th international conference on data engineering (ICDE), pages 4030–4043. IEEE, 2024.

[49] Adrian Michalke, Aljoscha Lepping, Volker Markl, Ricardo Martinez, Nils Schubert, Lukas Schwerdtfeger, Taha Tekdogan, Steffen Zeuch, Ariane Ziehn, Christoph 15

[58] Jawad Tahir, Christoph Doblander, Ruben Mayer, Sebastian Frischbier, and Hans-Arno Jacobsen. The debs 2021 grand challenge: analyzing environmental impact of worldwide lockdowns. In Proceedings of the 15th ACM International Conference on Distributed and Event-Based Systems, pages 136–141, 2021.

In 18th USENIX Symposium on Networked Systems Design and Implementation (NSDI 21), pages 389–405. USENIX Association, April 2021.

[59] Maria Lorena Tuballa and Michael Lochinvar Abundo. A review of the development of smart grid technologies. Renewable and Sustainable Energy Reviews, 59:710– 725, 2016.

[67] Steffen Zeuch, Ankit Chaudhary, Bonaventura Del Monte, Haralampos Gavriilidis, Dimitrios Giouroukis, Philipp M Grulich, Sebastian Bress, Jonas Traub, and Volker Markl. The nebulastream platform: Data and application management for the internet of things. In Conference on Innovative Data Systems Research (CIDR), 2020.

[60] U.S. Environmental Protection Agency. Air Quality System (AQS). Pre-generated files: Daily & AQI values. https://aqs.epa.gov/aqsweb/ airdata/download_files.html, 2026. Last accessed: September 2026.

[68] Sheng Zhang, Can Wang, Yibo Jin, Jie Wu, Zhuzhong Qian, Mingjun Xiao, and Sanglu Lu. Adaptive configuration selection and bandwidth allocation for edge-based video analytics. IEEE/ACM Transactions on Networking, 30(1):285–298, 2021.

[61] Shivaram Venkataraman, Aurojit Panda, Kay Ousterhout, Michael Armbrust, Ali Ghodsi, Michael J. Franklin, Benjamin Recht, and Ion Stoica. Drizzle: Fast and adaptable stream processing at scale. In Proceedings of the 26th Symposium on Operating Systems Principles, SOSP ’17, page 374–389, New York, NY, USA, 2017. Association for Computing Machinery. [62] Guozhang Wang, Lei Chen, Ayusman Dikshit, Jason Gustafson, Boyang Chen, Matthias J Sax, John Roesler, Sophie Blee-Goldman, Bruno Cadonna, Apurva Mehta, et al. Consistency and completeness: Rethinking distributed stream processing in apache kafka. In Proceedings of the 2021 international conference on management of data, pages 2602–2613, 2021. [63] Junjue Wang, Ziqiang Feng, Zhuo Chen, Shilpa George, Mihir Bala, Padmanabhan Pillai, Shao-Wen Yang, and Mahadev Satyanarayanan. Bandwidth-efficient live video analytics for drones via edge computing. In 2018 ieee/acm symposium on edge computing (sec), pages 159–173. IEEE, 2018. [64] Stephanie Wang, John Liagouris, Robert Nishihara, Philipp Moritz, Ujval Misra, Alexey Tumanov, and Ion Stoica. Lineage stash: fault tolerance off the critical path. In Proceedings of the 27th ACM Symposium on Operating Systems Principles, pages 338–352, 2019. [65] Yuanli Wang, Lei Huang, Zikun Wang, Vasiliki Kalavri, and Ibrahim Matta. Capsys: Contention-aware task placement for data stream processing. EuroSys ’25, New York, NY, USA, 2025. Association for Computing Machinery. [66] Le Xu, Shivaram Venkataraman, Indranil Gupta, Luo Mai, and Rahul Potharaju. Move fast and meet deadlines: Fine-grained real-time stream processing with cameo. 16

Supplementary material

Records/s

A

Sluice Sluice without idleness

30000

Implementation details

20000 10000

Query re-writing. We implement the re-writer using JavaParser [9] and the Spoon library [55]. Users submit Flink applications directly to Sluice without performing any manual query splitting, resource management, or task placement. The re-writer parses Flink DataStream programs and automatically generates the query segments and adaptive routing paths. To ensure compatibility with Sluice, user programs must conform to a minimal set of structural conventions: (i) the program must include a valid source operator, (ii) mobile operators must be defined as DataStream variables without chaining methods (e.g., name(), setParallelism()), and (iii) all user-defined objects must expose JSON-serializable fields via public getters and setters.

0 0

500

1000 1500 2000 2500 3000 Time (s)

Figure 12: Comparison of Sluice with and without watermark inactivity tolerance mechanism

deployed exactly where the placement plan dictates. Metrics collector. The metrics collector periodically pulls Flink metrics from the JobManagers during runtime. It records the useful processing time, observed and true input and output rates per task [42]. The routing controller pulls these metrics on demand whenever it needs to recompute a routing plan.

Watermark propagation. To enable correct watermark propagation across segments and availability under failures, Sluice injects heartbeat records into Kafka, each carrying a watermark timestamp and a partition tag. On the stateful segment side, we implement a custom watermark strategy that extracts these heartbeats to compute the global watermark. Because heartbeats are ordinary Kafka records, they inherit at-leastonce delivery, however, duplicates are harmless since the we only advance watermarks through a monotonic max-min reduction. To prevent any single slow partition from stalling the pipeline, we rely on Flink’s idleness mechanism [8]. Partitions that stop producing heartbeats are marked as idle and excluded from the watermark calculation until they recover.

Kafka integration. In Sluice, each query uses a dedicated Kafka topic and the results of each edge device are directed to a distinct partition within this topic. The cloud-based segment then consumes data from this same topic using a KafkaSource operator, reading from all partitions.

Routing controller. Sluice ’s controller periodically gathers metrics from Flink Job Managers and evaluates the routing policy in real time, without relying on any offline profiling. Policy decisions are independently evaluated for each segment, hence, the routing controller can be trivially scaled to support large deployments, as we show in §5.5. Routing decisions are sent via HTTP requests and each CP operator listens for them on a dedicated port. Operators maintain a routing flag that dynamically directs incoming events to either its main output (the cloud path) or its side output (the edge path).

B

Additional experiments

B.1

Sluice under failures

This experiment measures how the watermark inactivity tolerance mechanism described in Section 4.4 affects the availability and event time progress. We run Q1 on Testbed-RPi with a fixed input rate for 1 hour with a 5min warm-up. We compare the Sluice mechanism with and without the watermark inactivity tolerance mechanism. In Sluice without idleness, we keep the Sluice mechanism unchanged except to disable the watermark inactivity tolerance mechanism in the cloud source. At time 900s, we cancel the stateless query segment on one of the 5 edge devices to simulate failure happening, and leave the remaining 4 edge devices running continuously. Figure 12 shows the sliding average output throughput of the window operator on the stateful query segment, where each data point is calculated as the average throughput over the last 10 samples. We use this sliding averaging to smooth throughput spikes caused by the query logic itself, allowing us to isolate and focus on the effect of the watermark inactivity tolerance mechanism. The throughput is stable during the initial phase. When one of the edge devices fails at 900s, for Sluice, the throughput briefly spikes and then becomes stable again once the tolerance period elapses, because now the global watermark

Hybrid scheduler. To enforce a deterministic task placement plan on edge and cloud resource at runtime, we implemented a custom Flink scheduler that deterministically assigns tasks to edge/cloud workers according to a placement plan. The plan is encoded as a static mapping where each task is pinned to a specific location specified by the Task Manager IP address. To this end, we extended Flink’s ResourceProfile class to specify the target scheduling location per task. We also implemented a custom SlotMatchingStrategy that overrides the default slot allocation logic to match the task’s specified location with the available slots on the corresponding Task Manager, ensuring that edge and cloud replicas are 17

Target All-Cloud

advances using the minimum over the remaining 4 live broker partitions. The throughput is lower than before, since we have fewer event producers. However, for Sluice without idleness, the global watermark is blocked by the silent partition, whose corresponding stateless query segment has already been canceled. And the throughput remains 0 until the end. From this experiment, we show that the watermark inactivity tolerance mechanism prevents system-wide downtime and preserves availability for aggregative analytics under partial edge devices failures.

Sluice

All-Edge

CAPSys

Records/s

Q1

60k 40k 20k

1

2 3 4 1000 2000 3000 4000 5000 6000 7000

20 1

2 3 4 1000 2000 3000 4000 5000 6000 7000 Network BW Compute Contention

200

Operating Conditions

0

Additional results

Q5

C

Target All-Cloud

Sluice

All-Edge

Records/s

Q1

40k 1

2 3 4 1000 2000 3000 4000 5000 6000 7000

20 1

2 3 4 1000 2000 3000 4000 5000 6000 7000 Network BW Compute Contention

200

Operating Conditions

0

Records/s

40

(Mbps)

Network BW

Q5

60

0

0

1000 2000 3000 4000 5000 6000 7000 Time (s)

Figure 14: Sluice under variable operating conditions - RPi2

CAPSys

60k 20k

40

(Mbps)

Network BW

We report per-device performance for the remaining 4 RPi devices for all queries in Figures 13 - 24, complementing the main text where we show results for a single device per query in Section 5.3 and 5.4. The additional devices show similar results as the one device shown in the main sections. Note that for Q3, the input dataset exhibits data skew across different RPis. In RPi 2, 3, and 4, the input events are entirely filtered out by the mobile operators in the stateless query segment, which substantially reduces workload. Consequently, for Q3, the All-Cloud and All-Edge baselines achieve better performance on RPi 2,3,4 than on the other RPis.

Records/s

60

1000 2000 3000 4000 5000 6000 7000 Time (s)

Figure 13: Sluice under variable operating conditions - RPi1 18

Target All-Cloud

Sluice

All-Edge

Target All-Cloud

CAPSys

1

2 3 4 1000 2000 3000 4000 5000 6000 7000

20 1

2 3 4 1000 2000 3000 4000 5000 6000 7000 Network BW Compute Contention

200

Operating Conditions

Q1

Records/s

0 60 Q5

40

Network BW

Compute Contention

Operating Conditions

(Mbps)

(Mbps)

0

40

2 3 4 1000 2000 3000 4000 5000 6000 7000 Network BW

20 1

Network BW

20k

2 3 4 1000 2000 3000 4000 5000 6000 7000

Records/s

Q5

1

40k

60

200

CAPSys

Records/s

Records/s

Q1

40k 0

All-Edge

60k

60k 20k

Sluice

1000 2000 3000 4000 5000 6000 7000 Time (s)

0

1000 2000 3000 4000 5000 6000 7000 Time (s)

Figure 16: Sluice under variable operating conditions - RPi4

Figure 15: Sluice under variable operating conditions - RPi3

19

1800 3600 5400 Time (s)

(a) gradual rate pattern

1800 3600 5400 Time (s)

(b) abrupt rate pattern

Records/s Records/s

0

1800 3600 5400

1800 3600 5400

50k

Records/s

25k 0

1800 3600 5400

1800 3600 5400 Time (s)

(a) gradual rate pattern

Figure 17: Impact of input rate - RPi1

1800 3600 5400

100k

Records/s

40 20 0

0

40 20 0

1800 3600 5400

Records/s

0

1800 3600 5400

50k

1800 3600 5400

25k

1800 3600 5400

Records/s

Records/s

40 20 0

Records/s

Q1 Q3 Q4

Records/s

0

CAPSys

100k

50k

20k

1800 3600 5400

0

0

1800 3600 5400

100k

1800 3600 5400

40k

25k

Records/s

Q2

Records/s Records/s

0

1800 3600 5400

0

All-Edge

25k

50k

1800 3600 5400

Sluice

50k

100k

Records/s

Records/s Records/s

Q2

Records/s

Q3

Records/s

Records/s

Q4 Q5

0

50k 25k 0

1800 3600 5400

100k

50k

40 20 0

Target All-Cloud

50k

1800 3600 5400

100k

0

CAPSys

100k

50k

0

50k 25k 0

1800 3600 5400

100k 0

All-Edge

Q5

50k 25k 0

Sluice

Records/s

Q1

Records/s

Target All-Cloud

1800 3600 5400 Time (s)

(b) abrupt rate pattern

Figure 18: Impact of input rate - RPi2

20

1800 3600 5400 Time (s)

(a) gradual rate pattern

Records/s

Q1

1800 3600 5400 Time (s)

(b) abrupt rate pattern

Records/s

0

1800 3600 5400

1800 3600 5400

Records/s

25k

25k

Records/s

40 20 0

0

1800 3600 5400

40 20 0

1800 3600 5400

Records/s

0

1800 3600 5400 50k

1800 3600 5400 Time (s)

(a) gradual rate pattern

Figure 19: Impact of input rate - RPi3

50k

Records/s

0

1800 3600 5400

Records/s

Records/s

40 20 0

Records/s

Q2

Records/s

Q3 Q4

Records/s

0

1800 3600 5400

1800 3600 5400

100k

50k

25k

25k

50k 25k 0

1800 3600 5400

100k

1800 3600 5400

50k

CAPSys

150k

Records/s

0

1800 3600 5400

0

All-Edge

100k

50k

1800 3600 5400

Sluice

1800 3600 5400

100k

Records/s

Records/s Records/s

Q2

Records/s

Q3

Records/s

Records/s

Q4 Q5

0

50k 25k 0

1800 3600 5400

100k

50k

40 20 0

Target All-Cloud

50k

1800 3600 5400

100k

0

CAPSys

100k

50k

0

50k 25k 0

1800 3600 5400

100k 0

All-Edge

Q5

50k 25k 0

Sluice

Records/s

Q1

Records/s

Target All-Cloud

1800 3600 5400 Time (s)

(b) abrupt rate pattern

Figure 20: Impact of input rate - RPi4

21

(a) Network variations

Records/s

Records/s Records/s Records/s

Records/s

Q4

40k

20

1800 3600 5400 Compute Contention

1800 3600 5400 150 Network Bandwidth 100 50 0 1800 3600 5400 Time (s)

20k

1800 3600 5400

60

Records/s

20

1800 3600 5400 60k

40

Q5

40

Mbps

1800 3600 5400 150 Network Bandwidth 100 50 0 1800 3600 5400 Time (s)

1800 3600 5400

40 20

1800 3600 5400 Compute Contention

Mbps

20

100k

1800 3600 5400

60

1800 3600 5400

150k

20k

1800 3600 5400

0

1800 3600 5400

40k

Operating Conditions

40

20k

Records/s

Q1 Q2 Q3

Records/s

Records/s

1800 3600 5400

1800 3600 5400

50k

120k

1800 3600 5400

40k

20k

0

0

1800 3600 5400

50k

100k

60k

40k

Q5

0

1800 3600 5400

50k

Records/s

Records/s Records/s Records/s

100k

50k

0

1800 3600 5400

Records/s

Records/s Records/s Records/s

100k

Operating Conditions

0

1800 3600 5400

All-Edge

25k

1800 3600 5400

50k

Records/s

Q1 Q2 Q3 Q4

50k

0

0

1800 3600 5400

CAPSys

Sluice

50k

50k

25k

0

Target All-Cloud

Records/s

All-Edge

50k 0

CAPSys

Sluice

Records/s

Target All-Cloud

1800 3600 5400 Time (s) (b) Compute contention

(a) Network variations

Figure 21: Impact of network bandwidth and compute contention - RPi1

1800 3600 5400 Time (s) (b) Compute contention

Figure 22: Impact of network bandwidth and compute contention - RPi2

22

20

(a) Network variations

Records/s

Records/s

Records/s Records/s

Records/s

Records/s

Q1 Q2 Q4

40k

20

1800 3600 5400 Compute Contention

1800 3600 5400 60k

40

Q5

40

Mbps

1800 3600 5400 150 Network Bandwidth 100 50 0 1800 3600 5400 Time (s)

1800 3600 5400

1800 3600 5400 150 Network Bandwidth 100 50 0 1800 3600 5400 Time (s)

20k 60 40 20

1800 3600 5400

1800 3600 5400 Compute Contention

Mbps

20

100k

1800 3600 5400

60

1800 3600 5400

150k

20k

1800 3600 5400

0

1800 3600 5400

40k

Operating Conditions

40

20k

Records/s

Records/s

1800 3600 5400 Q5

Q3

Records/s

40k

20k

Operating Conditions

1800 3600 5400

1800 3600 5400

50k

120k 100k

60k

40k

Records/s

Q4

1800 3600 5400

0

0

1800 3600 5400

Records/s

Records/s Records/s

100k

100k

50k

50k

1800 3600 5400

150k

120k

0

Records/s

Records/s

Records/s Records/s

0

1800 3600 5400

All-Edge

25k

1800 3600 5400

50k

50k

Records/s

Q1 Q2 Q3

0

1800 3600 5400

CAPSys

Sluice

50k

50k

25k

0

Target All-Cloud

Records/s

All-Edge

50k 0

CAPSys

Sluice

Records/s

Target All-Cloud

1800 3600 5400 Time (s) (b) Compute contention

(a) Network variations

Figure 23: Impact of network bandwidth and compute contention - RPi3

1800 3600 5400 Time (s) (b) Compute contention

Figure 24: Impact of network bandwidth and compute contention - RPi4

23

Related documents

• Live Adaptation of Dataflow Stream Processing for Hybrid Edge-Cloud Analytics#1457812
• Design and Implementation of a Scalable Distributed Machine Learning Infrastructure for Real-Time High-Frequency Financial Transactions#110591
• Event-Driven ML Pipeline Orchestration for Manufacturing: An AWS Industry Experience#1215972
• Fault Tolerance for Stream Processing Engines#1402107
• Real-Time Data Analytics using Apache Spark: Architecture and Case Studies#93156