用datax卸数：从oss卸数到ftp，多文件卸数卡死

DataX 从 OSS 卸数到 FTP，多文件大文件任务卡死但不报错的原因与处理

这个现象本质上不是 DataX 本身卡死，而是 下游 FTP 在多并发 + 大文件场景下被“拖住”了，DataX 没有及时感知失败。

先说结论：

6 个 16G 文件 + Channel=6 的组合，已经把 FTP 端的并发、带宽或连接数顶满了，
DataX 线程在等待 FTP 写入 ACK，表现为“无反应、不报错”。

同样配置下 10G 文件能跑通，本身就是一个非常典型的信号。

一、为什么“卡住但不报错”

DataX 的执行模型决定了它在这种场景下很容易“假死”。

1. Channel ≠ 文件数，而是并发写线程数

你现在的配置是：

6 个文件

Channel = 6

在 OSS → FTP 的 writer 场景下，实际效果是：

同时 6 个线程

每个线程在持续向 FTP 推送大块数据流

这会同时消耗：

FTP 最大连接数

FTP 服务器 I/O

网络带宽

目标磁盘写入能力

1. FTP Writer 对“慢写入”的容错很差

在 DataX 的 ftpwriter 中：

只要 socket 连接还在

没有显式返回 error

写线程就会一直阻塞等待

于是你看到的现象是：

JobContainer 不退出

日志不报错

任务看起来“卡死”

实际上线程全在 等 FTP 写完数据。

1. 为什么 10G 能跑，16G 不行

这通常说明 临界点已经被你踩到了，比如：

FTP 服务端：

单连接限速

最大并发连接数

写磁盘 I/O 饱和

网络侧：

出口带宽被 6 路大文件长期占满

FTP 超时参数设置偏大，连接不被主动断开

16G × 6 并发，本质上是 持续高压写入，不是瞬时问题。

二、最常见、也最有效的解决方式

不兜圈子，直接给可用方案。

✅ 方案 1：降低 Channel 数（最优先）

不要让 Channel = 文件数。

建议：

Channel 改为 2 或 3

让文件排队写，而不是同时压 FTP

这是性价比最高的改法。

"setting": {
"speed": {
"channel": 2
}
}

✅ 方案 2：限制单通道带宽（如果版本支持）

如果 DataX 版本支持 byte 限速：

"speed": {
"channel": 3,
"byte": 52428800
}

等价于：

降低单线程写压力

避免 FTP 端被打满后“半死不活”

⚠️ 方案 3：拆批执行，而不是一次性跑完

与其：

6 个 16G 一起跑

不如：

每次跑 2～3 个文件

用调度控制顺序

这是很多生产环境的常规做法。

❌ 不建议的方向

反复调大 Channel（会更早卡死）

指望 DataX 自动报错（它不会）

只看 DataX 日志，不看 FTP 服务端日志

三、如何快速验证是不是这个问题

给你一个很“工程”的验证方式：

Channel 改成 1

只跑一个 16G 文件

如果能稳定跑完

那问题100% 在并发 + FTP 承载能力，不是 OSS，也不是 DataX bug。

总结一句话

DataX 在大文件 + 多并发 FTP 场景下，很容易出现“阻塞不报错”的假死状态。
解决思路不是“调大”，而是：降并发、限速、分批。

这是一个老问题，不是你配置错了，是默认配置太“乐观”。