把河水引进厂：入湖（SDI） · 数据中台

入湖不是"想接就接"：先把水化验一遍，六道关卡逐个签字，才准开闸放水。

水厂砌好了，第一次开泵，老师傅一把按住阀门："先化验，再进水。"——河在上游别人的地里，脏水一旦进了第一个池子，后面四级净水池全得重来；同一个错，越往后越贵。

一、先说人话

数据中台这边，"河"就是别人的业务库：Oracle 的 CMS、SQL Server 的 EBS、BMS……服务器不在你机架上，账号不在你手里，连改一张表的权限都不在你手里。所以这一关卡的不是技术，是交接：入湖不是"我拉一把数据"，而是"我提需求、你按我的规矩交付"。

水不是你的，池子是你的。脏水进厂的账很好算：湖里是四级净水池，SDI 贴源 → DWI 明细 → DWR 汇总明细 → DWS / ADS 应用。同一笔脏数据，躺在 SDI 里只是"一行难看的数"；流到 DWI 就变成口径错；流到 ADS，就成了老板手机上那个错数字。越往后修，越贵。

所以《数据入湖流程》里写得最硬的不是技术名词，是流程：清单驱动、六道关卡、任一不过就退回整改、改完才准进。下面这张图就是这一关的全貌。

图上只画了三道闸门，另外三道（Owner / 认证源 / 质量标签）和"标准"那道一起过。顶上那条紫色虚线是关键：业务上叫什么、库里是哪张表，得注册成一对，否则湖里全是"看着像"却没人敢用的表。

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

2.1 一张清单：接哪几股水，先写清楚

🗒 入湖规划清单（取水图）

像什么：拉管子之前先画一张取水图——要哪条河、哪个取水口、取到哪一层水，图纸上先标死，别到现场凭感觉。

其实是什么：由数据组基于数据湖的建设规划出这张清单，从最粗的一格抽屉，一路点到"哪张表的哪个字段"。

清单上的层级	说人话（越往下越具体）
主题域分组	最外面的大抽屉：几类业务话题合成一组
主题域	一类业务话题
业务对象	业务里能直接点名的那个东西
逻辑实体	这个业务对象在数据模型里对应的那张"概念表"
业务属性	这张概念表上有哪些业务字段
源系统物理表	落到某台真库里的那张真表
物理字段	真表里的真列名

清单还要同时给三类元数据，原文一口点名：

业务元数据: 业务含义、业务规则这一层（原文明确说：数据标准是业务元数据的重要组成部分）
技术元数据: 落在哪台库、哪张表、哪个字段——就是"逻辑实体 ↔ 物理表、属性 ↔ 字段"这层对应
管理元数据: Owner、密级、质量标签这类管数据也管人的信息；具体字段清单这一步的实际值要现场核
真名: 入湖规划清单，见《数据入湖流程》第 1 节"数据入湖需求分析及管理"

会出事清单只写到"业务对象"就开工，到了落地那一步没人说得清源表到底是哪张，只能凭印象挑一张。挑错了，下游 DWI 到 ADS 一条链全错，而且错得很像对的。

2.2 六道关卡：一张一张过，哪个不过都不许进

六道的顺序别调：先看水样（准备度），再定谁负责（Owner），然后立规矩（标准）、认水源（认证）、贴封条（密级），最后打质检标签（质量）。

🚪 第一道 · 数据源准备度（先看水样）

像什么：接管子之前，先让对方交两样东西：一份水质报告，一张管道图。

其实是什么：两件事一起做——源系统 IT 团队提供数据字典和数据模型，并检查源系统物理表的规范度；数据代表那边去评估源系统的数据质量。

真名: 检查数据源准备度
看什么: 数据字典、数据模型、物理表规范度、源系统数据质量
谁来做: 源系统 IT 团队 + 数据代表

注意只要了数据字典、没要数据模型，等于只拿到一张表清单，不知道表跟表怎么关联。落进湖里就是一堆孤岛表，下游想拼一张业务明细都拼不出来。

