Pith. sign in

REVIEW 4 major objections 5 minor 55 references

Towards a Proactive Autoscaling Framework for Data Stream Processing at the Edge using GRU and Transfer Learning

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Pith's one-line read A lightweight GRU that forecasts edge stream load with as little as 1.3% SMAPE is the proposed engine for proactive autoscaling, backed by DTW/MMD transfer learning and a horizontal scaler.

desk verdict A framework paper that is honest about its conceptual status but whose title and abstract overclaim; the implemented part is a narrow one-step forecasting benchmark. read the letter →

arxiv 2507.14597 v1 pith:JMAOB4Z5 submitted 2025-07-19 cs.DC cs.CVcs.LGcs.PF

classification cs.DCcs.CVcs.LGcs.PF
keywords edgestreamprocessingproactiveautoscalingGRUtime-seriesforecastingtransferlearningmaximummeandiscrepancydynamictimewarpingoperatorparallelism
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that proactive autoscaling for edge stream processing can be built from three pieces: a lightweight GRU network that forecasts the incoming load, a transfer-learning step that adapts an offline model to the online stream using DTW and MMD/CMMD, and a horizontal autoscaler that sets operator parallelism from the forecast. The experiments validate only the forecasting piece: the GRU reaches 1.3% SMAPE on a real-world load series and generally beats CNN, ARIMA, and Prophet across six datasets. The transfer-learning and autoscaling modules are described conceptually, so the end-to-end claim is an extension of the forecasting result rather than a demonstrated system.

What carries the argument

The carrying mechanism is the GRU's update-gate and reset-gate state update, which the paper uses to forecast load windows, combined with three supporting components: a DTW threshold that selects similar source time series, a joint loss $L_{\text{joint}} = L_t + \lambda_1 L_M + \lambda_2 L_{\text{CMMD}}$ that aligns marginal and conditional distributions in an RKHS, and the minimum-parallelism formula $\eta_{o_i}$ that converts predicted rates into operator replicas. The GRU is the only implemented component; it takes the last 24 time steps and outputs the next load value through a single-unit dense layer.

What would settle it

Train the same GRU to produce $p$-step-ahead forecasts on the IoT Traffic and NYCTT series; if SMAPE grows sharply as $p$ increases, or if the checkpoint-restart rescaling time exceeds the forecast lead time, the proactive autoscaler cannot act before load changes.

Watch

Extended reading notes

Core claim

The paper's central claim is that a lightweight GRU is an accurate and cheap predictor of non-stationary edge stream load, and that such a predictor can be made to work online through a homogeneous transductive transfer-learning procedure (DTW-based source selection plus joint distribution adaptation with MMD and CMMD losses) and can drive horizontal autoscaling through a parallelism formula adapted from earlier stream-processing work. The result, as the authors present it, is that GRU load forecasts with up to 1.3% SMAPE are accurate enough to precompute operator parallelism, and that the transfer and scaling stages turn those forecasts into proactive edge scaling decisions.

Load-bearing premise

The load-bearing premise is that the GRU's accuracy in predicting the very next load value survives when the model must predict several time steps ahead, which is what the autoscaling problem's projection horizon $p$ requires.

Editorial extensions

If this is right

  • If the GRU's forecast accuracy holds online, an edge autoscaler can change operator parallelism before a load spike arrives instead of after a threshold is breached.
  • The measured average training and inference time of 218.8 seconds suggests the predictive model is light enough to run periodically at the edge, unlike RL policies that need thousands of training iterations.
  • The DTW-plus-MMD/CMMD transfer step, if implemented, would let a model pre-trained on historical data be fine-tuned on a short online sample, addressing the short retention of stream databases.
  • The parallelism formula plus the cloud-migration rule gives a concrete policy for stateful operators that saturate edge nodes: scale to the maximum and offload when edge latency exceeds migration plus cloud latency.
  • Because the current experiments are one-step-ahead, the framework's proactive promise stands or falls on a multi-step evaluation.
  • The 1.3% SMAPE is reported after standardizing the real-world series to match the mean and variance of the synthetic data; an evaluation on raw, unprocessed stream load would isolate how much of the accuracy comes from preprocessing.
  • A direct multi-step forecasting test using the same GRU and datasets is the first experiment that would settle whether the proactive claim is viable.
  • The load-balancer migration rule compares edge latency with migration-plus-cloud latency, but the checkpoint-restart cost in the MAPE-K execute phase is not measured; that cost determines the minimum forecast lead time the system needs.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes a three-step framework for proactive horizontal autoscaling of edge stream processing: a GRU-based load forecaster, a transfer-learning module using DTW and MMD/CMMD, and a horizontal autoscaler following the MAPE-K loop. The authors implement and evaluate only the forecasting component, comparing GRU, CNN, ARIMA, and Prophet on six datasets (synthetic IoT traffic and New York City taxi trip records at 1-, 2-, and 5-minute sampling rates). They report that GRU achieves the lowest SMAPE (1.34% on the 5-minute NYCTT set) and lower training time than the baselines. The transfer-learning and autoscaling components are explicitly stated, in Sections IV and VII, to be at the conceptual stage rather than implemented.

