Spark JDBC分区读取首尾分区数据倾斜问题及解决方案

是，这完全是Spark JDBC默认分区机制的预期表现，不是功能bug。
Spark JDBC默认分区逻辑是基于用户手动传入的lowerBound、upperBound、numPartitions三个参数做等宽区间切分，整个切分过程不会主动查询分区列的实际极值、值分布、数据频数，切分规则完全固定：

1. 先计算固定步长：stride = (upperBound - lowerBound) / numPartitions
2. 按步长生成numPartitions个分区的查询过滤条件：
   • 第1个分区：拉取满足partitionColumn < lowerBound + stride的全量数据
   • 中间分区（第2到第numPartitions-1个）：拉取满足lowerBound + i*stride <= partitionColumn < lowerBound + (i+1)*stride的区间数据
   • 最后1个分区：拉取满足partitionColumn >= lowerBound + (numPartitions-1)*stride的全量数据
     你观测到的首尾分区数据量远大于中间分区的情况，本质是传入的lowerBound、upperBound和分区列的实际最小、最大值不匹配：所有落在第一个区间左侧的17个取值全被划入第一个分区，所有落在最后一个区间右侧的17个取值全被划入最后一个分区，中间区间刚好被等步长切分为30份，每份对应3个取值，和你贴出来的分配结果完全吻合。

不需要反复调试numPartitions取值，可根据实际场景从以下三类方案中选择：

• 自定义分区谓词（通用性最强，均匀性最好）
  先发起一个轻量JDBC查询获取分区列的实际分布分界点：比如执行百分位聚合查询，拿到按实际数据行数均分的分界点列表，手动构造每个分区的where过滤条件，调用JDBC读取方法时直接传入predicates参数，替代默认的numPartitions/partitionColumn/upperBound/lowerBound配置。这种方式完全按实际数据分布切分，不管分区列取值怎么动态变化、是否存在数据倾斜，都能保证每个分区的数据量基本一致，对数值、字符串、日期等所有可比较类型的分区列都适用。
• 动态查询实际极值（轻量无shuffle，适合分布均匀的递增列）
  如果分区列是自增ID、时间戳这类取值连续、分布均匀的字段，可以先执行两个轻量聚合查询拿到分区列的实际最小、最大值，直接作为lowerBound和upperBound传入即可。这个方案没有额外shuffle开销，也不需要手动维护上下界参数，但无法解决分区列本身数据分布倾斜导致的分区不均问题。
• 读取后二次重分区（实现最简单，适合中小数据量场景）
  如果数据量不算特别大，可以直接按默认逻辑读取DataFrame后，调用df.repartition(numPartitions, partitionColumn)做一次重分区，Spark会按分区列的哈希值自动把数据均匀打散到指定数量的分区中。这个方案代码改动最小，但会额外产生一次Shuffle开销，不适合TB级以上的超大数据集。

内容的提问来源于stack exchange，提问作者Kombajn zbożowy