预制件工厂：不用现场砌墙 · 数据中台

这套体系能撑到今天，不是因为人多，是因为四件重复活被做成了工具：建表、写 ETL 代码、挂调度、配同步。

以前盖房子，每个工地自己拌灰、自己砌砖，十个工地十种手艺，砌歪了要等验收那天才发现。后来改成预制件：砖在车间按模具压出来、盖好检验章，工地只负责吊装、拼装、调平。中台这几年的变化，就是从"工地"搬进了"车间"。

一、先说人话

中台要接几十个源系统、上千张表，需求是一批一批来的。如果每张表手写 DDL、每段整合层代码手写、每个任务手动去海豚里挂，那这条数会一直往上走，人加多少都不够。

把动作拆开看，重复的其实只有四件事：建表、写 ETL 代码、挂调度、配同步。这四件各自被做成了一个车间工具，于是"每个工地自己砌砖"变成了"车间出预制件"。这一关不讲流程，只讲你手里那几个工具：叫什么、在哪进、参数怎么选、选错了会怎样。

先记住一个判断标准：凡是"每次都要照着上一张表抄一遍"的动作，这套体系里基本上都已经有工具了。你要找的不是人手，是那个入口。

二、拆开看：一个车间，七件家什

下面每张卡还是四拍：像什么、其实是什么、真名在哪、搞错了会怎样。真名那一行可以直接抄。

🧱 预制砖车间：建表平台 ddls

像什么：砖不在工地拌，在车间按模具压，尺寸统一，出模就盖检验章。

其实是什么：把建生产表的 SQL 贴进去，平台逐项检查，过了才准发布。你不用再靠脑子记六条规矩，也就不会漏。

真名: ddls 建表平台
在哪: /dmt/ddls，也就是 http://dpf.sinopharmholding.com:10001/dmt/ddls
两种类型: Hudi、Doris
一次多条: 支持多个 SQL，用 ; 分割，一起检查

检查项是逐条报的，不是甩你一句"失败"：

检查	卡的是什么	适用
SQL 整体检查	整体语法等信息	Hudi / Doris
表备注	表必须写备注	Hudi / Doris
Location 检查	不能包含 `Location`，必须建管理表	Hudi
字段备注	字段必须写备注	Hudi / Doris
Schema 检查	不能为空	Hudi / Doris
字段名称检查	不能以 `_` 开头	Hudi / Doris

另外还有两块操作日志：发布历史和表操作历史。谁在什么时候发了哪张表，翻得到。

搞错了会怎样：带上 Location 建出来的就不是管理表了，元数据和文件各归一处，后面按管理表的路子维护——删表、清文件、对账——全对不上。所以这条不是建议，是硬拦。

🏷️ 反着出图纸：SQL 助填（INSERT 自动转 CREATE）

像什么：手里已经有装好的成品照片，车间照着照片反推出这张图纸。

其实是什么：贴一条 SparkSQL 的 insert，平台按它涉及的字段反推一份建表语句。这是最省事的一条路——你本来就要写 insert，顺手把表也建了。

在哪: ddls 的 SQL 助填，支持 SparkSql
方向一: insert into → Hudi 建表语句
方向二: insert overwrite → Hive 建表语句

字段怎么定，原文给了几条规矩，值得逐条看：

目标字段是引用的已有表字段 → 优先沿用源表的字段类型和备注。
字段是拼出来的、算出来的，但用 as 改成了已存在的字段名 → 类型给 string，备注取所有同名中文备注里出现率最高的那个。
名字也取不到 → 字段名给 col_x，备注写"待填写"。
system_code、cdc_partition_key、partition_key 这几个常用字段 → 默认 string，而且有这些字段时会自动生成分区，方便后期填充。
多个语句一起贴也行：create 语句会被当成"已存在的表"参与引用查找；insert 里用了不存在的表或字段，直接抛异常。

搞错了会怎样：所有"待填写""待补充"都必须后期补完。留着不补就发布，等于一批没打标的预制件直接吊上墙——出了问题是哪一块，谁也认不出来。

🏭 总装线：数工坊 DataMatic

像什么：你把图纸和料单递进车间，车间吐出成品，中间不经过人手抄字段。

其实是什么：上传 Mapping Excel → 平台解析 → 生成整合层 ETL 代码 → 直接生成到指定的海豚项目。名字里的 matic 就是"自动"那个词根，宗旨写得很直白：自动化、批量化、标准化。

真名: 数工坊 DataMatic（也叫数造工坊）
在哪: /dmt/etl；平台总入口 http://dpf.sinopharmholding.com:10001/dmt/，用 IAM 账号登录
前置: 本机 hosts 里要有 10.160.4.243 dpf.sinopharmholding.com
批次号: 就是上传文件的时间戳；文件名不做限制

