如何优化 S3 写入以避免 Apache Iceberg 的限制？

Question

我正在处理大型数据集，写入 S3，并面临限制问题（503 错误）。尽管我们使用的是 Apache Iceberg 表格式，但我们的挑战似乎在某种程度上独立于 Iceberg 本身。

为了缓解这一问题，我们开始通过在 S3 存储桶名称后面添加键前缀来对数据进行分区，旨在减少限制发生。尽管做出了这些努力，我们的摄取服务仍然遇到 503 错误，这让我质疑我们的前缀策略的有效性。

具体来说，我很好奇 S3 如何管理键前缀确定。它是按路径分隔符（斜杠 /）对键进行分组，还是逐个字符地评估前缀？我们的方法涉及哈希函数和 base64 编码，它经常在键前缀中包含破折号 (-)，可能会影响数据如何分类到限制桶中。如果前缀分组是基于每个字符完成的，则可能可以解释由于数据被汇集到同一存储桶中而导致的持续限制问题。

有人了解 S3 的前缀分组在这种情况下如何工作吗？

以下是文件在我的存储桶的根级别下的显示方式；

参见：

• https://www.youtube.com/watch?v=rHeTn9pHNKo&t=3219s
• https://repost.aws/knowledge-center/http-5xx-errors-s3

Answer 1

感谢您与我们联系。

为了给出更准确的答案，最好知道您如何写入 Iceberg 表。

首先要检查的一件事是确保

write.object-storage.enabled

属性设置为 true。这将确保对象分布在前缀中。

更根本的是，最好查看您正在编写的 Parquet 文件的大小。如果您有 CDC 类型的工作负载，并且有很多编写器编写小型 Parquet 文件，那么这将是一个问题。如果文件很小，则必须执行多个请求才能写入一小部分数据，这会大大增加请求数量。

对于事物的阅读方面。这一点更为重要，因为大数据工作负载最有可能遵循一次写入、经常读取的模式。确保定期压缩数据非常重要。这既适用于存储在 Avro 中的 Iceberg 元数据，也适用于数据文件本身（很可能是 Parquet）。可以通过 Spark 使用

rewrite_manifests

过程来优化元数据。这会将小清单组合成更大的清单，从而减少读取时的请求数量。最好先运行

rewrite_data_files

，然后如上所述运行

rewrite_manifests

，然后运行

rewrite_orphan_files

。

如果您不想关心这些东西，还有商业供应商，例如Tabular，可以确保您的 Iceberg 桌子处于原始状态。