1. 概述

数据仓库设计是大数据数仓建设的核心环节，直接决定了后续数据模型的质量、查询性能以及业务支撑能力。良好的数据仓库设计需要对业务有深刻理解，同时掌握维度建模方法论和分层架构思想。本章围绕数据仓库的分层规划和构建流程两个核心主题展开，从数据调研到汇总模型设计，完整覆盖数仓建设的全链路方法论。

---

2. 数据仓库分层规划

数据仓库分层是数仓架构设计的第一步，其核心目的是通过合理的层次划分，实现数据的解耦、复用和可管理性。业界主流的分层方案通常将数仓划分为以下四层：

ODS层（原始数据层 / Operational Data Store）

ODS层是数仓的最底层，直接对接业务系统的原始数据。该层的核心原则是：

• 保持原样：数据结构与业务系统保持一致，不做任何清洗或转换
• 全量/增量同步：根据业务特点选择全量同步（小表）或增量同步（大表）
• 历史归档：保留数据变更的历史快照，支持时间回溯

ODS层的作用相当于数据仓库的"数据湖入口"，所有上游数据首先进入该层，后续各层的加工都以ODS层为源头。

DWD层（数据明细层 / Data Warehouse Detail）

DWD层是数仓的核心加工层，在ODS层的基础上进行数据清洗、转换和维度退化：

• 数据清洗：去除脏数据、空值处理、格式标准化、去重
• 维度退化：将常用维度字段冗余到事实表中，减少后续关联查询（如将商品名称、分类直接冗余到订单明细表）
• 事实表明细化：将业务过程拆解为原子级别的事实记录，每一条记录代表一个不可再分的业务事件
• 统一编码：将各业务系统中不一致的编码体系（如性别"0/1"和"M/F"）统一为标准值

DWD层的设计质量直接决定了上层数据模型的稳定性和可维护性。

DWS层（数据汇总层 / Data Warehouse Summary）

DWS层面向跨主题域的公共汇总需求，对DWD层数据进行轻度汇总：

• 公共粒度：按照"天+维度"的粒度进行聚合（如"每天每个用户的下单金额汇总"）
• 跨域复用：汇总结果同时服务于报表、推荐、风控等多个下游场景
• 减少重复计算：将高频使用的汇总逻辑下沉到DWS层，避免各ADS应用重复计算

DWS层的关键价值在于复用性——同一张汇总表可能被多个ADS层报表引用，从而实现"一次计算、多处使用"。

ADS层（数据应用层 / Application Data Service）

ADS层是数仓的最上层，直接面向具体的业务应用场景：

• 报表数据：为BI报表、管理看板提供即席查询数据
• 指标计算：计算业务所需的各类KPI指标（如GMV、DAU、转化率）
• 数据推送：将计算结果写入MySQL、Redis等在线存储，供前端应用直接读取

ADS层的特点是与业务强绑定，通常按照具体报表或应用的需求来设计表结构。

分层原则总结

层级	数据粒度	数据来源	核心职责	面向场景
ODS	最细（原始记录）	业务数据库、日志	原始数据接入	数据归档
DWD	原子事件	ODS层	清洗转换、维度退化	明细查询
DWS	轻度汇总	DWD层	公共汇总、跨域复用	多场景共用
ADS	应用粒度	DWS/DWD层	指标计算、报表输出	具体应用

分层的核心思想是**“高内聚、低耦合”**：每一层只依赖其下一层，层与层之间通过明确的接口（表）进行数据传递，任何一层的变更不会向上蔓延。

---

3. 数据仓库构建流程

数据仓库的构建不是一蹴而就的，而是一个从业务理解到模型落地的系统性工程。以下按照标准流程逐步展开。

3.1 数据调研

数据调研是数仓建设的起点，目的是全面了解业务系统的数据现状：

1. 业务系统梳理：摸清企业有哪些业务系统（ERP、CRM、WMS、APP等），各系统的数据库类型、表数量、数据量级
2. 数据结构分析：获取各系统的ER图、核心表的DDL语句，理解表间关系和字段含义
3. 数据质量评估：检查数据完整性、一致性、准确性，识别脏数据和缺失字段
4. 数据量与增长趋势：统计各表的数据量、日增量、历史数据量，为后续存储和计算资源规划提供依据
5. 同步策略确定：根据数据特点确定每张表的同步方式（全量/增量）、同步频率（实时/小时/天）

