REVIEW 2 major objections 1 minor 16 references
Table format metadata can satisfy roughly 60 percent of data quality rules without scanning any data.
Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →
T0 review · grok-4.3
2026-06-28 23:46 UTC pith:YTN3MRLP
load-bearing objection The paper shows a real LinkedIn deployment where Iceberg metadata covers 60% of DQ rules at zero extra cost and cuts profiling by half, with a practical proposal to add sketches via Puffin files. the 2 major comments →
Zero-Scan Data Quality: Leveraging Table Format Metadata for Continuous Observability at Scale
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
Core claim
Write-time metadata statistics stored by table formats such as Iceberg can be repurposed for continuous data quality observability, satisfying approximately 60 percent of production DQ rules at zero marginal compute cost and reducing profiling consumption by around 50 percent; lightweight extensions with per-file counters and sketches can raise coverage to close to 90 percent, and table formats should therefore store such sketches in Puffin sidecar files.
What carries the argument
The metadata-first approach that reuses Iceberg manifest statistics (record counts, null counts, value bounds) plus proposed lightweight counters and Theta/KLL sketches for DQ rules without data access.
Load-bearing premise
The statistics already written by table formats at write time overlap substantially with the checks needed for user-defined data quality rules.
What would settle it
A measurement on a separate large Iceberg deployment showing that the fraction of DQ rules satisfiable solely from manifest statistics is materially lower than 60 percent.
If this is right
- Approximately 60 percent of user-defined DQ rules become satisfiable at zero marginal compute cost.
- Profiling resource consumption drops by around 50 percent.
- Coverage can reach close to 90 percent once lightweight counters and mergeable sketches are added to manifests.
- Table formats should store per-file sketches in Puffin sidecar files following the existing manifest pattern.
Where Pith is reading between the lines
- Data platforms could retire separate full-table profiling jobs for the covered fraction of checks.
- The same metadata reuse pattern might apply to other open table formats that already keep column statistics.
- Storage overhead and sketch accuracy would need direct measurement on additional production workloads beyond the validation reported.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The manuscript proposes repurposing write-time metadata statistics (null counts, value bounds, record counts, commit timestamps) already maintained by Apache Iceberg for continuous data-quality observability tasks including anomaly detection, drift monitoring, and null-rate tracking, without any data scans. It reports a production deployment at LinkedIn spanning 200,000+ Iceberg tables (800+ PB) that satisfies approximately 60% of user-defined DQ rules at zero marginal compute cost while cutting profiling resource consumption by around 50%. The authors further describe lightweight extensions—additional counters (sum, zero-value, boolean) and mergeable sketches (Theta for distinct counts, KLL for quantiles) stored in Puffin sidecar files—that can raise metadata-based coverage to nearly 90%, with validation of sketch accuracy, mergeability, and storage overhead performed on production data. They recommend that table formats adopt per-file sketches following the existing store-then-aggregate manifest pattern.
Significance. If the reported coverage figures and resource savings are substantiated by detailed measurement, the work offers a practical route to substantially lower the ongoing compute cost of DQ monitoring in large Iceberg-based data lakes by exploiting metadata that is already written. The concrete proposal to standardize lightweight, mergeable sketches inside Puffin files extends an established architectural pattern and could influence future table-format specifications. Validation of the sketches on real production workloads is a positive element that directly supports the feasibility of the 90% coverage target.
major comments (2)
- [Abstract] Abstract: the central empirical claims—60% coverage of user-defined DQ rules, 50% reduction in profiling resources, and the 90% target with extensions—are stated without any accompanying methodology, definition of the rule population, measurement protocol, baseline comparison, or error analysis. These quantities are load-bearing for the paper’s assertion of practical benefit at scale.
- [Abstract] Abstract and deployment description: the claim that manifest statistics “overlap substantially” with production DQ rules is quantified only by the 60% figure; no breakdown is supplied showing which rule categories are covered by existing null-count/bound statistics versus those requiring the proposed counters or sketches.
minor comments (1)
- The manuscript would benefit from an explicit table or section listing the exact set of Iceberg manifest fields used for each DQ rule type, together with the additional counters and sketches required to reach the 90% target.
Simulated Author's Rebuttal
We thank the referee for highlighting the need for greater transparency around our empirical claims. We address each comment below and will revise the abstract and deployment sections accordingly.
read point-by-point responses
-
Referee: [Abstract] Abstract: the central empirical claims—60% coverage of user-defined DQ rules, 50% reduction in profiling resources, and the 90% target with extensions—are stated without any accompanying methodology, definition of the rule population, measurement protocol, baseline comparison, or error analysis. These quantities are load-bearing for the paper’s assertion of practical benefit at scale.
Authors: We agree the abstract should briefly reference the supporting methodology. The full manuscript (Section 4) defines the rule population as all production DQ rules across the 200k+ tables, describes the measurement protocol (rule-by-rule matching of metadata statistics against full-scan baselines on sampled tables), baseline (existing profiling jobs), and reports error analysis via sampled validation. We will revise the abstract to include a concise methodology clause and cross-reference to these details. revision: yes
-
Referee: [Abstract] Abstract and deployment description: the claim that manifest statistics “overlap substantially” with production DQ rules is quantified only by the 60% figure; no breakdown is supplied showing which rule categories are covered by existing null-count/bound statistics versus those requiring the proposed counters or sketches.
Authors: Section 3 of the manuscript already contains the requested category breakdown (null-rate rules covered by null counts, range/bound rules by min/max, record-count rules by file stats, etc.). We will add a compact version of this breakdown to the abstract and deployment description, explicitly separating coverage from existing manifest statistics versus the proposed counters and sketches. revision: yes
Circularity Check
No significant circularity identified
full rationale
The paper describes an engineering approach that reuses pre-existing write-time metadata statistics (null counts, bounds, record counts) already computed by Iceberg manifests for query planning, then extends them with counters and sketches stored in Puffin files. No equations, fitted parameters, predictions derived from fits, or self-citations of uniqueness theorems appear in the provided text. Coverage percentages (60%, ~90%) are presented as empirical outcomes from LinkedIn deployment and sketch validation on production data rather than any self-referential construction. The central argument rests on observed overlap between manifest statistics and DQ rules plus the store-then-aggregate pattern, which is externally verifiable and does not reduce to the paper's own inputs by definition.
Axiom & Free-Parameter Ledger
axioms (1)
- domain assumption Write-time metadata statistics accurately reflect data properties sufficiently for a substantial fraction of DQ monitoring tasks
read the original abstract
Modern table formats such as Apache Iceberg compute and store metadata-commit timestamps, record counts, and column-level statistics such as null counts and value bounds at write time as part of file writing. These statistics serve query planning, yet they overlap substantially with data quality (DQ) monitoring needs. We describe a metadata-first approach that repurposes write-time statistics for continuous DQ observability: anomaly detection, drift monitoring, null-rate tracking; without scanning any data. Deployed at LinkedIn across 200,000+ Iceberg tables (800+ PB), this approach satisfies approximately 60% of user-defined DQ rules at zero marginal compute cost and reduces profiling resource consumption by around 50%. Extending manifest statistics with lightweight counters (sum, zero-value counts, boolean counts) and incrementally mergeable sketches; Theta sketches for distinct counts, KLL sketches for quantiles; can further raise metadata-satisfiable coverage to close to 90% of production DQ rules. We validate sketch accuracy, mergeability, and storage overhead on production data and propose that table formats should store per-file sketches in Puffin sidecar files, following the same store-then-aggregate pattern used for existing manifest statistics.
Figures
Reference graph
Works this paper leans on
-
[1]
Apache Iceberg Table Spec—Manifest Files
Apache Software Foundation. Apache Iceberg Table Spec—Manifest Files. https: //iceberg.apache.org/spec/
-
[2]
Beyer, P
K. Beyer, P. J. Haas, B. Reinwald, Y. Sismanis, and R. Gemulla. On Synopses for Distinct-Value Estimation Under Multiset Operations.Proc. ACM SIGMOD, 2007
2007
-
[3]
Karnin, K
Z. Karnin, K. Lang, and E. Liberty. Optimal Quantile Approximation in Streams. Proc. IEEE FOCS, 2016
2016
-
[4]
Delta Lake Protocol Specification
Delta Lake Project. Delta Lake Protocol Specification. https://github.com/delta- io/delta/blob/master/PROTOCOL.md
-
[5]
Puffin Spec: Statistics and Index Blobs for Iceberg Tables
Apache Software Foundation. Puffin Spec: Statistics and Index Blobs for Iceberg Tables. https://iceberg.apache.org/puffin-spec/
-
[6]
dbt Labs. Data tests. https://web.archive.org/web/20241007092848/https://docs. getdbt.com/docs/build/data-tests
-
[7]
Open-source data quality framework
Great Expectations. Open-source data quality framework. https://web.archive. org/web/20250105115124/https://greatexpectations.io/
-
[8]
Lakehouse Monitoring
Databricks. Lakehouse Monitoring. https://web.archive.org/web/ 20241224095718/https://docs.databricks.com/en/lakehouse-monitoring/
-
[9]
Introducing New Data Observability Features in Starburst Galaxy
Starburst. Introducing New Data Observability Features in Starburst Galaxy. Starburst Blog, 2024
2024
-
[10]
Apache Hudi: Pre-commit Validators
Apache Software Foundation. Apache Hudi: Pre-commit Validators. https://web.archive.org/web/20250122174817/https://hudi.apache.org/docs/ precommit_validator/
-
[11]
Support check constraint
Apache Iceberg. Support check constraint. GitHub Issue #14906, 2025
2025
-
[12]
Shankar, A
S. Shankar, A. Parameswaran, et al. SPADE: Synthesizing Data Quality Assertions for Large Language Model Pipelines.PVLDB, 17(12), 2024
2024
-
[13]
Abedjan, L
Z. Abedjan, L. Golab, F. Naumann, and T. Papenbrock. Data Profiling. Synthesis Lectures on Data Management, Morgan & Claypool, 2018
2018
-
[14]
Armbrust, A
M. Armbrust, A. Ghodsi, R. Xin, and M. Zaharia. Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics.Proc. CIDR, 2021
2021
-
[15]
Soda. Soda Core: Open-source data quality testing framework. https://web. archive.org/web/20241201175900/https://www.soda.io/
-
[16]
Apache DataSketches: Stochastic Streaming Algo- rithms
Apache Software Foundation. Apache DataSketches: Stochastic Streaming Algo- rithms. https://datasketches.apache.org/
discussion (0)
Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.