Pith. sign in

REVIEW 3 major objections 6 minor 23 references

FaaS and Furious: abstractions and differential caching for efficient data pre-processing

T0 review · 3 major / 6 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read A differential cache that treats S3 scans as reusable columnar fragments lets data pre-processing pipelines skip redundant reads, saving up to 30 percent of bytes read from object storage on overlapping workloads.

desk verdict A plausible semantic-caching reapplication with a real 30% byte-savings result, but the schema-addition determinism issue undercuts the headline 'transparent across schemas' claim. read the letter →

arxiv 2411.08203 v1 pith:LUFL44LS submitted 2024-11-12 cs.DB

Jacopo Tagliabue , Ryan Curtin , Ciro Greco This is my paper · ORCID
classification cs.DB
keywords datapre-processingdifferentialcachelakehouseobjectstoragecolumnarApacheArrowIcebergscancaching
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

Data pre-processing pipelines rarely repeat the same query twice, but their scans overlap: a data scientist might add a column, shorten a time window, or switch from Python to SQL while reading the same base table. This paper argues that such overlapping scans should be the unit of caching, rather than exact query results or exact file reads. It introduces Bauplan, a declarative, FaaS-style pipeline model for lakehouses, and a differential cache that stores scan fragments as Arrow tables and reassembles them with UNIONs. On TPC-H and a NYC taxi workload, the cache reads up to 30 percent fewer bytes than exact result or scan caches, with hand-verified optimality on the taxi case. If right, this gives data scientists the fast iteration loop they currently lack without changing their code.

What carries the argument

The central object is the scan: a request over a named Iceberg table for a set of columns (projection) and a row filter, executed as range-byte reads over Parquet files. The cache stores completed scans as Arrow tables, allowing zero-copy views and cheap UNION-based reassembly; a greedy algorithm (with an unspecified cost function compute_cost()) selects cached fragments to minimize the remaining scan, and Iceberg's file immutability makes invalidation free. This machinery carries the argument because every claimed saving derives from reusing such fragments across workloads.

What would settle it

Find a workload (e.g., overlapping but non-nested date filters on the NYC taxi table) where greedy cache selection reads more bytes from S3 than an exhaustive search over cache subsets; or instrument the cache to show that on the taxi workload the actual bytes read exceed the hand-computed optimal 1.171 GB.

Watch

Extended reading notes

Core claim

The central claim is that caching 'scans' — the projection-and-filter expressions that map to byte-range reads over immutable Parquet files in an Iceberg table — rather than caching materialized query outputs, unlocks reuse across the messy, partially overlapping queries typical of data pre-processing. The paper's design stores each scan's result as an Arrow table, so later scans can be answered by taking a UNION of cached fragments plus only the missing range from object storage. Because cached entries are keyed to immutable files with pointers to original S3 objects, invalidation is deterministic and free. The reported evidence is that this differential, columnar cache reduces bytes read from S3 by 17–31 percent across TPC-H scale factors and the motivating workload, and that on the NYC taxi scenario the achieved savings match a hand-computed optimal caching plan.

Load-bearing premise

The entire saving rests on the unproven assumption that greedily applying cached fragments one at a time leaves the same remaining scan as an optimal selection would, and that compute_cost() accurately measures scan cost.

Editorial extensions

If this is right

  • Data scientists can add or drop features, change libraries, or shift time windows without triggering a full re-read of the base table when the data is already cached.
  • The same cache serves both SQL and Python pipelines, because cache hits are keyed to logical scans rather than to a particular language or runtime.
  • Since cache invalidation comes from Iceberg's immutable file pointers, table updates cannot silently serve stale data.
  • If the 30 percent saving holds in production, iterative pre-processing workloads spend correspondingly less time waiting on object storage, which is the dominant latency in lakehouse pipelines.

