相同Spark作业在多AWS EMR实例并行运行的性能问题排查

一、S3写入是可能的瓶颈来源 #

结合你给出的作业细节，多实例并行写入S3时的性能损耗主要来自以下几点：

• S3请求限流：S3对单个存储桶的请求速率有默认阈值（PUT/POST/DELETE类请求3500次/秒，GET类5500次/秒）。多实例并行写入不同分区时，大量文件创建、写入、提交请求会集中打向同一存储桶，触发限流导致请求排队，直接拉长耗时。
• 分区目录竞争：即使写入不同分区，多个作业同时操作同一存储桶的元数据（如创建分区目录、更新目录列表）会产生隐性锁竞争，再加上S3的最终一致性特性，部分目录操作需要重试，增加额外开销。
• 分桶表的放大开销：中间分桶表需要按规则进行shuffle操作，多实例环境下跨节点数据传输的延迟会被S3的远程存储特性放大，若分桶数量配置不合理，这种开销会更显著。

二、Glue元数据更新也会导致性能下降 #

Glue Catalog的元数据操作存在并发限制，直接影响多实例并行作业的效率：

• 并发请求限流：Glue对ALTER TABLE ADD PARTITION这类元数据操作有并发请求限制，多个作业同时提交更新请求时会被排队处理，每个作业都需等待前一个请求完成，导致整体耗时显著增加。
• 元数据同步等待：Spark更新Glue元数据后，多实例环境下需要等待元数据同步到所有节点，若作业依赖最新元数据执行后续操作，会出现阻塞等待的情况。

优化方向参考 #

S3写入优化 #

• 调整Spark参数spark.sql.files.maxRecordsPerFile，增大单文件记录数，减少小文件数量，降低S3请求频率；
• 将不同作业的输出分散到同一存储桶的不同前缀下，缓解单个存储桶的请求压力；
• 合理设置分桶表的分桶数量，尽量让分桶数据在单节点内处理，减少跨节点shuffle。

Glue元数据优化 #

• 批量提交元数据更新，比如将多个分区的添加操作合并为一条ALTER TABLE ADD PARTITION命令，减少请求次数；
• 若作业不依赖实时元数据，可将元数据更新操作放到所有作业完成后统一执行，避免并行请求竞争。

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