Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Iceberg compaction always fails for primary-key tables — RewriteFiles committed after RowDelta

Đang mở
  • Có gì không ổn?
#4,352 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@Anurag15v đang làm issue này rồi.

Từ ngày 3/10/2026.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
76/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
data-engineering, databases

Hướng nghiên cứu

Start in IcebergLakeCommitter.commit() around lines 132 and 139, then read IcebergRewriteTest to understand the existing append-only coverage. Add coverage for a primary-key table with equality deletes and verify RewriteFiles is committed before RowDelta. Done means rewrite commits succeed, replace operations appear in snapshot history, and compacted file counts decrease.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Search before asking
  • I searched in the issues and found nothing similar.
Fluss version

0.9.1-incubating

Please describe the bug 🐞

IcebergLakeCommitter.commit() commits the RowDelta (new data + equality deletes) before the RewriteFiles (compaction). For PK tables using merge-on-read, every RowDelta adds equality delete files targeting existing data files in the same partitions. When commitRewrite() runs immediately after, validateFromSnapshot() detects those new deletes and rejects the commit.

Log evidence:

ERROR org.apache.fluss.lake.iceberg.tiering.IcebergLakeCommitter - Failed to commit rewrite files to iceberg, delete rewrite added files [...]
org.apache.iceberg.exceptions.ValidationException: Cannot commit, found new delete for replaced data file: GenericDataFile{content=data, ...}
    at org.apache.iceberg.exceptions.ValidationException.check(ValidationException.java:49)

This happens on every commit cycle for PK tables. The snapshot history confirms compaction never commits — every operation is overwrite (RowDelta), never replace (RewriteFiles):

operation    total-data-files
overwrite    312
overwrite    310
overwrite    308
overwrite    306

The file count grows monotonically (one file per bucket per commit), with no compaction.

Root cause: Commit ordering in IcebergLakeCommitter.commit() (line 132 vs 139). The RowDelta commits first, adding equality deletes that target the files the rewrite wants to replace.

// Current: RowDelta first, RewriteFiles second
long snapshotId = commit(snapshotUpdate, snapshotProperties);  // line 132 — RowDelta adds deletes

List<RewriteDataFileResult> rewriteDataFileResults =
        committable.rewriteDataFileResults();
if (!rewriteDataFileResults.isEmpty()) {
    Long rewriteCommitSnapshotId =
            commitRewrite(rewriteDataFileResults, snapshotProperties);  // line 139 — always fails
}

Append-only tables are unaffected because AppendFiles adds no delete files.

Test coverage gap: The existing IcebergRewriteTest only covers append-only tables (no identifier fields in the schema). PK tables with equality deletes are untested.

Also affects main (as of dd2d30a).

Solution

Swap the commit order — RewriteFiles first, RowDelta second. The rewrite validates from the snapshot it was planned against; committing it before the RowDelta means no new deletes exist yet, so validation passes. The RowDelta's equality deletes then correctly target the compacted files (which have a lower sequence number).

After applying the fix, replace operations appear and the file count drops immediately:

operation    total-data-files
overwrite    4
replace      2
overwrite    6
Are you willing to submit a PR?
  • I'm willing to submit a PR!
Ngôn ngữ chính
Java
Star
2.2k
Fork
656
Merge trung bình
2 ngày 2 giờ
Pull request đã merge (30 ngày)
120

Chuẩn bị môi trường

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/fluss

Tất cả issue của apache/fluss

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.