Spark Databricks 并发读S3小Parquet文件性能骤降问题咨询

核心结论 #

该场景下S3确实是核心性能瓶颈，小文件的高请求量特性叠加并发访问的资源竞争，是单独运行和并发运行耗时差异巨大的核心原因。

具体原因分析 #

• S3对象存储的访问特性：S3每次读取单个对象都需要发起独立的HEAD/GET请求，单作业读取2000个小文件就需要发起至少2000次IO请求，10个作业并发时总请求量飙升至2万次以上，会直接触发S3同前缀的默认请求限流（S3默认同前缀每秒支持3500次GET/HEAD请求），触发限流后的自动重试机制会大幅拉长整体耗时，即使作业读取的是桶下不同路径，只要路径前缀属于S3的同一分片范围，限流规则仍然生效。
• 身份认证开销放大：每个S3请求都需要携带Privacera令牌做鉴权，相当于每次IO请求额外增加了一次鉴权服务的往返开销，单作业运行时鉴权服务压力不大，并发跑满后鉴权服务的QPS瓶颈也会进一步拖慢请求响应速度。
• 缓存逻辑的额外开销：你当前使用df.cache().count()的逻辑，需要把所有小文件的全量数据拉取到集群内存落地缓存后再做计数，而不是仅读取Parquet文件的元数据统计行数，进一步放大了S3的IO请求量和带宽占用，并发场景下集群网卡、S3带宽都会出现资源争抢。

优化方案 #

1. 前置小文件合并：在Kinesis分钟级写入链路后，新增一个低优先级的微批次合并任务，例如每15分钟调用Databricks原生的OPTIMIZE命令对分区下的小文件做合并，目标文件大小控制在128MB~256MB，该操作不会影响写入链路的1分钟延迟要求，能将读请求量降低90%以上。
2. 调整计数逻辑：如果后续业务不需要提前缓存全量DataFrame，可将计数逻辑改为直接读取Parquet元数据统计行数：

spark.sql("SELECT COUNT(*) FROM parquet.`s3a://你的桶路径`")

不需要拉取全量文件内容，计数耗时可降低一个数量级。
3. 配置层面优化：开启Databricks的Parquet元数据缓存功能，配置参数spark.sql.parquet.metadataCache.enabled=true，减少重复的元数据请求；同时联系运维调整S3对应前缀的限流配额，以及Privacera鉴权服务的QPS上限。
4. 调度层面优化：对10个作业增加错开调度的启动延迟，避免同时发起大量S3读请求打满限流阈值。

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