Pith. sign in

REVIEW 3 major objections 5 minor 39 references

Justin: Hybrid CPU/Memory Elastic Scaling for Distributed Stream Processing

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A hybrid CPU/memory auto-scaler that decides between scaling up and scaling out can support target stream rates with up to 48% less CPU and 27–28% less memory than a CPU-only auto-scaler.

desk verdict A genuinely useful hybrid CPU/memory auto-scaler for Flink with a clean policy and real implementation, but the headline savings rest on hand-tuned thresholds and single-run evaluations that need tighter evidence. read the letter →

arxiv 2505.19739 v1 pith:P5KAXP3I submitted 2025-05-26 cs.DC

Donatien Schmitz (EPL) , Guillaume Rosinosky (LS2N) , Etienne Rivière (EPL) This is my paper · ORCID
classification cs.DC
keywords distributedstreamprocessingelasticscalinghybridresourcemanagementApacheFlinkRocksDBNexmarkDS2
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

Justin is an auto-scaler for distributed stream processing that treats CPU and memory as separable resources instead of scaling them together. It extends the existing DS2 autoscaler, which adjusts only the number of parallel tasks, by watching RocksDB state-access metrics: cache hit rate and average state-access latency. When an operator is CPU-saturated, Justin decides whether the cheaper fix is more memory per task (scale up) or more tasks (scale out), and it strips managed memory from stateless operators. In Nexmark benchmarks on Apache Flink, Justin supports the same target rates with up to 48% less CPU and 27–28% less memory on the stateful queries Q8 and Q11, in the same or fewer reconfiguration steps.

What carries the argument

The load-bearing object is the Justin decision rule (Algorithm 1): a set of conditions layered on DS2's busyness-based trigger. For each operator that DS2 wants to scale out, Justin reads two RocksDB-derived metrics, the cache hit rate $\theta$ and the average state-access latency $\tau$, and applies two thresholds, $\Delta_\theta = 80\%$ and $\Delta_\tau = 1\,\mathrm{ms}$, together with a history flag marking whether the last action was a vertical scale-up and a memory level counter that doubles per-task managed memory up to a maximum. The rule cancels the horizontal scale-out and issues a scale-up when memory pressure is indicated, and rolls back a previous scale-up when the metrics did not improve. Stateless operators are given no managed memory. These mechanisms do the work of separating memory-bound operators from CPU-bound ones and of enacting heterogeneous memory allocations through task-slot placement with bin packing.

What would settle it

Run a read-heavy stateful Nexmark query on the same seven-node testbed with a target rate, then vary the per-task managed memory so that the cache hit rate stays just above 80% while the state working set still forces disk accesses; if Justin fails to scale up and instead scales out, adding CPU without reducing state-access latency, the threshold choice is falsified. More directly, reproducing the Q8/Q11 experiments and finding that Justin uses no less CPU or memory than DS2 at the same target rate would contradict the paper's central claim.

Watch

Extended reading notes

Core claim

The paper's central claim is that a stream-processing auto-scaler can reduce resource consumption substantially by making vertical memory scaling an explicit alternative to horizontal parallelism scaling. The mechanism is a policy layered on DS2: when DS2 proposes to increase an operator's parallelism, Justin checks whether the operator's cache hit rate is below 80% or its average state-access latency exceeds 1 ms; if so, it cancels the scale-out and instead increases the per-task managed memory, provided memory is not already at the maximum level. Subsequent decisions use the history of past scale-ups to keep or roll back that choice. The evaluation reports that on the Nexmark Q8 and Q11 queries this policy reaches target rates with 48% less CPU and 27–28% less memory than DS2 while taking the same or fewer reconfiguration steps, and that on queries with small or absent state it saves memory without harming throughput.

Load-bearing premise

The policy's two thresholds — a cache hit rate below 80% or an average state-access latency above 1 ms — were chosen by the authors from their own experimental analysis; if those values do not transfer to other workloads or hardware, Justin will sometimes scale up when scaling out would be better, or miss a profitable scale-up, and the resource savings may not hold.

Editorial extensions

