数仓入门：给小白的一次系统科普

很多人第一次接触数仓时，会同时看到一大堆缩写：

ODS、DWD、DWS、ADS、ETL、维度表、事实表、离线数仓、实时数仓。

这些词单独看都不短，放在一起更容易让人有点发懵。其实数仓并不是“神秘的大数据系统”，它本质上是在解决一个很实际的问题：

业务系统里虽然有很多数据，但这些数据往往分散、混乱、不统一，不能直接拿来稳定做分析、报表、指标和决策，所以需要一个专门的地方把数据整理好。

这个“专门整理分析数据的地方”，就是数据仓库，简称数仓。

先用一句话理解数仓

如果把业务系统比作“前线作战”，那数仓更像“后方情报中心”。

• 业务库负责支撑线上交易、下单、支付、登录
• 数仓负责沉淀、清洗、汇总、分析数据

业务库关注的是“事务处理要快、要准、要能并发”。
数仓关注的是“历史数据要全、口径要统一、分析要方便”。

所以，数仓一般不是给用户直接下单用的，而是给下面这些场景用的：

• BI 报表
• 经营分析
• 用户画像
• 推荐、风控、营销等数据支持
• 运营看板
• 管理层指标

为什么不能直接查业务数据库

这是很多小白最容易问的问题。

答案是：有时候能查，但不能长期靠它。

原因主要有四类。

1. 业务库是为交易设计的，不是为分析设计的

业务库一般追求：

• 单条查询快
• 写入快
• 事务一致性强
• 支撑大量在线请求

但分析场景经常是：

• 查很长时间范围的数据
• 做多表关联
• 做聚合统计
• 跑复杂指标

如果直接在业务库上频繁跑复杂 SQL，很容易把线上系统拖慢。

2. 业务数据口径经常不统一

比如“新增用户数”这个指标，不同人可能会有不同理解：

• 注册成功就算新增
• 首次激活才算新增
• 首次下单才算有效新增

如果没有统一口径，不同部门拉出来的数据就会对不上。
数仓的重要作用之一，就是把指标定义统一下来。

3. 业务表结构通常是为功能服务的

业务表设计时，优先考虑的是功能实现，比如订单创建、支付回调、库存扣减。
它未必适合直接做分析。

例如一个运营同学想看：

• 某渠道近 30 天下单转化率
• 某类用户的复购率
• 某地区按周统计的支付成功金额

这些分析往往需要把多个业务系统的数据拉通、清洗、关联，再形成统一主题。

4. 业务库不适合沉淀长期历史

很多业务系统为了性能，会归档旧数据、删中间表、变更字段。
但数仓分析往往非常依赖历史趋势。

比如：

• 去年同期对比
• 月度趋势
• 留存分析
• 生命周期分析

这些都要求数据长期、稳定、可追溯。

数仓到底在做什么

可以把数仓工作理解成四步：

1. 把原始数据收进来
2. 把脏乱差的数据清洗整理
3. 按主题做明细与汇总
4. 对外提供报表、指标、查询结果

如果用一张最基础的数据流转图来表示，大概是这样：

        业务系统 / 日志 / 第三方数据
          |
          v
      ODS 原始层
          |
          v
      DWD 明细层
          |
          v
      DWS 汇总层
          |
          v
      ADS 应用层
          |
          v
 BI看板 / 报表 / 指标接口 / 数据服务
      

这是最常见的一条主线。你以后看到大部分数仓介绍，基本都绕不开这几层。

数仓分层到底是什么意思

分层的本质，是让不同加工阶段的数据放在不同位置，避免所有逻辑揉成一团。

你可以把它理解成“数据加工流水线”。

ODS：原始数据层

ODS 全称一般是 Operational Data Store。

这一层的核心特点是：

• 离源头最近
• 尽量保留原始结构
• 主要用于接数据，不做太多业务加工

比如订单系统原始表长什么样，进 ODS 后通常也大致长什么样。

ODS 常见来源：

• MySQL 业务库同步
• App / Web 行为日志
• Kafka 消息
• 第三方平台数据
• Excel / CSV / API 导入数据

ODS 的价值不是“分析方便”，而是“先把原材料稳定接住”。

可以把它理解成仓库里的“原材料区”。

DWD：明细数据层

DWD 全称一般是 Data Warehouse Detail。

这一层会在 ODS 的基础上做比较重要的清洗和标准化，比如：

• 去重
• 脏数据修正
• 字段类型统一
• 补充业务标识
• 拆分事件
• 统一时间格式

这一层的核心仍然是“明细”，也就是每一条数据通常都还保留较细粒度。

例如：

• 每一笔订单
• 每一次支付
• 每一条点击行为
• 每一次登录记录

你可以把 DWD 理解成“可分析的干净明细层”。

很多分析工作，最终都会落到 DWD，因为它信息最完整，也最接近真实业务事件。

DWS：汇总数据层

