Trino项目Iceberg表DELETE操作后数据一致性问题分析

问题背景

在Trino数据库项目的最新版本升级过程中（从v468升级到v469及以上版本），用户报告了一个严重的数据一致性问题：当对Iceberg格式的表执行DELETE操作后，系统会出现异常的数据删除行为。这个问题主要出现在使用HDFS存储的场景中，而在S3兼容存储上表现正常。

问题现象

用户反馈的主要异常表现包括：

1. 执行带条件的DELETE语句时，不仅删除了符合条件的数据，还会随机删除同一分区内不符合条件的数据记录
2. 在分区表场景下，删除操作会影响非目标时间范围的数据（如删除2024年12月数据时，会连带删除1-11月的部分数据）
3. 使用Spark执行相同删除操作时行为正常，表明问题特定于Trino实现
4. 该问题在v468版本不存在，从v469开始出现，持续影响到v471版本

技术分析

从技术实现角度看，这个问题可能涉及以下几个关键方面：

Iceberg MOR机制实现

Iceberg采用Merge-on-Read（MOR）机制来处理数据更新和删除操作。当执行DELETE时，系统不会直接修改原始数据文件，而是生成删除标记文件（delete files）。在读取时，Trino需要正确合并基础数据文件和删除标记文件以得到正确结果。

版本差异分析

v468版本工作正常而v469+出现问题的现象表明，可能是在以下方面的修改引入了缺陷：

1. 删除谓词下推逻辑的变更
2. 分区剪枝优化器的调整
3. 对HDFS文件系统特定实现的处理逻辑变化
4. Iceberg格式版本兼容性处理

存储系统差异

问题在HDFS上重现而在S3存储上正常，提示可能与以下因素相关：

1. HDFS文件系统API的特定行为
2. 文件锁机制的实现差异
3. 元数据缓存处理方式不同

问题复现

通过以下步骤可以稳定复现该问题：

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. 验证数据一致性

SELECT
    date(date_trunc('month', created_at)) as month,
    count(*)
FROM iceberg.schema.table
GROUP BY 1
ORDER BY 1 DESC;

影响评估

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

1. 数据丢失风险：不符合条件的数据被意外删除
2. 数据质量下降：报表和查询结果不准确
3. 系统可靠性受损：用户对Trino的信任度降低

临时解决方案

对于受影响的用户，建议：

1. 暂时回退到v468版本
2. 对于关键删除操作，使用Spark作为替代方案
3. 加强数据备份和验证机制

总结

Trino在v469及以上版本中出现的Iceberg表DELETE操作异常是一个需要高度重视的数据一致性问题。开发团队应优先调查HDFS特定路径下的MOR实现逻辑，特别是与删除谓词处理和分区剪枝相关的代码变更。用户在生产环境升级前应充分测试DELETE操作的数据一致性，避免潜在的数据丢失风险。