Spark读取非分区Delta表并行度优化与CPU低利用率问题咨询

1. 读取阶段任务数与表分区数的关系 #

你的部分认知成立，但需分场景细化：

• 分区表：无过滤条件时，读取阶段Spark生成的任务数与表的物理分区数直接对应。比如一张按日期分100个区的表，全表扫描会生成100个读取任务；若添加分区过滤（如where dt='2024-01-01'），任务数等于命中的分区数量。
• 非分区表：任务数由底层文件大小、spark.sql.files.maxPartitionBytes（默认128MB）、spark.sql.files.openCostInBytes（默认4MB，用于衡量文件打开开销，控制小文件合并逻辑）共同决定。Spark会将连续小文件合并为单个分区，最终任务数≈总数据量/maxPartitionBytes（受小文件合并规则影响）。

2. spark.sql.shuffle.partitions对读取阶段的影响 #

该配置完全不作用于读取阶段。它仅控制shuffle类操作（如join、group by、distinct等宽依赖转换）的输出分区数，和非分区表的读取任务数没有任何关联，即便设为200，也不会直接生成200个读取任务。

3. 调整spark.sql.files.maxPartitionBytes无性能提升的可能原因 #

你调整参数后未看到效果，大概率是以下因素导致：

• 小文件过多：若非分区表由大量极小文件（如几KB级）组成，Spark会优先依据spark.sql.files.openCostInBytes合并小文件，即便缩小maxPartitionBytes，合并后的分区数也不会明显增加。
• 集群资源未饱和：若Executor总核数（spark.executor.cores * spark.executor.instances）远小于集群的96核，或spark.task.cpus（默认1）设置不合理，即便增加读取任务数，也无法充分利用CPU资源，并行度上不去。
• 瓶颈不在读取阶段：若读取阶段耗时占比极低，性能瓶颈出现在后续转换、shuffle或写入环节，提升读取并行度无法带动整体性能。需查看作业Stage耗时分布，确认瓶颈位置。
• 存储层IO限制：若底层存储（如对象存储）的IO带宽不足，即便增加读取任务数，也无法提升吞吐量，CPU利用率自然无法提高。

额外优化建议 #

• 处理非分区表小文件：先通过OPTIMIZE（Databricks环境）或手动合并小文件，减少文件数量后再调整maxPartitionBytes，才能有效增加分区数。
• 匹配集群资源配置：设置spark.executor.instances=12、spark.executor.cores=8（总核数96），确保Executor总核数接近集群可用核数，同时保持spark.task.cpus=1，让单个任务占用1核。
• 分析Stage详情：在Databricks作业UI查看各Stage的任务数、耗时分布，精准定位瓶颈后再针对性优化。

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