企业官网建设流程全解析

简介：这份文档面向数据仓库建设者、数据开发工程师与数据分析人员，聚焦数仓数据模型该如何设计这一核心命题，帮助读者理清分层逻辑、统一建模口径，解决实际项目中分层混乱、模型随意、命名不一等常见痛点。资源包内含1个doc文档，约77KB，以文字讲解为主，便于通读与查阅。内容围绕ODS、CDM（DWD、DWS、DIM）与ADS三层架构展开，梳理各层功能定位与边界，并给出数据调研、数据域划分、总线矩阵构建、原子与派生指标区分、一致性维表与事实表设计、公共汇总模型搭建直至代码开发与部署运维的完整流程。同时针对分层边界不清、模型缺乏标准化、代码与命名不规范、主题域划分不完整、主键选择不当等问题提供解决思路，并强调高内聚低耦合、核心与扩展模型分离、公共逻辑下沉、指标一致性等设计原则。目前已有182人学习，适合需要系统掌握数仓建模方法论、提升模型可维护性与复用性的从业者参考。

1. 数据仓库数据模型设计：从分层边界到落地避坑的实战拆解

很多团队做数仓，第一版模型上线时看着挺整齐，半年后就开始出现“同一指标三个口径、ADS 直接读 ODS、DWD 反向依赖 DWS”这类烂账。问题往往不在工具，而在数据模型设计阶段没有把分层边界、数据域划分和公共逻辑下沉讲清楚。这份《数据仓库｜数据模型该如何设计？》文档，核心就是解决这件事：它把 ODS、CDM（DWD/DWS/DIM）、ADS 四层的职责、开发流程和模型设计原则拆成可执行的步骤，适合正在搭数仓、或者被烟囱式开发折磨过的数据开发、数仓建模和 BI 同学。下面我按“先立分层、再落模型、最后避坑”的顺序，把文档里的方法论和我自己踩过的坑一起讲透。

2. 分层标准与开发流程：把 ODS 到 ADS 的边界钉死

2.1 四层架构的职责与边界

文档里把数仓分成 ODS、CDM、ADS 三层，其中 CDM 又细分为 DWD、DWS、DIM。这个分层不是拍脑袋，而是为了把“原始数据、公共加工、应用定制”三类诉求隔离开。ODS 层要求结构与源系统基本一致，采用增量或全量同步，保留历史变化，方便后期核对。DWD 层以业务过程为建模驱动，做清洗转化，构建最细粒度明细事实表，并适当冗余重要属性形成宽表。DWS 层基于指标需求做初步汇总，通常是宽表，强调命名规范、口径一致。DIM 层建立一致性维表，降低计算口径不统一的风险。ADS 层面向具体应用，整合成主题域服务数据，直接对接 BI 和报表。

边界不清是数仓混乱的头号原因。文档里提到一个典型场景：为了快速开发，直接从 ODS 开发 ADS 表，结果 ADS 和 DWS 边界模糊，竖起一个又一个小烟囱。我见过更离谱的，DWD 表里直接引用了 ADS 的汇总结果，形成反向引用，一旦 ADS 逻辑调整，整条链路跟着崩。所以分层的第一原则是：DWD 只引用 ODS、DIM 和部分 DWD；DWS 只引用 DIM、DWD；ADS 可以引用 DWS、DWD、DIM，但尽量减少对 ODS 的直接依赖。

提示：分层边界不是画在文档里的，而是要落到调度依赖和代码审查里。每次新增表，先问一句“它属于哪一层，引用了谁”，比事后重构便宜得多。

2.2 开发流程的七步落地

文档给出的开发流程是：数据调研、数据域划分、构建总线矩阵、明确统计指标、模型设计、代码开发、部署运维。这七步里，前四步是设计阶段，后三步是实施阶段。很多团队跳过总线矩阵直接写 SQL，结果就是指标口径对不上。

数据调研要搞清楚业务系统表关系、字段含义，以及具体需要哪些指标、口径是什么。数据域划分是对业务过程或维度做抽象，比如交易、流量、用户。总线矩阵用来明确业务过程所属数据域，以及业务过程与分析维度的关系。统计指标要区分原子指标和派生指标，原子指标不可再分，派生指标由原子指标加修饰词和时间周期组成。

模型设计阶段按 DIM、DWD、DWS、ADS 的顺序构建。代码开发就是业务逻辑实现、测试和数据验证。部署运维包括上线任务、任务监控和 DQC 监控。这七步看起来简单，但每一步都有坑。比如数据域划分，文档特别强调数据域不是一成不变的，要随业务发展调整，不能大一统地粗略划分。

2.3 一个可抄作业的建表顺序

