Spark JDBC读取Oracle数据时作业长时间卡在单个任务

问题场景 #

使用Spark通过JDBC对接Oracle执行数据读取，实现代码如下：

df = spark.read \
.format("jdbc") \
.option("url", "{}".format(db_url)) \
.option("dbtable","({})".format(query)) \
.option("user","{}".format(db_username)) \
.option("numPartitions", 1000) \
.option("partitionColumn", "CD_CONVENIO") \
.option("lowerBound", int(ParameterBound['MIN'])) \
.option("upperBound", int(ParameterBound['MAX'])) \
.option("password","{}".format(db_password)) \
.option("customSchema", schema) \
.option("driver", "oracle.jdbc.driver.OracleDriver") \
.load()

本次查询预计返回约19.9万行数据，作业执行监控如下：

异常表现：作业运行过程中会长时间卡在某一个任务上，流程无法顺利推进完成。

根因分析 #

• 分区数设置严重脱离数据规模：总数据量仅19.9万时设置numPartitions=1000，单分区平均仅承载199条数据，过高的分区数会产生大量无效数据库连接开销，同时放大分区键倾斜的影响
• 分区键数据倾斜：如果CD_CONVENIO字段分布不均，会出现单个分区承载绝大多数数据、其余分区快速执行完成的情况，整个作业的耗时完全由这个超大分区决定
• 分片谓词无法下推：直接包裹自定义SQL作为dbtable时，如果子查询对分区键做了函数转换、结构不合理，Spark生成的分片范围条件无法下推到Oracle基表扫描层，会导致部分分片查询扫全表、无法命中索引，执行时间指数级上升
• 分区边界不匹配：如果传入的lowerBound/upperBound是全表极值而非本次查询过滤后返回数据的实际极值，会出现大量空分区和单个超大分区并存的问题，进一步加剧倾斜

修复方案 #

• 调整分区数适配数据规模：19.9万数据量将numPartitions设置为4_{10即可，单分区承载2}5万行是JDBC读取的合理粒度，既不会给数据库造成过大连接压力，也能避免分区粒度过细带来的倾斜放大问题，调整示例：

.option("numPartitions", 8)

• 校验分区键分布：提前在Oracle侧统计CD_CONVENIO的数据分布，如果单个字段值对应的数据占比超过总数据量的20%，更换分布更均匀的数值型字段（如主键ID、数值型时间戳字段）作为分区键，分布检查SQL参考：

SELECT CD_CONVENIO, COUNT(1) as row_cnt 
FROM 业务表
-- 需添加和读取逻辑完全一致的过滤条件
GROUP BY CD_CONVENIO
ORDER BY row_cnt DESC

• 适配谓词下推规则：自定义子查询必须直接暴露原始CD_CONVENIO字段，不要在子查询中对该字段做函数运算、类型转换，保证Spark生成的分片范围条件可以被Oracle解析，命中基表索引
• 校准分区边界：ParameterBound中存储的MIN/MAX值必须是本次查询过滤后结果集的CD_CONVENIO实际极值，不能直接取全表极值，避免分区范围和实际数据分布错位
• 补充JDBC稳定性参数：添加fetchSize和读取超时配置，避免连接长时间无响应挂死：

.option("fetchSize", "10000")
.option("oracle.jdbc.ReadTimeout", "300000")

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