Cassandra/Spark读取性能优化：写入Oracle性能未达预期求助

首先得拆解下性能不升反降的核心可能——虽然你把Cassandra的单分区拆成了更小的桶，但大概率是读取端并行度没匹配上、Oracle写入的JDBC参数没适配新的分区逻辑，或是分桶后出现了隐性的数据倾斜。下面给你几个具体的排查和优化方向：

一、优化Cassandra读取的并行度与分区利用率 #

1. 确保Spark读取task与Cassandra桶分区一一匹配
   拆分桶后，要让Spark能精准感知每个小分区，避免一个task读多个小分区（浪费并行能力）或多个task抢一个大分区（负载不均）。可以通过调整spark.cassandra.input.split.size_in_mb参数，让分片大小和你的桶分区平均大小一致。比如你的桶平均是32MB，就把参数设为32：

   spark.conf.set("spark.cassandra.input.split.size_in_mb", "32")
   

2. 排查分桶后的数据倾斜问题
   计数器桶可能没完全均匀拆分数据，比如某些桶因业务高峰数据量远超其他桶。你可以在Spark UI的Stage页面查看每个task的输入数据量，如果差异超过2倍，就说明存在倾斜。
   解决办法：对倾斜的桶单独做局部repartition，或者在Cassandra端调整计数器步长，让每个桶的数据量更均衡。

二、优化Oracle JDBC写入的核心参数 #

这部分往往是Spark写入关系型数据库的瓶颈，即使读取端并行度够了，写入端跟不上也会拖慢整体速度：

1. 调大批量写入的批次大小并开启语句合并
   默认JDBC批次很小，你可以通过batchSize调至10000甚至更高（根据Oracle负载调整，别过载），同时开启rewriteBatchedStatements让驱动把批量插入合并为单条批量语句，大幅提升写入效率：

   val jdbcProps = new Properties()
   jdbcProps.put("user", "your_oracle_user")
   jdbcProps.put("password", "your_oracle_pwd")
   jdbcProps.put("batchSize", "10000")
   jdbcProps.put("rewriteBatchedStatements", "true")
   jdbcProps.put("driver", "oracle.jdbc.OracleDriver")
   

2. 匹配写入并行度与Oracle连接数限制
   Spark写入的并行度由读取后的分区数决定，但不能超过Oracle的最大连接数（避免连接池耗尽）。建议把写入并行度控制在Oracle允许连接数的70%左右，比如允许1000连接就设700个写入分区：

   df.write
     .option("numPartitions", "700")
     .jdbc("jdbc:oracle:thin:@//your_oracle_host:1521/your_db", "target_table", jdbcProps)
   

3. 使用Oracle官方高版本驱动
   优先用ojdbc8或更高版本的驱动，旧版本驱动可能不支持部分批量优化特性，还可能存在性能BUG。

三、调整Spark作业的资源配置 #

分桶后读取task数变多，如果集群资源没跟上，会导致task排队拖慢整体速度：

1. 合理分配Executor资源
   增加Executor数量，同时给每个Executor分配足够的CPU和内存，确保能并行处理多个task：

   spark-submit \
     --num-executors 20 \
     --executor-cores 4 \
     --executor-memory 8G \
     --driver-memory 4G \
     your_job.jar
   

2. 关闭不必要的shuffle与推测执行
   既然不需要手动repartition，就关闭Spark自动触发的不必要shuffle；如果task执行时间差异不大，关闭推测执行避免重复执行浪费资源：

   spark.conf.set("spark.speculation", "false")
   spark.conf.set("spark.sql.shuffle.partitions", "0") # 无shuffle场景下设置
   

四、其他辅助优化点 #

• 给Oracle目标表预分区：如果目标表没分区，建议按写入日期或Cassandra分桶键做分区，让Spark能并行写入不同的Oracle分区。
• 监控阶段耗时：在Spark UI的SQL页面查看读取和写入阶段的耗时占比，针对性优化瓶颈环节——比如如果写入阶段全部卡在数据库响应，就重点调优JDBC参数和Oracle的数据库配置。

按照上面的步骤逐一排查优化，应该能把性能拉回甚至超过之前400万条/小时的水平。

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