If this is right

  • Deployments that currently use DS2 can adopt Justin without lengthening convergence: reported reconfiguration counts are the same or fewer on the tested queries.
  • Read-heavy stateful operators should receive additional per-task memory before extra parallel tasks, because the cache hit rate and access latency identify cases where scale-out wastes CPU.
  • Write-dominated or stateless operators should be handled with parallelism only, and stateless operators should run with zero managed memory.
  • The memory savings are not limited to RAM: less managed memory per task also reduces the memory footprint of each Task Manager, allowing denser packing of tasks on the same nodes.
  • Queries with large state and frequent reads, such as sliding/session windows and joins, are the main beneficiaries; queries with small state are not penalized.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper: the fixed 80% cache-hit and 1 ms latency thresholds were selected from experiments on one testbed, so a natural extension is an adaptive policy that adjusts them from observed workload characteristics without retuning.
  • Beyond the paper: coupling Justin's memory decisions with key-skew rebalancing could handle cases where a few hot keys carry most of the state; the paper notes skew as a limitation but does not solve it.
  • Beyond the paper: the per-task memory levels could be predicted ahead of reconfiguration (for example, from the operator's working-set size) rather than discovered reactively, reducing the number of scale-up attempts.
  • Beyond the paper: co-scheduling memory-intensive tasks of one query with stateless tasks of another on the same Task Manager could consolidate memory further, a direction the paper lists as future work.
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

3 major / 5 minor

Summary. The paper presents Justin, an auto-scaler for Apache Flink that extends the DS2 CPU-only elastic scaling policy with memory-aware decisions. Justin monitors per-operator busyness, RocksDB cache hit rate, and state-access latency, and uses these signals to choose between horizontal scaling (changing parallelism) and vertical scaling (changing per-task managed memory) during a reconfiguration. The implementation modifies the Flink Kubernetes Operator and uses a bin-packing scheduler to place tasks with heterogeneous memory demands. The evaluation on the Nexmark benchmark reports that Justin reaches the target rate in as many or fewer reconfiguration steps than DS2, with up to 48% lower CPU usage and 27-28% lower memory usage on queries Q8 and Q11, and with memory savings on stateless queries. The paper's central claim is that decoupling CPU and memory scaling improves resource efficiency for stateful streaming workloads.

Significance. If the reported results are robust, this is a valuable contribution to the DSP elasticity literature. The paper identifies a real limitation of CPU-only auto-scalers (the coupling of memory with parallelism) and proposes a practical, implementable policy that uses storage-layer metrics to arbitrate between horizontal and vertical scaling. The microbenchmarks in Section 3 provide an instructive characterization of how memory affects RocksDB-backed state access under read-, write-, and update-dominated workloads. The authors have made the artifact publicly available (DOI in the footnote), which strengthens reproducibility. However, the evidence for the headline savings is currently weakened by the absence of a sensitivity analysis for the two decision thresholds and by an evaluation that appears to be based on a single run per configuration, with no error bars or statistical comparison.

major comments (3)
  1. [Section 5, Experimental setup; Algorithm 1] The policy's decision to prefer scale-up over scale-out is gated by two fixed thresholds, Δθ = 80% and Δτ = 1 ms, which the authors state were selected 'through experimental analysis' on the same Nexmark setup used for the evaluation. The paper does not report the observed cache-hit rate and state-access latency trajectories for Q8 and Q11, and it provides no sensitivity analysis showing how the qualitative results (48% CPU savings, 27-28% memory savings, and the number of reconfiguration steps) vary with these thresholds. Since the first reconfiguration's choice between vertical and horizontal scaling is determined by these thresholds, the headline savings could be an artifact of threshold tuning. I request that the authors report the time series of θ and τ for the stateful operators in Q8 and Q11 and include a sensitivity study (e.g., varying Δθ from 60% to 95% and Δτ from 0.5 ms to 2 ms) to demonstrate that the resource-savings and step-count claims are not confined to the chosen values.
  2. [Section 5.1, Figure 5] The experimental comparison against DS2 appears to be based on a single run per query and per auto-scaler. The paper states that metrics are collected and aggregated at 5-second granularity and that scaling decisions occur at the end of 2-minute windows, but no repeated trials, error bars, confidence intervals, or statistical tests are reported. The claims that Justin uses '48% less CPU' and '27-28% less memory' are point estimates from single trajectories, and the number of reconfiguration steps is similarly a single observation. I ask the authors to run each configuration multiple times (at least three to five repetitions) and report the variance (or a paired statistical comparison) to establish that the differences are not due to run-to-run variability in the scaling dynamics.
  3. [Section 5.1, Q8 paragraph] The discussion of Q8 states that Justin needs three scale-out reconfigurations while DS2 needs four, but also that Justin's intermediate configurations take longer to stabilize, so that DS2 actually converges sooner. This is an important qualification that is not fully reconciled in the paper's abstract, which claims only that Justin reaches the target rate 'in as many or fewer reconfiguration steps.' The convergence time is a practically meaningful dimension of auto-scaler quality; I ask the authors to report the wall-clock convergence time for all queries (not only Q8 and Q11) and to clarify whether the trade-off between fewer steps and longer stabilization is consistent across queries.
minor comments (5)
  1. [Section 4.2, Algorithm 1] The comment on line 14 ('Roll-back scale in') is confusing; the surrounding text says 'cancel the previous scale-up.' Please align the comment with the intended action, which is to revert to the memory level before the last vertical scaling if the vertical scaling did not improve metrics.
  2. [Section 3, Microbenchmarks] The box plots in Figure 4 are described as showing the distribution of the measured rate, but the number of samples per configuration and the precise aggregation method are not stated. Adding this information (e.g., number of 5-second measurements per 10-minute run, whether all samples are used) would help readers interpret the spread.
  3. [Section 5, Experimental setup] The paper says that the elastic scaling trigger parameters are set to keep the average busyness between 20% and 80%, but it does not specify the target busyness used by DS2 after scaling, nor the exact values of the DS2 trigger thresholds. Please provide these parameters or a reference to the DS2 configuration used.
  4. [Abstract] The phrase 'finegrain memory allocation' should be 'fine-grained memory allocation' for consistency with the rest of the text.
  5. [Section 5.1, Q11 and Q8] The paper does not discuss the cost of state migration during reconfigurations, even though vertical scaling and horizontal scaling may impose different migration overheads. Since the policy explicitly alternates between scale-up and scale-out, a sentence on how migration costs were handled (or why they were negligible) would strengthen the evaluation.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Justin's policy is a heuristic evaluated against the external Nexmark benchmark and DS2 baseline; the tuned thresholds are a robustness concern, not a circular reduction.

full rationale

The paper's central claim—that Justin supports target rates with fewer CPU and memory resources than DS2 on Nexmark Q8 and Q11—is an empirical comparison against an external benchmark and an external baseline (DS2, Kalavri et al. OSDI 2018), not a derivation from fitted parameters. Algorithm 1 is a reactive heuristic that uses DS2's scale-out decision and conditionally replaces it with scale-up based on cache hit rate and state access latency thresholds. The paper states in Section 5: "Through experimental analysis, we identify two thresholds that allow suitable identification of memory pressure for some operator's tasks: A cache hit rate over Delta_theta = 80% and an average state access latency over Delta_tau = 1ms." This is threshold calibration, but it does not make the reported savings circular: the headline metrics (CPU cores and memory at a target rate) are measured outcomes, not quantities defined as functions of the thresholds. The thresholds affect which action is tried, but there is no equation or definition in which the reported result equals the calibrated input. The self-citations present (e.g., StreamBed [29]) appear only in related work and are not load-bearing for the main contribution; no uniqueness theorem or ansatz is imported from prior work by the same authors to force the policy. The absence of sensitivity analysis for the thresholds is a legitimate robustness and generalizability concern, but under the rubric requiring an exhibited reduction of the result to its inputs, it does not constitute circularity.

Assumptions & free parameters 5 free parameters · 5 assumptions · 0 invented entities

The central claim depends on several hand-tuned thresholds and implicit behavioral assumptions about RocksDB and DS2. The paper does not present sensitivity analysis or a formal model, so these are the main uncharged inputs.

free parameters (5)
  • Delta_theta (cache hit rate threshold) = 80%
    Chosen through experimental analysis in Section 5; triggers vertical scale-up when hit rate is below this value. No sensitivity analysis is reported.
  • Delta_tau (state access latency threshold) = 1 ms
    Chosen through experimental analysis in Section 5; triggers vertical scale-up when average latency exceeds this value. No sensitivity analysis is reported.
  • maxLevel (maximum memory level) = 3
    Limits memory scale-up to 3 doublings of the minimum (up to 632 MB in evaluation). Set by the authors, not justified by data.
  • Decision window and stabilization period = 2 minutes, 1 minute
    Inherited from DS2 but still parameters; metrics aggregated over 5-second granules. The choice affects convergence behavior.
  • Busyness trigger bounds = 20%-80%
    DS2 triggers are configured to keep average busyness between these bounds; affects how often reconfiguration happens.
assumptions (5)
  • domain assumption DS2's busyness-based capacity model and trigger logic are correct and sufficient to detect the need for reconfiguration.
    Justin builds on DS2 and uses its trigger unmodified (Algorithm 1, line 1); if DS2's capacity estimates are wrong, Justin's hybrid decisions inherit the error.
  • domain assumption RocksDB cache hit rate and state access latency are reliable, monotone indicators of memory pressure.
    The policy's entire vertical-scaling decision rests on these metrics (Algorithm 1 lines 8 and 16); the paper justifies this with microbenchmarks but not with a model.
  • domain assumption Managed memory allocated per task is the dominant factor in state access performance; heap and network memory can be ignored.
    Justin only adjusts managed memory, assuming stateless tasks need none and stateful tasks need only RocksDB cache and MemTable memory. This ignores JVM heap effects.
  • domain assumption No data skew: load is evenly distributed across tasks of an operator.
    Stated in the conclusion as an implicit assumption; if keys are skewed, per-task memory needs differ and the homogeneous per-operator allocation may fail.
  • domain assumption The 2-minute decision window yields stable, representative metrics.
    The policy averages metrics over a short window and assumes they reflect steady-state behavior; bursty workloads could mislead the trigger.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Justin: Hybrid CPU/Memory Elastic Scaling for Distributed Stream Processing." pith.science (2026). https://pith.science/paper/P5KAXP3I

@misc{pith2026250519739,
  author       = {Pith},
  title        = {Pith review of: Justin: Hybrid CPU/Memory Elastic Scaling for Distributed Stream Processing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/P5KAXP3I}},
  note         = {Machine review of arXiv:2505.19739}
}
read the original abstract

