一、先说人话

整套同步从一开始就分成两件事，不是"一个工具干完"：DataX 管进厂，SeaTunnel 管出厂。原文的说法是：DataX 负责离线入湖，SeaTunnel 负责湖内入仓。

人话就是：河在城外（业务库不归你管），厂在城里（数据湖），城市管网在更里面（Doris 仓）。第一段是"从别人的河里往自己厂里抽"，第二段是"从自己厂里往自己管网里送"。两段水的性质完全不同，所以工具也分开。

为什么不拿一个工具干两件事？因为两头要的东西正好相反。抽水那一段，关键指标是"别把源库压死"——源库是别人的生产库，DataX 靠主从架构，对源端压力小；送水那一段，关键指标是"快"，SeaTunnel 吃的是湖里那套分布式计算资源，表再大也是几台机器一起搬。

原文把这句话写成了产品优势的第一条：双引擎分工明确，各取所长，链路清晰。分开的另一个好处是不互相拖累：入湖那边在抽一条几千万行的源表，不会把出湖的管子堵住；出湖这边要重建 Doris 表结构，也不用等入湖跑完。

看图只用记三件事：左边那池水本来就有（湖里确实有数据），中间那台泵是 SeaTunnel，右边才是页面真正连的地方（Doris）。泵上方两块牌子是"接头"的名字——两块牌子不是同一根管子，装混了，泵就在往别的地方抽水。

牌子上写的是接头的大名。目标端那根按环境分名字：SIT 实跑的叫 SIT_DORIS_GK_SINK，生产是另一根，名字自己核，别照图上的字面抄。

二、拆开看：每个零件是什么

2.1 它是个"产品"，不是一堆脚本

2.2 一个真实节点长什么样

下面这份是从真实构建脚本（add_seatunnel.py，给工作流 187800689635488 加"07_同步宽表至Doris"）里原样拿出来的配置，只调了换行和缩进，值一个没动：

{
  "env": {
    "parallelism": 5,
    "job.mode": "BATCH"
  },
  "source": [{
    "LINK": "HUDI_GK_LINK",
    "table_path":
      "dm_gk_hudi_sit.ads_log_inv_kpi_wide"
  }],
  "sink": [{
    "LINK": "SIT_DORIS_GK_SINK",
    "table_path":
      "dm_gk_dws.ads_log_inv_kpi_wide",
    "schema_save_mode": "RECREATE_SCHEMA",
    "write_mode": "overwrite"
  }]
}

看着像代码，其实是四个零件的清单：环境（几台泵、跑哪种活）、源（从哪接头取哪张表）、目标（往哪根接头灌哪张表）、灌法（表结构怎么办、数据怎么进去）。逐个说：

2.3 节点参数：泵装在海豚上，还得填四格

配置只是泵里那套管子；泵装在海豚上，外面还有一圈参数。真实值如下（同样来自 add_seatunnel.py）：

为什么用集群模式？因为这段活天生是"多台一起搬"。cluster 模式下任务提交给集群，几台机器分片搬，调度机只管发号。反过来用单机模式，调度机既当发包人又当干活的人，一张大表就能把它按住——现场已经有现成的例子：单项目 756 个任务分在 10 台 worker 上，其中 10.160.10.26 一台就扛了 218 个、排队 3.8 分钟，其余九台基本闲着。负载已经不均，再让谁单机硬扛就是雪上加霜。

为什么超时是 1800 秒？这条宽表正常几分钟就跑完。1800 秒不是"给足时间"，是判死线：真跑过半小时，多半不是慢，是引擎心跳停了（见 2.5）。与其让它挂着耗到天亮，不如判失败、让下游重跑一遍——重跑的成本远低于"早上八点发现昨晚什么都没进仓"。

2.4 SIT 和生产：两根不同的管子

2.5 失败了怎么办：三层兜底

同步这件事，失败是常态不是异常。原文给的产品能力里就写着"异常重试"，落到现场是三层，从下往上兜：

1. 节点自己那一层：failRetryTimes。海豚节点参数里就有这个开关，本脚本明确设成 0——意思是"别在节点上反复重试"，因为同一批重试三次和重试一次，失败原因不会变，只是多排三次队。
2. 下游那一层：retry_to_doris。专门有个任务，把当天没同步成功的重跑一遍（现场是 08:15 触发）。近 8 天 45,571 次成功 / 296 次失败 / 529 次被杀，失败率 0.65%，retry_to_doris 自动重跑之后全部成功。
3. 人那一层：SeaTunnel 的 overview 页面。http://seatunnel.sinopharmholding.com:10001/#/overview 看 job 状态、并行度、有没有在重试。这一步是给"重跑也没好"的情况准备的，不是第一反应。

