Pith. sign in

REVIEW 3 major objections 4 minor 40 references

Eudoxia: a FaaS scheduling simulator for the composable lakehouse

T0 review · 3 major / 4 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read The paper argues that a composable lakehouse whose workloads are all cloud functions can be scheduled and optimized cheaply with a deterministic simulator, and presents Eudoxia as that simulator with validation on TPC-H.

desk verdict A useful open-source simulator with a clean pluggable design, but the validation only checks runtime at one fixed allocation, so the headline claim about evaluating scheduling policies is not yet supported. read the letter →

arxiv 2505.13750 v1 pith:EMBHXNR5 submitted 2025-05-19 cs.DB cs.DC

Tapan Srivastava , Jacopo Tagliabue , Ciro Greco This is my paper · ORCID
classification cs.DBcs.DC
keywords FaaSschedulingcomposabledatasystemslakehousesimulatorBauplanserverlessfunctionsTPC-H
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

The paper argues that once a data lakehouse expresses every workload—SQL queries, Python pipelines, bookkeeping steps—as cloud functions, the hard optimization problem becomes one of scheduling functions onto pools of CPU and RAM. It introduces Eudoxia, a deterministic simulator that models this problem at one CPU tick per ten microseconds and lets developers plug in their own scheduling algorithms. The authors claim Eudoxia can stand in for expensive cloud experiments: when they run TPC-H queries both on a Bauplan production instance and in the simulator, predicted runtimes miss by 0.44–3.08 percent, with an average error of 1.74 percent. If that holds, scheduler design for composable lakehouses can be iterated cheaply and safely before touching real infrastructure.

What carries the argument

The load-bearing abstraction is the Container: a simulated bundle of operators plus allocated CPUs and RAM, created by the scheduler and executed by the executor. The executor precomputes, from each operator's hidden CPU scaling function and RAM requirement, how many ticks the container needs to finish or when it will hit an out-of-memory error, so a scheduler's decisions translate deterministically into runtimes and failures. Around this loop, the workload generator emits pipeline DAGs with configurable arrival distributions and priorities, and every scheduler implementation fits a fixed signature (inspect newly arrived and failed pipelines, return suspensions and assignments), which is what makes custom scheduling algorithms a matter of writing one Python function.

What would settle it

Run a TPC-H workload in Eudoxia and on the same cloud instance, but start a second workload that saturates object storage or network bandwidth on the host; if simulated runtimes stay unchanged while the real queries slow down by more than the reported validation error, the CPU/RAM-only execution model is missing a load-bearing factor.

Watch

Extended reading notes

Core claim

The central claim is that scheduling in a composable lakehouse reduces to a tractable, simulatable problem because the system's programming model makes every unit of work a function with the same shape. Eudoxia's execution model assigns each operator a RAM requirement and a CPU scaling function saying how runtime depends on allocated CPUs; the scheduler sees only queue state, while the executor uses these hidden values to decide real completion times and out-of-memory failures. The paper validates the model by running the 22 TPC-H queries at 10GB on a Bauplan production instance and matching each query's CPU/RAM profile in Eudoxia, obtaining runtimes within an average of 1.74 percent of production. The intended consequence is that developers can evaluate naive, priority, priority-pool, or user-written scheduling algorithms against their own infrastructure model without paying for cloud experiments.

Load-bearing premise

The model assumes a function's runtime depends only on how many CPUs it is given and how much RAM it needs; if real cloud runtimes depend significantly on I/O contention, network delays, data layout, or noisy neighbors, simulated scheduling decisions may not predict production behavior.

Editorial extensions

If this is right

  • If the validation generalizes, scheduling algorithms for FaaS lakehouses can be ranked on throughput, latency, and cost from simulation alone.
  • Because real traces and real CPU scaling functions can be plugged into Eudoxia, a team can replay its own production workload history to test a new scheduler before deploying it.
  • The three built-in schedulers illustrate the policy space—greedy single-pool, priority with preemption, and multi-pool priority—giving developers baselines for custom implementations.
  • The simulation's determinism means two runs with the same parameters and workload seed produce comparable numbers, which is what benchmarking different policies requires.
  • A single-VM 'reasonable scale' assumption is built into the model: each function runs in one container and cannot split across hosts, so the simulator is calibrated for scale-up workloads rather than distributed engines.

