Spark读取S3海量JSONL文件：列表作业优化及任务数调优问询

一、列表作业（List Job）耗时优化方案 #

针对12万文件的S3目录列表耗时2小时的问题，结合AWS EMR环境，可从以下方向优化：

1. 前缀拆分并行列表 #

如果S3目录的文件名有可拆分的规则（如首字母、ID段），直接指定多个前缀范围（例如s3://bucket/path/0*、s3://bucket/path/1*）让Spark并行扫描，避免单前缀全量扫描的瓶颈。即使没有物理分区，也可以通过逻辑拆分前缀实现并行列表。

2. 调优Spark与S3客户端参数 #

• 增大单次列表返回量：设置spark.hadoop.fs.s3a.list.max-items=10000（默认1000），减少S3 List API的调用次数，降低请求开销。
• 启用批量列表API：设置spark.hadoop.fs.s3a.list.bucket.enable=true，使用S3批量列表接口，提升列表效率。
• 优化Executor资源：当前m5.xlarge单节点有4vCPU、16GB内存，可调整spark.executor.cores=3、spark.executor.memory=12GB，让单个Executor同时处理更多列表任务，提升并行能力。
• 开启S3A客户端优化：设置spark.hadoop.fs.s3a.fast.upload=true，启用S3A的列表逻辑优化。

3. 利用EMR专属优化特性 #

• 启用EMRFS缓存：开启EMRFS Consistent View，它会缓存目录列表，重复运行作业时可直接复用缓存，避免重复扫描（首次运行仍需全量扫描，适合周期性作业）。

二、Spark列表任务数量的确定逻辑 #

Spark生成的列表任务数量由以下因素共同决定：

1. 文件总数：目录下文件越多，拆分的任务数越多。
2. spark.hadoop.fs.s3a.list.max-items：单次List请求返回的文件数越少，需要拆分的任务数越多。
3. spark.hadoop.fs.s3a.list.max-pending：控制同时发起的S3 List请求上限，间接影响任务并行数。
4. Executor资源：Spark会根据集群可用的Executor核心数，动态调整任务数量，确保资源被充分利用。

你看到的10000个列表任务，是Spark为了并行处理12万文件的列表请求，避免单个任务处理过多文件导致超时或效率低下而拆分的结果。

三、调整列表任务数量提升性能的方法 #

可以通过以下参数调整任务数量，适配你的EMR集群资源：

• 调大spark.hadoop.fs.s3a.list.max-items：比如设置为10000，减少任务总数，降低任务调度开销。注意不要设置过大，避免单个任务处理文件过多导致内存溢出。
• 调大spark.hadoop.fs.s3a.list.max-pending：比如设置为2000，允许同时发起更多List请求，提升并行度。但要注意AWS S3的API请求限制（默认每秒5500次），避免触发限流。
• 优化Executor核心数：增加每个Executor的核心数（如m5.xlarge设为3核），让单个Executor能同时处理更多列表任务，提升整体并行能力。

调整参数时建议小范围测试，结合集群资源和S3 API限制找到最优值，避免资源耗尽或被限流。

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