Distributed Stream Processing (DSP) engines analyze continuous data via queries expressed as a graph of operators. Auto-scalers adjust the number of parallel instances of these operators to support a target rate. Current auto-scalers couple CPU and memory scaling, allocating resources as one-size-fits-all packages. This contrasts with operators' high diversity of requirements. We present Justin, an auto-scaler that enables hybrid CPU and memory scaling of DSP operators. Justin monitors both CPU usage and the performance of operators' storage operations. Its mechanisms enable finegrain memory allocation for tasks upon a query reconfiguration. The Justin policy identifies individual operators' memory pressure and decides between adjusting parallelism and/or memory assignment. We implement Justin in Apache Flink, extending the Flink Kubernetes Operator and the DS2 CPU-only auto-scaler. Using the Nexmark benchmark, our evaluation shows that Justin identifies suitable resource allocation in as many or fewer reconfiguration steps as DS2 and supports a target rate with significantly fewer CPU and memory resources.

Figures

Figures reproduced from arXiv: 2505.19739 by the authors.

Figure 1
Figure 1. A WordCount query using four operators. We then present Justin policies and mechanisms (§4). We detail DS2, Flink’s current elastic scalers. We present how Justin collects metrics about a running query’s resource usage and storage performance in RocksDB. Based on these metrics, Justin’s auto-scaling policy adjusts DS2 decisions and derives CPU and memory allocations. These allocations are enacted by mechanisms for f… view at source ↗
Figure 2
Figure 2. Word count query deployed on two Task Managers and eight Task Slots. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Memory allocation between tasks and RocksDB LSM tree. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Evaluation of multiple memory-cpu configurations on three different state [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Elastic scaling performance of Justin (plain lines) compared to DS2 (dot [PITH_FULL_IMAGE:figures/full_fig_p012_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

39 extracted references · 39 canonical work pages

  1. [1]

    https://flink.apache.org/ (Feb 2025)

    Apache flink. https://flink.apache.org/ (Feb 2025)

    work page 2025

  2. [2]

    https://storm.apache.org/ (Feb 2025)

    Apache storm. https://storm.apache.org/ (Feb 2025)

    work page 2025

  3. [3]

    https://github.com/apache/ flink-kubernetes-operator (Feb 2025)

    Flink kubernetes operator. https://github.com/apache/ flink-kubernetes-operator (Feb 2025)

    work page 2025

  4. [4]

    https://rocksdb.org/ (Feb 2025)

    Rocksdb. https://rocksdb.org/ (Feb 2025)

    work page 2025

  5. [5]

    In: DEBS 2017

    Affetti, L., Margara, A., Cugola, G.: Flowdb: Integrating stream processing and consistent state management. In: DEBS 2017. pp. 134–145

    work page 2017

  6. [6]

    In: ICDE 2024

    Agnihotri, P., Koldehofe, B., Stiegele, P., Heinrich, R., Binnig, C., Luthra, M.: Ze- rotune: Learned zero-shot cost models for parallelism tuning in stream processing. In: ICDE 2024

    work page 2024

  7. [7]

    In: EuroSys 2022

    Asyabi, E., Wang, Y., Liagouris, J., Kalavri, V., Bestavros, A.: A new benchmark harness for systematic and robust evaluation of streaming state stores. In: EuroSys 2022

    work page 2022

  8. [8]

    In: ICDCS 2014

    Barazzutti, R., Heinze, T., Martin, A., Onica, E., Felber, P., Fetzer, C., Jerzak, Z., Pasin, M., Riviere, E.: Elastic scaling of a high-throughput content-based pub- lish/subscribe engine. In: ICDCS 2014. pp. 567–576

    work page 2014

Show all 39 references
  1. [9]

    Pro- ceedings of the VLDB Endowment10(12), 1718–1729 (2017)

    Carbone, P., Ewen, S., Fóra, G., Haridi, S., Richter, S., Tzoumas, K.: State man- agement in apache flink®: consistent stateful distributed stream processing. Pro- ceedings of the VLDB Endowment10(12), 1718–1729 (2017)

    2017

  2. [10]

    ACM Computing Surveys54(11s), 1–36 (2022)

    Cardellini, V., Lo Presti, F., Nardelli, M., Russo, G.: Runtime adaptation of data stream processing systems: The state of the art. ACM Computing Surveys54(11s), 1–36 (2022)

    2022

  3. [11]

    CNCF: Prometheus (2024),https://prometheus.io/

    2024

  4. [12]

    ACM Trans

    Dong, S., Kryczka, A., Jin, Y., Stumm, M.: RocksDB: Evolution of development priorities in a key-value store serving large-scale applications. ACM Trans. on Stor- age 17(4) (2021)

    2021

  5. [13]

    In: ACM HPDC

    Fang, J., Zhang, R., Fu, T.Z., Zhang, Z., Zhou, A., Zhu, J.: Parallel stream pro- cessing against workload skewness and variance. In: ACM HPDC. 2017 (2017)

    2017

  6. [14]

    The VLDB Journal33(2), 507–541 (2024)

    Fragkoulis, M., Carbone, P., Kalavri, V., Katsifodimos, A.: A survey on the evo- lution of stream processing systems. The VLDB Journal33(2), 507–541 (2024)

    2024

  7. [15]

    TPDS 201325(6), 1447–1463

    Gedik, B., Schneider, S., Hirzel, M., Wu, K.L.: Elastic scaling for data stream processing. TPDS 201325(6), 1447–1463

  8. [16]

    In: USENIX ATC 2017

    Iorgulescu, C., Dinu, F., Raza, A., Hassan, W.U., Zwaenepoel, W.: Don’t cry over spilled records: Memory elasticity of data-parallel applications and its application to cluster scheduling. In: USENIX ATC 2017. pp. 97–109

    2017

  9. [17]

    In: OSDI 2018

    Kalavri, V., Liagouris, J., Hoffmann, M., Dimitrova, D., Forshaw, M., Roscoe, T.: Three steps is all you need: fast, accurate, automatic scaling decisions for distributed streaming dataflows. In: OSDI 2018

    2018

  10. [18]

    In: Proc

    Kreps, J., Narkhede, N., Rao, J., et al.: Kafka: A distributed messaging system for log processing. In: Proc. of the NetDB. vol. 11 (2011)

    2011

  11. [19]

    ACM Computing Surveys (CSUR) 53(3), 1–41 (2020)

    Liu, X., Buyya, R.: Resource management and scheduling in distributed stream processing systems: a taxonomy, review, and future directions. ACM Computing Surveys (CSUR) 53(3), 1–41 (2020)

    2020

  12. [20]

    Discrete Applied Mathematics123(1-3), 379–396 (2002)

    Lodi, A., Martello, S., Vigo, D.: Recent advances on two-dimensional bin packing problems. Discrete Applied Mathematics123(1-3), 379–396 (2002)

    2002

  13. [21]

    The VLDB Journal 29(1), 393–418 (2020) Hybrid CPU/Memory Elastic Scaling for Distributed Stream Processing 17

    Luo, C., Carey, M.J.: Lsm-based storage techniques: a survey. The VLDB Journal 29(1), 393–418 (2020) Hybrid CPU/Memory Elastic Scaling for Distributed Stream Processing 17

    2020

  14. [22]

    In: CIKM 2025

    Madsen, K.G.S., Zhou, Y.: Dynamic resource management in a massively parallel stream processing engine. In: CIKM 2025. pp. 13–22

    2025

  15. [23]

    In: UCC 2020

    Millnert, V., Eker, J.: Holoscale: Horizontal and vertical scaling of cloud resources. In: UCC 2020. pp. 196–205

    2020

  16. [24]

    In: ICDE 2016

    Nasir, M.A.U., Morales, G.D.F., Kourtellis, N., Serafini, M.: When two choices are not enough: Balancing at scale in distributed stream processing. In: ICDE 2016. pp. 589–600

    2016

  17. [25]

    Acta Informatica33, 351–385 (1996)

    O’Neil, P., Cheng, E., Gawlick, D., O’Neil, E.: The log-structured merge-tree (lsm- tree). Acta Informatica33, 351–385 (1996)

    1996

  18. [26]

    Rabl, T., Traub, J., Katsifodimos, A., Markl, V.: Apache Flink in current research. it-Inf. Tech.58(4) (2016)

    2016

  19. [27]

    arXiv preprint arXiv:2407.14843 (2024)

    Razavi, K., Salmani, M., Mühlhäuser, M., Koldehofe, B., Wang, L.: A tale of two scales: Reconciling horizontal and vertical scaling for inference serving systems. arXiv preprint arXiv:2407.14843 (2024)

    2024 arXiv

  20. [28]

    ACM Computing Surveys52(2), 1–37 (2019)

    Röger, H., Mayer, R.: A comprehensive survey on parallelization and elasticity in stream processing. ACM Computing Surveys52(2), 1–37 (2019)

    2019

  21. [29]

    In: DEBS 2024

    Rosinosky, G., Schmitz, D., Rivière, E.: Streambed: capacity planning for stream processing. In: DEBS 2024. pp. 90–102

    2024

  22. [30]

    In: CCGrid 2021

    Russo, G.R., Cardellini, V., Casale, G., Presti, F.L.: MEAD: Model-based vertical auto-scaling for data stream processing. In: CCGrid 2021. pp. 314–323

    2021

  23. [31]

    ACM Transactions on Au- tonomous and Adaptive Systems (2023)

    Russo Russo, G., Cardellini, V., Lo Presti, F.: Hierarchical auto-scaling policies for data stream processing on heterogeneous resources. ACM Transactions on Au- tonomous and Adaptive Systems (2023)

    2023

  24. [32]

    In: SIGMOD 2022

    Sarkar, S., Athanassoulis, M.: Dissecting, designing, and optimizing LSM-based data stores. In: SIGMOD 2022. pp. 2489–2497

    2022

  25. [33]

    In: ICDE 2023

    Sarkar, S., Dayan, N., Athanassoulis, M.: The LSM design space and its read optimizations. In: ICDE 2023. pp. 3578–3584. IEEE

    2023

  26. [34]

    In: IPDPS 2009

    Schneider, S., Andrade, H., Gedik, B., Biem, A., Wu, K.L.: Elastic scaling of data parallel operators in stream processing. In: IPDPS 2009. pp. 1–12

    2009

  27. [35]

    Technical report (2008)

    Tucker, P., Tufte, K., Papadimos, V., Maier, D.: Nexmark–a benchmark for queries over data streams (draft). Technical report (2008)

    2008

  28. [36]

    The VLDB Journal pp

    Verwiebe, J., Grulich, P.M., Traub, J., Markl, V.: Survey of window types for aggregation in stream processing systems. The VLDB Journal pp. 1–27 (2023)

    2023

  29. [37]

    In: EuroSys 2025

    Wang, Y., Huang, L., Wang, Z., Kalavri, V., Matta, I.: CAPSys: Contention-aware task placement for data stream processing. In: EuroSys 2025

    2025

  30. [38]

    In: SOSP 2013 (2013)

    Zaharia, M., Das, T., Li, H., Hunter, T., Shenker, S., Stoica, I.: Discretized streams: Fault-tolerant streaming computation at scale. In: SOSP 2013 (2013)

    2013

  31. [39]

    IEEE Transactions on Services Computing15(5), 2883–2896 (2021)

    Zong, Z., Wen, L., Hu, X., Han, R., Qian, C., Lin, L.: Mespaconfig: Memory-sparing configuration auto-tuning for co-located in-memory cluster computing jobs. IEEE Transactions on Services Computing15(5), 2883–2896 (2021)

    2021

Pith tools

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