Significance. If the forecasting results were conclusive, they would provide a modest contribution to load prediction for distributed stream processing. The paper's broader significance as an autoscaling framework is limited because two of the three components are not implemented or evaluated; the honest disclosure of this limitation is a strength, and the problem formulation in Section III is clear. The forecasting comparison is reproducible in principle, but the evaluation design and the one-step horizon undermine the strength of the claims. The paper does not provide code or machine-checked artifacts, and no falsifiable system-level predictions are tested.

major comments (4)
  1. [Abstract; Sections IV and VII] The abstract and title present a complete proactive autoscaling framework, but Section IV states that "both the transfer learning and autoscaling frameworks are currently at advanced conceptual stages," and Section VII repeats this qualification. The experimental evaluation in Section V covers only the predictive module. As a result, the evidence supports only a load-forecasting benchmark, not the framework-level claim. Please either implement and evaluate the transfer-learning and autoscaling components or reframe the contributions to explicitly scope the paper as a forecasting study with a proposed, not yet validated, framework.
  2. [Section III-A vs. Section V-B] Section III-A defines the autoscaling objective as multi-step forecasting over a projection horizon p, f({ϖ_i}_{i=1}^n) ≈ {ϖ̂_i}_{i=n+1}^{n+p}, while Section V-B specifies that a fully connected output layer with a single unit is used to predict the load for the next time step. No multi-step forecasting experiments or lead-time analysis are reported, although the checkpoint-restart scaling procedure in Section IV-C-1-d introduces reconfiguration latency that requires a forecast horizon longer than one step. The paper should either add multi-step forecasting evaluation (e.g., recursive or direct strategies) and analyze the forecast lead time against the scaling latency, or revise the problem definition to a one-step lookahead.
  3. [Section V-A, Algorithm 2] Algorithm 2 standardizes the real-world NYCTT time series by shifting and scaling its z-scores to match the mean and standard deviation of the synthetic IoT Traffic data. This preprocessing removes the real-world distributional characteristics that the transfer-learning framework is intended to address, and it makes the "real-world dataset" claim in the abstract misleading. The evaluation should be repeated on the raw NYCTT series (or at least both raw and matched versions reported), and the authors should justify the normalization as a realistic benchmarking procedure.
  4. [Section V-B and Section VI] The ARIMA model is restricted to p,q ≤ 3, d ∈ {0,1}, Nelder-Mead optimization, and 30 iterations, and the text acknowledges that these constraints "capped its accuracy." The resulting comparison does not fairly represent ARIMA's performance, so the claim that GRU outperforms ARIMA is weaker than stated. Please use a standard auto_arima configuration or otherwise justify the restricted search space, and report variability across repeated runs (e.g., mean ± standard deviation over multiple seeds) for the neural models, since none of the reported numbers carry error bars.
minor comments (5)
  1. [Section I] The phrase "The the three-step proactive autoscaling framework" contains a duplicated article and should be corrected.
  2. [Figure 6b caption] The caption contains the typo "modesl" instead of "models".
  3. [Section V-B] The text says "Table 1 shows the runtime of the experiments," but Table I lists configuration specifications (CPU, RAM, GPU, software), not runtimes; the reference should point to the table containing training-time results.
  4. [Section IV-A-2] The ARIMA equation shown is a simplified ARMA(1,1) form rather than a general ARIMA(p,d,q) model; the notation should be either explicitly restricted or corrected to the general form.
  5. [Section VI] The explanation that all models achieve lower errors on NYCTT than on IoT Traffic is stated twice in the same section; the duplicate explanation should be consolidated.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the implemented GRU forecasting benchmark is self-contained, and the untested transfer-learning and autoscaling modules are explicitly disclosed as conceptual rather than presented as derived predictions.