上传前要选四个参数，这是最容易选错的地方：

参数	怎么选
类型	除了司库的任务，其他项目都选整合
业务	质量域的器械 / 零售 / 分销 → 直接选器械、零售、分销；其他域的器械 / 零售 / 分销 → 选 `CMS（器械/零售/分销）`；`EBS`、`BMS` 没有特殊要求，按需选
主题域	零售、质量、库存、财务、采购、销售……按需选
解析参数	按行填写 Mapping 文档里要整合的 sheet 名，可以填多个

搞错了会怎样：解析出错平台会提示，但解析对错都能生成代码。所以正确姿势是先"生成验证代码"看一眼，再最终生成；不验证直接生成，就是把错模板直接灌进项目。

🚚 发货单：选项目、填测试参数

像什么：出厂前必须问一句"这车货送哪个库房"。送错了，另一个库房永远等不到这车货。

其实是什么：生成本身不分环境，是你在这一屏选项目，决定了代码落到海豚的哪一套环境里。这张对照表记不住就存成手机图。

界面上选	落到海豚项目
`POC`	`poc`
`ETL生产环境`	`ETL_合并_离线计算`
`ETL测试环境`	`auto_dwi_sit`
`司库项目`	`ETL_SIKU`

还有两个可填项：测试参数填 gkyy_cms_comp、gksn_cms_dis5 这种指定公司，就只生成那一家；不填则生成全部代码，耗时较长。备注是这次生成任务的说明，可不填。

搞错了会怎样：想上生产却选了 ETL测试环境。测试那边天天绿，生产里一条代码都没有——这种错藏在"跑通了"的假象里，最难发现。

🚪 门禁和台账：生成记录、权限管理

像什么：车间门口有个登记本，谁提过什么货一翻就知道；进门还得刷工牌，工牌上写着你能碰哪条线。

其实是什么：两件事——生成记录是台账，能查本人和其他所有人的代码生成记录；权限管理是工牌，分管理员权限和用户权限两种，管理员权限最高。

用户权限怎么给: 按业务 + 项目两条一起授权
业务是什么: 你负责开发的那块内容。上传模板时只能选自己负责的部分，按需申请
项目是什么: 海豚里的项目，就是上一张表那四个，按需申请
还有一份: 默认开通权限的人列表和《数工坊使用手册》，直接问管理员要

搞错了会怎样：业务申请了、项目没申请，生成代码那一步选不到目标项目；项目有了、业务没覆盖，上传模板时选不到那条业务线。能登进平台，不等于能生成到生产。

🚪➡️🚪 同一个车间，两道门：ETL 整合层代码工具

像什么：车间有南北两个门，进去是同一台机器，同一排按钮。

其实是什么：那篇《ETL-整合层代码工具》写的页面结构就两块——模板上传页和代码生成记录页，参数、项目对照、权限、记录，跟数工坊一模一样。它就是 DataMatic 模块清单里那一项，名字叫 ETL 整合层代码生成工具。

入口一: 从 /dmt/ 的模块清单点进去
入口二: 直接开 /dmt/etl
结论: 同一件事有两个入口，别重复开发

搞错了会怎样：有人以为是两个工具，另起一套生成器。Mapping 格式一分叉，同一张表就有了两套代码，最后互相覆盖，还得回去查是谁生成的。

🧰 车间外三件配套：过磅、台账、样品间

像什么：货出了车间还没完——要过磅（数不对就退回）、要登记去向、还得留个样品间让人自己来看货。

其实是什么：三件配套工具，一件管"数对不对"，一件管"数从哪来"，一件管"临时要个数"。

过磅: 一致性检查自动调度：源 ↔ 贴源、湖 ↔ 仓 的差异自动巡检，结果落表可追
台账: 数据血缘工具，血缘入 Neo4j，能可视化、能查询
样品间: adhoc 查询平台（/adhoc，IAM 账号登录，即席 SQL）
样品间: Superset，自助分析

搞错了会怎样：四件重复活都自动化了，唯独"数对不对"还靠人抽看——生成得越快，错得越快、错得越多。巡检不挂上，车间产能越高越危险。

三、串起来：一张 Mapping 到一条工作流

把车间连起来看，就是从左边递进去一张 Excel，右边出来一条能跑的工作流。

对着图走一遍，七步：