Reading between the lines

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

  • The magnitude of the saving is workload-dependent: workloads whose scans are disjoint would see no benefit, so the 30 percent figure is a property of iterated, overlapping pre-processing, not of all lakehouse queries.
  • The same differential-cache idea could be ported to other open formats (e.g., Delta Lake) provided they expose immutable file lists and a way to map filters to files.
  • Because the cost function compute_cost() is left unspecified, the greedy algorithm's practical behavior may depend on whether scan sizes can be estimated accurately from Parquet metadata; a natural extension is to compare greedy versus exhaustive cache selection on synthetic filter sets.
  • The hand-verified optimality on the NYC taxi workload suggests the cache may already be near-optimal on realistic filter patterns, but the paper's evidence is preliminary (three workloads), not a general bound.
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 / 6 minor

Summary. The paper presents Bauplan, a declarative pipeline programming model for lakehouse data pre-processing, and a differential columnar cache that treats S3 scans (projections plus filters over Iceberg/Parquet tables) as the unit of caching. Cached fragments are stored as Arrow tables to enable zero-copy sharing and to avoid repeated Parquet-to-Arrow conversion. The paper argues that caching scans rather than exact query results allows reuse across overlapping filters, different projection sets, and multiple languages, and reports preliminary benchmarks on TPC-H (SF1 and SF100) and a NYC taxi workload showing up to 31.2% fewer bytes read than a scan cache. The authors also describe cache invalidation via Iceberg file immutability and position the work against existing SQL caches and pipeline frameworks.

Significance. If the design holds, the differential scan cache is a practical contribution: it targets a real bottleneck (object-storage read volume in iterative data-science workflows), uses open lakehouse formats, and the hand-computed optimal plan for the taxi workload is a useful consistency check. The paper is honest about the preliminary nature of the results and explicitly names a limitation in the conclusion. However, the central claim that the cache works 'transparently across ... schemas' is broader than what the implementation and benchmarks support, and the quantitative evaluation lacks the detail needed to assess robustness.

major comments (3)
  1. [Section V and Abstract] The conclusion states that 'Iceberg scans do not guarantee row order, making positional joins non-deterministic when a scan adds projections over existing (pre-filtered) tuples.' This directly contradicts the abstract's claim that the cache works 'transparently across programming languages, schemas and time windows' and the motivating scenario of 'adding or removing features' in Section I. The benchmarks in Table II exercise fixed or shrinking projections, so the reported 'up to 30% fewer bytes' does not validate the feature-addition case. Please either describe a correct mechanism for projection expansion (for example, maintaining row identity or a deterministic sort key when combining cached and newly scanned columns) or explicitly restrict the transparency claim to scans whose projection sets are subsets of cached projections. This is load-bearing because feature addition is a headline use case.
  2. [Section III-B, Listing 3] The statement 'a non-greedy algorithm will produce the same scan after the cache' is asserted without proof, and the function compute_cost() is left unspecified. The greedy selection of cache elements directly determines how many bytes must be read from S3, so any suboptimality would weaken the byte-savings claims in Table II. Please define compute_cost(), prove the optimality claim, or replace it with a systematic comparison of the greedy selection against exhaustive search on the benchmark workloads. The hand-computed optimal check for the taxi workload is a good start but should be extended and described as a method rather than a one-off verification.
  3. [Section III-C, Table II] The benchmark methodology is under-specified. The paper does not report error bars, the number of repeated runs, the cache warm-up protocol, the hardware used for the Table II runs, or the implementation details of the result-cache and scan-cache baselines (for example, whether they share the same Arrow-based storage as the proposed cache). Because the central quantitative claim is 'up to 30% fewer bytes' on S3 reads, these details are necessary for reproducibility and for assessing whether the measured savings are stable. Please provide the missing experimental protocol and variability measures.