下面这段伪代码展示的是从 ODS 到 DWD 再到 DWS 的典型加工顺序，重点看依赖关系，不要照搬表名。

-- 第一步：ODS 层，保持与源系统一致，只做增量/全量同步 INSERT OVERWRITE TABLE ods_order_di PARTITION (dt='${bizdate}') SELECT order_id, user_id, sku_id, order_status, create_time, pay_time, amount FROM source_order WHERE dt = '${bizdate}'; -- 第二步：DIM 层，建立一致性维表，比如用户维、商品维 INSERT OVERWRITE TABLE dim_user_df PARTITION (dt='${bizdate}') SELECT user_id, user_name, register_time, user_level FROM ods_user_df WHERE dt = '${bizdate}'; -- 第三步：DWD 层，清洗转化，冗余维度属性，构建明细宽表 INSERT OVERWRITE TABLE dwd_trade_order_di PARTITION (dt='${bizdate}') SELECT o.order_id, o.user_id, u.user_name, u.user_level, o.sku_id, o.order_status, o.amount, o.create_time FROM ods_order_di o LEFT JOIN dim_user_df u ON o.user_id = u.user_id AND u.dt = '${bizdate}' WHERE o.dt = '${bizdate}'; -- 第四步：DWS 层，按主题域和粒度做初步汇总，宽表化 INSERT OVERWRITE TABLE dws_trade_user_sku_1d PARTITION (dt='${bizdate}') SELECT user_id, sku_id, COUNT(order_id) AS order_cnt, SUM(amount) AS order_amt FROM dwd_trade_order_di WHERE dt = '${bizdate}' GROUP BY user_id, sku_id;

这段代码的关键在于：ODS 不做业务逻辑，DIM 保证维度一致性，DWD 做清洗和冗余，DWS 做汇总。参数${bizdate}是业务日期，通常由调度系统传入。DWD 层冗余了user_name和user_level，是为了减少下游频繁关联 DIM 表。DWS 层按用户和商品粒度汇总，是为了支撑上层按用户或商品分析的需求。如果 DWS 层直接引用 ADS 表，就会形成反向依赖，这是文档里明确禁止的。

3. 公共层模型设计：DWD 与 DWS 的复用、易用和稳定

3.1 公共层设计的三个核心原则

公共层包括 DWD、DWS、DIM，它的价值在于抽象、复用、沉淀，提升整体数据效率并确保口径一致。文档里把公共层设计要点总结为：需求上识别共性逻辑，设计上抽象复用模型，实现上平衡易用性和稳定性。具体落到三个原则：复用性、易用性、稳定性。

复用性方面，指标复用性抽象要把不可累加指标转为可累加指标，比如比率型指标保留分子分母；粒度复用性抽象要以最大公约数逻辑抽象，比如上游有子公司粒度和一级类目粒度，就可以设计出 SKU 粒度的 DWS 表。易用性方面，DWS 通过冗余维度属性、采用大宽表方式构建，减少下游频繁关联；DWD 通过星型模型、维度冗余和信息完善度设计，提升易用性。稳定性方面，公共层要扁平化设计，避免依赖层级过深；DWS 结合访问热度、数据稳定情况做解耦，比如按 1d、nd、td 垂直拆分；DIM 也可以垂直拆分，保证核心维度产出效率。

注意：公共层不是为某一应用场景单独设计的，而是面向大部分应用场景。如果某个指标只在一个地方使用，就没有必要沉淀到 DWS，直接放在 ADS 更合适。

3.2 DWS 沉淀的判断标准与粒度抽象

DWS 的核心诉求是通过空间换时间，在节约成本、提升效率的同时实现口径一致。但文档特别提醒：不能为了加工 DWS 而加工 DWS。判断是否沉淀公共层，核心问题是“是否具有共性”。如果是事后沉淀，要看指标的应用场景有多少，只在一个地方使用就不必沉淀。

粒度抽象是 DWS 设计的难点。文档给了一个例子：上游表 ADS1 是子公司粒度，ADS2 是一级类目粒度，那就可以设计出 SKU 粒度的 DWS 表，因为 SKU 是子公司和一级类目的最大公约数。这样下游无论按子公司还是按一级类目分析，都可以从这张 SKU 粒度的 DWS 表上卷得到。

下面这段 SQL 展示的是从 DWD 到 DWS 的粒度抽象过程，假设 DWD 是订单明细，DWS 要按用户和 SKU 汇总。