full rationale

The paper's only implemented and evaluated component is the GRU load forecaster in Section V. The forecast is trained on an 80% split and tested on the held-out 20% split, with SMAPE and RMSE computed from the actual versus predicted series; no fitted parameter is renamed as a prediction and no evaluation equation is equivalent to the training objective by construction. The transfer-learning and autoscaling parts of the framework are explicitly labeled as not implemented: Section IV states that 'both the transfer learning and autoscaling frameworks are currently at advanced conceptual stages guided by theoretical principles and design considerations,' and the conclusion repeats this qualification. Because these modules are not claimed to have produced measured results, their absence is a completeness/validation gap rather than a circular derivation. The normalization in Algorithm 2, which z-scores the NYCTT counts and shifts/scales them to the IoT Traffic mean and standard deviation, is a preprocessing and comparability choice; it may weaken the claim that the model was tested on a genuine raw real-world distribution, and it narrows the domain gap that the transfer-learning stage is supposed to address, but it does not make the forecast equal to its input or force the reported error values. The parallelism formula in Section IV-C is adopted from an external prior work ([7]), not from the authors' own prior results, so there is no self-citation chain carrying the argument. Overall, no load-bearing step reduces to its own inputs by definition, by fitted-value construction, or by self-citation.

Assumptions & free parameters 6 free parameters · 4 assumptions · 0 invented entities

The framework's evaluation relies primarily on the empirical forecasting comparison; the conceptual components introduce unvalued parameters and domain assumptions, and the synthetic and rescaled datasets underpin everything. No new physical or conceptual entities are postulated.

free parameters (6)
  • GRU model hyperparameters (units/layer, learning rate, dropout, batch size, epochs, sequence length) = 64, 0.01, 0.2, 16, 10, 24
    Empirically tuned in Section V-B; these values drive the reported SMAPE and RMSE but are not justified independent of the test data.
  • ARIMA search-space bounds = p,q <= 3; d in {0,1}
    Hand-chosen in Section VI to reduce cost; the paper concedes this capped ARIMA's accuracy, weakening the baseline comparison.
  • Adjustment factor alpha = Not specified
    Algorithm 1 line 8 scales the synthetic loads at each sampling rate; the value is not given, affecting comparability of SMAPE across rates.
  • DTW distance threshold dt = Not specified
    Introduced in Section IV-B for source-series selection in the conceptual transfer-learning stage; no value or sensitivity analysis is provided.
  • Domain adaptation loss weights lambda1, lambda2 = Not specified
    Weights for MMD and CMMD losses in Section IV-B objective; no values because the stage is conceptual.
  • Load balancer latency thresholds = Not specified
    Condition for offloading in Section IV-C; conceptual, no measured values.
assumptions (4)
  • domain assumption Ingress rate is a sufficient univariate reflection of the load on the stream processing system.
    Section III states this directly; the entire forecasting approach reduces load to this single metric.
  • domain assumption The parallelism formula from reference 7 is valid in edge environments, assuming additive rates and no inter-operator contention.
    Adopted in Section IV-C; the paper itself warns that excessive parallelism can reduce throughput, citing reference 49.
  • domain assumption The generated datasets (cubic-spline interpolation, plus/minus 10% noise, z-score matching) represent real edge stream workloads.
    Section V-A Algorithms 1-2 create the evaluation data; no real edge stream trace is used, and the NYCTT series is rescaled to the synthetic distribution.
  • domain assumption Minimizing MMD and CMMD drives the source and target conditional and marginal distributions to match, making the transferred model accurate online.
    Section IV-B defines the joint objective and asserts that at minimum MMD and CMMD the distribution differences are zero; this is a standard transfer-learning hope but is not validated here.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Towards a Proactive Autoscaling Framework for Data Stream Processing at the Edge using GRU and Transfer Learning." pith.science (2026). https://pith.science/paper/JMAOB4Z5