数据调研的成果通常是一份详细的数据调研报告，包含表清单、字段说明、数据量统计、质量问题清单和同步策略建议。

3.2 明确数据域

数据域是从业务视角对数据进行主题划分，将零散的表按照业务含义归类到不同的域中：

• 交易域：下单、支付、退款、结算等交易相关数据
• 用户域：用户注册、登录、画像、会员等级等用户相关数据
• 商品域：商品、品类、品牌、SPU/SKU等商品相关数据
• 营销域：优惠券、活动、促销、广告投放等营销相关数据
• 物流域：发货、配送、签收、退货物流等物流相关数据
• 内容域：文章、视频、评论、点赞等内容相关数据（适用于内容型业务）

数据域的划分原则：

• 高内聚：同一域内的数据在业务含义上紧密相关
• 低耦合：不同域之间的数据尽量独立，通过公共维度关联
• 稳定性：数据域的划分应相对稳定，不随业务细节频繁调整

3.3 构建业务总线矩阵

业务总线矩阵（Bus Matrix）是Kimball维度建模方法论中的核心工具，包含维度模型所需的所有事实（业务过程）以及维度，以及各业务过程与各维度的关系。矩阵的行是一个个业务过程（按数据域分组），矩阵的列是一个个维度，行列的交点表示业务过程与维度的关系。

以电商场景为例，业务总线矩阵如下：

数据域	业务过程	时间	用户	商品	地区	支付方式	退单类型	退单原因类型
交易域	加购物车	√	√	√
交易域	下单	√	√	√	√
交易域	取消订单	√	√	√	√
交易域	支付成功	√	√	√		√
交易域	退单	√	√	√	√		√
交易域	退款成功	√	√	√	√	√
用户域	注册	√	√
营销域	领取优惠券		√
营销域	使用优惠券(下单)		√
营销域	使用优惠券(支付)		√
互动域	收藏商品	√		√
互动域	评价	√	√	√

构建步骤：

1. 纵向列出所有业务过程：从业务调研中提炼出核心的业务动作，并按数据域分组（如交易域下的下单、支付成功、退单等）
2. 横向列出所有维度：梳理出各业务过程中涉及的维度（如时间、用户、商品、地区、支付方式等）
3. 标记交叉关系：在每个业务过程与维度的交叉格中标记"√"，表示该业务过程关联该维度
4. 识别公共维度：发现跨多个业务过程共享的维度，这些维度需要作为一致性维度统一设计

核心理解：

• 一个业务过程对应维度模型中的一张事务型事实表
• 一个维度则对应维度模型中的一张维度表
• 所以构建业务总线矩阵的过程就是设计维度模型的过程
• 但需要注意的是，总线矩阵中通常只包含事务型事实表，另外两种类型的事实表（快照事实表、累积快照事实表）需单独设计

3.4 明确统计指标

在模型设计之前，需要明确业务关心的统计指标，这是模型设计的输入和验证标准：

指标分类：

分类	说明	示例
原子指标	不可再拆分的基础度量	下单金额、支付笔数
派生指标	原子指标+时间周期+修饰词	近7天下单金额、新客支付笔数
复合指标	多个原子指标的运算结果	客单价=支付金额/支付笔数

指标定义要素：

• 名称：统一命名规范，如"{时间周期}{修饰词}{原子指标}"
• 业务口径：明确的计算逻辑，如"下单金额=订单表中状态为已下单的订单金额之和"
• 数据来源：对应的DWD/DWS表和字段
• 更新频率：T+1/实时/小时级

明确统计指标的意义在于：模型设计要以指标为导向，确保设计出的模型能够支撑所有业务指标的计算需求。

3.5 维度模型设计

维度模型设计是数仓建设的核心环节，采用Kimball维度建模方法论，将业务数据组织为事实表+维度表的结构。

维度建模的三个步骤：

第一步：选择业务过程

业务过程是企业运营中的关键事件，如"用户下单"“用户支付”“商家发货”。每个业务过程对应一张事实表。

第二步：声明粒度

粒度是事实表中每一行数据所代表的业务含义。例如：

• “一个订单中的一件商品”——订单明细粒度
• “一个订单”——订单粒度
• “一个用户一天”——用户天粒度

