MinIO存储3亿行Apache Iceberg表小Parquet文件压实方案咨询

1. MinIO 部署下超大规模 Iceberg 表推荐压实方案 #

采用「存量一次性压实 + 日常增量压实 + 定期元数据清理」的三级落地流程：

• 首次存量压实选择业务低峰期执行，提前做好表快照备份，执行后观察24小时查询性能无问题再清理旧快照
• 日常增量压实按天/小时调度，仅处理新写入产生的小文件，避免占用过多集群资源
• 每次压实完成后，间隔1~3天再执行快照过期、孤儿文件清理，和MinIO的生命周期策略对齐，避免误删数据
• MinIO侧提前开启批量删除、分片上传优化，关闭MinIO默认版本控制（若必须开启则版本保留周期和Iceberg快照保留周期保持一致），调大S3客户端连接数上限，避免压实过程中出现连接超时
• 所有压实操作先在测试环境同规模表验证，生产执行前设置合理的任务超时时间，若执行失败自动回滚，不影响线上查询

2. 重写操作选型：rewrite_data_files 还是 OPTIMIZE #

Iceberg 0.13版本中，Spark侧的rewrite_data_files存储过程和Trino侧的OPTIMIZE语法底层均调用Iceberg原生的文件重写逻辑，一致性能力一致，可根据场景选择：

• 大规模存量压实优先选Spark的rewrite_data_files：Spark分布式调度能力更强，适合大吞吐量的全量/大范围分区重写任务，性能更高
• 日常小批量增量压实可选Trino的OPTIMIZE：语法更简洁，适合调度轻量级的小范围重写任务
• 不建议使用自定义的手动合并文件逻辑，容易破坏Iceberg的ACID特性，出现数据一致性问题

3. 推荐目标文件大小 #

优先选择压缩后256MB的Parquet文件，适配绝大多数场景：

• 若业务以Trino即席查询为主，单表字段少、查询过滤性强，可下调到128MB，降低单文件扫描开销
• 若业务以Spark批量ETL为主，单表是超过200字段的宽表，可上调到512MB，减少任务调度开销
• 不建议设置超过1GB的目标文件大小，过大的文件会导致查询时IO瓶颈上升，且故障重试成本过高

4. 增量压实最佳实践（无需全量重写） #

核心思路是缩小重写范围，仅处理有小文件的分区/文件：

• 按分区筛选：若表按时间分区，每次仅重写最近N天的热分区，历史冷分区如果没有写入需求不需要重写；也可以先统计每个分区的小文件占比，仅重写小文件占比超过30%的分区
• 按文件大小筛选：重写时设置min_file_size阈值（比如100MB），只有小于该阈值的文件才会被纳入重写范围，已经符合大小要求的文件直接跳过
• 按写入时间筛选：每次重写仅处理上一次压实任务之后新产生的文件，不用重复处理已经压实过的历史文件
• 轻量级调度：把增量压实做成定时任务，每天低峰期执行一次，处理前一天新产生的小文件，避免小文件累积到需要全量重写的程度

5. Spark/Trino 执行配置与示例命令 #

Spark 侧配置与命令 #

核心配置（提前配置在Spark任务参数中）

# MinIO S3适配配置
spark.hadoop.fs.s3a.endpoint=http://你的MinIO服务地址:端口
spark.hadoop.fs.s3a.access.key=你的MinIO访问密钥
spark.hadoop.fs.s3a.secret.key=你的MinIO加密密钥
spark.hadoop.fs.s3a.path.style.access=true
spark.hadoop.fs.s3a.connection.maximum=1000
# Iceberg catalog配置
spark.sql.catalog.iceberg=org.apache.iceberg.spark.SparkCatalog
spark.sql.catalog.iceberg.type=hive
spark.sql.catalog.iceberg.uri=thrift://你的Hive Metastore地址:9083
spark.sql.catalog.iceberg.io-impl=org.apache.iceberg.aws.s3.S3FileIO
# 重试配置避免提交失败
spark.sql.iceberg.commit.retry.num-retries=5

执行命令示例

1. 全量重写整表（仅首次存量压实使用）

CALL iceberg.system.rewrite_data_files(
  table => '库名.表名',
  target_file_size_mb => 256
);

2. 增量重写指定时间范围的分区

CALL iceberg.system.rewrite_data_files(
  table => '库名.表名',
  where => 'dt >= "2024-05-01" AND dt < "2024-06-01"',
  target_file_size_mb => 256,
  min_file_size_mb => 100
);

资源建议

3亿行规模的表，建议分配20_{50个Executor，每个Executor配置4核8G内存，可在1}2小时内完成全量压实。

Trino 侧配置与命令 #

执行命令示例

1. 全量重写整表

OPTIMIZE 库名.表名
SET target_file_size = '256MB';

2. 增量重写指定时间范围的分区

OPTIMIZE 库名.表名
WHERE dt >= '2024-05-01' AND dt < '2024-06-01'
SET target_file_size = '256MB';

注意事项

大规模压实前调大当前会话的内存限制：SET SESSION query_max_memory = '64GB'; SET SESSION query_max_memory_per_node = '16GB';，避免任务OOM。

生产落地额外注意事项 #

• 压实完成后建议保留至少7天的快照，出现异常可随时回滚到压实前的版本
• 压实后间隔1~3天再执行快照过期和孤儿文件清理，释放存储空间：

-- 过期7天前的快照，至少保留最近10个快照
CALL iceberg.system.expire_snapshots(
  table => '库名.表名',
  older_than => TIMESTAMP '2024-05-01 00:00:00',
  retain_last => 10
);
-- 清理3天前的孤儿文件
CALL iceberg.system.remove_orphan_files(
  table => '库名.表名',
  older_than => TIMESTAMP '2024-05-05 00:00:00'
);

内容的提问来源于stack exchange，提问作者Sazzad Hossen