👤 第二道 · 明确数据 Owner（这池水挂谁的名）

像什么：小区楼顶的水箱上必须钉一块牌子，写清责任人电话。

其实是什么：入湖之前就把"这数据归谁管"写明白，入湖数据的管理责任才清晰。原文把这条放在第一句，就是因为后面所有整改都得有人接。

真名: 数据 Owner
不过就: 责任不清，源端整改找不到人接，只能整条链一起背锅

📏 第三道 · 发布数据标准（同一把尺子）

像什么：同一个"销售量"，销售按开票算、财务按回款算——两把尺子量同一根木头，永远吵不完。

其实是什么：数据标准把每个数据属性的业务含义、业务规则写下来。原文的说法很重：这是正确理解和使用数据的重要依据，本身也是业务元数据的重要组成部分。

真名: 数据标准（业务含义 + 业务规则）
不过就: 同一个指标两套算法，报表天天被业务退回，而且谁都不算错

✅ 第四道 · 认证数据源（只认那口原井）

像什么：村里有三口井，只认最早打的那口原井——后面接的管子，水都是从它引出去的。

其实是什么：原则上以初始源进湖。原文说得很直接：数据源认证是保证数据湖数据一致性和唯一性的重要措施。

真名: 认证数据源 / 初始源进湖
不过就: 同一笔订单从 CMS 进一遍、又从下游系统进一遍，湖里两份都"看着对"，从此对账永远差一截

🔒 第五道 · 定义数据密级（先贴封条）

像什么：档案柜分几层抽屉，谁能开哪一层，得先写在柜门上，不能等人来了再商量。

其实是什么：信息安全管理专员向业务 Owner 提出定密需求，和业务 Owner 一起确定定密规则，定下数据密级、定密时间、降密期 / 降密条件，最后由信息安全管理专员在信息架构管理平台注册密级信息。

真名: 数据密级 · 定密规则 · 定密时间 · 降密期 / 降密条件
落在哪: 信息架构管理平台（注册密级信息）
不过就: 密级没定，进了湖没人敢共享；反过来，该封的没封，谁都能查

🏷️ 第六道 · 评估入湖数据质量（打质检标签）

像什么：每一批水出厂贴一张质检单，合格不合格，一眼看出来。

其实是什么：对入湖数据做质量评估，给入湖数据打质量标签。标签跟着数据走，下游看一眼就知道这批能不能用。

真名: 质量标签
不过就: 湖里落地库有 3,027 张表，长得都差不多；没有标签，没人知道哪张能用

注意六道是一票否决原文这句没有例外条款：不满足上述任意一条入湖标准，就应推动源系统数据代表完成整改，满足要求后方可实施数据入湖。所以别想着"先搬进来再补"——补不动的，脏水已经在池子里了。

2.3 三种进水口：管子粗细不一样

关卡过完，才轮到选管子。三种口子对应三种场景，别看哪个"先进"就选哪个。

进水口	用什么	一句人话
初始化批量入湖	`CDM`	第一次进厂，把整条河的水一次抽满——要历史数据就走这条。
增量批量入湖	`CDM`	每天只抽新涨的那一段，靠增量字段 `cdc_partition_key` / `additiondate` 切。
增量实时入湖	`CDL`	河一涨就立刻抽，不等夜里跑批；Oracle 的河必须先过 `DRS`，再进 `CDL`。

选之前还有一道分叉，原文写得很明确：不要求历史数据、小批量数据、实时性要求高的场景，建议虚拟入湖；要求历史数据、大批量数据、实时性要求不高的场景，可以物理入湖。后面跟着一句注释：本期以物理入湖为主。分工也定死了——虚拟入湖由数据代表实施，负责设计和部署虚拟表；物理入湖由对应数据湖的 IT 代表承接，设计集成方案和数据质量监测方案。