@misc{pith2026250714597,
  author       = {Pith},
  title        = {Pith review of: Towards a Proactive Autoscaling Framework for Data Stream Processing at the Edge using GRU and Transfer Learning},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JMAOB4Z5}},
  note         = {Machine review of arXiv:2507.14597}
}
read the original abstract

Processing data at high speeds is becoming increasingly critical as digital economies generate enormous data. The current paradigms for timely data processing are edge computing and data stream processing (DSP). Edge computing places resources closer to where data is generated, while stream processing analyzes the unbounded high-speed data in motion. However, edge stream processing faces rapid workload fluctuations, complicating resource provisioning. Inadequate resource allocation leads to bottlenecks, whereas excess allocation results in wastage. Existing reactive methods, such as threshold-based policies and queuing theory scale only after performance degrades, potentially violating SLAs. Although reinforcement learning (RL) offers a proactive approach through agents that learn optimal runtime adaptation policies, it requires extensive simulation. Furthermore, predictive machine learning models face online distribution and concept drift that minimize their accuracy. We propose a three-step solution to the proactive edge stream processing autoscaling problem. Firstly, a GRU neural network forecasts the upstream load using real-world and synthetic DSP datasets. Secondly, a transfer learning framework integrates the predictive model into an online stream processing system using the DTW algorithm and joint distribution adaptation to handle the disparities between offline and online domains. Finally, a horizontal autoscaling module dynamically adjusts the degree of operator parallelism, based on predicted load while considering edge resource constraints. The lightweight GRU model for load predictions recorded up to 1.3\% SMAPE value on a real-world data set. It outperformed CNN, ARIMA, and Prophet on the SMAPE and RMSE evaluation metrics, with lower training time than the computationally intensive RL models.

Figures

Figures reproduced from arXiv: 2507.14597 by the authors.