minor comments (6)
  1. [Listing 1] The columns list contains a missing quote: 'columns=["c1, "c2", "c3"]' should be 'columns=["c1", "c2", "c3"]'.
  2. [Section III-C] The text says 'queries in the TCP are only mildly overlapping in semantics'; this should be 'TPC-H' (or 'TPC') rather than 'TCP'.
  3. [Figure 2 caption] The caption refers to the 'control plain' sending a physical plan; this should be 'control plane'.
  4. [Section V] The phrase 'object storage latency disrupt the feedback loop' should be 'object storage latency disrupts the feedback loop'.
  5. [Figure 4 caption] The caption has an extra period and colon: 'left to right).:' should be cleaned up to 'left to right).'.
  6. [Section II] Consider clarifying in the text that the 'columns' parameter in Listing 1 is a projection list and that filters are pushed down to the scan; this would help readers who are not familiar with the Bauplan API.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the cache savings are measured against fixed baselines, and the admitted limitations are correctness risks, not circular derivations.

full rationale

The paper's central quantitative claim is an empirical measurement, not a derivation: Table II reports total GBs processed under three cache policies (result cache, scan cache, and Bauplan's differential cache), and the stated 'up to 30% savings on S3 reads' is a direct comparison of those measured values. No parameter is fitted to the benchmark data, and no predicted quantity is constructed from an input in a way that forces the outcome. The hand-computed 'optimal caching plans' for the NYC taxi workload are an independent verification of an upper bound, not a fitted target disguised as a result. The paper's self-citations [12], [13] provide background on the Bauplan platform, but the cache benchmark's numeric outcome does not reduce to those citations. The unproven claim in Section III-B that 'a non-greedy algorithm will produce the same scan after the cache' is a missing proof of a heuristic optimality assumption, which is a correctness risk rather than a circular step. Likewise, the Section V admission that 'Iceberg scans do not guarantee row order, making positional joins non-deterministic when a scan adds projections over existing (pre-filtered) tuples' is an explicit limitation that undercuts the abstract's 'transparent across schemas' claim for the feature-addition workflow, but it is a stated correctness gap in the benchmark coverage, not a self-referential derivation. Accordingly, the paper is not circular; its weaknesses are empirical scope and unproven heuristic guarantees, which are outside the circularity definition.

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

No fitted parameters are used; the byte-savings are measured. The axioms are the design assumptions about scan granularity, Iceberg file immutability, greedy selection, and Arrow zero-copy. The greedy optimality assumption is the most fragile and is stated without proof.

assumptions (4)
  • domain assumption Scans over object storage are the atomic building blocks for a heterogeneous set of operations.
    The entire cache design is built around scan granularity; stated in Section I contribution 2 and Section III-A.
  • domain assumption Iceberg table scans map to an underlying set of immutable Parquet files, making cache invalidation free.
    This underpins the deterministic cache invalidation described in Section III-B; it relies on Iceberg file immutability.
  • ad hoc to paper A greedy cache-element selection yields the same remaining scan as an optimal selection.
    Stated without proof in Section III-B; compute_cost() is unspecified, so correctness of the greedy algorithm is assumed.
  • domain assumption Arrow IPC allows zero-copy sharing and negligible serialization cost for cached fragments.
    Based on Table I measurements; assumed to generalize beyond the benchmark environment.

how reviews work

0 comments
Cite this review

Pith. "Pith review of FaaS and Furious: abstractions and differential caching for efficient data pre-processing." pith.science (2026). https://pith.science/paper/LUFL44LS

@misc{pith2026241108203,
  author       = {Pith},
  title        = {Pith review of: FaaS and Furious: abstractions and differential caching for efficient data pre-processing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LUFL44LS}},
  note         = {Machine review of arXiv:2411.08203}
}
read the original abstract

Data pre-processing pipelines are the bread and butter of any successful AI project. We introduce a novel programming model for pipelines in a data lakehouse, allowing users to interact declaratively with assets in object storage. Motivated by real-world industry usage patterns, we exploit these new abstractions with a columnar and differential cache to maximize iteration speed for data scientists, who spent most of their time in pre-processing - adding or removing features, restricting or relaxing time windows, wrangling current or older datasets. We show how the new cache works transparently across programming languages, schemas and time windows, and provide preliminary evidence on its efficiency on standard data workloads.

Figures

Figures reproduced from arXiv: 2411.08203 by the authors.