非结构化的东西（文件）另算，是4 种方式：基本特征元数据入湖、文件解析内容入湖、文件关系入湖、原始文件入湖。原文特别点了一句：基本特征元数据入湖是必选内容，后面三项按分析诉求选择性入湖，也可以延后入湖。

小窍门基本特征元数据入湖，说白了是"文件本身不进湖，进湖的是这份文件的户口信息"——正文还留在源系统，湖里只存它的基本特征。所以它必选：连户口都没有的文件，后面三种方式一条都走不了（原文要求，后三种都得以先拿到基本特征元数据为前提）。

2.4 谁来搬：调度上只认 DataX

🚚 抽水泵的专职司机

像什么：抽水泵不是谁路过谁开。值班表上写死了：哪台泵、归哪个组、在哪个环境跑。

其实是什么：海豚上的数据集成节点就两种。DataX 管入湖：源端 → 数据湖 Hudi；SeaTunnel 管同步：一般从数据湖 Hudi → 数仓（也支持别的源端和目标端）。干入湖这活，DataX 节点的 Worker 分组选 datax，环境名称也选 datax。

真名: DataX 组件 · Worker 分组 datax · 环境名 datax
出处: 《数据实施规范》3.3.5 数据集成节点约束

反方向那根管子是 SeaTunnel：出湖、入仓用，Worker 分组和环境名都是 seatunnel。这页只提一句——方向反了，接上去也是白接。

会出事Worker 分组挑错，任务排在不该跑的组上，一直排队等资源；拿 SeaTunnel 硬做入湖，那是把出厂管当进水管装，接头对不上。

2.5 落地叫什么名字：一张表一个门牌

🏷 贴源层的门牌号

像什么：每家钉一块门牌：小区 + 楼号 + 房型。缺一段，快递就找不到人。

其实是什么：贴源层的表名是死公式，四段拼起来，不许自己起名。

公式: gk${公司缩写}_${系统名}_${系统类型}
gk: 固定写法。gk 开头这一整段（gksd / gkjx 之类）说的是"哪家公司"，不是系统
公司缩写: 紧跟 gk 的那两个字母：gksd 里的 sd、gkjx 里的 jx
系统名: cms——CMS 系统
系统类型: dis6——系统的类型那一段
两个真例: gksd_cms_dis6（规范原文举的例子）、gkjx_cms_dis6（复盘里那条真实血缘 gkjx_cms_dis6.scm_salbill_hdr.stopflag 的前缀，标的是江西销售场景）

注意某两个字母到底对应哪家公司，按你们的公司缩写表核，别照着别人的名字抄；dis6 这类系统类型的取值清单，原文只写了"系统类型"这一层，没展开枚举——这一步的实际值要现场核。

会出事名字自己起了，血缘就断在这张表上：一致性检查任务按名字认表，对不上就当它不存在；SIT 叫一个名、生产叫另一个名，发布前那次回读也查不出来。

2.6 进厂之后还要验：搬完不等于干完

🔍 五件收尾事

像什么：水进了池子，化验班还得每天取样：今天抽了几吨、抽了多久、哪次抽浑了、有没有抽漏。

其实是什么：入湖落完地，链路上还要挂五件事，缺一件就算"只搬不验"。

要挂的事	它在盯什么
贴源层入湖数据检查	跟源端对账：行数、关键指标对不对得上
入湖数据质量监控	第六道打的那些质量标签，有没有掉
入湖时长统计	每批搬了多久；忽然变慢，就是管子堵了
入湖问题汇总	出过的问题攒成一本账，别每次重新踩
注册元数据	业务元数据 ↔ 技术元数据：逻辑实体 ↔ 物理表、属性 ↔ 字段

最后那条单独说：注册元数据就是把"业务上叫什么"和"库里是哪张表"结成一对。原文的目的是让数据消费人员能用业务语义快速搜到湖里的数据，降低湖里取数的门槛，让更多业务分析人员能理解和消费数据。

真名: 贴源层入湖数据检查 · 入湖数据质量监控 · 入湖时长统计 · 入湖问题汇总 · 注册元数据

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