业务把需求写成一张 Mapping Excel：sheet 里是"源表字段 → 目标表字段"一行行的对应关系。
开 /dmt/etl，上传这张 Excel，选四个参数：类型选整合（司库除外）、业务选你负责的域、主题域选零售/质量/库存……、解析参数按行填 sheet 名（可多个）。
点确定，平台自动解析，并把解析结果摊在前端给你看；报错就按错误提示改模板。不管解析对不对，都可以先生成验证代码。
生成代码时选项目：POC / ETL生产环境 / ETL测试环境 / 司库项目。只想先验一家公司，就在测试参数里填 gksn_cms_dis5 这种。
目标表还没有？把 insert 贴进 ddls，用 SQL 助填反推 create，六项检查过了再发布——insert into 出 Hudi 建表语句，insert overwrite 出 Hive 建表语句。
代码落到海豚项目后挂调度：业务 SQL 用 SQL 节点（数据源选 KYUUBI）、入湖用 DATAX、出湖用 SEATUNNEL、纯中转用 SHELL（脚本 echo 1）。
出厂后：一致性检查自动巡检源↔贴源、湖↔仓；血缘进 Neo4j；临时要看数去 /adhoc 或 Superset。

小窍门先小批量试。测试参数里填一家公司（如 gkyy_cms_comp），几分钟就能看出模板对不对；确认没问题再去掉参数全量生成。全量生成耗时长，拿全量去试错最费时间。

四、以前跟现在：省下来的到底是什么

"效率提升"这种话没用，直接摆两列：左边是每个工地自己砌砖，右边是车间出预制件。

环节	以前（现场砌墙）	现在（车间预制）
建表	手写 DDL，六项检查靠人记	`ddls` 贴 SQL，检查结果逐条报；`insert` 还能反推 `create`
写 ETL	手写整合层 SQL，字段一个个对	上传 Mapping Excel，解析后直接生成代码
挂调度	在海豚里一个个建节点、连依赖	生成代码时选项目，代码直接落进去
配同步	手动配入湖、出湖任务	可视化配源端、湖路径、目标表、调度周期，自动串联
耗时	一步一步手工来，慢，而且检查项容易漏	平台自动跑检查、自动落项目，人只做验收
检查项	容易漏，漏了要到对账那天才知道	写死在工具里，漏不掉

合起来看，省的不是打字时间，是记性：以前六项检查全靠人记，现在检查项在工具里跑。人只要管两件事——Mapping 对不对、项目选对没。

但预制件不是白拿的，三句实话，一句都不能省：

实话一：模板错，则全错模板里字段对应写错，生成出来的是一批代码一起错。以前手写只错一张表，现在是一整批一起错——所以第 3 步那个"生成验证代码"不是可选项。

实话二：命名得守规范生成器是按规范拼库表名的（贴源 gk{公司缩写}_{系统名}_{系统类型}，其他层 {数据分层}_{场景}_{一级}_{二级}），名字不合规范，生成出来进不了库，血缘也接不上。

实话三：权限要按"业务 + 项目"申请没申请就是"看得见、动不了"：上传模板只能选自己负责的业务，生成代码得先有那个项目。临时要权限也是走申请，不是找个人开后门。

五、搞错了会怎样

四个车间各有各的坏法，实际最常踩的是这几种。都不是"慢一点"，是"白干一轮"。

会出事把 insert into 和 insert overwrite 弄混。前者反推出 Hudi 建表语句，后者反推出 Hive 建表语句：该增量的表建成 Hive 表，upsert 就无从谈起；反过来该建 Hive 的建成 Hudi，白背一套 type='cow'、primaryKey、preCombineField 的约束。

会出事项目选错。想进 ETL_合并_离线计算，手滑选了 auto_dwi_sit：测试环境天天绿，生产里一条代码都没有，直到有人问"这张表怎么不更新"。

注意批次号就是上传时间戳，文件名不做限制。同一个模板改八遍传八遍，只有批次号分得清哪次是最终版——所以"生成记录"那一屏别不看。

注意字段名不能以 _ 开头，Hudi 表不能带 Location。这两条在 ddls 里是硬拦，别绕：绕过去的东西，后面所有按管理表、按字段名做的巡检和血缘都会错位。

这几种错的共同点是：当场都不报错。表建出来了、代码生成了、任务也绿了，问题要等到有人问"这张表怎么不更新"或者对账差分时才浮出来。所以车间给了两道免费保险：ddls 的六项检查，和生成代码前的"生成验证代码"。

用不用这两道保险，是这套东西里最省钱的一个决定。

六、一句话记住

回头看这四件重复活：建表、写码、挂调度、配同步。它们原来散在每个项目、每个人手里，靠师父带徒弟传手艺；现在被收到一个地方，做成四个工具，谁进来都是同一套手艺。

所以中台那个"中"，不是中间件，也不是"中间那一层"。是把重复劳动收到中间，统一做一遍。

做对了业务只交一张 Mapping，剩下的建表、写码、挂调度、配同步都在车间里自动完成——工地只负责拼装和调平。