Apache Iceberg 小文件优化：1000个文件压缩至6个的性能实测

引言：大数据中的“小文件”困境

在处理海量分析型数据时，Apache Iceberg 等表格式常面临一个棘手问题：小文件问题。当数据以大量微小的文件而非少量大文件形式写入时，会引发元数据开销激增，导致查询规划变慢，执行效率降低。本文将探讨如何通过压缩技术解决这一问题，并实测其带来的性能提升。

Apache Iceberg：运行在文件之上的数据库层

Apache Iceberg 是一个开源的表格式，它运行在底层数据文件（如 Parquet、Avro 或 ORC）之上。它为数据湖带来了类似数据库的核心特性，包括模式演变、分区演变、时间旅行以及可靠的事务。

Iceberg 表通常包含数据文件和元数据文件。元数据文件（Manifest）和快照（Snapshot）帮助查询引擎快速定位相关数据，而无需递归遍历目录。这种设计让引擎能够像操作传统数据库表一样操作文件集合。

为什么会出现大量小文件？

尽管 Iceberg 提供了 write.target-file-size-bytes 参数来控制文件大小，但它并不保证绝对能生成指定大小的文件。原因包括：

• 流式写入限制：例如每分钟产生一个小批次的流任务，长期积累会形成成千上万个文件。
• 批处理任务限制：以 Spark 为例，其任务输出往往独立生成文件，且无法跨分区边界合并。如果单个任务产生的数据量极小（如仅 70KB），即使设置了 512MB 的目标大小也无济于事。

解决方案：数据压缩

压缩是解决小文件问题的关键手段。它通过读取现有的小文件，将行重写为更少、更大的文件，从而减少查询引擎需要打开和管理的文件数量。

操作方法：Iceberg 本身不会自动执行压缩，管理员需要调用 rewrite_data_files 存储过程，或配置外部系统触发该过程。默认策略通常是 bin-pack（打包），即改变文件大小但不刻意排序行。

实战测试：压缩前后的性能对比

为了验证压缩的效果，我们在本地环境构建了一个包含 5,000 万行数据 的 Iceberg 表，初始状态为 1,000 个小文件。我们定义了三种 SQL 工作负载，分别测量压缩前后的执行情况。

测试环境与配置

本次实验完全在本地运行，无需依赖云服务、Docker 或 Hadoop 集群。虽然无法复刻生产环境中的超大规模数据，但该测试足以揭示压缩对元数据处理和查询引擎工作量的影响。

测试结果分析

通过对比发现，压缩后的效果立竿见影：

• 元数据开销大幅降低：从管理 1,000 个文件转变为管理 6 个文件，查询引擎的规划压力和 I/O 开销显著减少。
• 查询性能显著提升：由于需要打开和扫描的文件数量大幅减少，整体查询耗时显著下降。

总结

对于使用 Iceberg 的开发者而言，定期执行数据压缩是维护高性能查询的必要操作。通过将碎片化的文件合并，不仅能优化元数据管理，更能直接提升查询吞吐量，是提升数据湖分析效率的关键实践。