把上面这些零件按原文的顺序排一遍，就是一次真实的入湖。顺序不是讲究，是省事的唯一办法——每一步的产出正好是下一步的输入。

出清单。数据组按数据湖建设规划出《入湖规划清单》：主题域分组 → 主题域 → 业务对象 → 逻辑实体 → 业务属性 → 源系统物理表 → 物理字段，附业务 / 技术 / 管理三类元数据。
看水样。源系统 IT 交数据字典和数据模型，验物理表规范度；数据代表评源系统数据质量。交不齐，止步。
过五道标准。明确数据 Owner → 发布数据标准（业务含义 + 业务规则）→ 认证数据源（以初始源进湖）→ 定义数据密级（定密规则、降密期 / 降密条件）→ 评估数据质量打标签。任一条不满足：推源系统数据代表整改，改完才准进。
选进水口。要历史全量 → CDM 初始化批量；要每天增量 → CDM 增量批量，靠 cdc_partition_key / additiondate 切；要秒级 → CDL，Oracle 先经 DRS。文件走 4 种方式，基本特征元数据必选。
挂上调度开泵。海豚上建 DataX 节点，Worker 分组 datax、环境名 datax，落到 SDI 贴源层，表名按 gk${公司缩写}_${系统名}_${系统类型} 钉死。
注册元数据。业务元数据和技术元数据对起来：逻辑实体 ↔ 物理表、属性 ↔ 字段，让人能按业务词搜到表。
入湖后校验。贴源层入湖数据检查、入湖数据质量监控、入湖时长统计、入湖问题汇总，四件一起挂。
交给下一关。到这一步，SDI 里才有资格出现 gksd_cms_dis6.scm_salbill_hdr 这种表；再往下才是 Spark SQL 洗进 DWI——那是下一关的事。

回头看这八步：真正花时间的是第 2、3、4 步，第 5 步只是"按图纸拧阀门"。所以入湖干得顺不顺，看的不是 DataX 跑得多快，是前面那张清单和那六道关卡签得干不干净。

四、搞错了会怎样

进厂之后最容易松的那口气，就在"任务跑成功了"这一刻。任务绿着，数据照样能错。原文的监控模型把源 → 贴源这一段的异常分了三种，每一种都会让任务显示成功。

会出事 · source_delete源端把数据删了（或者整批清掉重灌），湖里还留着旧的那一份。对账一看：源端行数和 SDI 行数对不上，而且只少不多。这种最容易骗人——任务全是绿的，数据是错的，错的还是"多出来的"那份。

会出事 · source_add源端新增了数据，但增量时间字段没生效。增量入湖是按时间字段切片抽的，这个字段不更新，新数据就永远落在切片之外。表现很干脆：源端明明多了一批，湖里一行没多。

注意 · table_columns入湖表的字段和源端对不上——源端加了列、改了类型，湖里还是旧的。SDI 一般不吭声，等到下游 Spark SQL 一跑，字段错位、类型炸掉，报错落在 DWI，人却要一路倒查回入湖这一步。

再补一层：入湖任务自己也有三种坏法，跟上面三类不是一回事——failed（网络 / 资源）、stopped（超时被停）、running（长期挂着不结束）。任务状态管"搬没搬完"，数据异常管"搬得对不对"，两本账得分开看。

小窍门排查顺序别搞反：先看任务三态（没搬完就别聊数据），再看数据三类（搬完了但不对，直接查 source_add 和 table_columns）。反过来先怀疑业务口径，能查一整天。

五、一句话记住

做对了水没化验就进厂，后面四级净水全是白干。

换成流程话：清单写清、六道关卡过完、改完再进；进来之后还要验、要注册元数据、要盯那三类异常。省掉哪一步，代价都会翻着倍还回来——因为在 SDI 里改一行是改一行，在 ADS 里改一个数，是改一屋子人的判断。

事实来源：数据入湖流程 · 数据实施规范 3.3.5这一关只管"进厂"下一关：四级净水