2.6 它还能干别的：不止"湖 → Doris"

这套泵不是只会往 Doris 一个方向灌。原文写的是"同步至 Doris 数据仓库（或其他指定数据存储形式）"，实际用过的还有这几种：

文件服务器那条有两个坑是原文专门标出来的：一个数据集只要生成 1 个文件，并发数必须设成 1；部分外部服务器没给删除权限（原文点名紫竹 FTP），传错了删不掉，属于数据泄露风险，所以正式同步前可以在数据集里先加 1=0 条件空跑一遍，验证文件名和路径对了再放开。

2.7 同一件事，历史上还有第二条路径

出湖入仓这件事，不是只有 SeaTunnel 一根管子。历史上湖 → DWS 这一段也用过 CDM 同步，证据就在监控看板里：它判断一张表的状态，是按四段任务的结果算的——入湖一致性检查、入湖 CDM 任务、湖仓开发任务、同步 CDM 任务。最后那一段，就是当年跑"湖 → 仓"的那条路径。

现在新链路以 SeaTunnel 为主：规范里出湖节点的类型就写死了 SEATUNNEL，Worker 分组 seatunnel；而 CDM 主要留在入湖那一段（初始化批量、增量批量）。两条路径都通，意味着排查时先要认清"这条链现在到底是谁在跑"——拿老 CDM 任务的日志去解释新 SeaTunnel 节点的失败，能查一下午，查的还是别人家的账。

三、串起来：一次完整的上线流程

下面这八步就是真实干过一遍的顺序。注意第 6 步：回读不是可选项，它是这道工序里唯一一道"自己检查自己"的关口。

1. 先确认接头在。源端 HUDI_GK_LINK、目标端 SIT 的 SIT_DORIS_GK_SINK，两个都得是平台上已经注册好、能连通的。接头不存在，写再漂亮的配置也是空转。
2. 写配置。三块：env（parallelism + job.mode）、source（LINK + table_path）、sink（LINK + table_path + schema_save_mode + write_mode）。
3. 取模板骨架。不要从零手搓节点，取一个本项目已验证可用的 SEATUNNEL 任务当模板，只留该留的字段：taskType、workerGroup、environmentCode、failRetryTimes、timeout 这些，其余换成新的。
4. 申请 task code。海豚的节点编号得先申请（gen-task-codes），一次申请几个就加几个节点，编号不能重。
5. 拼节点。taskParams 里塞进 rawScript（上面那份 JSON），再补 startupScript=seatunnel.sh、deployMode=cluster、failRetryTimes=0、timeout=1800。
6. 挂依赖 + 提交 + 回读。上游加工跑完才准开泵（本例：06_指标宽表_全量 → 07_同步宽表至Doris、05_口径校验_全量 → 08_同步校验至Doris）。整份定义 PUT 上去之后，立刻 GET 回来对三样：版本号、任务数、依赖数；再逐个节点看有没有 _sit 残留。
7. 发布、启动。release 之后 start。写操作之前要先拿临时管理员权限（1 小时），申请理由写清具体场景。
8. 跑完验数。到 Doris 里对行数和关键指标，跟湖里那张表比一遍。任务绿只是"搬完了"，行数对上才叫"搬对了"。

回头看这八步：真正容易出事的是第 1 步和第 6 步，都不是"技术难"，是"省了那一眼"。接头没确认，配出来的是个连不通的任务；回读没做，发出去的是份自己没看过的定义。

四、搞错了会怎样

前面几关的错，多半错在"理解"；这一关的错，多半错在"省了一眼"——接头没核、回读没做、参数写反了方向。它有个共同点：任务都是绿的。

下面这几条，前三条是红线级的，后三条是"绿着也要盯"的。

五、一句话记住

落到手上的动作就三件：先看 SeaTunnel 的 overview 里那个 job 是什么状态，再看海豚上这个节点的 table_path 和 LINK 有没有指错厂区，最后才回去看加工那段的 SQL。顺序反了，能省的时间全赔进去。

再补一句给以后的人：这根管子身上贴着四张纸条，别撕——deployMode=cluster（活给集群干）、timeout=1800（半小时不动就判死）、failRetryTimes=0（重试交给下游）、write_mode=overwrite（整段覆盖）。撕掉哪一张，后面都会有人重新踩一遍。