如何管理 AWS 中呈指数级增长的 Apache Iceberg 元数据？

Question

我担任开发人员已经十多年了，但我对数据工程还是个新手。我在 AWS Glue 和 S3 中设置了几个 Iceberg 表。我已经将生产数据复制到这些表了几周（每天大约 100k-300k 插入），发现我们的 S3 存储大小正在爆炸式增长。经过一番分析，99% 的存储都是元数据。在最坏的情况下，一张表只有 13GB 的实际数据和 66TB 的元数据（我很快清空了该存储桶）。其他几个存储桶有 200 MB 到 2GB 的数据，但仍然有 5TB 到 7TB 的元数据。

Iceberg 如此快地积累元数据正常吗？或者这只是每天有这么多插入的一个因素？

我尝试在 Athena 中运行“OPTIMIZE table”查询，该查询是从 Athena 文档中获取的，但它只扫描大约 2GB，每次运行需要 30 分钟，这对于手动处理 5TB 来说太慢了。经过几天的谷歌搜索和阅读文档后，我仍然觉得自己没有取得任何进展。有人如何管理这些东西？说真的，任何反馈、建议或链接都值得赞赏。

谢谢！

Answer 1

您多久向 Iceberg 表写入一次。每次插入都会生成新的元数据，因此如果可能的话最好批量插入。

每次插入后都会创建一个新快照。快照将链接到现有数据和新数据。有时，您想按照您已经建议的方式运行

OPTIMIZE

来重写数据。这会将 Parquet 文件压缩成更大的文件。

您需要定期运行的另一项作业是

VACUUM

。这将使旧快照过期并删除数据和元数据。运行

VACUUM

将限制 Iceberg 提供的时间旅行，因为旧数据将被删除。快照何时过期可以通过表属性设置。

这里缺少的是元数据的实际压缩。这可以通过 Spark

使用 rewrite_manifests

 程序

来完成。这将合并小清单。最好先运行 rewrite_data_files，然后如上所述运行 rewrite_manifests

，然后运行 

rewrite_orphan_files。我知道人们按计划在 lambda 内运行 Spark 来维护他们的 Iceberg 表。

如果您不想关心这些东西，还有商业供应商，例如

Tabular，可以确保您的 Iceberg 桌子处于原始状态。

希望这有帮助！如果您还有任何疑问，请告诉我。