-- DWS 层：按用户+SKU 粒度汇总，保留可累加指标 INSERT OVERWRITE TABLE dws_trade_user_sku_1d PARTITION (dt='${bizdate}') SELECT user_id, sku_id, COUNT(DISTINCT order_id) AS order_cnt, -- 订单数，可累加 SUM(amount) AS order_amt, -- 订单金额，可累加 SUM(CASE WHEN order_status = 'paid' THEN amount ELSE 0 END) AS paid_amt, MAX(order_status) AS latest_status FROM dwd_trade_order_di WHERE dt = '${bizdate}' GROUP BY user_id, sku_id;

这里order_cnt和order_amt都是可累加指标，下游可以按用户上卷，也可以按 SKU 上卷。paid_amt是条件汇总，保留了支付金额的原子性。latest_status是状态快照，方便下游直接使用。参数${bizdate}控制分区，GROUP BY决定了汇总粒度。如果后续要按一级类目分析，可以在 DWS 之上再建一层粗粒度汇总，或者直接在 ADS 层做上卷。

3.3 DWD 宽表化与维度冗余的取舍

DWD 层相对好设计，核心是基于维度建模，冗余维度属性，降低频繁关联，提升基础数据模型的易用性和复用性。文档建议 DWD 以星型模型为主，通过维度冗余和信息完善度提升易用性。但冗余不是越多越好，文档在成本与性能平衡原则里提到：适当的数据冗余换取查询和刷新性能，不宜过度冗余与数据复制。

我一般会这样判断：如果某个维度属性在 80% 以上的下游查询中都会被用到，就冗余到 DWD；如果只有少数场景用，就留在 DIM 里按需关联。另外，DWD 层要严格遵守层次依赖，只引用 ODS、DIM 和部分 DWD，不能引用 DWS 或 ADS。这一点在文档里被反复强调，因为反向引用会让整个数仓的依赖关系变成一团乱麻。

4. ADS 层与应用集市：需求驱动与共性下沉的平衡

4.1 ADS 层的定位与设计原则

ADS 层面向应用逻辑做数据加工，存放数据产品个性化的统计指标，直接对接数据消费者，是产品、运营可以直接感知的一层。文档给 ADS 层的定位是：根据特定业务诉求，按业务角度组织数据，快速满足业务需求。核心关注研发效率、口径一致性，以及核心应用的稳定性。

ADS 层设计有几个原则。需求驱动，按需最小原则设计，除非有明确的业务延续，否则不做过度的扩展设计。划分集市域，以高内聚低耦合原则对集市进行划分，让单集市数据研发聚焦在某一领域的业务需求实现，集市间避免互相依赖。共性抽象下沉，ADS 也可以抽象出公共部分，通过依赖 ADS 数据提升开发效率。减少对 ODS 的依赖，降低源系统变更带来的改造成本。

提示：ADS 层最容易犯的错是“什么都往里面塞”。我见过一个 ADS 表有 200 多个字段，下游根本不知道每个字段什么含义。ADS 表应该专表专用，场景间松耦合。

4.2 应用集市划分与依赖管理

应用集市划分的核心是高内聚低耦合。文档建议按业务领域划分集市，比如交易集市、流量集市、用户集市。每个集市内部可以有自己的 ADS 表，但集市之间应该避免互相依赖。如果两个集市确实有共性逻辑，应该下沉到公共层，而不是在 ADS 之间互相引用。

减少对 ODS 的依赖是 ADS 设计的另一个重点。文档明确说：减少直接引用 ODS 表，降低源系统变更带来的改造成本。架构合理上考虑，公共层针对复用性场景进行模型沉淀，当源系统变更时，通过公共层适应性改造屏蔽下游变更。这意味着 ADS 层应该尽量引用 DWD 或 DWS，而不是直接读 ODS。

下面这段 SQL 展示的是 ADS 层如何从 DWS 获取数据，而不是从 ODS 直接加工。

-- ADS 层：面向具体报表需求，从 DWS 获取数据 INSERT OVERWRITE TABLE ads_trade_user_summary_1d PARTITION (dt='${bizdate}') SELECT user_id, SUM(order_cnt) AS total_order_cnt, SUM(order_amt) AS total_order_amt, SUM(paid_amt) AS total_paid_amt FROM dws_trade_user_sku_1d WHERE dt = '${bizdate}' GROUP BY user_id;

这里 ADS 表从 DWS 表汇总，而不是从 ODS 或 DWD 直接加工。好处是 DWS 已经做了口径统一和粒度抽象，ADS 只需要按应用需求做最后一步聚合。如果源系统订单表结构变更，只需要调整 ODS 到 DWD 的加工逻辑，ADS 不受影响。

4.3 需求驱动与过度设计的边界

文档强调 ADS 层要需求驱动，按需最小原则设计。但实际工作中，业务需求往往不明确，或者经常变化。我的经验是：先按当前明确的需求建表，预留扩展字段但不要过度冗余。如果业务说“以后可能要看某个维度”，那就等真正需要时再加，而不是提前把字段都塞进去。

