做数据集成的工程师手上通常已经有几台服务器，真正的困惑不在"装不装得上"，而在"这台机器到底扛得住几个同步作业"。SeaTunnel（原 Waterdrop）是一个独立的分布式数据集成引擎，既可以用自带的 Zeta 引擎跑，也可以提交到已有的 Flink 或 Spark 集群上执行。它不是常驻的 connector 框架，也不是一条 mysqldump 命令。把并发度、内存缓冲、脏数据落盘、出网带宽、checkpoint 与源端影响这六件事拆开讲清楚，机器选型才有依据。本文按这个路径展开，并给出三档机器形态的六维对照表与九条避坑清单。
先把位置说清楚。Kafka Connect 这类框架的模型是"常驻 worker + 常驻 connector"：进程一直在跑，靠 offset topic 记录进度，靠 REST 接口管理，任务生命周期是长期运行。SeaTunnel 的模型更接近"提交一个作业，引擎负责把作业切成多个 task 并调度执行"。用 Zeta 引擎时，集群由 master 节点做作业解析、切分与调度，worker 节点跑具体 task；如果已经有一套 Flink 或 Spark，也可以把 SeaTunnel 作为作业提交上去，由 Flink 或 Spark 承担调度与容错。
这个差别对服务器选型的影响很大。常驻 connector 的机器是"永远占着"的，内存和连接数按峰值常驻；SeaTunnel 的批同步作业是"窗口内占着"的，跑完就释放。于是同一台机器上可以错峰跑多个作业，但错峰排布做不好，就会在凌晨两三点出现 CPU、内存、网络三样同时打满的情况。
再说说它跟"导出再导入"的本质区别。导出脚本是单线程、单连接、无切分、无容错、无位点：一张 2 亿行的表 dump 出来可能要几个小时，中途断了只能重来，源库上还挂着一条长事务。SeaTunnel 这类引擎的核心价值，在于把一张表横向切成很多块（chunk），并行读、并行写、失败只重跑失败的块，并且能把"读到哪了"这件事持久化下来。
增量同步有两种做法，它们对源库和本机资源的消耗模式完全不同，选错的话会出现"同步从来没报错，但业务库每天下午卡一次"这种很难归因的问题。
第一种是 CDC 模式，读 MySQL 的 binlog 或 PostgreSQL 的 WAL。源端只需要一条（或少量）日志拉取连接，对源库几乎不产生 SELECT 压力。它的代价在别处：源库必须开启日志且保留足够长时间，作业停机超过日志保留期就只能重新全量；快照阶段要做一次全表扫描，某些数据库在快照瞬间需要全局一致性，锁表时间过长会让业务写入报错。CDC 的另一个好处是能抓到物理删除——源端 delete 掉的行，目标端可以跟着删。
第二种是按时间戳或自增 ID 轮询。每次轮询都在源库上执行一批区间查询，压力等于"并发度 × 分片数 × 轮询频率"。它要求 update_time 或自增主键上有可用索引，否则每次轮询都是一次全表扫描。它抓不到物理删除，源端删掉的行在目标端会一直留着，做对账时表现为"目标比源多"。它还有一个隐蔽的边界问题：同一秒内有多条记录变更，且时间戳精度只到秒，下一次轮询的起点如果按"上次最大时间戳"算，就会漏掉同一秒里没被取走的行；按"上次最大时间戳减一格"算，又必然重复。
并发度是 SeaTunnel 里最容易被误用的参数。很多团队把它理解成"线程数"，觉得机器核数多就往上加。实际上每调高 1 个并发，机器上会多出这么几样东西：一条到源库的独立 JDBC 连接、一份读缓冲、一份写缓冲、一个行对象的反序列化上下文，以及到目标端的一条连接。源库侧则多出一个并发查询会话、一份排序或扫描的临时空间。
把账算细一点。假设一个作业并发度设为 8，源库是 MySQL，那么源库上同一时刻至少挂着 8 个连接，每个都在跑一条针对某个主键区间的 SELECT。如果这台机器上还并行跑了 3 个作业，源库侧就是 24 条并发查询。MySQL 的 max_connections 默认值普遍在 151 左右，业务本身还要用掉一大半，留给同步的可能只有三四十条。这就是为什么"并发度照抄默认值"在测试库上没问题，上了生产就把源库拖垮。
并发度调小的代价同样明确：同步窗口拉长。一张 500GB 的表，单 task 顺序读的吞吐受限于单连接的网络与源库扫描速度，假设稳定在 40MB/s，跑完需要约 3.5 小时；拆成 8 个 task 后理想情况下能压到 30 分钟以内，但并发上升后源库侧的随机 I/O 会同步增加，加速比通常是次线性的——8 倍并发可能只拿到 4 到 5 倍的提速.
切分策略决定了并发度到底加在了哪里。按表切分是最朴素的做法：每张表一个 task，或者每张表若干 task。它的好处是边界清晰，一张表出问题不影响别的表；坏处是严重的倾斜——系统里通常有几张日志表、几张流水表占了 90% 的数据量，剩下几百张维表加起来不到 1%。按表切分时，那几张大表的 task 会跑几个小时，别的 task 早就空转退出了，整体窗口由最慢的那张表决定。
按主键区间切分是把单张表切成 N 段。引擎会先探测主键的最小值与最大值，或者按配置的切分字段和切分大小估算边界，然后每个 task 负责一段。这种切法能真正把大表的压力摊开，但它对源库有额外要求：主键或切分字段上必须有索引，否则每一段都是一次全表扫描，N 段就是 N 次全表扫描，压力比不切还大。切分字段如果分布不均，比如按自增 ID 切而中间有大段空洞，或者按某个状态字段切而某个状态占了 80% 的行，就会出现大部分 task 几秒跑完、一两个 task 跑几小时的极端倾斜。
还有一种常被忽略的情况：主键是字符串或 UUID。按 UUID 切分几乎必然倾斜，因为 UUID 的分布虽然均匀，但范围查询在 B+ 树上的局部性很差，每一段都是随机 I/O，源库缓冲池命中率会掉得很明显。这种表更适合按创建时间做区间切分，或者干脆按天做分区级切分。
内存问题很少表现为"整体不够用"，更多表现为"某个 task 突然膨胀"。每个 task 的内存占用大致由四部分组成：读缓冲（一次从源库取回的结果集）、行对象（反序列化后的 Java 对象或 Row 结构）、写缓冲（攒批等待 flush 到目标端）、以及序列化与压缩的临时空间。前三项都跟单行的大小成正比，而单行大小恰恰是最容易被低估的量。
举个例子：一张 200 列的用户行为宽表，其中有几个 TEXT 字段存放 JSON 原文，平均行长 8KB。读缓冲一次取 1000 行就是 8MB，行对象膨胀系数按 2 到 3 倍算就是 16 到 24MB，写缓冲再攒 1000 行又是 8MB 以上。单个 task 轻松超过 50MB。并发度开到 16，光缓冲就接近 1GB，再加上引擎自身的元数据结构和堆外内存，一台 16G 的机器会非常紧张。这就是为什么"内存给大"经常不如"并发拆细"——把批大小从 1000 行降到 200 行，单个 task 的峰值内存降到五分之一，而吞吐往往只损失几个百分点，因为瓶颈根本不在缓冲深度上。
大字段还有一个更麻烦的特性：它不是均匀的。平均行长 8KB 的表里，可能有 0.1% 的行是 5MB 的异常报文。这一类长尾行会让某个 task 的瞬时内存冲到平均值的几十倍，触发 OOM。处理方式通常有两种：一是在源端 SQL 里限制大字段的截取长度，二是在作业里设置单行的大小上限，超出的行直接进入脏数据通道而不是继续留在堆里。
堆外内存也需要单独关注。不少连接器使用堆外缓冲来减少 GC 压力，这部分不受 Xmx 控制，靠的是引擎自身的内存模型和直接内存上限。机器层面只看到"进程 RSS 一直涨"却查不到堆内异常时，多半是堆外在增长，此时调大堆内参数毫无作用，反而挤压了堆外的可用空间。给 SeaTunnel 分配内存时的稳妥做法是堆内与堆外一起算，并给操作系统和页缓存留出至少 20% 的余量。
同步作业里"失败的那一行"比"失败的那个作业"更常见。类型转换失败（源端 varchar 里混进了非数字，目标端是 bigint）、主键冲突（同一主键在源端有两行，或者重跑导致重复写入）、字段超长（源端 500 字符，目标端 255）、目标端约束不满足（非空字段收到 NULL）、源端记录在读取过程中被删除——这些都是行级错误，不是作业级错误。
行级错误通常有三条出路。第一条是丢弃，配一个容错阈值，比如允许 1% 或者 100 行以内的错误，超了才让作业失败。好处是作业能跑完，坏处是数据静默缺失，对账时才发现。第二条是落盘，把错误行连同错误信息一起写到本地文件或对象存储里，事后人工或自动重放。第三条是不容忍，任何一行出错立刻让整个作业失败，等人工介入。
生产环境里推荐的做法是落盘加阈值，而不是单纯丢弃。落盘的价值在于可追溯：一条被丢掉的记录，如果没有留下原文和原因，事后根本无法判断是数据源的问题还是转换规则的问题。代价是磁盘占用。脏数据目录的大小估算公式很朴素：错误行数 × 平均行长 × 2（原文加错误信息）。一张 200 列宽表，如果错误率是 0.5%、每天同步 2000 万行，一天就是 10 万行，按 8KB 算，一天 1.6GB。看起来不多，但如果作业连续出错一周没人管，就是 11GB。
真正危险的不是脏数据本身，而是脏数据目录放在哪。默认配置往往指向引擎安装目录下的某个子目录，也就是系统盘。系统盘一旦被写满，受影响的就不只是同步作业了：引擎的 checkpoint 写不进去、日志写不进去、操作系统层面也可能因为无法写临时文件而出现各种诡异故障，最终整台机器不可用。所以脏数据目录必须单独挂盘，并且设置保留策略——按天数滚动删除，或者设置目录容量上限并在超限时告警。把脏数据目录放在独立的挂载点上，即便写满也只是同步作业停摆，不会连带拖垮系统。
数据集成是少见的"网络先于 CPU 打满"的负载。跨机房、跨云同步时，出网带宽是硬约束，而且是最容易被低估的约束。估算口径其实很简单：需要搬运的数据总量 ÷ 允许的时间窗口 = 必须的平均吞吐。一天要搬 2TB，窗口给 6 小时，平均吞吐就是 2TB/21600s ≈ 95MB/s，换算成带宽约 760Mbps。这个数字还要乘上 1.5 到 2 的安全系数，因为同步不是匀速的，且失败重跑会重复消耗带宽。
更麻烦的是，买到了 1G 的出网带宽，不代表就能跑到 1G。单条 TCP 连接的吞吐上限大致等于接收窗口除以往返时延。窗口是 64KB、RTT 是 30ms 的连接，理论上限约 2.1MB/s，也就是 17Mbps 左右。现代操作系统默认开启窗口缩放，实际窗口可以大很多，但 RTT 越大，填满窗口所需的在途字节数就越多，单连接越难跑满。这就是跨地域同步经常跑不满带宽的根本原因：不是带宽不够，是单连接受限于时延。
解决思路有两个方向。一是增加并发连接数，也就是前面说的并发度——它在这里的作用不只是并行读源库，更是并行占满链路。二是调大 TCP 缓冲区与窗口上限，这一层在操作系统参数里，机器交付后需要确认是否按长胖网络做过调优。这两件事都做，才可能让一条跨地域链路的实测吞吐接近标称值。需要提醒的是，具体能跑到多少，取决于两端机房之间的实际链路状况，公开资料无法给出确定数字，需要用真实数据量做一次窗口内的压测才能确认。
压缩是另一个可调的旋钮。开启传输压缩后，链路上跑的是压缩后的字节，带宽消耗下降，代价是两端各多出一次压缩与解压缩的 CPU 开销。对文本类数据（日志、JSON、CSV）压缩比通常在 3:1 到 10:1，非常划算；对已经序列化或已经压缩过的数据（Parquet、图片、视频），压缩比接近 1:1，纯属浪费 CPU。选择压缩算法时也有取舍：gzip 压缩比高但 CPU 消耗大，lz4 和 snappy 速度快但压缩比一般，zstd 在两者之间可调档。经验上的判断准则很直接——如果 CPU 已经跑满而带宽还有富余，就降级压缩档位；如果带宽跑满而 CPU 还很闲，就提高压缩档位。
作业失败是不可避免的：机器重启、源库主从切换、网络抖动、目标端短暂不可用。所以引擎必须知道"刚才读到哪了"，这就是 checkpoint 与位点的意义。Zeta 引擎会把 checkpoint 写到配置的存储后端，可以是本地文件系统、HDFS，也可以是兼容 S3 协议的对象存储。CDC 作业的日志位点、批作业的 chunk 完成情况，都落在 checkpoint 里。
这里有一个必须想明白的语义问题：checkpoint 是周期性做的，两次 checkpoint 之间完成的写入，在恢复时会被重放。也就是说，故障恢复天然会带来"至少一次"语义，而不是"恰好一次"。除非目标端支持事务性的两阶段提交或幂等写入，否则重复数据一定会出现。
因此目标端写入必须设计成幂等的。两条路：upsert 和先删后插。upsert（MySQL 的 ON DUPLICATE KEY UPDATE、PostgreSQL 的 ON CONFLICT、支持 MERGE 的引擎）依赖目标表上有唯一键，同一行重复写入时按主键覆盖，语义上最接近"恰好一次"，代价是写入路径变慢，且目标端要有可用的唯一索引支撑。先删后插通常按分区或按批次操作：先删掉目标端对应分区的数据，再整批插入，这样能保证分区内的最终一致性，代价是切换瞬间目标端该分区会短暂为空或者短暂为旧数据，下游查询会看到抖动，且删除加插入落在一个事务里时，大分区会造成长事务。
选择哪条路取决于目标端的特性。数仓类、支持 MERGE 的引擎（如 Iceberg、Hudi、Doris、StarRocks 的部分表模型）优先走 upsert；传统关系型数据库在批量覆盖场景下，先删后插配合分区切换通常更快。无论哪条路，前提都是目标端有明确的唯一性约束，否则幂等无从谈起。
还有一个运营层面的细节：位点与 checkpoint 的存储位置必须跟作业的生命周期匹配。把 checkpoint 放在机器本地盘，机器一旦被回收或迁移，位点就丢了，重跑只能从最早位点或重新全量开始。放在共享存储或对象存储上，作业可以在集群内任意节点恢复。这一点在多节点部署时尤其关键——不要把 CDC 作业的命运绑死在单台机器的本地盘上。
把前面的讨论收拢成一张表。三档形态对应三种典型的团队规模与数据量：轻量档是单台机器跑几十张表的定时批同步，标准档是三台机器组成的小集群跑常驻 CDC 加多个批作业，重型档是独立集群配万兆内网与出网保障，面向跨地域、大体量、多团队的场景。以下为典型部署思路，并非特指某一真实客户。
| 对比维度 | 轻量档：单台 4–8 核 / 16–32G | 标准档：3 台 8–16 核 / 64G | 重型档：独立集群 + 万兆内网 | 关键观测指标 |
|---|---|---|---|---|
| CPU | 4–8 核，仅在同步窗口内跑满；开压缩时容易成为瓶颈 | 每台 8–16 核，CDC 解析常驻占用 2–4 核，批作业错峰使用余量 | 每台 16 核以上，压缩与解析不再是约束，瓶颈转到网络与写端 | CPU 使用率、压缩线程排队长度 |
| 内存 | 16–32G，并发须压到 4 以内，批大小建议 500 行以下 | 每台 64G，可常驻 2–3 个 CDC 作业并同时跑批，需隔离堆内与堆外 | 每台 128G 起，作业间用容器或槽位隔离，避免单作业膨胀拖垮同机邻居 | 堆内使用率、堆外与 RSS 差值、GC 停顿时长 |
| 硬盘 | 单块 SSD 即可，但必须给脏数据与 checkpoint 划出独立目录 | SSD 系统盘 + 独立数据盘，checkpoint 建议上共享存储，脏数据盘按天滚动 | NVMe 承载 checkpoint 与临时落盘，容量按日均增量 × 保留天数 × 2 估算 | 脏数据目录增长率、checkpoint 写入耗时、磁盘剩余空间 |
| 网络 | 千兆内网够用；跨地域时出网带宽是主要限制，需向服务商确认上限 | 万兆内网，节点间数据交换不成为瓶颈；出网按日均增量 × 安全系数估算 | 万兆内网 + 明确的出网保障，跨地域需多连接并行才能跑满链路 | 出网带宽利用率、RTT、单连接吞吐 |
| 源端影响 | 并发小，源库连接占用少，适合只读从库与业务低峰窗口 | CDC 常驻 + 批作业错峰，需给源库预留连接与 I/O 预算并设限流 | 须配源库保护策略：只读从库、限速、窗口避让、I/O 配额 | 源库连接数、慢查询数、主从复制延迟 |
| 运维成本 | 单机运维，脚本化调度即可，人力投入最小，但无冗余 | 需引入监控告警与作业编排，单机故障可切换，维护成本中等 | 需要专职维护：容量规划、版本升级、故障演练、跨团队协作 | 作业失败率、平均恢复时长、同步延迟分位值 |
表的读法是从右往左看约束，从左往右看成本。轻量档的真实瓶颈几乎一定是出网带宽和源库连接，加 CPU 加内存收益很小；标准档的瓶颈在内存隔离与作业编排——三个节点上谁跑什么、失败了切到哪，需要提前定好；重型档的瓶颈转移到运维本身，机器已经不是问题，问题变成有多少人能管得住这套东西。
三档之间的跃迁也有明确信号。从轻量到标准，信号是 CDC 作业数量超过 2 个，或者单台机器上批作业的并发总和长期超过 8；从标准到重型，信号是日均增量超过单机出网能力，或者同步延迟的分位值开始超过业务可接受的时限。到了重型档，出网带宽与内网带宽的规格必须写进采购清单，因为这时候带宽已经是架构约束而不是性能参数。
现象：测试库一切正常，切到生产后源库报警连接数打满、慢查询激增。原因：默认并发通常是按引擎自身能力给的，没有考虑源库的连接预算与同时在跑的作业数。处置：按"源库可用连接数 ÷ 作业数"倒推并发上限，把并发度写进每个作业的独立配置而不是依赖全局默认值。
现象：同步出来的数据跟业务主库对不上，差异集中在最近几分钟。原因：从库本身落后于主库，同步读的是滞后的快照。处置：在作业开始前检查复制延迟，超过阈值就等待或告警；对一致性要求高的表直接读主库并限速，或者在目标端用主库的位点做二次校对。
现象：每天上午十点同步作业集体变慢，源库 CPU 飙升。原因：批作业窗口没做避让，跟业务高峰撞在一起，源库缓冲池被同步的大范围扫描冲掉，业务查询命中率下降。处置：把全量窗口挪到业务低峰，增量作业限速，给同步账号单独设置资源组或 I/O 配额。
现象：一个作业里其他 task 早就结束，最后一个 task 还在跑，整体窗口被它拖死。原因：大表没有可用的切分字段或切分字段分布倾斜，压根没切成块。处置：确认主键或时间字段上的索引，改用分区级切分或时间区间切分；无索引可用的表，接受长窗口并单独安排时间，不要跟其他作业抢资源。
现象：同步速度随时间单调下降，第一天 30 分钟，一个月后 3 小时。原因：目标端缺少唯一键或索引，每次 upsert 都要全表扫描定位行，数据量越大写入成本越高。处置：写入前确认目标表的主键与唯一索引；大批量首次导入完成后再建二级索引；定期做目标端统计信息更新。
现象：机器突然不可用，SSH 都登不上，排查发现根分区 100%。原因：脏数据目录默认落在系统盘，持续写入无人清理。处置：脏数据目录强制挂在独立数据盘，配置按天滚动与容量上限告警，把"脏数据目录增长率"做成常规监控项。
现象：按标称带宽算出来 2 小时能搬完，实际跑了 8 小时。原因：单连接受 RTT 限制跑不满，且链路存在波动，标称值不等于可用值。处置：上线前用真实数据量跑一次窗口内压测，按实测值 × 0.7 作为规划吞吐；多连接并行并调大 TCP 缓冲区。
现象：故障恢复后，目标端部分数据重复，部分数据缺失。原因：checkpoint 是周期性写入，恢复时重放了未完成的部分；或者位点文件被清理、被写到本地盘后随机器回收丢失。处置：checkpoint 放共享存储，确认保留份数；目标端强制幂等（upsert 或分区级先删后插）；恢复后跑一次区间对账。
现象：业务方先发现数据不对，数据团队才知道同步早就停了。原因：监控只覆盖了机器指标（CPU、内存、磁盘），没有覆盖业务指标（同步延迟、位点滞后、脏数据条数）。处置：把"当前位点落后源端的时长""单表最近一次成功时间""脏数据增长速率"三条做成必告警项，阈值按业务可容忍延迟设定。
批同步足够用的场景其实比想象中多。如果业务能接受 T+1，数据量在每天几十 GB 以内，源端以插入为主、很少更新和删除，那么批同步是最省事的选择：机器占用是脉冲式的，运维简单，出错后重跑一遍就行，不需要维护常驻进程和日志位点。报表类、离线分析类、训练数据准备类的需求，绝大多数都属于这一类。这类场景配轻量档机器足矣，把预算花在更大的磁盘和更稳的调度上，比花在更多核上更划算。
必须上 CDC 的场景也有清晰边界。当业务要求准实时（分钟级甚至秒级可见）、源端存在频繁的更新和删除、或者必须感知删除事件时，轮询批同步在原理上就做不到：轮询抓不到删除，且为了逼近实时而不断缩短轮询周期，会把源库查询压力推到不可接受的程度。对账严格、要求源目标行数严格一致的场景，同样只能靠 CDC。这类场景对应标准档机器，需要常驻内存、稳定的 checkpoint 存储，以及配套的延迟监控。
中间地带的处理方式是分层：用 CDC 保证核心表的准实时与一致性，用批同步搬运大体量的历史数据和日志类数据。这两类作业对资源的诉求完全不同，理想情况下应该分开部署——CDC 作业需要稳定的常驻内存，批作业需要瞬时的高吞吐，混在一起互相干扰。当机器数量有限必须混跑时，至少要做内存隔离与错峰调度。
第一件：用真实数据量跑一次全量，估算窗口。不要用抽样数据，不要用 1% 的数据量外推。全量同步的耗时不是线性的，源库在大范围扫描下的 I/O 表现、目标端在索引维护下的写入表现，都跟数据量强相关。跑完记录下三个数字：总耗时、峰值内存、峰值出网带宽。这三个数字决定了机器规格。
第二件：用生产并发跑一次源库压力观察。在源库侧盯着连接数、慢查询数、主从复制延迟、缓冲池命中率这四项，按生产环境的并发度和作业数跑一遍。观察的重点不是"源库有没有挂"，而是"业务查询的响应时间有没有变差"。同步作业不报错不代表没有影响，源库变慢往往是下游先感知到的。
第三件：做一次 kill 掉作业后的重跑验证。在作业跑到一半时强制中断，然后恢复，检查三件事：恢复是否成功、目标端是否出现重复数据、缺失的数据是否会被补上。这一项最能暴露幂等设计的漏洞。很多团队跳过这一步，直到某次真实故障才发现目标端根本没有唯一键，重复数据已经铺满了整张表，清理成本远高于当初做幂等的成本。
Q1：同步作业应该部署在源库所在机房，还是目标数仓所在机房？
A1：优先部署在离"数据量更大的那一端"更近的位置，通常情况下是源端。因为跨机房链路上跑的是读取结果，靠近源端意味着传输的字节数已经是读出来的量，不会因为重试或过滤而放大。若目标端写入需要极低延迟（例如实时看板），则反过来靠近目标端更合适。两端都无法靠近时，可以考虑在中间节点部署，但要多付一次跨地域传输成本。
Q2：并发度开多少合适，能不能照抄官方文档的默认值？
A2：不能照抄。并发度受三个约束共同限制——源库可分配的连接数、本机内存除以单 task 缓冲占用、CPU 核数除以压缩开销。取三者的最小值，再乘 0.7 的安全系数作为起始值，然后按实测吞吐微调。同一台机器上跑多个作业时，要按所有作业的并发总和来算，而不是单个作业。
Q3：源库已经用只读从库了，为什么同步结果还是跟主库对不上？
A3：从库自身存在复制延迟，同步读的是滞后快照。差异集中在最近几分钟的数据上，且延迟越大差异越多。处理办法是作业启动前检查复制延迟并在超阈值时等待或告警，对一致性要求高的表直接读主库并限速，或者在目标端用主库位点做二次校对。
Q4：跨地域一天要搬 2TB，出网带宽该按什么口径估算？
A4：按"总字节数 ÷ 可用窗口秒数 × 安全系数 1.5 到 2"估算，2TB 除以 6 小时约 95MB/s，再乘系数就是规划值。注意标称带宽不等于可用吞吐，单连接受 RTT 限制往往跑不满，需要用多连接并行并调大 TCP 缓冲区，最后以真实数据量压测的实测值为准。
Q5：脏数据目录能不能直接放系统盘？
A5：不建议。系统盘写满会影响 checkpoint、日志乃至操作系统本身，恢复成本高。正确做法是挂在独立数据盘上，配置按天滚动保留与容量上限告警，并把脏数据目录的增长率纳入常规监控。脏数据量突然飙升通常是上游数据结构变更的信号，本身就是需要告警的事件。
Q6：作业失败重跑后目标端出现重复数据，怎么从根上解决？
A6：checkpoint 是周期性的，恢复时会重放未完成的部分，因此"至少一次"是默认语义。根治办法在目标端：建唯一键并改用 upsert，或者按分区先删后插。两者都要求目标表有明确的唯一性约束，没有唯一键就无法幂等。恢复完成后再跑一次区间对账确认无重复无缺失。
Q7：机器要不要上 NVMe，普通 SSD 够不够？
A7：轻量档普通 SSD 足够，瓶颈在网络和源端。标准档以上建议把 checkpoint 与临时落盘放在更快的介质上，因为 checkpoint 写入耗时直接影响故障恢复速度，也影响 CDC 作业的事件处理延迟。是否上 NVMe 要看日均增量与保留天数算出的落盘压力，而不是一概而论。
Q8：CDC 作业和批同步作业能不能部署在同一台机器上？
A8：能，但不推荐长期混跑。CDC 需要稳定的常驻内存，批作业的内存是脉冲式的，批作业启动时的尖峰可能把常驻作业的堆挤爆，表现为 CDC 作业重启与位点回退。机器紧张时至少要做内存隔离（分开的进程与明确的堆上限）和错峰调度，并把两类作业的资源占用分别监控。
回到标题里的三个关键词。并发度的上限由源库连接预算决定，不由机器核数决定，取"源库连接数、本机内存除以单 task 缓冲、CPU 除以压缩开销"三者的最小值再乘安全系数，是唯一稳妥的定法。脏数据必须落盘而不是静默丢弃，落盘目录必须独立挂载并按天滚动，否则撑爆系统盘只是时间问题。出网带宽必须按"总量 ÷ 窗口 × 1.5 到 2"估算，并且必须用真实数据量实测，因为单连接吞吐受 RTT 限制，标称带宽与实际可用吞吐之间常有不小的差距。
机器形态上，几十张表定时批同步用轻量档单台即可，把预算放在磁盘与调度上；出现常驻 CDC 或多个并发作业后进入标准档，重点是内存隔离、checkpoint 共享存储与延迟监控；日均增量超过单机出网能力时进入重型档，此时内网带宽与出网规格要写进采购清单，因为它们已经是架构约束而非性能参数。上生产前的三件事——真实数据量全量估算窗口、生产并发下观察源库压力、kill 掉作业验证重跑幂等——一件都不能省。
一万网络深耕 IDC 19 年（成立于 2007 年），在服务器配置与节点选择上可以给数据集成团队提供几项具体支持：按日均增量与同步窗口倒推 CPU、内存、磁盘与出网带宽的规格组合，避免把预算压在不会成为瓶颈的部件上；为脏数据目录、checkpoint 目录规划独立挂载点与容量；按同步链路的两端位置给出节点选择建议，跨地域场景下协助评估出网带宽规格与实际可用吞吐的差距；提供 7×24 中文工单（平均 5 分钟响应）、硬件故障 10 分钟自动迁移、免费系统盘快照、5–20G 免费 DDoS 防护，以及 BGP 多线 + CN2 GIA 回国线路与自营机柜最快 1 分钟上架。
价格方面不作臆测：服务器租用的报价主要受 CPU、内存、存储、带宽、IP 和线路影响，具体规格与对应价格需实时询价，以官方实时报价为准。本文提到的三档形态只是资源配置思路的参考，不构成报价。
本文技术内容基于 SeaTunnel 公开文档与通用数据集成工程实践整理，机器规格与价格参考自一万网络官网公开页面（https://www.idc10000.net/ 服务器租用、带宽与机房相关页面），具体以签约时最新报价与合同为准。
上一篇：2026 服务器租用 MQTT 消息中枢 Mosquitto 落地全解：长连接、QoS 队列与持久化六维对比 + 避坑避雷手册
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
