优化Spark从Oracle读取并写入Parquet至S3的任务性能

一、JDBC读取阶段优化 #

• 精简查询字段：避免使用select *，只选择业务需要的列，减少数据传输量与内存占用。
• 优化JDBC读取参数：
  • 添加option("fetchSize", "10000")，增大JDBC批量读取大小，降低Oracle与Spark之间的网络往返次数；若表包含大字段（如CLOB/BLOB），额外添加option("oracle.jdbc.useFetchSizeWithLongColumn", "true")避免读取异常。
  • 利用Oracle分区表特性：如果table1本身按partition_col分区，修改查询语句为(select col1, col2... from table1 where c1>0 and partition_col between ? and ?)，让Oracle提前做分区裁剪，减少扫描的数据量。
• 验证分区数据分布：除行数均匀外，需检查每个分区的数据字节量是否均匀——部分任务耗时久可能是因为分区内存在大量大字段，导致单分区处理负载更高。

二、S3写入阶段优化 #

• 切换到Magic Committer：将spark.hadoop.fs.s3a.committer.name从directory改为magic，Magic Committer直接将文件写入最终S3路径，避免Directory Committer的文件重命名开销，大幅提升大文件写入的最终提交速度。
• 调整Parquet压缩与文件大小：
  • 设置spark.sql.parquet.compression.codec=snappy（默认配置，确认生效），在压缩比与写入速度间取得平衡；若存储成本优先，可尝试gzip但会增加CPU开销。
  • 调整spark.sql.files.maxPartitionBytes=256m，让每个写入分区对应256M原始数据，生成的Parquet文件大小更合理，减少小文件数量同时避免单个文件过大。
• 匹配写入并行度：根据读取的numPartitions调整写入分区数，确保每个Executor的任务负载均匀。例如800G数据按256M/分区计算，可设置写入分区数为3200左右（通过df.repartition(3200).write...），避免少数任务处理过大的数据块。

三、集群与运行时配置优化 #

• 调整Executor资源配比：当前2核80G的Executor配置内存冗余严重，推荐改为4核32G（总核数从40提升至80，并行度翻倍），或保持2核但将内存降至16-32G，释放的资源可增加Executor数量，提升整体并行处理能力。
• 开启推测执行：将spark.speculation=true，Spark会自动检测并重启执行缓慢的任务，避免个别慢任务拖垮整个Job的耗时。
• 优化S3连接配置：
  • 增大S3连接池大小：spark.hadoop.fs.s3a.connection.maximum=50，提升并发上传的连接数。
  • 调整S3上传线程数：spark.hadoop.fs.s3a.threads.max=100，加快多文件并行上传速度。
• GC参数优化：针对Executor配置调整GC参数，例如2核Executor设置：

  spark.executor.extraJavaOptions="-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:ParallelGCThreads=2 -XX:ConcGCThreads=1"
  

  避免因内存过大导致GC停顿过长，影响任务执行效率。

四、慢任务排查 #

• 查看慢任务的Executor日志，重点检查是否存在频繁GC、网络延迟（Oracle或S3连接超时）、大字段处理异常等问题。
• 监控Executor节点的网络IO、CPU使用率，确认是否存在节点资源瓶颈（如某节点磁盘IO过高、网络带宽被占满）。

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