Reading between the lines

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

  • A natural next step is calibrating CPU scaling functions from real telemetry per operator type (filter, join, IO-heavy read), which would let Eudoxia distinguish memory-bound from network-bound queries instead of treating every operator the same way.
  • The same simulator loop could be reused for capacity planning—for example, asking what arrival rate or pool size a given scheduler tolerates before interactive queries miss a latency target—since cost and utilization are already logged per tick.
  • Extending the executor with an explicit I/O or network contention model is the most direct way to test whether the CPU/RAM-only approximation holds when pipelines share hosts, a scenario the current validation does not exercise.
  • Because the paper's validation runs each query alone with caching disabled, the strongest test of the simulator would be reproducing the reported 1.74 percent average error under concurrent mixed workloads, where preemption and OOM failures actually occur.
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 / 4 minor

Summary. The paper presents Eudoxia, a deterministic discrete-event simulator for scheduling FaaS functions in the composable lakehouse architecture embodied by Bauplan. The authors describe the Bauplan programming and execution model, formalize the scheduling problem for function DAGs with three priority classes, and introduce a modular simulator with pluggable workload generation, executor, and scheduler components. The paper demonstrates the developer API for registering custom schedulers and reports a preliminary validation in which 19 TPC-H queries at 10GB are run alone on a 16-vCPU Bauplan instance; simulated runtimes are within 0.44% to 3.08% (mean 1.74%) of measured runtimes. The paper concludes that Eudoxia is a cheap mechanism for evaluating scheduling algorithms against user infrastructure.

Significance. If the simulator's runtime model generalizes beyond the calibrated single-query, fixed-allocation setting, Eudoxia would be a valuable, low-cost tool for the composable data systems community. The open-source release under a permissive license, the clean separation of workload generation, executor, and scheduler interfaces, and the deterministic tick-based design are genuine strengths that lower the barrier to experimentation. The provided validation is a reasonable first step, but it only exercises the runtime model at one resource allocation with no concurrency, leaving the paper's central claim about evaluating scheduling algorithms unsupported. Because the scheduler decision space includes CPU allocation sizes, preemption, queueing, and OOM handling, the current evidence does not establish that Eudoxia can reliably rank scheduling policies against real cloud behavior.

major comments (3)
  1. [Section 4.2 / Figure 3] The only quantitative validation compares single-query runtimes at a fixed 16-vCPU allocation with caching disabled. The three built-in schedulers described in Section 4.1.2 allocate fractions of resources (e.g., 10% slices), double allocations on OOM failures, preempt low-priority containers, and route work across multiple pools; none of these behaviors is compared against a real multi-tenant Bauplan deployment. Because queueing delay, preemption cost, OOM handling, and resource contention are precisely the phenomena that distinguish scheduling policies, the paper's claim that Eudoxia enables developers to evaluate scheduling algorithms against their infrastructure is not yet supported. A concrete test would be to run a mixed workload of interactive and batch pipelines concurrently on Bauplan and in Eudoxia, then compare the ranking of the built-in schedulers by metrics such as p95 latency and throughput across several CPU allocations.
  2. [Section 3.2.1 / Section 4.2] The execution model assumes that an operator's runtime is fully determined by a user-supplied CPU scaling function and a peak RAM requirement, with no dependence on I/O contention, network behavior, data layout, or host interference. The validation constructs simulated pipelines 'with similar statistics' to the measured traces, so the reported 0.44-3.08% errors partly reflect input replay: the simulator is given the same CPU and RAM characteristics observed on Bauplan and then recovers the same runtimes. This is a correctness risk for the scheduling claim because scheduler decisions explore allocations and interleavings far from the single calibrated point. I recommend validating the CPU scaling functions at multiple allocation sizes (for example 2, 8, and 16 vCPUs) and testing the simulator under controlled contention (e.g., two pipelines sharing a pool) to demonstrate that the model extrapolates.
  3. [Section 4.2, paragraph beginning 'We believe'] The statement that the workload generator setup 'can effectively represent any kind of workload in the appropriate and necessary dimensions' is unsupported by the evidence. The validation covers only TPC-H SQL queries at 10GB, run serially on one instance, and the workload generator's distributions are user-supplied defaults rather than characterized against diverse real workloads. The abstract's claim that Eudoxia 'can simulate a wide range of workloads' is therefore overstated. Please either narrow this claim to what is demonstrated (TPC-H-style SQL functions with given CPU and RAM profiles) or add validation with additional workload types, such as Python pipelines, different dataset sizes, and bursty arrival patterns.