DWS 全称一般是 Data Warehouse Service，也常被理解成主题汇总层。

这一层的重点是：

• 按主题组织
• 对明细做轻度到中度聚合
• 让常用分析更高效

例如把订单明细按天、按用户、按商品、按地区进行汇总，形成：

• 用户日下单统计
• 商品日销售统计
• 城市周支付汇总
• 渠道日转化汇总

DWS 的目的不是“给最终用户直接看”，而是“把通用分析能力沉淀下来”。

也就是说，DWS 是很多指标复用的中间层。

ADS：应用数据层

ADS 全称一般是 Application Data Service。

这一层是最接近业务使用方的一层，通常直接服务于：

• 看板
• BI 报表
• 固定指标查询
• 运营后台
• 管理驾驶舱

ADS 的数据一般是“面向具体应用场景”设计的。

比如：

• 首页核心经营指标宽表
• 某业务线日监控报表
• 某产品转化漏斗结果表
• 某领导专题分析报表

如果说 DWS 是“可复用的公共半成品”，那 ADS 更像“可以直接端给使用方的成品”。

一张图看懂 ODS、DWD、DWS、ADS

这四层不是绝对固定的标准，不同公司名字和拆法会有差异，但思想基本一致。

什么是 ETL / ELT

讲数仓时，ETL 几乎一定会出现。

ETL 是：

• Extract：抽取
• Transform：转换
• Load：加载

意思是：把数据从源头抽出来，做加工转换，再放进目标系统。

传统数仓更常说 ETL。
现在也经常说 ELT：

• 先抽取
• 先加载到数仓
• 再在数仓内部转换

区别可以粗略理解为：

• ETL：先加工，再入仓
• ELT：先入仓，再加工

随着云数仓和大数据平台能力变强，ELT 越来越常见，因为它更方便保留原始数据，也更灵活。

什么是事实表和维度表

这是数仓里另一个核心概念。

事实表

事实表记录的是“发生过什么业务事实”。

比如：

• 一笔订单
• 一次支付
• 一次点击
• 一次曝光

事实表通常有两个特点：

• 数据量大
• 会不断新增

事实表里常见字段：

• 用户 ID
• 商品 ID
• 时间
• 金额
• 数量
• 状态

维度表

维度表记录的是“如何描述这些事实”。

比如：

• 用户维度：性别、年龄、城市、注册渠道
• 商品维度：类目、品牌、价格带
• 时间维度：天、周、月、季度
• 地区维度：省、市、区

维度表的作用，是给事实表提供分析视角。

一个简单例子

比如你有一张订单事实表：

你还有一张用户维度表：

还有一张商品维度表：

把它们关联起来之后，你就能分析：

• 哪个城市下单金额最高
• 哪个渠道来的用户更容易购买
• 哪个品类转化更好

所以，事实表回答“发生了什么”，维度表回答“从什么角度看这件事”。

什么是维度建模

维度建模是一种非常常见的数仓建模方法，核心思想是：

围绕业务过程建立事实表，再围绕分析视角建立维度表。

它的优点是：

• 结构容易理解
• 适合分析场景
• 方便做聚合和报表

最常见的模型是星型模型。

                用户维度
           |
地区维度 - 订单事实表 - 商品维度
           |
        时间维度
      

中间是一张事实表，四周是多个维度表，看起来像星星，所以叫星型模型。

对于小白来说，先理解这句话就够了：

维度建模就是把“业务事件”和“分析视角”拆开来组织。

什么是宽表

宽表是数仓里很常见的一种结果形态。

所谓宽表，就是把很多分析需要的字段提前拼到一张表里，减少下游频繁联表。

例如一张用户订单宽表里，可能同时包含：

• 用户基础信息
• 订单信息
• 商品信息
• 渠道信息
• 标签信息

这样做的好处是：

• 查询更方便
• 下游使用门槛更低
• BI 报表开发更快

代价是：

• 冗余字段更多
• 维护成本更高
• 口径变更时影响面可能更大

所以宽表不是“越宽越好”，而是看具体应用场景。

离线数仓和实时数仓有什么区别

离线数仓

离线数仓通常按小时、按天调度任务。

比如：

• 每天凌晨跑前一天的数据
• 每小时汇总一次订单

它的特点是：

• 成本相对低
• 适合大批量处理
• 对时效要求没那么高

常见场景：

• T+1 报表
• 历史趋势分析
• 周报、月报
• 经营复盘

实时数仓

实时数仓更强调低延迟。

比如：

• 用户刚下单，几分钟内看板就更新
• 风控规则秒级生效
• 实时监控大屏快速刷新

它的特点是：

• 时效高
• 架构更复杂
• 对链路稳定性要求更高

常见场景：

• 实时监控
• 实时推荐
• 实时风控
• 活动大盘

一句话区分

很多公司并不是二选一，而是离线和实时并存。

一条典型的数据流转链路

为了把概念串起来，我们看一个“订单分析”的简单例子。

