trade 是数据域还是主题域？数仓分层里最容易搞混的一对概念，一篇讲透

一、一个目录归属之争事情是这样的。我在数仓里建了几张交易相关的聚合表按习惯放进了dws/trade/。过了两天又做了一批给 SupersetBI 报表工具看板用的查询 SQL顺手在trade/下面开了个子目录支付成功率/把十来个看板查询都塞了进去。同事瞄了一眼问我「trade是主题域吗那支付成功率又算什么」我张口就想答「是」话到嘴边又咽了回去 —— 因为我突然发现数据域和主题域这俩词我天天挂在嘴边但真要说清它俩到底差在哪还得停下来想想更说不清支付成功率这种东西在分层体系里到底站在哪一格。如果你也曾在建目录、起表名时对着dwd / dws / ads发过呆或者被「数据域」「主题域」「业务过程」「数据集市」这堆词绕晕过这篇就是写给你的。我们把它一次性捋清楚。本篇聊的是建模与分层的概念不涉及具体怎么用 ClickHouse Dolphin 把数仓搭起来。后者可以看这篇ClickHouse Flink DolphinScheduler中小厂三件套搞定离线实时数仓。二、先分清两个「方向」纵向分层 vs 横向归类大部分人对数仓的认知停留在那条经典的纵向分层链路上ODS → DWD → DWS → ADS (贴源) (明细) (汇总) (应用) DIM维表横插一脚层干啥的一句话ODS贴源层原始数据搬进来基本不加工DWD明细层清洗、规范化后的明细事实一行一个业务事件DWS汇总层按维度做轻度聚合存可加的基础度量ADS应用层算好、能直接展示的最终结果DIM维度层公共维表给各层 JOIN 用这条链路描述的是「加工到第几步了」—— 是个纵向的、关于加工深度的维度。但这里有个很多人忽略的事实数据域 / 主题域根本不在这条链路上。它们是横向的 —— 描述「这块数据归哪个业务大类」。打个比方纵向分层像「食材 → 切配 → 半成品 → 成品菜」而数据域像「川菜区 / 粤菜区 / 湘菜区」。一个讲加工程度一个讲菜系归属是两个正交的维度。你不会问「半成品是不是川菜」对吧同理「DWS 是不是一个数据域」也是个伪命题。搞混这两个方向是一切混乱的根源。三、数据域 vs 主题域到底差在哪这俩长得太像连很多团队内部都混用。但方法论上参考阿里 OneData 那套它们的导向不同数据域Data Domain主题域Subject Area导向建模导向分析导向怎么划按业务过程抽象按分析视角组织用在哪DWD / DWS 建模归类ADS / 数据集市 / BI 消费层稳不稳定很稳定业务过程不常变跟着分析需求走相对灵活例子交易域、用户域、流量域交易、用户、流量同一大类换个分析视角看数据域是「面向业务过程的抽象集合」。比如「交易域trade」它把下单、支付、退款、回调这些业务过程打包成一个稳定的大类。你建 DWD/DWS 表时按这个归类。主题域是「面向分析的组织」。它站在分析师/看板的视角围绕某个分析目标把指标聚到一起。关键认知 ——它俩常常是同一个业务大类在两层的两个名字交易这个业务大类在DWS 建模层叫它「数据域」在BI 消费层叫它「主题域」。同一个trade两层两种身份不矛盾。所以回到开篇那个问题trade是「域」级的东西不是某个具体主题。至于叫数据域还是主题域看你站在哪一层说话。那它下面还有什么完整的层级是这样的数据域trade 交易 ← 域最顶层稳定 └─ 业务过程下单 / 支付 / 退款 / 回调… ← 不可再拆的业务事件 └─ 分析主题支付成功率 / 失败归因… ← 围绕一个分析目标 └─ 具体指标 / 看板 ← 落到一张张报表支付成功率站在分析主题这一层 —— 它不是域是trade域底下、围绕「支付成功率」这个分析目标聚起来的一组看板。一句话总结这一节trade是域支付成功率是域下的分析主题。四、落到目录聚合表放哪看板查询放哪概念清楚了建目录就有据可依了。我最后的结构是这样dws/ trade/ ← 数据域交易 订单状态聚合表.sql ← 可加基础度量成功数/失败数/金额… 退款聚合表.sql bi/ ← 消费层给 BI 工具读 trade/ ← 主题域交易 支付成功率/ ← 分析主题 各渠道支付成功率.sql ← 算好比率 中文列直接喂图 大盘按天趋势.sql ...为什么聚合表进dws/、看板查询进bi/两条判断口诀屡试不爽口诀一存的是「可加的基础度量」还是「算好的最终指标」聚合表存的是成功数 / 失败数 / 金额这种可累加的计数 —— 这是 DWS 的活。比率成功率 成功 / 总数不可加两天的成功率不能相加除以二所以不进聚合表留到查询时用聚合后的计数现算。看板查询负责把计数算成比率、贴上中文列名、做 ROLLUP 小计 —— 这是「应用/消费」层的活。口诀二被多处复用还是绑定单一报表一张聚合表喂「失败率快照 / 按天趋势 / 按渠道 / 按支付方式」一堆看板 → 公共、可复用 → DWS。一个查询只服务一张图 → 绑定单一报表 → 应用/消费层。顺带一个容易纠结的点消费层这些纯 SELECT 查询不建表、不在 ETL 链路里、给 BI 工具读到底算不算 ADS我的处理是 —— 它们口径上是 ADS 的逻辑算最终指标但既然只是查询、不落表就单独拎到一个bi/目录和「调度器要跑的建表 ETL」物理分开职责更清晰。叫bi/还是ads/团队约定即可关键是别把纯查询和建表 ETL 混在一个目录里。五、三个常见误区踩过的、见别人踩过的列在这里帮你避雷。误区一把纵向分层当成数据域。第二节说过「DWS 是不是一个域」是伪命题这里补一句更实用的一张表的完整坐标是「哪一层 × 哪个域」—— 比如那张订单状态聚合表坐标是「DWS 层 × 交易域」层和域各回答一半缺一不可。误区二主题名起得太窄结果什么都往里塞。我一开始把支付成功率/当筐连「支付失败原因分析」「回调成功率」也丢了进去。可「失败归因」严格说不属于「成功率」。随着指标变多要么把主题名放宽支付质量/要么拆成兄弟主题支付成功率/支付失败分析/。分析主题该按「回答什么问题」来切而不是按「凑在一起方便」来堆。误区三拿存储模型宽表 / 窄表来回答归属问题。「该用宽表还是窄表」是物理存储的选择跟「这块数据归哪个域、哪个主题」是两码事。别让这两个问题互相干扰 —— 先定域和主题逻辑归属再定宽表还是窄表物理实现。六、总结把这篇压缩成几句能带走的话纵向分层ODS/DWD/DWS/ADS讲加工深度数据域 / 主题域讲业务归属两个正交维度别混。数据域 建模导向按业务过程建模层用主题域 分析导向按分析视角消费层用。常常是同一业务大类在两层的两个名字。trade是域支付成功率是域下的分析主题。层级是数据域 → 业务过程 → 分析主题 → 指标/看板。建目录两口诀存「可加基础度量」还是「算好指标」「多处复用」还是「绑定单一报表」。分析主题按「回答什么问题」切太窄就放宽或拆兄弟主题。下次再有人问你「这个算数据域还是主题域」你可以淡定反问一句「你站在建模层问还是消费层问」—— 能把对方问住基本就说明你真懂了。七、延伸阅读想知道这套分层在轻量技术栈上怎么真正跑起来 → ClickHouse Flink DolphinScheduler中小厂三件套搞定离线实时数仓️ 标签数据仓库数仓分层数据建模数据域主题域ClickHouse