minor comments (4)
  1. [Section 4.1.2] In the description of the priority scheduler, the word 'qery' appears twice; it should be 'query'.
  2. [Abstract] The phrase 'simulations as an effective tools' has a subject-verb agreement issue; it should be 'as an effective tool'.
  3. [Figure 3] The caption says 'Distribution of percent error of simulator estimates for runtime vs. real runtime' but the plot appears to show bar charts of runtimes for a subset of queries. Please align the caption with the actual plot content or add an error-distribution panel.
  4. [References] Reference [12] is cited as 'Hai et. all'; this should be 'Hai et al.'

Circularity Check

1 steps flagged · score 6.0 of 10

The validation's simulated runtimes are calibrated from the measured Bauplan runs, so the reported 1.74% error is a fit residual, not an independent prediction.

  1. fitted input called prediction [Section 3.2.1 (Workload Generation) and Section 4.2 (Preliminary Validation)]
    "Each operator is generated with some required amount of RAM to execute... Each operator is also generated with a CPU scaling function, which returns how long the operator will take to complete based on how many CPUs are allocated. ... We first validate this approach by running data workloads against a Bauplan cloud instance, measuring runtime statistics such as CPU and RAM utilization along with runtime and comparing this to the runtime estimated by Eudoxia on a pipeline with similar statistics."

    The simulator's completion time is a deterministic function of the two per-operator inputs (RAM requirement and CPU scaling function); the paper states these 'are used to determine what the true execution time for a pipeline on a container will be.' In validation, the simulated pipeline is constructed to have 'similar statistics' to the measured Bauplan execution—i.e., CPU/RAM utilization and runtime are drawn from the same run being compared. The simulator then returns a runtime derived from those very measurements. Reporting 0.44–3.08% error (average 1.74%) between the simulated and real runtime is therefore reporting the residual of a fit, not the accuracy of an independent prediction.

full rationale

The only quantitative validation (Section 4.2) constructs the simulated pipeline from statistics of the same real execution being compared, making the runtime comparison circular: the executor's runtime is a direct function of the per-operator CPU scaling function and RAM requirement, and those are the statistics measured and matched. The error range therefore measures how well the model reproduces its calibration inputs at a single 16-vCPU allocation, and does not validate the CPU-scaling behavior at other allocations or any scheduler-specific behavior (preemption, OOM requeueing, concurrent contention). No load-bearing self-citation or imported uniqueness theorem was found; the references to Bauplan's own prior work describe the system under study rather than substituting for the validation. Because the paper's headline claim—that developers can use Eudoxia to evaluate scheduling algorithms—rests on this circular runtime validation, the paper exhibits partial circularity rather than a fully independent benchmark.

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

No speculative physical entities are introduced. The new software abstractions such as Container, Scheduler, and Workload Generator are part of the artifact, not external postulates. The ledger highlights that the central validation depends on user-supplied scaling functions and RAM requirements, which are fitted to the measured traces rather than independently derived.

free parameters (3)
  • Per-operator CPU scaling function = Not specified; chosen to match TPC-H traces during validation
    The simulator uses this function to compute true runtime from allocated CPUs. In the validation, the values are derived from Bauplan measurements, so the resulting match is partly by construction.
  • Per-operator peak RAM requirement = Not specified
    Used to model out-of-memory failures and container sizing. During validation these values are set from telemetry, with no independent estimate from first principles.
  • Workload generator distribution parameters = User-provided defaults
    Interarrival times, resource requirements, and scaling behavior are drawn from distributions centered on user parameters. There is no evidence these match real production submission patterns.
assumptions (4)
  • domain assumption Pipeline runtime is a deterministic function of allocated CPUs and RAM.
    Core model assumption stated in Section 3.2.1 and used in the Section 4.2 validation. It ignores I/O contention, network effects, and other interference.
  • domain assumption Data functions are atomic units of scheduling and cannot be split across VMs.
    Section 2.2 constrains the scheduling problem to single-VM scale-up execution, inherited from Bauplan's design and not independently evaluated.
  • domain assumption Most analytical workloads fit within a single high-memory VM.
    Section 2.2 cites external work on the Amazon Redshift fleet to justify the scale-up model, but the simulator does not test this assumption.
  • domain assumption Workload generator distributions centered at user parameters capture real submission processes.
    Section 3.2.1 assumes random generation from user-specified distributions represents production pipeline arrivals; no production trace is used to calibrate these distributions.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Eudoxia: a FaaS scheduling simulator for the composable lakehouse." pith.science (2026). https://pith.science/paper/EMBHXNR5

