（一）数据模型架构原则：四层七阶，数据湖仓建模的“第一块基石”

《新兴数据湖仓设计与实践手册·数据湖仓建模及模型命名规范（2025年）》 由四篇递进式指南组成，以"模型架构---公共规范---分层规范---命名规范"为主线，系统构建可演进、可治理、可共享的现代数据湖仓。

首篇 《数据模型架构原则》 提出了 "ODS-DW-APP" 四层（含DW内DWD/DWM/DWS）数据分层架构，并围绕主题域划分、高内聚低耦合、公共逻辑下沉及成本性能平衡四大原则，为湖仓一体的维度建模奠定统一且可扩展的设计基石。

后续三篇将在此框架内，依次落地公共设计模式、各层细化规范及统一命名体系，帮助企业用一套方法论完成从数据入湖到价值变现的全链路建设，敬请期待完整版。

把舵定向：让数据湖仓十年不翻船的数据模型架构顶层原则

1. 到底分几层才够用？一次讲透分层背后的取舍逻辑

优秀可靠的数仓体系，往往需要清晰的数据分层结构，即要保证数据层的稳定又要屏蔽对下游的影响，并且要避免链路过长。那么问题来了，一直在讲数仓要分层，那数仓分几层最好？

目前市场上主流的分层方式眼花缭乱，不过看事情不能只看表面，还要看到内在的规律，不能为了分层而分层，没有最好的，只有适合的。

分层是以解决当前业务快速的数据支撑为目的，为未来抽象出共性的框架并能够赋能给其他业务线，同时为业务发展提供稳定、准确的数据支撑，并能够按照已有的模型为新业务发展提供方向，也就是数据驱动和赋能。

一个好的分层架构，要有以下好处：

1. 清晰数据结构；
2. 数据血缘追踪；
3. 减少重复设计；
4. 数据关系条理化；
5. 屏蔽原始数据的影响。

数仓分层要结合公司业务进行，并且需要清晰明确各层职责，一般采用如下分层结构：

2. 四层七阶全景图：从ODS原始沼泽到APP黄金服务台

数仓建模在哪层建设呢？我们以维度建模为例，建模是在数据源层的下一层进行建设 ，在上图中，就是在DW层进行数仓建模，所以DW层是数仓建设的核心层。

下面详细阐述下每层建设规范，和上图的分层稍微有些区别：

1. 数据源层 ODS→ "零修改搬运工：ODS如何当好'数据时光机'"

ODS 层，是最接近数据源中数据的一层，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的 DWD 层来做。

2.数据仓库层 DW→ "DW三大护法：DWD洗地、DWM炼金、DWS铸剑"

数据仓库层是我们在做数据仓库时要核心设计的一层，在这里，从 ODS 层中获得的数据按照主题建立各种数据模型。 DW 层又细分为 DWD（Data Warehouse Detail）层、DWM（Data WareHouse Middle）层和 DWS（Data WareHouse Servce） 层。

1. 数据明细层：DWD（Data Warehouse Detail） 该层一般保持和 ODS 层一样的数据粒度，并且提供一定的数据质量保证。DWD 层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理。 同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。 另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性 。

2. 数据中间层：DWM（Data WareHouse Middle） 该层会在 DWD 层的数据基础上，数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。 直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。 在实际计算中，如果直接从 DWD 或者 ODS 计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在 DWM 层先计算出多个小的中间表，然后再拼接成一张 DWS 的宽表。由于宽和窄的界限不易界定，也可以去掉 DWM 这一层，只留 DWS 层，将所有的数据再放在 DWS 亦可。 3) 数据服务层：DWS（Data WareHouse Servce） DWS 层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，基于 DWD 层上的基础数据，整合汇总成分析某一个主题域的服务数据，一般是宽表。 DWS 层应覆盖 80% 的应用场景。又称数据集市或宽表。 按照业务划分，如主题域流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP 分析，数据分发等。 一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。

3. 数据应用层 APP→"最后一公里：APP把数据送到产品嘴边"

在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、 PostgreSql、Redis 等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。

4. 维表层→ "维度小宇宙：高、低基数维表的双子星攻略"

如果维表过多，也可针对维表设计单独一层，维表层主要包含两部分数据：

• 高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
• 低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。

3. 主题域划分原则→ "怎么切蛋糕？业务过程 vs 数据域的终极对决"

1) 按照业务或业务过程划分

业务容易理解，就是指的功能模块/业务线。

业务过程：指企业的业务活动事件，如下单、支付、退款都是业务过程。不过需要注意的是，一个业务过程是一个不可拆分的行为事件，通俗的讲，业务过程就是企业活动中的事件。

2) 按照数据域划分

数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。其中，业务过程可以概括为一个个不可拆分的行为事件，在业务过程下，可以定义指标，维度是指度量的环境，如买家下单事件，买家是维度。为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。

4. 数据模型设计原则→ "五条黄金军规，一个都不能少"

1) 高内聚、低耦合

即主题内部高内聚、 不同主题间低耦合。明细层按照业务过程划分主题，汇总层按照"实体+ 活动"划分不同分析主题，应用层根据应用需求划分不同应用主题。

2) 核心模型和扩展模型要分离

建立核心模型与扩展模型体系，核心模型包括的字段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的字段过度侵入核心模型，以免破坏核心模型的架构简洁性与可维护性。

3) 公共处理逻辑下沉及单一

越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用实现，不要让公共逻辑多处同时存在。

4) 成本与性能平衡

适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。

5) 数据可回滚

处理逻辑不变，在不同时间多次运行数据结果确定不变。

下篇预告：《数仓公众设计规范》