Figure 1
Figure 1. Logical and Runtime Graphs of a DSP Job in order to sustain the incoming load, as well as selecting the appropriate execution environment within the IoT-edge-cloud architecture. Existing approaches such as Machine learning, threshold-based policies, reinforcement learning, and heuris￾tics, are either reactive, resource-demanding, or lack runtime adaptation to the data stream. For example, threshold-based techniques … view at source ↗
Figure 2
Figure 2. Overview of the proposed approach: a hypothetical [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Architectures of the GRU and LSTM Neural Networks. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Process Flow of the proposed TL Framework [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Architecture of the Proposed Autoscaler throttle data flow, introducing additional latency even after scaling. Complex or stateful operations are generally not ideal for edge-only execution due to the limited computational capacity of edge devices [50]. To adapt this m…
Figure 6
Figure 6. Figure 6: Performance comparison of GRU model and baseline methods using their forecast trajectories [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: Average RMSE and Model Compuation time of all TSF models across all datasets [PITH_FULL_IMAGE:figures/full_fig_p011_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

55 extracted references · 54 canonical work pages

  1. [1]

    An overview on edge computing research,

    K. Cao, Y . Liu, G. Meng, and Q. Sun, “An overview on edge computing research,” IEEE access, vol. 8, pp. 85 714–85 728, 2020

  2. [2]

    Towards automatic parameter tuning of stream processing systems,

    M. Bilal and M. Canini, “Towards automatic parameter tuning of stream processing systems,” in Proceedings of the 2017 Symposium on Cloud Computing, 2017, pp. 189–200

  3. [3]

    Wasp: Wide-area adaptive stream processing,

    A. Jonathan, A. Chandra, and J. Weissman, “Wasp: Wide-area adaptive stream processing,” in Proceedings of the 21st international middleware conference, 2020, pp. 221–235

  4. [4]

    Automatic performance tuning for distributed data stream processing systems,

    H. Herodotou, L. Odysseos, Y . Chen, and J. Lu, “Automatic performance tuning for distributed data stream processing systems,” in 2022 IEEE 38th International Conference on Data Engineering (ICDE) . IEEE, 2022, pp. 3194–3197

  5. [5]

    Hierarchical auto- scaling policies for data stream processing on heterogeneous resources,

    G. Russo Russo, V . Cardellini, and F. Lo Presti, “Hierarchical auto- scaling policies for data stream processing on heterogeneous resources,” ACM Transactions on Autonomous and Adaptive Systems, vol. 18, no. 4, pp. 1–44, 2023

  6. [6]

    Towards evaluating stream processing autoscalers,

    G. Siachamis, J. Kanis, W. Koper, K. Psarakis, M. Fragkoulis, A. Van Deursen, and A. Katsifodimos, “Towards evaluating stream processing autoscalers,” in 2023 IEEE 39th International Conference on Data Engineering Workshops (ICDEW) . IEEE, 2023, pp. 95–99

  7. [7]

    Three steps is all you need: fast, accurate, automatic scaling decisions for distributed streaming dataflows,

    V . Kalavri, J. Liagouris, M. Hoffmann, D. Dimitrova, M. Forshaw, and T. 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), 2018, pp. 783–798

  8. [8]

    Fas: A flow aware scaling mechanism for stream processing platform service based on lms,

    Y . Wu, R. Rao, P. Hong, and J. Ma, “Fas: A flow aware scaling mechanism for stream processing platform service based on lms,” in Proceedings of the 2017 International Conference on Management Engineering, Software Engineering and Service Sciences, 2017, pp. 280– 284

Show all 55 references
  1. [9]

    Stream data load prediction for resource scaling using online support vector regression,

    Z. Hu, H. Kang, and M. Zheng, “Stream data load prediction for resource scaling using online support vector regression,” Algorithms, vol. 12, no. 2, p. 37, 2019

  2. [10]

    Recurrent concept drifts on data streams,

    N. Gunasekara, B. Pfahringer, H. M. Gomes, A. Bifet, and Y . Sing, “Recurrent concept drifts on data streams,” in Proceedings of the Thirty- Third International Joint Conference on Artificial Intelligence, IJCAI-24, 2024, pp. 8029–8037

  3. [11]

    Elastic data stream processing,

    T. Heinze, “Elastic data stream processing,” 2021

  4. [12]

    Model-based reinforcement learning for elastic stream processing in edge computing,

    J. Xu and B. Palanisamy, “Model-based reinforcement learning for elastic stream processing in edge computing,” in 2021 IEEE 28th International Conference on High Performance Computing, Data, and Analytics (HiPC). IEEE, 2021, pp. 292–301

  5. [13]

    Runtime adaptation of data stream processing systems: The state of the art,

    V . Cardellini, F. Lo Presti, M. Nardelli, and G. R. Russo, “Runtime adaptation of data stream processing systems: The state of the art,” ACM Computing Surveys, vol. 54, no. 11s, pp. 1–36, 2022

  6. [14]

    Mead: Model-based vertical auto-scaling for data stream processing,

    G. R. Russo, V . Cardellini, G. Casale, and F. L. Presti, “Mead: Model-based vertical auto-scaling for data stream processing,” in 2021 IEEE/ACM 21st International Symposium on Cluster, Cloud and Internet Computing (CCGrid). IEEE, 2021, pp. 314–323

  7. [15]

    Q-flink: A qos-aware controller for apache flink,

    M. R. HoseinyFarahabady, A. Jannesari, J. Taheri, W. Bao, A. Y . Zomaya, and Z. Tari, “Q-flink: A qos-aware controller for apache flink,” in 2020 20th IEEE/ACM International Symposium on Cluster, Cloud and Internet Computing (CCGRID) . IEEE, 2020, pp. 629–638

  8. [16]

    Auto-sizing for stream processing applications at {LinkedIn},

    R. P. Singh, B. Kumarasubramanian, P. Maheshwari, and S. Shetty, “Auto-sizing for stream processing applications at {LinkedIn},” in 12th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 20) , 2020

  9. [17]

    Turbine: Facebook’s service management platform for stream processing,

    Y . Mei, L. Cheng, V . Talwar, M. Y . Levin, G. Jacques-Silva, N. Simha, A. Banerjee, B. Smith, T. Williamson, S. Yilmaz et al. , “Turbine: Facebook’s service management platform for stream processing,” in 2020 IEEE 36th International Conference on Data Engineering (ICDE) . IE...

  10. [18]

    An optimal model for optimizing the placement and parallelism of data stream processing applications on cloud-edge computing,

    F. R. De Souza, M. D. de Assunc ¸ao, E. Caron, and A. da Silva Veith, “An optimal model for optimizing the placement and parallelism of data stream processing applications on cloud-edge computing,” in 2020 IEEE 32nd International Symposium on Computer Architecture and High Per...

  11. [19]

    Joint operator scaling and placement for distributed stream processing applications in edge computing,

    Q. Peng, Y . Xia, Y . Wang, C. Wu, X. Luo, and J. Lee, “Joint operator scaling and placement for distributed stream processing applications in edge computing,” in Service-Oriented Computing: 17th International Conference, ICSOC 2019, Toulouse, France, October 28–31, 2019, Proc...

  12. [20]

    Elastic resource allocation based on dynamic perception of operator influence domain in distributed stream processing,

    F. Liu, W. Zhu, W. Mu, Y . Zhang, M. Li, Z. Zhu, and W. Wang, “Elastic resource allocation based on dynamic perception of operator influence domain in distributed stream processing,” in International Conference on Computational Science . Springer, 2022, pp. 734–748

  13. [21]

    Optimal operator deployment and replication for elastic distributed data stream processing. concurr. comput.(2017)

    V . Cardellini, F. Lo Presti, M. Nardelli, and G. Russo Russo, “Optimal operator deployment and replication for elastic distributed data stream processing. concurr. comput.(2017).”

  14. [22]

    Streamcloud: An elastic and scalable data streaming system,

    V . Gulisano, R. Jimenez-Peris, M. Patino-Martinez, C. Soriente, and P. Valduriez, “Streamcloud: An elastic and scalable data streaming system,” IEEE Transactions on Parallel and Distributed Systems, vol. 23, no. 12, pp. 2351–2365, 2012

  15. [23]

    Elastic scaling for data stream processing,

    B. Gedik, S. Schneider, M. Hirzel, and K.-L. Wu, “Elastic scaling for data stream processing,” IEEE Transactions on Parallel and Distributed Systems, vol. 25, no. 6, pp. 1447–1463, 2013

  16. [24]

    Elastic pulsar functions for distributed stream processing,

    G. Russo Russo, A. Schiazza, and V . Cardellini, “Elastic pulsar functions for distributed stream processing,” in Companion of the ACM/SPEC International Conference on Performance Engineering , 2021, pp. 9–16

  17. [25]

    Elastic symbiotic scaling of operators and resources in stream processing systems,

    F. Lombardi, L. Aniello, S. Bonomi, and L. Querzoni, “Elastic symbiotic scaling of operators and resources in stream processing systems,” IEEE Transactions on Parallel and Distributed Systems , vol. 29, no. 3, pp. 572–585, 2017

  18. [26]

    Proactive elasticity and energy aware- ness in data stream processing,

    T. De Matteis and G. Mencagli, “Proactive elasticity and energy aware- ness in data stream processing,” Journal of Systems and Software , vol. 127, pp. 302–319, 2017

  19. [27]

    Drs: Auto-scaling for real-time stream analytics,

    T. Z. Fu, J. Ding, R. T. Ma, M. Winslett, Y . Yang, and Z. Zhang, “Drs: Auto-scaling for real-time stream analytics,” IEEE/ACM Transactions on networking, vol. 25, no. 6, pp. 3338–3352, 2017

  20. [28]

    Elastic stream processing with latency guarantees,

    B. Lohrmann, P. Janacik, and O. Kao, “Elastic stream processing with latency guarantees,” in 2015 IEEE 35th International Conference on Distributed Computing Systems . IEEE, 2015, pp. 399–410

  21. [29]

    Feedback-control & queueing theory-based resource management for streaming applications,

    R. Tolosana-Calasanz, J. Diaz-Montes, O. F. Rana, and M. Parashar, “Feedback-control & queueing theory-based resource management for streaming applications,” IEEE Transactions on parallel and distributed systems, vol. 28, no. 4, pp. 1061–1075, 2016

  22. [30]

    A stream-processing server with an internal and an external queue,

    T. Cooper, P. Ezhilchelvan, and I. Mitrani, “A stream-processing server with an internal and an external queue,” Queueing Models and Service Management, vol. 4, no. 1, pp. 31–53, 2021

  23. [31]

    Model-based scheduling for stream processing systems,

    Y . Wang, Z. Tari, M. R. HoseinyFarahabady, and A. Y . Zomaya, “Model-based scheduling for stream processing systems,” in 2017 IEEE 19th International Conference on High Performance Computing and Communications; IEEE 15th International Conference on Smart City; IEEE 3rd Intern...

  24. [32]

    Elastic complex event processing exploiting prediction,

    N. Zacheilas, V . Kalogeraki, N. Zygouras, N. Panagiotou, and D. Gunop- ulos, “Elastic complex event processing exploiting prediction,” in 2015 IEEE International Conference on Big Data (Big Data) . IEEE, 2015, pp. 213–222

  25. [33]

    Evaluation of load prediction techniques for distributed stream processing,

    K. Gontarska, M. Geldenhuys, D. Scheinert, P. Wiesner, A. Polze, and L. Thamsen, “Evaluation of load prediction techniques for distributed stream processing,” in 2021 IEEE International Conference on Cloud Engineering (IC2E). IEEE, 2021, pp. 91–98

  26. [34]

    Caladrius: A performance modelling service for distributed stream processing systems,

    F. Kalim, T. Cooper, H. Wu, Y . Li, N. Wang, N. Lu, M. Fu, X. Qian, H. Luo, D. Cheng et al., “Caladrius: A performance modelling service for distributed stream processing systems,” in 2019 IEEE 35th Inter- national Conference on Data Engineering (ICDE) . IEEE, 2019, pp. 1886–1897

  27. [35]

    Qos-and contention- aware resource provisioning in a stream processing engine,

    M. R. H. Farahabady, A. Y . Zomaya, and Z. Tari, “Qos-and contention- aware resource provisioning in a stream processing engine,” in 2017 IEEE International Conference on Cluster Computing (CLUSTER) . IEEE, 2017, pp. 137–146

  28. [36]

    Cost-effective transfer learning for data streams,

    O. Wu, Y . S. Koh, G. Dobbie, and T. Lacombe, “Cost-effective transfer learning for data streams,” in 2022 IEEE International Conference on Data Mining (ICDM) . IEEE, 2022, pp. 1233–1238

  29. [37]

    Multi-source transfer learning for non-stationary environments,

    H. Du, L. L. Minku, and H. Zhou, “Multi-source transfer learning for non-stationary environments,” in 2019 International Joint Conference on Neural Networks (IJCNN) . IEEE, 2019, pp. 1–8

  30. [38]

    Proscale: Proactive autoscaling for microservice with time- varying workload at the edge,

    K. Cheng, S. Zhang, C. Tu, X. Shi, Z. Yin, S. Lu, Y . Liang, and Q. Gu, “Proscale: Proactive autoscaling for microservice with time- varying workload at the edge,” IEEE Transactions on Parallel and Distributed Systems, vol. 34, no. 4, pp. 1294–1312, 2023

  31. [39]

    Introduction to sequence learning models: Rnn, lstm, gru,

    S. Ashraf Zargar, “Introduction to sequence learning models: Rnn, lstm, gru,” 2021

  32. [40]

    Deep learning for time series forecasting: a survey,

    J. F. Torres, D. Hadjout, A. Sebaa, F. Mart´ınez- ´Alvarez, and A. Troncoso, “Deep learning for time series forecasting: a survey,” Big data, vol. 9, no. 1, pp. 3–21, 2021

  33. [41]

    A comparative study on long short-term memory and gated recurrent unit neural networks in fault diagnosis for chemical processes using visualization,

    S. Mirzaei, J.-L. Kang, and K.-Y . Chu, “A comparative study on long short-term memory and gated recurrent unit neural networks in fault diagnosis for chemical processes using visualization,” Journal of the Taiwan Institute of Chemical Engineers , vol. 130, p. 104028, 2022

  34. [42]

    Lstm and gru neural networks as models of dynamical processes used in predictive control: A comparison of models developed for two chemical reactors,

    K. Zarzycki and M. Ławry ´nczuk, “Lstm and gru neural networks as models of dynamical processes used in predictive control: A comparison of models developed for two chemical reactors,” Sensors, vol. 21, no. 16, p. 5625, 2021

  35. [43]

    A comparison between arima, lstm, and gru for time series forecasting,

    P. T. Yamak, L. Yujian, and P. K. Gadosey, “A comparison between arima, lstm, and gru for time series forecasting,” in Proceedings of the 2019 2nd international conference on algorithms, computing and artificial intelligence, 2019, pp. 49–55

  36. [44]

    Implementing transfer learning across different datasets for time series forecasting,

    R. Ye and Q. Dai, “Implementing transfer learning across different datasets for time series forecasting,” Pattern Recognition, vol. 109, p. 107617, 2021

  37. [45]

    Predictive efficiency of arima and ann models: A case analysis of nifty fifty in indian stock market,

    V . S. Pandey and A. Bajpai, “Predictive efficiency of arima and ann models: A case analysis of nifty fifty in indian stock market,” Inter- national Journal of Applied Engineering Research , vol. 14, no. 2, pp. 232–244, 2019

  38. [46]

    Rafferty, Forecasting Time Series Data with Facebook Prophet: Build, improve, and optimize time series forecasting models using the advanced forecasting tool

    G. Rafferty, Forecasting Time Series Data with Facebook Prophet: Build, improve, and optimize time series forecasting models using the advanced forecasting tool. Packt Publishing Ltd, 2021

  39. [47]

    A multi- source transfer learning model based on lstm and domain adaptation for building energy prediction,

    H. Lu, J. Wu, Y . Ruan, F. Qian, H. Meng, Y . Gao, and T. Xu, “A multi- source transfer learning model based on lstm and domain adaptation for building energy prediction,” International Journal of Electrical Power & Energy Systems , vol. 149, p. 109024, 2023

  40. [48]

    Maximum mean discrepancy for generalization in the presence of distribution and missingness shift,

    L. Ouyang and A. Key, “Maximum mean discrepancy for generalization in the presence of distribution and missingness shift,” arXiv preprint arXiv:2111.10344, 2021

  41. [49]

    Learning from the past: Adaptive parallelism tuning for stream processing systems,

    Y . Han, L. Chen, H. Wang, Z. Chen, Y . Zhang, C. Yang, K. Hao, and Z. Yang, “Learning from the past: Adaptive parallelism tuning for stream processing systems,” arXiv preprint arXiv:2504.12074 , 2025

  42. [50]

    Investigating edge vs. cloud computing trade-offs for stream processing,

    P. Silva, A. Costan, and G. Antoniu, “Investigating edge vs. cloud computing trade-offs for stream processing,” in 2019 IEEE International Conference on Big Data (Big Data) . IEEE, 2019, pp. 469–474

  43. [51]

    A review on architecture and models for autonomic software systems,

    P. Dehraj and A. Sharma, “A review on architecture and models for autonomic software systems,” The Journal of Supercomputing , vol. 77, no. 1, pp. 388–417, 2021

  44. [52]

    Some new observations on slo-aware edge stream processing,

    A. Shahid, P. Kang, P. Lama, and S. U. Khan, “Some new observations on slo-aware edge stream processing,” in 2023 IEEE Cloud Summit . IEEE, 2023, pp. 27–32

  45. [53]

    Using stream processing to find suitable rides: An exploration based on new york city taxi data,

    R. Tsch ¨umperlin, D. Bucher, and J. Schito, “Using stream processing to find suitable rides: An exploration based on new york city taxi data,” in Proceedings of Spatial Big Data and Machine Learning in GIScience- Workshop at GIScience 2018 . SpatialBigData, 2018, pp. 13–16

  46. [54]

    Efficient taxi and passenger searching in smart city using distributed coordination,

    A. Agrawal, V . Raychoudhury, D. Saxena, and A. D. Kshemkalyani, “Efficient taxi and passenger searching in smart city using distributed coordination,” in 2018 21st International Conference on Intelligent Transportation Systems (ITSC) . IEEE, 2018, pp. 1920–1927

  47. [55]

    Model-based stream processing auto-scaling in geo-distributed environments,

    H. Arkian, G. Pierre, J. Tordsson, and E. Elmroth, “Model-based stream processing auto-scaling in geo-distributed environments,” in 2021 International Conference on Computer Communications and Networks (ICCCN). IEEE, 2021, pp. 1–10

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.