第一步：业务数据产生

用户在 App 上下单，订单系统、支付系统、埋点系统都会产生数据：

• 订单表
• 支付表
• 用户行为日志

第二步：进入 ODS

这些原始数据被同步到 ODS。

这时主要目标是：

• 不丢数据
• 稳定接入
• 保留原貌

第三步：进入 DWD

在 DWD 层做清洗与规范：

• 去重订单
• 统一时间格式
• 标准化状态字段
• 关联业务主键

得到“可信明细数据”。

第四步：进入 DWS

再做公共汇总，比如：

• 用户天粒度下单次数
• 商品天粒度销量
• 渠道天粒度支付金额

第五步：进入 ADS

最后做面向业务的结果表：

• 每日经营总览
• 渠道转化报表
• 重点商品销售看板

这时 BI、看板、数据接口就可以直接使用这些数据。

数仓不只是存表，它还包含很多工程环节

很多人以为数仓就是“写 SQL 建几张表”。其实真正的数仓工程要比这完整得多。

通常至少包括这些部分：

• 数据接入
• 表设计
• 分层建模
• 任务调度
• 数据质量校验
• 指标口径管理
• 权限控制
• 任务监控报警
• 血缘分析
• 成本治理

1. 数据接入

要解决：

• 数据从哪里来
• 怎么同步
• 多久同步一次
• 会不会丢

2. 任务调度

要解决：

• 哪张表先跑
• 哪张表后跑
• 失败了怎么重试
• 上游没到下游能不能跑

3. 数据质量

要解决：

• 今天数据量是不是异常
• 主键是否重复
• 空值是否超标
• 指标波动是否异常

4. 数据治理

要解决：

• 表太多怎么管理
• 字段什么意思
• 谁在用这张表
• 指标定义是否统一

所以数仓是“数据工程体系”，不是单纯的“几张统计表”。

常见角色分别在做什么

数仓相关工作通常会涉及多种角色。

数据开发 / 数仓开发

主要负责：

• 数仓分层设计
• SQL / Spark / Flink 开发
• 宽表与指标表建设
• 调度任务开发

数据分析师 / BI

主要负责：

• 报表分析
• 指标解读
• 业务洞察
• 可视化展示

数据产品经理

主要负责：

• 指标体系规划
• 数据需求梳理
• 数据产品设计
• 业务口径协调

算法 / 推荐 / 风控团队

主要负责消费数仓数据，用于：

• 特征构建
• 训练数据准备
• 实时决策支持

小白最容易混淆的几个概念

数仓和数据库的区别

数据库是大类概念。
数仓是数据库/数据平台的一种应用形态，更偏分析。

数仓和数据湖的区别

可以粗略理解为：

• 数据湖更强调“先收集各种原始数据”
• 数仓更强调“面向分析的结构化建模和指标体系”

很多公司实际会把两者结合。

数仓和 BI 的区别

• 数仓负责准备和组织数据
• BI 负责展示和分析数据

可以理解成：

学数仓时可以先抓住哪条主线

如果你是小白，建议先按下面这条学习顺序来理解：

1. 为什么业务库不能直接做分析
2. 数仓的目标是什么
3. ODS、DWD、DWS、ADS 分别做什么
4. 什么是事实表、维度表
5. 什么是离线和实时
6. 一条业务数据如何从源头走到报表
7. 什么是统一口径、调度、质量、治理

只要这条主线通了，后面再学：

• Hive / Spark / Flink
• Kafka
• 调度平台
• 指标平台
• 实时链路

就会顺很多。

一份适合记忆的总图

        数据源
  - MySQL 业务库
  - 日志
  - 第三方平台
  - 消息流
      |
      v
ODS 原始层
  - 接住数据
  - 保留原貌
      |
      v
DWD 明细层
  - 清洗
  - 去重
  - 标准化
  - 保留业务明细
      |
      v
DWS 汇总层
  - 按主题聚合
  - 公共指标沉淀
      |
      v
ADS 应用层
  - 面向看板、报表、查询接口
      |
      v
业务使用方
  - BI
  - 运营
  - 管理层
  - 算法/推荐/风控
      

最后怎么真正理解数仓

不要把数仓只看成一堆缩写。

更好的理解方式是把它想成一句完整的话：

数仓就是把分散的原始业务数据，按照统一规则沉淀、清洗、建模、汇总，最终稳定地服务给分析、报表、指标和数据应用。

当你能把这句话和下面这些概念对应起来时，说明你已经真正入门了：

• 原始数据怎么进来
• 为什么要分层
• 明细和汇总的区别
• 事实和维度的区别
• 离线和实时的区别
• 指标为什么要统一口径
• 为什么数仓需要调度、质量和治理

如果后面你愿意继续深入，下一步最值得展开的主题通常是：

• 维度建模怎么落地
• 宽表怎么设计
• 指标体系怎么建
• 离线链路和实时链路怎么搭
• 常见数仓面试题怎么答