过度设计的另一个表现是 ADS 表粒度太细。比如业务只需要按天汇总，却建了小时粒度的 ADS 表，结果数据量巨大，查询反而慢。文档里提到成本与效率要有一个权衡，数据量小的场景可以优先构建 DWD 再构建 DWS，数据量大的场景可以优先构建粗粒度 DWS，DWD 采用水平拆分。这个思路同样适用于 ADS：按实际查询需求决定粒度，不要为了“可能有用”而过度加工。

5. 避坑与排查：数仓模型设计中最容易翻车的五件事

5.1 分层边界模糊，ADS 直接读 ODS

现象：ADS 表直接引用 ODS 表，源系统字段变更后 ADS 任务大面积报错。原因：为了快速交付，跳过公共层直接加工，导致 ADS 与 ODS 强耦合。解决：强制 ADS 层只引用 DWS、DWD、DIM，如果确实需要 ODS 数据，先在公共层沉淀。文档里明确说“减少直接引用 ODS 表，降低源系统变更带来的改造成本”，这条要写进代码审查清单。

5.2 DWD 反向引用 DWS 或 ADS

现象：DWD 表里出现了对 DWS 或 ADS 的依赖，调度依赖图出现环。原因：开发人员为了复用已有汇总逻辑，直接引用下游表。解决：DWD 只允许引用 ODS、DIM 和部分 DWD。文档里强调“dwd 应严格遵守层次依赖，理论上只可引用 ODS、DIM 和部分 DWD 数据，不可引用处于下游层次的 ADS 等数据”。一旦发现反向引用，立即重构，把公共逻辑下沉到 DWD 或 DWS。

5.3 数据域划分不明确导致数据冗余

现象：同一份数据在多个域里重复存储，口径还不一致。原因：数据域划分没有覆盖所有业务过程，或者划分太粗。解决：文档建议数据域要随业务发展调整，不能大一统地粗略划分。我一般会先梳理业务过程清单，再按业务过程归属划分数据域，确保每个业务过程只属于一个域。如果发现跨域重复，就把公共逻辑下沉到 DWS。

5.4 命名不统一导致下游无法理解

现象：同一个指标在不同表里叫order_amt、order_amount、pay_amount，下游不知道该用哪个。原因：没有统一的命名规范，或者规范没有强制执行。解决：文档里提到“相同的字段含义在不同表中字段命名必须相同，必须使用规范定义中的名称”。我一般会在建模阶段先定好指标字典，所有表引用字典里的字段名，代码审查时检查命名一致性。

5.5 DWS 过度沉淀导致成本失控

现象：DWS 表数量爆炸，很多表只有一两个下游任务在用，存储和计算成本居高不下。原因：为了“复用”而沉淀，没有判断是否真有共性。解决：文档里说“不能为了加工 DWS 而加工 DWS 数据，要基于是否是业务的核心指标判断是否要沉淀公共层”。我一般会定期 review DWS 表的访问热度，如果一张表连续一个月只有一两个下游任务，就考虑下线或合并到 ADS。

6. 进阶技巧：用总线矩阵和指标字典把模型设计变成可验证的流程

总线矩阵和指标字典是文档里提到但容易被忽略的两个工具。总线矩阵用来明确业务过程所属数据域，以及业务过程与分析维度的关系。指标字典用来统一原子指标和派生指标的定义。这两个工具用好了，模型设计就从“凭经验”变成“可验证”。

我一般会先画一张总线矩阵表，行是业务过程，列是分析维度，交叉点标记是否有关联。比如交易业务过程关联用户、商品、时间、地区等维度。这张表能帮我在建模前就发现哪些维度是共用的，哪些业务过程是孤立的。下面是一个简化的总线矩阵示例。

指标字典则用来定义每个指标的原子性和派生关系。比如“订单金额”是原子指标，“近 7 天订单金额”是派生指标，由原子指标加时间周期修饰。文档里说“明确原子指标与派生指标”，这一步做好了，DWS 和 ADS 的口径一致性就有保障。

验证模型设计是否合理，我一般会走一遍“从 ADS 反推”的流程：随便挑一个 ADS 表，看它引用了哪些 DWS 或 DWD，再往上追溯是否最终都落到 ODS 和 DIM，有没有反向引用或跨层引用。如果整条链路清晰，没有环，没有 ADS 直接读 ODS，那模型设计基本合格。这个习惯我坚持了三年，每次新模型上线前都强制走一遍，省下了无数次重构的后悔药。希望帮到你。

本文还有配套的精品资源，点击获取