配置SparkSQL的分块个数（即shuffle分区数）是优化作业性能的关键一步，通常建议设置为集群CPU核心数的2-3倍，并需根据数据量和执行计划动态调整。
什么是SparkSQL的分块个数
在SparkSQL中,分块个数指的是shuffle分区数，它决定了数据在集群中重新分布时的并发粒度，当你执行join、groupBy或distinct等操作时，Spark会触发shuffle，将数据按照key打散到不同分区中并行处理，这个参数由spark.sql.shuffle.partitions控制，默认值为200。
分块个数直接影响作业的并行度、内存压力和文件输出大小，设置过小会导致单个任务处理数据量过大，容易引发OOM；设置过大会产生大量小文件，增加调度开销，理解它的本质，是后续调优的基础。
SparkSQL分块个数设置多少合适
这是每个Spark使用者都会遇到的问题,答案并非固定数字，而是取决于以下因素：
- 集群规模：可用的CPU核心总数（vCores）是基础参考值，一般认为，分区数设置为核心数的2-3倍能保证CPU充分利用且调度开销可控。
- 数据量大小：单个分区处理的数据量建议在100MB-1GB之间，如果数据量较大，分区数应相应增加，避免单个任务处理过久。
- shuffle复杂度：涉及多表join或大聚合时，分区数需要足够多以避免数据倾斜，但也不能过多导致小文件问题。
实操建议：对于大多数生产作业，可以先从核心数的2倍开始尝试，观察任务执行时间与资源利用率，再逐步调整，比如你有一个10节点、每节点32核的集群，总核心数320，初始分区数可设为
640或960。
SparkSQL分区数配置对比：固定值与动态调整
传统上,用户通过spark.sql.shuffle.partitions设置一个固定值，整个作业都使用这个数值，但自Spark 3.0起，自适应查询执行（AQE）提供了动态调整能力，让分区优化更加智能。
| 配置方式 | 设置方法 | 优点 | 缺点 |
|---|---|---|---|
| 固定值 | spark.sql.shuffle.partitions=500 |
简单直接，行为可预测 | 无法适应不同阶段的数据量变化，容易造成资源浪费或性能瓶颈 |
| 动态调整 | 开启AQE并设置spark.sql.adaptive.coalescePartitions.enabled=true |
根据shuffle输出自动合并小分区，减少任务数，提升稳定性 | 需要额外配置，对极端倾斜场景仍需手动干预 |
行业共识认为，对于长周期ETL作业，动态调整能显著减少小文件问题，平均性能提升20%（据Spark官方社区经验数据），而对于交互式查询，固定值配合经验设置更为直接。
如何启用动态分区合并
在spark-submit中添加以下配置：
--conf spark.sql.adaptive.enabled=true --conf spark.sql.adaptive.coalescePartitions.enabled=true --conf spark.sql.adaptive.coalescePartitions.minPartitionNum=10
当AQE检测到某个stage的输出分区数据量过小时,会自动将相邻分区合并，使最终分区数保持在合理范围内，这一机制与手动设置spark.sql.shuffle.partitions
并不冲突，后者在AQE关闭时生效，开启后则作为初始分区数。
如何根据场景调整分块个数
不同业务场景对分块个数的要求差异很大,下面列举几个典型场景及配置策略。
数据倾斜场景下SparkSQL分块个数调整
数据倾斜是分布式计算的常见难题,当某个key对应的数据量远超其他key时，该分区任务会成为长尾，拖慢整体进度，此时单纯增加分区数效果有限，必须结合倾斜处理方案。
- 增大分区数：将
spark.sql.shuffle.partitions提高到核心数的4-5倍，尽可能分散热点key。 - 开启AQE倾斜优化：设置
spark.sql.adaptive.skewJoin.enabled=true，Spark会自动将倾斜分区拆分为多个子分区。 - 手动加盐：对倾斜key添加随机前缀，再通过两次聚合实现负载均衡。
注意：增加分区数会带来更多网络开销和任务调度压力，建议在倾斜程度不严重时优先使用AQE自动处理。
小文件输出场景
写入Hive或HDFS时,如果分区数过多，会产生大量小文件，影响后续读取效率，应对策略：
- 使用AQE动态合并分区,减少输出文件数量。
- 在写入前通过
coalesce或repartition控制分区数，例如df.coalesce(100).write.parquet(...)。 - 设置
spark.sql.shuffle.partitions为一个较小值，但需保证shuffle阶段不OOM。
实操参数：spark.sql.adaptive.coalescePartitions.parallelismFirst=false可让Spark优先考虑文件大小而非并行度，从而生成更少的大文件。
大查询与交互式查询
对于单次扫描大量数据的SQL,分区数应略高以充分利用集群资源，而对于多次迭代的交互式查询，稳定的分区数反而更关键，避免每次执行计划不同导致响应时间波动。
- 批处理：分区数可设为核心数的3-4倍，配合动态分区合并。
- Ad-hoc查询：固定分区数，如核心数的2倍，并关闭AQE（或保持开启但设置较小最小分区数）。
常见问题解答（Q&A）
SparkSQL分块个数和并行度有什么区别
并行度（spark.default.parallelism）用于RDD操作，而spark.sql.shuffle.partitions专门控制SparkSQL的shuffle分区数，两者在SparkSQL中并不等价，SQL任务默认使用后者，如果混用，可能出现预期不符，建议SQL作业统一使用SQL专用参数。
分块个数设置过大有什么坏处
分区数过多会导致每个任务处理的数据量过小,任务调度开销占比增大，同时产生大量小文件，给下游存储和读取带来压力，极端情况下，Driver端会因任务元数据过多而内存溢出，因此分区数并非越大越好，需要根据实际数据量权衡。
如何查看当前作业的分块个数
在Spark UI的SQL选项卡中，每个Stage的详细信息会显示分区数量，你也可以在代码中通过spark.conf.get("spark.sql.shuffle.partitions")获取当前值，对于运行中的作业，可通过日志或监听器实时查看。
SparkSQL分块个数的配置没有银弹，核心在于理解数据与集群的规模关系，善用动态调整机制，并结合实际场景反复验证。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/543252.html
