AWS Glue执行MERGE INTO时遇S3Exception请求速率过高问题求助

实用优化方案 #

1. 控制Glue作业的并发请求量 #

• 下调worker配置：当前用150G 2X worker，高规格worker会带来高并发请求。先尝试减少worker数量（比如降到80以内），或者换成标准worker，降低单批次的S3请求密度。
• 配置Spark参数限制S3并发：在作业的Spark配置里添加以下参数，直接控制请求速率：
  • spark.sql.shuffle.partitions：设为512（和现有分区数匹配或略低，避免shuffle产生过多小任务）
  • spark.hadoop.fs.s3a.max.total.concurrent.requests：设为800（全局S3请求上限）
  • spark.hadoop.fs.s3a.max.concurrent.requests：设为400（每个bucket的请求上限）

2. 优化Iceberg MERGE的执行范围 #

• 只MERGE目标分区：CDC数据是增量，先过滤出本次需要更新的分区，在MERGE语句里加上分区过滤条件，比如WHERE iceberg_table.partition_col IN (SELECT DISTINCT cdc.partition_col FROM cdc_data)，避免全表扫描所有1024个分区的文件。
• 拆分CDC批次：把大份的CDC数据拆成多个小批次，分批次执行MERGE，比如按时间拆分，每次只处理1小时的CDC数据，降低单次请求压力。
• 清理Iceberg元数据：开启元数据自动清理，设置Iceberg表属性：
  • write.metadata.delete-after-commit.enabled=true：提交后删除旧元数据文件
  • write.metadata.previous-versions-max=3：只保留最近3个版本的元数据，减少元文件数量

3. 优化Iceberg表的文件结构 #

• 合并小文件：全量导入作业里设置spark.sql.adaptive.advisoryPartitionSizeInBytes=134217728（128MB），让写入的Iceberg文件大小控制在64-256MB之间，减少小文件数量——小文件越多，S3请求次数越高。
• 检查热点分区：如果某几个分区数据量远大于其他，MERGE时会集中访问这些分区的文件，导致请求突增。可以把热点分区拆成更小的子分区，或者单独处理这些分区的CDC数据。

4. 调整分区策略 #

• 增加二级分区：在原有分区键的基础上，再加一个低基数的分区列（比如日期），把1024个大分区拆分成更多小分区，分散S3的请求压力，避免单个分区被频繁访问。

验证建议 #

1. 先拿小批量CDC数据测：调整配置后，用少量数据跑MERGE，看是否还触发S3速率超限。
2. 看CloudWatch日志：定位是元数据请求还是数据文件请求超限，针对性调整参数。
3. 检查Iceberg表文件：用Glue数据目录查看表的文件分布，确保文件大小在合理范围。

内容的提问来源于stack exchange，提问作者Andrei Burlacu