@misc{pith2026250513750,
  author       = {Pith},
  title        = {Pith review of: Eudoxia: a FaaS scheduling simulator for the composable lakehouse},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EMBHXNR5}},
  note         = {Machine review of arXiv:2505.13750}
}
read the original abstract

Due to the variety of its target use cases and the large API surface area to cover, a data lakehouse (DLH) is a natural candidate for a composable data system. Bauplan is a composable DLH built on "spare data parts" and a unified Function-as-a-Service (FaaS) runtime for SQL queries and Python pipelines. While FaaS simplifies both building and using the system, it introduces novel challenges in scheduling and optimization of data workloads. In this work, starting from the programming model of the composable DLH, we characterize the underlying scheduling problem and motivate simulations as an effective tools to iterate on the DLH. We then introduce and release to the community Eudoxia, a deterministic simulator for scheduling data workloads as cloud functions. We show that Eudoxia can simulate a wide range of workloads and enables highly customizable user implementations of scheduling algorithms, providing a cheap mechanism for developers to evaluate different scheduling algorithms against their infrastructure.

Figures

Figures reproduced from arXiv: 2505.13750 by the authors.

Figure 1
Figure 1. Bauplan workers are off-the-shelf VMs, provid [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Simulator Architecture. Users set parameters and [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Distribution of percent error of simulator estimates [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

40 extracted references · 23 canonical work pages

  1. [1]

    AWS Lambda

    2024. AWS Lambda. https://docs.aws.amazon.com/lambda/latest/api/API_ Invoke.html

    work page 2024

  2. [2]

    Azure Functions

    2024. Azure Functions. https://azure.microsoft.com/en-us/products/functions/

    work page 2024

  3. [3]

    Open Whisk

    2024. Open Whisk. https://github.com/apache/openwhisk

    work page 2024

  4. [4]

    2025. Arroyo. 2023. Arroyo - Serverless Stream Processing. https://www.arroyo.dev/

    work page 2025

  5. [5]

    InfluxDB: open source time series, metrics, and analytics database

    2025. InfluxDB: open source time series, metrics, and analytics database. https://influxdata.com/

    work page 2025

  6. [6]

    Arrow Flight RPC — Apache Arrow v20.0.0

    Apache Arrow Flight [n.d.]. Arrow Flight RPC — Apache Arrow v20.0.0. https: //arrow.apache.org/docs/format/Flight.html

    work page

  7. [7]

    Bailey, Aniruddha Marathe, David K

    Peter E. Bailey, Aniruddha Marathe, David K. Lowenthal, Barry Rountree, and Martin Schulz. 2015. Finding the limits of power-constrained application per- formance. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (Austin, Texas) (SC ’15) . Asso- ciation for Computing Machinery, New York, NY, U...

    arXiv 2015

  8. [8]

    Calheiros

    Rajkumar Buyya, Rajiv Ranjan, and Rodrigo N. Calheiros. 2009. Modeling and simulation of scalable Cloud computing environments and the CloudSim toolkit: Challenges and opportunities. In 2009 International Conference on High Perfor- mance Computing and Simulation . 1–11. https://doi.org/10.1109/HPCSIM.2009. 5192685

    work page doi:10.1109/hpcsim.2009 2009

Show all 40 references
  1. [9]

    Jones, Samuel Madden, and Hari Balakrishnan

    Carlo Curino, Evan P.C. Jones, Samuel Madden, and Hari Balakrishnan. 2011. Workload-aware database monitoring and consolidation. In Proceedings of the 2011 ACM SIGMOD International Conference on Management of Data (Athens, Greece) (SIGMOD ’11). Association for Computing Machin...

    2011

  2. [10]

    Darren Dao, Jeannie Albrecht, Charles Killian, and Amin Vahdat. 2009. Live Debugging of Distributed Systems. In Compiler Construction, Oege de Moor and Michael I. Schwartzbach (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 94–108

    2009

  3. [11]

    Neha Gholkar, Frank Mueller, and Barry Rountree. 2016. Power Tuning HPC Jobs on Power-Constrained Systems. In Proceedings of the 2016 International Conference on Parallel Architectures and Compilation (Haifa, Israel) (PACT ’16). Association for Computing Machinery, New York, N...

    2016

  4. [12]

    Tao Hai, Jincheng Zhou, Dayang Jawawi, Dan Wang, Uzoma Oduah, Cresantus Biamba, and Sanjiv Kumar Jain. 2023. Task scheduling in cloud environment: optimization, security prioritization and processor selection schemes. Journal of Cloud Computing 12, 1 (2023), 15

    2023

  5. [13]

    Joseph, Randy Katz, Scott Shenker, and Ion Stoica

    Benjamin Hindman, Andy Konwinski, Matei Zaharia, Ali Ghodsi, Anthony D. Joseph, Randy Katz, Scott Shenker, and Ion Stoica. 2011. Mesos: a platform for fine-grained resource sharing in the data center. In Proceedings of the 8th USENIX Conference on Networked Systems Design and ...

    2011

  6. [14]

    Amandeep Khurana and Julien Le Dem. [n.d.]. The Modern Data Architecture The Deconstructed Database. ([n. d.])

  7. [15]

    Andrew Lamb, Yijie Shen, Daniël Heres, Jayjeet Chakraborty, Mehmet Ozan Kabak, Liang-Chi Hsieh, and Chao Sun. 2024. Apache Arrow DataFusion: A Fast, Embeddable, Modular Analytic Query Engine. In Companion of the 2024 International Conference on Management of Data (Santiago AA,...

    2024

  8. [16]

    Weiwei Lin, Siyao Xu, Ligang He, and Jin Li. 2017. Multi-resource scheduling and power simulation for cloud computing. Information Sciences 397-398 (2017), 168–186. https://doi.org/10.1016/j.ins.2017.02.054

    2017 doi

  9. [17]

    Xuezheng Liu, Zhenyu Guo, Xi Wang, Feibo Chen, Xiaochen Lian, Jian Tang, Ming Wu, M Frans Kaashoek, and Zheng Zhang. 2008. D3S: Debugging deployed distributed systems. In NSDI

    2008

  10. [18]

    Semih Salihoğlu Luca Bigon, Jacopo Tagliabue. 2025. DAG lakehouse planning with an ephemeral and embedded graph database

    2025

  11. [19]

    Dipankar Mazumdar, Jason Hughes, and JB Onofre. 2023. The Data Lakehouse: Data Warehousing and More. arXiv:2310.08697 [cs.DB] https://arxiv.org/abs/ 2310.08697

    2023 arXiv

  12. [20]

    Frank McSherry, Michael Isard, and Derek Gordon Murray. 2015. Scalability! But at what COST?. In USENIX Workshop on Hot Topics in Operating Systems

    2015

  13. [21]

    Our World in Data. 2024. Historical price of computer memory and stor- age. https://ourworldindata.org/grapher/historical-cost-of-computer-memory- and-storage?time=2010..latest&facet=metric

    2024

  14. [22]

    Tapasya Patki, Zachary Frye, Harsh Bhatia, Francesco Di Natale, James Glosli, Helgi Ingolfsson, and Barry Rountree. 2019. Comparing GPU Power and Fre- quency Capping: A Case Study with the MuMMI Workflow. In2019 IEEE/ACM Workflows in Support of Large-Scale Science (WORKS) . 31...

    2019

  15. [23]

    Pedro Pedreira, Orri Erling, Konstantinos Karanasos, Scott Schneider, Wes McKin- ney, Satya R Valluri, Mohamed Zait, and Jacques Nadeau. 2023. The Composable Data Management System Manifesto. Proc. VLDB Endow. 16, 10 (June 2023), 2679–2685. https://doi.org/10.14778/3603581.3603604

    2023

  16. [24]

    Mark Raasveldt and Hannes Mühleisen. 2019. DuckDB: an Embeddable Analytical Database. In Proceedings of the 2019 International Conference on Management of Data (Amsterdam, Netherlands) (SIGMOD ’19). Association for Computing Machinery, New York, NY, USA, 1981–1984. https://doi...

    2019 doi

  17. [25]

    Alireza Sahraei, Soteris Demetriou, Amirali Sobhgol, Haoran Zhang, Abhigna Nagaraja, Neeraj Pathak, Girish Joshi, Carla Souza, Bo Huang, Wyatt Cook, Andrii Golovei, Pradeep Venkat, Andrew Mcfague, Dimitrios Skarlatos, Vipul Patel, Ravinder Thind, Ernesto Gonzalez, Yun Jin, and...

    2023

  18. [26]

    Jacopo Tagliabue. [n.d.]. You Do Not Need a Bigger Boat: Recommendations at Reasonable Scale in a (Mostly) Serverless and Open Stack(RecSys ’21). Association for Computing Machinery, New York, NY, USA. https://doi.org/10.1145/3460231. 3474604

    doi

  19. [27]

    Jacopo Tagliabue, Hugo Bowne-Anderson, Ville Tuulos, Savin Goyal, Romain Cledat, and David Berg. 2023. Reasonable Scale Machine Learning with Open- Source Metaflow. ArXiv abs/2303.11761 (2023)

    2023 arXiv

  20. [28]

    Jacopo Tagliabue, Tyler Caraza-Harter, and Ciro Greco. 2024. Bauplan: Zero-copy, Scale-up FaaS for Data Pipelines. InProceedings of the 10th International Workshop on Serverless Computing (Hong Kong, Hong Kong) (WoSC10 ’24). Association for Computing Machinery, New York, NY, U...

    2024

  21. [29]

    Jacopo Tagliabue, Ryan Curtin, and Ciro Greco. 2024. FaaS and Furious: abstrac- tions and differential caching for efficient data pre-processing . In2024 IEEE Inter- national Conference on Big Data (BigData) . IEEE Computer Society, Los Alamitos, CA, USA, 3562–3567. https://do...

    2024

  22. [30]

    Jacopo Tagliabue and Ciro Greco. 2024. Reproducible data science over data lakes: replayable data pipelines with Bauplan and Nessie. In Proceedings of the Eighth Workshop on Data Management for End-to-End Machine Learning (Santiago, AA, Chile) (DEEM ’24). Association for Compu...

    2024

  23. [31]

    Jacopo Tagliabue, Ciro Greco, and Luca Bigon. 2023. Building a Serverless Data Lakehouse from Spare Parts. ArXiv abs/2308.05368 (2023). https://api. semanticscholar.org/CorpusID:260775634

    2023 arXiv

  24. [32]

    Shanjiang Tang, Bingsheng He, Ce Yu, Yusen Li, and Kun Li. 2022. A Survey on Spark Ecosystem: Big Data Processing Infrastructure, Machine Learning, and Applications. IEEE Transactions on Knowledge and Data Engineering 34, 1 (2022), 71–91. https://doi.org/10.1109/TKDE.2020.2975652

    2022

  25. [33]

    TPC-H Homepage

    TPC-H [n.d.]. TPC-H Homepage. https://www.tpc.org/tpch/

  26. [34]

    Alexander van Renen, Dominik Horn, Pascal Pfeil, Kapil Vaidya, Wenjian Dong, Murali Narayanaswamy, Zhengchun Liu, Gaurav Saxena, Andreas Kipf, and Tim Kraska. 2024. Why TPC is Not Enough: An Analysis of the Amazon Redshift Fleet. Proc. VLDB Endow. 17, 11 (July 2024), 3694–3706...

    2024

  27. [35]

    Abhishek Verma, Luis Pedrosa, Madhukar Korupolu, David Oppenheimer, Eric Tune, and John Wilkes. 2015. Large-scale cluster management at Google with Borg. In Proceedings of the Tenth European Conference on Computer Systems (Bordeaux, France) (EuroSys ’15). Association for Compu...

    2015

  28. [36]

    Zehao Wang. 2021. Understanding the Challenges and Assisting Developers with Developing Spark Applications. 2021 IEEE/ACM 43rd International Conference on Software Engineering: Companion Proceedings (ICSE-Companion) (2021), 132–134

    2021

  29. [37]

    Hellerstein

    Michael Whittaker, Cristina Teodoropol, Peter Alvaro, and Joseph M. Hellerstein

  30. [38]

    Jerin Yasmin, Jiale Wang, Yuan Tian, and Bram Adams. 2024. An Empirical Study of Developers’ Challenges in Implementing Workflows as Code: A Case Study on Apache Airflow. ArXiv abs/2406.00180 (2024). https://api.semanticscholar. org/CorpusID:270213226

    2024

  31. [39]

    Zaharia, Ali Ghodsi, Reynold Xin, and Michael Armbrust

    Matei A. Zaharia, Ali Ghodsi, Reynold Xin, and Michael Armbrust. 2021. Lake- house: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. In Conference on Innovative Data Systems Research . 7

    2021

  32. [2018]

    In Proceedings of the ACM Symposium on Cloud Computing (Carlsbad, CA, USA) (SoCC ’18)

    Debugging Distributed Systems with Why-Across-Time Provenance. In Proceedings of the ACM Symposium on Cloud Computing (Carlsbad, CA, USA) (SoCC ’18). Association for Computing Machinery, New York, NY, USA, 333–346. https://doi.org/10.1145/3267809.3267839

Pith tools

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