PrestoDB Iceberg表删除操作后数据一致性异常问题分析

问题背景

近期在PrestoDB社区中，多个用户报告了从版本468升级到469及更高版本后，对Iceberg表执行DELETE操作时出现的数据一致性问题。该问题表现为：当对分区表执行条件删除时，系统不仅会删除符合条件的数据，还会错误地删除同一分区内不符合条件的随机数据行。

问题复现路径

通过用户提供的复现案例，我们可以清晰地构建问题场景：

1. 创建测试表

CREATE OR REPLACE TABLE iceberg.schema.table
WITH(
    format = 'PARQUET',
    partitioning = ARRAY['year(created_at)']
) AS (
SELECT
    1000000 + rn1 * 10 + rn2 AS order_id,
    from_unixtime(1704067200 + CAST(rand() * 31622400 AS BIGINT)) AS created_at,
    uuid() as user_id
FROM UNNEST(SEQUENCE(1, 10000)) AS t1(rn1)
CROSS JOIN UNNEST(SEQUENCE(0, 1000)) AS t2(rn2)
);

2. 执行条件删除

DELETE FROM iceberg.schema.table
WHERE created_at >= timestamp'2024-10-10 00:00:00.000';

3. 验证数据时发现不符合条件的2024年1-9月数据也被部分删除

技术分析

问题特征

1. 版本相关性：仅出现在469+版本，468版本正常
2. 存储系统相关性：HDFS环境必现，S3环境正常
3. 操作模式：仅影响DELETE操作，不影响INSERT/UPDATE
4. 数据分布：错误删除发生在同一分区内

潜在原因推测

基于问题表现和技术背景，可能涉及以下方面：

1. 合并式读取(MOR)实现缺陷：469版本可能引入了新的合并读取逻辑，在处理删除标记时未能正确应用过滤条件
2. 分区剪枝异常：虽然正确识别了目标分区，但在实际数据扫描阶段可能错误处理了分区边界
3. 谓词下推失效：删除操作的过滤条件未能正确下推到存储层
4. HDFS客户端交互问题：特定版本与HDFS的交互可能存在序列化/反序列化异常

影响评估

该问题属于严重的数据一致性问题，会导致：

1. 数据不可逆丢失（DELETE操作不可回滚）
2. 报表数据不准确
3. 业务逻辑出现不可预期行为
4. 跨系统数据不一致（如Spark与Presto查询结果不同）

临时解决方案

对于受影响用户，建议：

1. 暂时回退到468版本
2. 对于关键删除操作，改用Spark执行
3. 加强数据备份策略
4. 在测试环境充分验证后再进行生产环境升级

技术启示

这个问题揭示了分布式SQL引擎在实现ACID特性时面临的挑战：

1. 版本升级需要更完善的一致性测试套件
2. 存储系统差异可能导致同一功能表现不同
3. 删除操作在分布式环境中的实现复杂度常被低估
4. 分区表的数据本地性处理需要特别关注

建议开发者在实现类似功能时：

• 增加跨存储系统的集成测试
• 对删除操作实现双重校验机制
• 加强版本间行为一致性验证
• 考虑引入删除操作的预校验阶段