河水从城外流进来，进厂先过进水口，再一级一级净水池往下走，最后灌瓶、进城市管网、拧开你家的水龙头。
你现在看到的每一张报表、每一个页面数字，都是这条管子里流出来的水。
一、先破一个误会：这不是“买了一套中台”
很多人以为数据中台是个产品：签合同、装机、导数据，就有了。这套不是。这里没有一个叫“中台”的软件，只有一整套开源组件，被人一根线一根线接起来，接成了一条流水线。
为什么非得自己拼？因为现成的东西解决不了这三件事：
- 业务口径各算各的：同一个“销售额”，销售算含税、财务算不含税、库存算发出未开票，三个部门三套数。
- 同一份数据反复取：每个场景自己去源库拉一遍 CMS、EBS、BMS，源库被拉得喘不上气，口径还各不相同。
- 页面数字互相对不上：两个页面同一个指标差一截，谁也说不清是谁错了、错在哪一步。
自己拼的好处很土，但很实在：口径写在表里，表挂在链路上，链路有监控。数字对不上时，能一层一层往下查到是哪张表、哪个任务、哪一天的数据。
二、拆开看：六段水管，一段一段对
整条链就六段。下面每段都按同一个格式讲：像什么、其实是什么、真名叫什么、接错了会怎样。
顺着读一遍，你就知道一个数字从源库爬到手机页面，中间被搬了几次、被改了几次。
像什么：城外那条河。水好不好，取决于上游谁在往里排。
其实是什么：各个业务系统自己的库，数据天生带着人家的口径和毛病，你没法要求它干净。
- 真名
Oracle/SQL Server上的 CMS、EBS、BMS 等源业务系统- 在哪
- 各业务系统自己的数据库，不归数据中台管
搞错了会怎样：把源库当查询库用，几十个场景同时连上去拉数，源库先垮，业务系统跟着停。
像什么：厂门口那道进水闸，带滤网和流量表。进来的水先在这儿过一遍，原样存一池。
其实是什么：把源库的表按全量或增量搬进湖里，一行不改，落成贴源层；后面所有加工都从这一池水开始。
- 真名
DataX（批量）、CDM（初始化批量 / 增量批量）、CDL（增量实时，Oracle先过DRS再到CDL）- 落地表
- 贴源层
SDI，命名gk{公司缩写}_{系统名}_{系统类型}，例gkjx_cms_dis6 - 在哪
- 海豚里 Worker 分组
datax、环境名datax
搞错了会怎样：进水口不按清单进水、谁想接就接，湖里很快出现五张都叫“销售明细”的表，名字各不一样。
像什么：四口依次往下的池子。第一池是原水，第二池加药沉淀，第三池过滤，第四池出水前把硬度调好。
其实是什么：同一份数据在湖里按四层各存一遍，越往后越干净、越汇总、行数越少；而且要能单独回查，不能只剩个结果。
- 真名
SDI贴源 →DWI明细 →DWR汇总明细 →DWS汇总- 库名
dwi_gk_hudi/dwr_gk_hudi/dm_gk_hudi- 谁在搅
Spark SQL，统一从Kyuubi进来写
搞错了会怎样：跳过中间层，直接从贴源层拼报表。口径规则散落在几十个 SQL 里，改一次规则要改几十处。
像什么：灌装车间。水到这儿不再论吨，按瓶灌、贴标签、装箱，一瓶对应一个页面上的一个位置。
其实是什么：面向具体场景和页面的结果表。页面要什么，就在这一层拼好什么，前面四层的复杂到这儿收口。
- 真名
DM/ADS应用层，例dm_gk_hudi.ads_pur_ps_channel、dm_gk_hudi.ads_sad_se_jx_dtl- 在哪
- 湖里
dm_gk_hudi库；出湖后进仓dm_gk_dws
搞错了会怎样：结果表不按场景命名、字段随手加，半年后没人知道那张 ads_ 开头的表是谁的、能不能删。
像什么：埋在地下的城市主管网。厂里水再好，管网漏了、压力不够，楼上照样没水。
其实是什么：对外供数的 OLAP 库。页面和报表直连它查，查得快不快、稳不稳，用户第一时间就能感觉到。
- 真名
Doris，湖里出来靠SeaTunnel送（Hudi→Doris）- 硬规矩
- 副本必须 3（
replication_allocation = "tag.location.default: 3"）、禁Auto Bucket、≤2000 万行禁用动态分区 - 看压力
- Grafana 面板
10.160.4.111:8182
搞错了会怎样：开了 Auto Bucket，tablet 数量失控、小文件爆炸，查询越跑越慢，最后只能重建表。
像什么：你家厨房那个龙头。你只关心拧开有没有水、水压稳不稳，不关心厂里几台泵在转。
其实是什么：报表、自助分析、即席取数三类出口，全都直连 Doris 的表，拧开就有数。
- 真名
帆软 FineReport、Superset、adhoc查询平台（/adhoc）- 交付
- 字段口径说明、
DDL、映射文档、验算报告
搞错了会怎样：页面里写死一段 SQL 自己算口径，链路上查不到它。数字错了只能靠人肉翻页面。
三、一张图看完这条水管
把六段画在一条线上就是下面这张图。从左往右就是水的方向，中间那格四小格是四级净水池；下面一排是三个岗位。
- 最左边蓝框是河水：所有数据都从业务系统自己的库里来，这里不修改任何东西。
- 中间那块四小格是净水池：
SDI→DWI→DWR→DWS，格子颜色越深表示水越干净、数据越汇总。 - 橙色两段是出厂：
ADS灌装成结果表，最后从水龙头拧出来；中间那个蓝框Doris是进城的主管网。 - 下排三个岗位守整条线：
Kyuubi管开门、海豚管几点开泵、监控管水质和压力，谁都不属于某一段。
四、厂里就三个岗位，记住名字就够
管子再多，真要认人的只有三个岗：一个管开门，一个管排班，一个管化验。哪一步出问题，先找这三个岗。
它们站的位置不一样，混着记最容易乱，下面按“站在哪、管什么”分开写。
像什么：厂门口那道总闸。不管你是哪个车间的，用水都得从这道闸过，闸上还有一本登记簿。
其实是什么：所有 Spark SQL 的统一 JDBC 入口。谁在什么时候跑了什么 SQL，都在这一层留痕。
- 真名
Kyuubi，入口jdbc:kyuubi://…:10009（办公室.50/.236，VPN.100）- 硬规矩
- DEV 账号必须带
kyuubi.engine.share.level.subdomain=<子域>
搞错了会怎样：平台的要求是必须带这个子域标记；不带会不会被平台 KILL，目前没拿到证据（10 月 24 日那两次超时，也可能只是元数据行锁），所以别把它当已证实的结论讲——但照规矩带，别省。用 SQL 注释或连上后 SET 冒充，平台都不认。
像什么：厂里的值班室，墙上挂着时刻表：几点开哪台泵、先开哪台后开哪台、哪台坏了重开几次。
其实是什么：作业编排和依赖调度。谁等谁、出错重试几次、漏了怎么补数，全写在这张时刻表上。
- 真名
DolphinScheduler，三套厂区：生产 /UAT/ 开发（开发环境不开启调度）- 项目编码
- 生产 BI_PRD
148405435832576、SIT149223761565792、ETL 生产136016656440288、ETL SIT12302943659968、SUPP12923899913280 - 节点约定
- 业务 SQL 用
SQL组件选KYUUBI；入湖DATAX（worker=datax）；出湖SEATUNNEL（worker=seatunnel）；中转用SHELL跑echo 1
搞错了会怎样：依赖检查只认“上次成功”、不认“今天跑没跑”，08:00:05 就放行；上游 10 月 3 日下线了，下游照样天天准点搬一遍旧数据。
像什么：化验室墙上那排表：水质多少、压力多少。哪个格子红了，立刻有人去打铃。
其实是什么：分四段看数据——源到贴源、入湖任务、湖仓调度、湖到仓到页面。哪一段漏了，一眼能看出是管子的问题还是水的问题。
- 真名
Prometheus+Grafana、DS 实例失败率、入湖湖仓到帆软全链路监控、自建一致性检查- 看什么
- 表级监控字段：
finereport_name（哪个页面）、dws_table（哪张表）、job_name（哪个任务）、job_owner（谁负责）
搞错了会怎样：只盯任务成功失败、不看数据本身，任务全绿，页面数字照样是错的。
五、这座厂是一年年长出来的，不是一次建成的
看时间线就明白：2022 年下半年先吵架构、写规范，2023 年才大批进水，后面几年全在补工具和监控。
下表按语雀知识库 313 篇文档的创建时间排。文档的节奏，基本等于项目推进的节奏。
| 时间 | 在干什么 |
|---|---|
| 2022-09 | 立项。第 1 篇文档《数据挖掘架构需求》，先把需求写成文 |
| 2022-10 （33 篇） | 架构选型大爆发：Lambda / Kappa / 混合架构、数据湖、湖仓一体、Hudi、Spark / Hive 参数，还有《数仓设计规范》 |
| 2022-11 （43 篇） | 方案落地：数据中台架构与方法论、元数据方案、数据质量、数据资产分类、医疗健康数据分级分类、数据安全 |
| 2022-12 （12 篇） | 数据入湖流程定稿、CDM 问题清单、入湖配置方案、数据集成架构 |
| 2023-01 （33 篇） | 入湖工程化：入湖第一阶段、CDM / API 文档、并行写 Hudi、大规模入湖与调度 |
| 2023-06～11 | Hudi 增量能力（copy_to_temp_view）、Hudi / 集群优化、入湖湖仓到帆软全链路监控 |
| 2024 | 双周迭代发布制度（2024-04 起记录不断）、2024-10 数据库迁移 |
| 2025 | 离线 / 实时数据同步解决方案、Superset、ETL 代码工具与数工坊、对外同步流程、权限申请流程 |
| 2026 | 迭代发布继续（2026-01 至 2026-09 每月都有记录）、数据中台十五五规划、项目多环境介绍更新 |
最该看的是 2022-10 和 2022-11 这两个月：一个月 33 篇、一个月 43 篇，架构和方法论都是那两个月定下来的。后面几年没再推翻，只是照着它长。
六、现在这座厂有多大（实测记录，不是文档口径）
下面这些数是上平台实测查出来的，不是文档里的目标值。文档写的是“应该怎样”，这里写的是“现在实际怎样”。
- 真名
- 生产湖
dm_gk_hudi、落地库dm_gk_hudi_sit、最忙那台 worker10.160.10.26 - 生产湖
dm_gk_hudi2,763 张表- 落地库
dm_gk_hudi_sit3,027 张表- 单项目任务
- 756 个任务，分布在 10 台 worker 上
- 最忙那台
10.160.10.26一台扛 218 个、排队 3.8 分钟，其余 9 台基本空闲- 近 8 天
- 45,571 成功 / 296 失败 / 529 被杀，失败率 0.65%
- 失败根因
- 集中在
SeaTunnel心跳超时，retry_to_doris自动重跑后全部成功 - SUPP 场景
- 44 条工作流（42 条在线、08:00 调度，2 条停用）
2,763 张表是这套体系的体量，也是它的负担：同样的活本来该 10 台机器分，现在快压在一台上。这不是水管坏了，是水压全压在一个接口上。
七、搞错了会怎样（真实事故，不是假设）
这一段最该背下来。前面讲的是管子怎么接，这里讲的是管子接错以后，现场长什么样。
INSERT OVERWRITE 互相覆盖。后跑的把手删了，页面上少一天的数，任务状态还是成功的。这三条后来都写进了红线清单。第 11 关会把 13 条红线连同踩坑现场一次讲完。
八、一句话记住
技术是拼的，规范是写的，规模是靠工具化撑起来的。
拼，说的是这套开源组件自己接线、自己排班；写，说的是 313 篇文档里那些分层、命名和红线；工具化，说的是把建表、写 ETL、挂调度、配同步、接页面都做成了平台上的按钮。
- 真名
- 这句话出自《数据中台是怎么搭出来的（复盘）》的收尾结论，不是宣传口号
九、往下怎么读
后面 11 关就是把这六段拆开讲。建议按下面这个顺序走，一关没看懂就停在那一关，别硬赶。
- 先底座（第 2 关）：HDFS、YARN、Spark、Hudi、Kyuubi、Ranger、Datasophon 这些家什各管什么。
- 再进水（第 3 关）：清单驱动、六道前置检查、DataX / CDM / CDL 三条进水管。
- 再净水（第 4 关）：SDI → DWI → DWR → DWS → ADS，为什么同一份数据要存好几遍。
- 再灌装与排班（第 5、6 关）：Spark SQL 怎么把水灌进瓶里，海豚怎么排时刻表。
- 再管网（第 7、8 关）：SeaTunnel 出湖、Doris 怎么分区分桶、副本为什么必须 3。
- 再水龙头（第 9 关）：建表平台、数工坊、adhoc、Superset、血缘，把重复活变成流水线。
- 再化验（第 10 关）：四段式监控，哪一段漏了一眼看得出来。
- 最后红线（第 11、12 关）：13 条红线与真实事故，以及你手上那几个地址各站在链条的哪一段。
这一关只需要记住一个画面：河水 → 进水口 → 四级净水池 → 灌装线 → 城市管网 → 水龙头，中间站着 Kyuubi、海豚、监控三个岗位。