Delta Kernel优化：在活动文件扫描时跳过检查点中的删除记录

在Delta Lake的Kernel模块中，ActiveAddFilesIterator组件负责重放事务日志并确定在特定表版本中哪些AddFile记录仍然处于活动状态（即尚未被RemoveFile逻辑删除）。这项功能是Delta Lake实现ACID事务和版本控制的核心机制之一。

现有实现机制分析

当前实现采用反向日志重放策略：当扫描到一个AddFile记录时，需要检查后续是否存在对应的RemoveFile记录。这里存在两个关键场景：

1. 对于从JSON日志文件中读取的AddFile记录，需要检查后续JSON文件中是否存在对应的RemoveFile记录
2. 对于从Parquet检查点文件中读取的AddFile记录，由于其本身就是检查点时刻的活动文件快照，因此不需要检查同一检查点文件中的RemoveFile记录

性能优化机会

目前的实现中，Parquet检查点文件的读取仍然会加载RemoveFile记录，这实际上是不必要的开销。优化思路很明确：在仅需要确定活动AddFile的场景下，读取检查点文件时可以完全跳过RemoveFile记录的加载。

这项优化已经在Delta Kernel的Rust实现(kernel-rs)中采用，证明了其可行性和有效性。Java实现(Kernel)也可以采用相同的优化策略。

技术实现细节

具体到Java实现，需要修改ActionsIterator类中构建Parquet读取Schema的逻辑。当前实现会包含完整的Action类型，而优化后应该：

1. 在活动文件扫描场景下，构建仅包含AddFile的读取Schema
2. 跳过RemoveFile字段的读取
3. 保持其他场景下的完整Schema读取

预期收益

这项优化将带来以下好处：

1. 减少I/O开销：检查点文件中不需要读取RemoveFile数据
2. 降低内存占用：减少反序列化的对象数量
3. 提升处理速度：减少不必要的数据处理

值得注意的是，这项优化与行组跳过(row group skipping)是不同的概念。行组跳过是通过谓词下推实现的物理优化，而本优化是逻辑层面的Schema裁剪。

适用性分析

在实际场景中，AddFile和RemoveFile记录通常随机分布在检查点文件中，因此行组跳过可能效果有限。而本优化无论记录分布如何都能带来稳定收益，是更普适的性能提升方案。

对于Delta Lake用户来说，这项优化将透明地提升表扫描性能，特别是在处理包含大量版本历史的大型表时效果更为明显。