Apache Iceberg 在 Spark 环境下数据读取异常问题分析

问题背景

在 Apache Iceberg 1.7.1 版本与 Spark 3.5.4 集成环境中，用户在使用 PySpark 操作存储在 Nessie 中的 Iceberg 表时，发现数据读取结果异常，并伴随有 Spark executor 进程崩溃(SIGSEGV)的情况。该问题主要出现在特定查询条件下，表现为读取结果与底层 Parquet 文件实际存储数据不一致。

环境配置

该问题出现在以下技术栈环境中：

• 硬件架构：aarch64
• Java 版本：OpenJDK 17.0.13
• 大数据组件：Spark 3.5.4 + Iceberg 1.7.1 + Nessie 0.101.2
• 运行环境：AWS EKS 集群

关键配置方面，用户启用了 Iceberg 的 Spark Catalog 集成，并配置了 Nessie 作为元数据存储后端。数据存储使用 S3 对象存储，文件格式为 Parquet，采用 ZSTD 压缩。

问题现象

用户报告的核心问题表现为：

1. 数据读取不一致：当查询特定分区(dt='2025-01-26'且pt_col1='val2')时，返回结果中出现了本应不存在的distinct_id2=0的记录，而实际Parquet文件中这些记录的distinct_id2值均≥1。

2. 进程崩溃问题：在执行某些特定查询时，Spark executor 会随机出现 SIGSEGV 错误导致进程崩溃。崩溃情况包括四种不同的堆栈轨迹，主要涉及Java虚拟机内部的内存访问问题。

3. 问题可重现性：问题具有稳定的重现性，在相同查询条件下总是返回相同错误结果，且崩溃情况也呈现一定规律性。

技术分析

从问题现象和错误日志分析，可以得出以下技术要点：

1. 数据一致性层面：底层Parquet文件数据正确，但通过Iceberg读取时出现不一致，这表明问题可能出在元数据处理或查询执行路径上，而非数据写入过程。

2. 崩溃原因分析：四种不同的SIGSEGV错误表明存在内存访问问题，可能涉及：

   • JVM符号表处理异常
   • Netty内部线程本地存储访问问题
   • 内存屏障处理异常
   • 弱引用处理过程中的崩溃

3. 特定性表现：问题仅出现在特定分区组合下，且错误记录数量与总记录数存在固定关系(num_rows_incorrect = num_total_rows - 5000)，暗示可能存在某种边界条件或缓冲区处理问题。

解决方案

该问题已在Iceberg 1.8.0版本中得到修复。对于遇到类似问题的用户，建议采取以下措施：

1. 版本升级：将Iceberg升级至1.8.0或更高版本，这是最直接的解决方案。

2. 临时规避措施：如果无法立即升级，可以考虑：

   • 避免使用特定查询模式(如ORDER BY等可能触发问题的操作)
   • 对问题分区数据进行重写或转换处理
   • 调整JVM参数增加内存稳定性

3. 监控措施：在生产环境中加强对数据一致性的校验机制，特别是对关键业务数据的双重验证。

经验总结

这一案例为大数据技术栈集成提供了重要经验：

1. 版本兼容性：在复杂技术栈(Spark+Iceberg+Nessie)集成时，需要特别注意各组件的版本兼容性。

2. ARM架构考量：问题出现在aarch64架构环境，提醒我们在非x86架构上部署时需进行更全面的测试。

3. 数据验证机制：即使底层存储数据正确，查询层仍可能出现问题，因此需要建立端到端的数据验证流程。

4. 问题诊断方法：当遇到类似数据不一致问题时，可采取以下诊断步骤：

   • 首先验证底层文件数据是否正确
   • 检查不同查询模式下的行为差异
   • 收集完整的错误日志和核心转储
   • 尝试简化问题场景进行隔离测试

这一问题的发现和解决过程，体现了开源社区协作的价值，也为类似场景下的问题排查提供了参考范例。