粒度的选择原则：尽可能选择最细粒度，因为细粒度数据可以向上汇总，但粗粒度数据无法向下拆分。

第三步：确定维度

维度是观察和分析业务的角度，常见的维度包括：

维度	说明	典型字段
用户维度	描述用户属性	用户ID、昵称、等级、注册时间
商品维度	描述商品属性	商品ID、名称、分类、品牌、价格
时间维度	描述时间属性	日期、星期、月份、季度、是否节假日
地域维度	描述地理属性	省、市、区、商圈
渠道维度	描述来源属性	渠道名称、渠道类型、推广来源

事实表设计要点：

• 只包含度量值（可聚合的数值）和维度外键
• 度量值必须是可以累加或可计算的（如金额、数量、时长）
• 避免在事实表中存放维度描述字段（维度退化除外）

维度表设计要点：

• 包含维度的描述性属性（如商品名称、分类名称）
• 采用宽表设计，将相关属性冗余到同一张表中
• 使用**缓慢变化维（SCD）**策略处理维度属性的变更

常见模型类型：

星型模型（Star Schema）：
    ┌──────────────┐
    │   事实表      │
    └──┬──┬──┬──┬──┘
       │  │  │  │
    ┌──┘  │  │  └──
    │     │  │     │
  维度A  维度B 维度C 维度D

雪花模型（Snowflake Schema）：
    ┌──────────────
    │   事实表      │
    └──┬──┬──┬──┬──┘
       │  │  │  │
    ┌──┘  │  │  └──┐
    │     │  │     │
  维度A  维度B 维度C 维度D
    │              │
    ──子维度      └──子维度

• 星型模型：事实表直接关联所有维度表，结构简单、查询效率高，是数仓的首选模型
• 雪花模型：维度表进一步规范化拆分，减少数据冗余，但增加查询复杂度，一般不推荐

3.6 汇总模型设计

汇总模型设计是在维度模型的基础上，针对高频查询和性能优化需求，设计预聚合的汇总数据模型。

汇总模型的分类：

类型	说明	适用场景
轻度汇总	按1-2个维度聚合，保留较多维度信息	DWS层公共汇总表
高度汇总	按少量维度深度聚合，粒度较粗	ADS层报表汇总表
立方体汇总	多维度组合预计算（OLAP Cube）	多维分析、即席查询

汇总模型设计原则：

1. 以查询驱动：根据实际的高频查询模式来确定汇总粒度和汇总维度
2. 避免过度汇总：汇总粒度太粗会丢失细节信息，太细则失去汇总意义
3. 复用优先：同一汇总结果尽量服务于多个应用场景
4. 一致性保证：汇总结果与明细数据之间必须保持数值一致性

汇总模型示例（以电商场景为例）：

DWS层——用户日汇总表（dws_user_day）：
  - 粒度：用户 × 天
  - 度量：当日下单金额、下单笔数、支付金额、支付笔数、浏览商品数
  - 维度外键：用户ID、日期ID

DWS层——商品日汇总表（dws_product_day）：
  - 粒度：商品 × 天
  - 度量：当日销量、销售金额、浏览次数、加购次数
  - 维度外键：商品ID、日期ID

ADS层——每日经营看板（ads_daily_dashboard）：
  - 粒度：天
  - 度量：当日GMV、订单数、客单价、转化率、DAU
  - 维度外键：日期ID

---

关键要点总结

数据仓库设计是一套系统性的工程方法论，核心要点如下：

1. 分层规划是基础：ODS→DWD→DWS→ADS四层架构实现数据从原始到应用的有序流转，每层职责清晰、互不越界
2. 数据调研是前提：不了解业务数据的现状，就无法做出合理的模型设计
3. 数据域划分是框架：将散乱的表按照业务主题归类，建立全局数据视图
4. 业务总线矩阵是桥梁：连接业务过程和维度，识别公共维度和建模优先级
5. 指标定义是导向：以业务指标为驱动，确保模型设计"有的放矢"
6. 维度建模是核心：事实表+维度表的星型模型是数仓最经典的模型范式
7. 汇总模型是优化：预聚合设计提升查询性能，但需平衡粒度与复用性

掌握以上内容，就具备了从零开始设计一个企业级数据仓库的核心能力。后续的实践需要在具体业务场景中反复打磨，逐步形成适合自身业务的数仓设计规范。