apache/seatunnel

[Feature][Hive/COS] 任务执行过程中，Rename操作时间过长，是否存在可优化空间？

Open

#9,231 opened on Apr 25, 2025

View on GitHub
 (5 comments) (0 reactions) (0 assignees)Java (6,897 stars) (1,432 forks)batch import
help wanted

Description

Search before asking

  • I had searched in the feature and found no similar feature requirement.

Description

Spark引擎执行过程中，所有的executors都执行完成后，Driver端会单线层执行rename操作，将数据文件从/tmp/seatunnel移动到最终目录。 这个rename的过程是单线程串行执行的，当文件数量多的时候这个过程是非常漫长的。特别是使用对象存储的时候，如COS,似乎也是基于同样的逻辑。

我有几个疑问和建议： 1、为什么设计时使用的是单线程串行的方式？是出于规避什么风险吗？ 2、如果要做优化的话，是否可以参考阿里的jindo oss commit 通过Multipart Upload的方式来实现？或者有更合理的方式推荐呢？

Usage Scenario

No response

Related issues

No response

Are you willing to submit a PR?

  • Yes I am willing to submit a PR!

Code of Conduct

Contributor guide

Tech stack
java
Domain
backendperformance
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
4
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
3-5 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
fresh
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
SeaTunnel basicsSpark execution modelObject storage concepts
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
Examine the rename logic in the Spark sink module (e.g., SeatunnelSparkSink or HiveSink) as shown in the screenshots. Investigate why the rename is single threaded and identify potential risks. Explore using multipart upload similar to Alibaba's Jindo SDK for COS, or consider parallel rename operations. Check repository issues and existing tests for related discussions.