Figure 1
Figure 1. A sample multi-language, cloud data pipeline. The pipeline takes raw data in object storage (S3) to a final training dataset, by going through intermediate steps that wrangle dataframes into progressively cleaner data assets. In this short paper, we discuss how to design pipeline abstractions to optimize for user interactivity, and then dive deeper on a columnar cache design that significantly improves performance i… view at source ↗
Figure 2
Figure 2. High-level communication flow between users and the cloud platform. 1) user requests a DAG execution, 2) the control plain sends a physical plan to a cloud worker, 3) the worker fetches data from object storage and 4) returns the log messages and the tuples back to the user. Listing 2. Simplified snippet for pre-processing in an Airflow DAG. def preprocess( s3_in_url, s3_out_bucket, s3_out_prefix ): # Do pre-process… view at source ↗
Figure 3
Figure 3. The physical plan for cleaned data.. A system function performing scans over S3 is added automatically before the user code: this decoupling shields users from data management and allows the addition of a data cache (purple, Section III-A). decompress data from files in S3 (Table I): no other optimiza￾tion matters if we can’t lower the latency of moving data to user functions. In other words, to achieve the fast tur… view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Differential, language-agnostic scans for workloads (1)-(3) (left to right).: logical representation of the dataframes based on user code (top); S3 scans to download dataframe fragments (middle, request #3 requires no scan); physical dataframes as assembled from fragme…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

23 extracted references · 17 canonical work pages

  1. [1]

    Global big data & analytics market by compo- nent,

    Research and Markets, “Global big data & analytics market by compo- nent,” 2024. [Online]. Available: https://www.researchandmarkets.com/ reports/5337600/global-big-data-and-analytics-market-by-component

    work page arXiv 2024

  2. [2]

    “everyone wants to do the model work, not the data work

    N. Sambasivan, S. Kapania, H. Highfill, D. Akrong, P. Paritosh, and L. M. Aroyo, ““everyone wants to do the model work, not the data work”: Data cascades in high-stakes ai,” in Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems , ser. CHI ’21. New York, NY , USA: Association for Computing Machinery,

    work page 2021

  3. [3]

    Lakehouse: A new generation of open platforms that unify data warehousing and advanced analytics,

    M. A. Zaharia, A. Ghodsi, R. Xin, and M. Armbrust, “Lakehouse: A new generation of open platforms that unify data warehousing and advanced analytics,” in Conference on Innovative Data Systems Research , 2021

    work page 2021

  4. [4]

    Towards scalable dataframe systems,

    D. Petersohn, S. Macke, D. Xin, W. Ma, D. Lee, X. Mo, J. E. Gonzalez, J. M. Hellerstein, A. D. Joseph, and A. Parameswaran, “Towards scalable dataframe systems,” Proc. VLDB Endow., vol. 13, no. 12, p. 2033–2046, jul 2020. [Online]. Available: https://doi.org/10.14778/3407790.3407807

    arXiv 2020

  5. [5]

    Operationalizing machine learning: An interview study,

    S. Shankar, R. Garcia, J. M. Hellerstein, and A. G. Parameswaran, “Operationalizing machine learning: An interview study,” 2022. [Online]. Available: https://arxiv.org/abs/2209.09125

    arXiv 2022

  6. [6]

    Reasonable Scale Machine Learning with Open-Source Metaflow

    J. Tagliabue, H. Bowne-Anderson, V . Tuulos, S. Goyal, R. Cledat, and D. Berg, “Reasonable scale machine learning with open-source metaflow,” ArXiv, vol. abs/2303.11761, 2023

    work page Pith review arXiv 2023

  7. [7]

    Global data pipeline tools market by compo- nent,

    Research and Markets, “Global data pipeline tools market by compo- nent,” 2024. [Online]. Available: https://www.researchandmarkets.com/ report/data-pipeline-tools

    work page 2024

  8. [8]

    Airflow,

    Apache, “Airflow,” https://github.com/apache/airflow, 2024

    work page 2024

Show all 23 references
  1. [9]

    Spotify, “Luigi,” https://github.com/spotify/luigi, 2024

    2024

  2. [10]

    Parquet,

    Apache, “Parquet,” https://github.com/apache/parquet-format, 2024

    2024

  3. [11]

    Iceberg,

    ——, “Iceberg,” https://github.com/apache/iceberg, 2024

    2024

  4. [12]

    Reproducible data science over data lakes: replayable data pipelines with bauplan and nessie,

    J. Tagliabue and C. Greco, “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, ser. DEEM ’24. New York, NY , USA: Association for Computing Mac...

    2024

  5. [13]

    Building a serverless data lakehouse from spare parts,

    J. Tagliabue, C. Greco, and L. Bigon, “Building a serverless data lakehouse from spare parts,” ArXiv, vol. abs/2308.05368, 2023. [Online]. Available: https://api.semanticscholar.org/CorpusID:260775634

    2023 arXiv

  6. [14]

    Build end-to-end machine learning workflows with amazon sagemaker and apache airflow,

    R. Thallam and M. Dominguez, “Build end-to-end machine learning workflows with amazon sagemaker and apache airflow,” 2024. [Online]. Available: https://github.com/aws-samples/ sagemaker-ml-workflow-with-apache-airflow/blob/master/src/dag ml pipeline amazon video reviews.py

    2024

  7. [15]

    Apache, “Arrow,” https://github.com/apache/arrow, 2024

    2024

  8. [16]

    Predicate caching: Query-driven secondary indexing for cloud data warehouses,

    T. Schmidt, A. Kipf, D. Horn, G. Saxena, and T. Kraska, “Predicate caching: Query-driven secondary indexing for cloud data warehouses,” in Companion of the 2024 International Conference on Management of Data , ser. SIGMOD/PODS ’24. New York, NY , USA: Association for Computing...

    2024

  9. [17]

    How developers iterate on machine learning workflows - a survey of the applied machine learning literature,

    D. Xin, L. Ma, S. Song, and A. G. Parameswaran, “How developers iterate on machine learning workflows - a survey of the applied machine learning literature,” ArXiv, vol. abs/1803.10311, 2018. [Online]. Available: https://api.semanticscholar.org/CorpusID:4378544

    2018 arXiv

  10. [18]

    Why tpc is not enough: An analysis of the amazon redshift fleet,

    A. van Renen, D. Horn, P. Pfeil, K. E. Vaidya, W. Dong, M. Narayanaswamy, Z. Liu, G. Saxena, A. Kipf, and T. Kraska, “Why tpc is not enough: An analysis of the amazon redshift fleet,” in VLDB 2024, 2024

    2024

  11. [19]

    dbt-core,

    dbt-labs, “dbt-core,” https://github.com/dbt-labs/dbt-core, 2024

    2024

  12. [20]

    Semantic data caching and replacement,

    S. Dar, M. J. Franklin, B. T. J ´onsson, D. Srivastava, and M. Tan, “Semantic data caching and replacement,” in Proceedings of the 22th International Conference on V ery Large Data Bases , ser. VLDB ’96. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 1996, p. 330–341

    1996

  13. [21]

    Data caching for Enterprise-Grade Petabyte-Scale OLAP,

    C. Tang, B. Fan, J. Zhao, C. Liang, Y . Wang, B. Wang, Z. Qiu, L. Qiu, B. Ding, S. Sun, S. Che, J. Mai, S. Chen, Y . Zhu, J. Xie, Y . J. Sun, Y . Li, Y . Zhang, K. Wang, and M. Chen, “Data caching for Enterprise-Grade Petabyte-Scale OLAP,” in 2024 USENIX Annual Technical Confe...

    2024

  14. [22]

    Differential storage: A key building block for a duckdb-based data warehouse,

    J. Hwang, “Differential storage: A key building block for a duckdb-based data warehouse,” https://motherduck.com/blog/ differential-storage-building-block-for-data-warehouse/, 2024

    2024

  15. [2021]

    Available: https://doi.org/10.1145/3411764.3445518

    [Online]. Available: https://doi.org/10.1145/3411764.3445518

Pith tools

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