在 Apache Paimon 中，“删除过期数据”是一个多层级的概念。根据你的业务配置，Paimon 的数据过期与删除可以分为 快照级别（Snapshot）、分区级别（Partition） 和 行/记录级别（Record-Level） 三个层面。每个层面的删除时机和触发机制都有所不同：

---

一、 快照级别过期 (Snapshot Expiration) —— 文件物理删除时机

Paimon 的 LSM-Tree 架构会为每次 Commit 生成 1~2 个 Snapshot（快照），用于支持 Time Travel（时光回溯查询）。快照过期是文件系统上物理释放磁盘空间的关键步骤。

• 触发时机：
  在每次 Flink/Spark 写入作业执行 Commit（数据提交） 时，由 Writer 自动在后台同步或异步触发。
• 判定与删除逻辑：
  • Paimon 会根据配置参数（如 snapshot.time-to-live 存活时间、snapshot.num-retained.min 最小保留数、snapshot.num-retained.max 最大保留数）判定哪些快照已过期。
  • 当一个快照被判定过期时，Paimon 会将其从元数据中移除。随后，仅属于该过期快照、且未被任何其他活跃快照或 Tag 引用的底层数据文件（Data Files）和清单文件（Manifests），才会被真正从 HDFS 或对象存储中物理删除。
• 安全保护机制（Safe Consumption）：
  如果你配置了 Consumer ID（消费者 ID）来消费增量数据，即使某些快照满足了过期时间，只要 Consumer 还没有消费完毕，Paimon 也不会将其物理删除，以此确保流消费的安全。

---

二、 分区级别过期 (Partition Expiration) —— 历史分区清理时机

对于按时间分区的表（如按天、按小时分区），为了防止历史分区无限积压，可以配置分区过期。

• 触发时机：
  由 Paimon 的 Streaming Sink（如 Flink 写入算子）在后台进行定时轮询检查时触发。
• 检查间隔：
  由参数 'partition.expiration-check-interval' 控制（默认值为 1h，即每小时检查一次）。
• 判定与删除逻辑：
  • 当达到检查时机时，Paimon 会根据配置的 'partition.expiration-time'（分区有效期）进行判断。
  • 策略选择（partition.expiration-strategy）：
    • values-time（默认）：通过解析分区值（例如 dt=20260608）提取时间，与当前系统时间进行对比，超出有效期则判定过期。
    • update-time：直接对比分区目录在文件系统中的最后修改时间（Last Modified Time），超出有效期则判定过期。
  • 逻辑与物理删除：一旦判定分区过期，该分区在最新的 Snapshot 中将被逻辑标记删除（客户端无法再查询到）。随后，这些分区下的物理文件会在下一次快照过期清理中被彻底物理删除。

---

三、 行/记录级别过期 (Record-Level Expiration) —— 主键表行数据 TTL

Paimon 支持针对主键表（Primary Key Table）配置行级的数据生存时间（类似 HBase 或 Redis 的 TTL），防止单表数据量过大。

• 触发时机：
  行级数据的过期严格发生在 Compaction（文件合并）阶段。
• 判定与删除逻辑：
  • 你需要配置 'record-level.expire-time'（数据保留时长）和 'record-level.time-field'（作为时间基准的字段）。
  • 当 Flink 在后台对某些 Bucket 进行 Compaction，需要将多个 Sorted Run（排好序的文件组）进行合并并写出新文件时，Paimon 会在读取并归并数据的过程中，过滤并丢弃那些时间字段已经过期的数据行。
• 注意：无强实时性保证（No Strong Guarantee）
  • 记录的物理删除完全依赖于 Compaction 的发生。如果某个 Bucket 写入量很小，长期没有触发 Compaction，即使某些数据行在业务时间上已经过期，它们依然可以被查询到。
  • 强制删除手段：如果需要确保过期的行数据立刻在物理和逻辑上彻底消失，可以通过手动调用的方式触发一次表的 Full Compaction（全量合并），这会强制对所有 Bucket 的文件进行重写并剔除过期记录。

---

总结建议