Spark从Teradata迁移至Dell ECS S3（Parquet格式）性能优化问询

问题背景 #

现有Spark集群配置为1个1GB Worker节点、2GB Driver节点，需将Teradata中的0.3GB数据集迁移至Dell ECS S3并以Parquet格式存储。测试发现单分区读取后直接写入耗时1分3秒为最优结果，而基于Business_Date的源端分区读取或目标端分区写入方案耗时更长，咨询当前资源下是否还有性能优化空间，或该结果已是性能上限。

当前方案的性能瓶颈分析 #

1. 集群资源限制：仅1个Worker节点意味着所有任务只能单线程执行，无法通过并行读取/写入提升性能。分区方案引入的多分区JDBC连接、数据shuffle、小文件写入等额外开销，反而抵消了并行带来的潜在收益，导致耗时增加。
2. 不必要的缓存开销：df.cache()会将全量数据加载到Worker内存中，对于0.3GB数据集来说，1GB Worker内存虽能容纳，但缓存过程本身会占用额外时间和内存资源，拖慢端到端流程。
3. JDBC读取默认参数限制：Teradata JDBC驱动默认fetchsize较小（通常为100），会导致频繁的网络往返，降低读取效率。

可尝试的优化点 #

1. 调整Spark内存与分区参数 #

针对小数据集和单Worker场景，减少不必要的shuffle分区数，优化内存分配：

# 提交作业时设置参数
spark-submit \
  --executor-memory 768m \  # 留部分内存给Worker系统进程
  --driver-memory 2g \
  --conf spark.sql.shuffle.partitions=8 \  # 远低于默认200，减少shuffle开销
  --conf spark.hadoop.fs.s3a.buffer.dir=/local/tmp \  # 用本地磁盘做S3写入缓冲
  your_script.py

2. 优化JDBC读取参数 #

增大fetchsize减少网络往返，去掉不必要的缓存：

df = spark.read.format("jdbc")\
    .option("user", "user_name")\
    .option("password","pwd")\
    .option("url","jdbc:teradata://servername/LOGMECH=TD2")\
    .option("driver","com.teradata.jdbc.TeraDriver")\
    .option("query","sql_query_for_source_table")\
    .option("fetchsize", 10000)  # 增大fetchsize提升读取速度
    .load()

filepath = 's3a://s3_bucket_name/prefix/tablename'

# 直接写入，跳过cache步骤
df.write.mode("overwrite")\
    .format("parquet")\
    .option("compression","snappy")\
    .save(filepath)

3. 优化S3写入配置 #

启用S3优化的输出提交器，减少写入时的网络开销：

# 新增S3提交器配置
--conf spark.sql.parquet.output.committer.class=org.apache.spark.sql.execution.datasources.parquet.ParquetOutputCommitter \
--conf spark.hadoop.fs.s3a.committer.name=directory

结论 #

当前集群资源（单1GB Worker）下，单分区方案的1分3秒已接近性能上限，但通过上述优化点（调整fetchsize、去掉缓存、优化Spark/S3参数），可小幅压缩耗时（预计能减少5-10秒左右）。若要获得更大性能提升，需增加Worker节点数量以实现并行处理，但受限于现有资源配置，单线程执行的瓶颈无法突破。

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