Delta-RS项目数据过滤机制在检查点操作后的异常行为分析

问题背景

Delta-RS作为开源数据湖解决方案的核心组件，其数据过滤机制（Data Skipping）通过统计信息实现查询优化。但在特定场景下，当表经过检查点（checkpoint）操作后，对非统计目标列的过滤查询会出现异常结果。

现象表现

当Delta表配置了delta.dataSkippingStatsColumns参数（例如设为"ref_date"列）后：

1. 首次写入数据正常
2. 执行检查点操作后
3. 继续追加数据
4. 对非统计列（如"date"或"values"）进行过滤时：
   • 返回结果不完整（仅包含检查点后新增数据）
   • 查询性能显著下降（因生成无效过滤条件）

技术原理分析

预期行为机制

Delta表应：

1. 仅对dataSkippingStatsColumns指定列收集统计信息
2. 查询时仅基于这些列的统计信息进行数据跳过
3. 其他列的过滤应在完整数据集上执行

实际异常机制

检查点操作后：

1. 检查点文件错误地记录了所有列的统计信息（包括非统计目标列）
2. 统计信息中非目标列的min/max值被记录为NULL
3. 查询引擎错误地将这些NULL值纳入过滤条件生成
4. 最终产生形如(date >= NULL AND date <= NULL)的无效条件

影响范围

该缺陷会导致：

1. 数据正确性问题：查询结果缺失历史数据
2. 性能退化：生成大量无效过滤条件增加计算开销
3. 使用限制：迫使业务方必须将所有查询列加入统计配置

临时解决方案

建议采取以下应急措施：

1. 调大检查点间隔参数：

   delta_table.alter.set_table_properties({"delta.checkpointInterval": "9999999"})
   

2. 手动删除已生成的检查点文件
3. 将需要过滤的列全部加入统计配置（牺牲写入性能）

修复方向建议

根本解决方案应从以下层面入手：

1. 检查点写入层：

   • 严格遵循dataSkippingStatsColumns配置
   • 禁止记录非配置列的统计信息

2. 查询解析层：

   • 过滤条件生成时排除非统计列
   • 保持与原始配置的一致性

3. 兼容性考虑：

   • 优先修复写入端行为
   • 确保新旧版本reader的兼容性

最佳实践建议

在使用Delta-RS时应注意：

1. 明确区分统计列与普通列
2. 监控检查点后的查询行为变化
3. 重要查询列应显式加入统计配置
4. 升级前充分测试检查点功能

该问题的修复将显著提升Delta-RS在复杂查询场景下的可靠性和性能表现，建议用户关注后续版本更新。