1. 先说结论

数据库和数据仓库的根区别不是数据量，而是设计目标不同：

	数据库（Database）	数据仓库（Data Warehouse）
为谁设计	业务系统	分析决策
核心动作	增删改查（OLTP）	读与聚合（OLAP）
一句话定位	让业务跑起来	让数据说话

理解了这层，后面的技术差异都是这个定位的自然延伸。

2. 从一个场景说起

假设你在做电商：

• 数据库在干的事：用户下单 → 扣库存 → 记录支付状态 → 更新物流信息。每秒几千笔，每笔都要快、要准、不能错。
• 数据仓库在干的事：把过去 3 年所有订单拉出来，按地区、品类、时段交叉分析，看哪个品类的复购率在下滑。

一个是开车，一个是看仪表盘——都需要，但关注点完全不同。

---

3. 核心差异逐项对比

3.1 用途与负载类型

维度	数据库	数据仓库
负载类型	OLTP（联机事务处理）	OLAP（联机分析处理）
典型操作	INSERT / UPDATE / DELETE / SELECT	SELECT（大量聚合、JOIN）
单次操作数据量	少（1~几行）	大（百万~亿行扫描）
并发用户	多（数千~数万业务连接）	少（数十~数百分析师）
响应要求	毫秒级	秒级甚至分钟级可接受

关键理解：OLTP 追求"单次快"，OLAP 追求"大批量算得动"。

3.2 数据模型

数据库 — 关系模型（范式化）

核心目标是消除冗余、保证一致性，通常遵循第三范式（3NF）：

orders 表:     order_id | user_id | product_id | quantity | price | created_at
order_items 表: item_id | order_id | product_id | quantity | unit_price
products 表:   product_id | name | category | price
users 表:      user_id | name | email | region

优点：写入高效、无冗余、更新方便。
缺点：查询"华东区 2025 年 Q3 各品类销售额"需要多表 JOIN，性能很差。

数据仓库 — 维度模型（反范式化）

核心目标是查询方便、聚合快速，通常采用星型模型或雪花模型：

事实表（fact_sales）:
  sale_id | date_key | product_key | region_key | quantity | amount

维度表（dim_date / dim_product / dim_region）:
  date_key | year | quarter | month | day
  product_key | name | category | sub_category
  region_key | province | city | district

优点：查询直观、聚合高效、业务人员易理解。
缺点：数据冗余、存储空间大、不适合频繁更新。

3.3 数据流向：ETL 是桥梁

业务系统 DB  ──┐
              │    ETL / ELT       ┌──────────────┐
日志系统     ──┼── Extract ────────→│  Data        │──→ BI 报表
              │   Transform        │  Warehouse   │──→ 数据分析
第三方 API   ──┘   Load             │              │──→ 机器学习
                                   └──────────────┘

关键点：数据仓库的数据不是凭空产生的，它来自多个业务系统，经过清洗、转换、统一口径后汇总在一起。

3.4 时间维度

维度	数据库	数据仓库
关注的时间	当前状态（现在）	历史趋势（过去）
数据覆盖	当前有效数据	全量历史数据（数年）
更新方式	覆盖更新（UPDATE）	追加写入（INSERT / SCD）
典型问题	“这个用户现在的余额是多少？”	“过去 12 个月余额变化趋势如何？”

数据仓库的时间穿越能力是其核心价值之一——能回溯任意时间点的数据状态，这通过缓慢变化维度（SCD）技术实现。

3.5 存储与架构

维度	数据库	数据仓库
代表产品	MySQL、PostgreSQL、Oracle	Snowflake、BigQuery、Redshift、ClickHouse
存储格式	行存（Row-based）	列存（Columnar）
扩展方式	垂直扩展为主	水平扩展（MPP / 分布式）
索引策略	B+Tree、Hash 等，针对点查优化	分区、分桶、预聚合，针对扫描优化
成本	相对低	较高（存储+计算分离架构）

行存 vs 列存是性能差异的根本原因之一：

行存（数据库）：          列存（数据仓库）：
┌─────────────────┐     ┌──────┐┌──────┐┌────────┐
│ id | name | age  │     │ id   ││ name ││ age    │
│ 1  | 张三 | 25   │     │ 1    ││ 张三 ││ 25     │
│ 2  | 李四 | 30   │     │ 2    ││ 李四 ││ 30     │
│ 3  | 王五 | 28   │     │ 3    ││ 王五 ││ 28     │
└─────────────────┘     └──────┘└──────┘└────────┘
读一整行快（单条查询）    读一列快（聚合计算：AVG(age)）

查询 AVG(age) 时，行存要读出每行的全部字段再过滤；列存只读 age 列，I/O 量可能差 10~100 倍。

---

4. 数据仓库的分层架构

真实的数据仓库不是一张大表，而是分层的：

┌─────────────────────────────────────────────┐
│              ADS（应用数据层）                │  ← 面向业务的报表、指标
├─────────────────────────────────────────────┤
│              DWS（汇总数据层）                │  ← 按主题预聚合
├─────────────────────────────────────────────┤
│              DWD（明细数据层）                │  ← 清洗后的标准化明细
├─────────────────────────────────────────────┤
│              ODS（原始数据层）                │  ← 业务系统原始数据 1:1 同步
├─────────────────────────────────────────────┤
│              业务数据库 / 日志 / API          │  ← 数据源
└─────────────────────────────────────────────┘

每层各司其职：

• ODS：原样保留，可追溯
• DWD：统一口径、清洗脏数据、标准化字段
• DWS：按业务主题预聚合（如"每日分地区销售汇总"），加速查询
• ADS：面向具体应用场景，直接对接 BI 工具或数据产品

---

5. 常见误区辨析

误区一：“数据量大了就该上数据仓库”

❌ 数据量不是唯一标准。如果业务只需要实时查询当前状态，即使有 TB 级数据，数据库（配合读写分离、分库分表）可能更合适。

✅ 需要跨系统整合数据、做历史趋势分析、支撑 BI 报表时，才真正需要数据仓库。

误区二：“数据仓库会替代数据库”

❌ 两者是互补关系，不是替代关系。没有数据库就没有数据源，没有数据仓库就无法高效分析。

✅ 合理的架构是：数据库支撑业务运转，数据仓库支撑分析决策，ETL 把两者串联起来。

误区三：“数据湖 = 数据仓库”

	数据湖（Data Lake）	数据仓库（Data Warehouse）
数据类型	结构化 + 半结构化 + 非结构化	结构化
Schema	读时定义（Schema-on-Read）	写时定义（Schema-on-Write）
加工程度	原始数据	清洗转换后
用户	数据科学家、数据工程师	业务分析师
代表产品	S3 + Hive、Delta Lake、Iceberg	Snowflake、BigQuery、Redshift

数据湖更"自由"，但更易沦为"数据沼泽"；数据仓库更"严谨"，但灵活性受限。现代趋势是 湖仓一体（Lakehouse），两者融合。

---

6. 如何选择？

你的需求是什么？
│
├─ 实时事务处理、高并发读写、强一致性
│   → 数据库（MySQL / PostgreSQL / TiDB）
│
├─ 跨系统数据分析、历史趋势、BI 报表
│   → 数据仓库（Snowflake / BigQuery / ClickHouse）
│
├─ 存各种原始数据，后续再决定怎么用
│   → 数据湖（S3 + Hive / Delta Lake）
│
└─ 既要又要？分析+事务混合负载
    → HTAP 数据库（TiDB / OceanBase）
    或 湖仓一体（Databricks / StarRocks）

---

7. 总结

	数据库	数据仓库
一句话	让业务跑起来	让数据说话
设计目标	事务处理效率	分析查询性能
数据模型	范式化（3NF）	维度模型（星型/雪花）
操作类型	OLTP	OLAP
存储方式	行存	列存
时间视角	现在	历史
数据来源	业务自身产生	多系统汇聚（ETL/ELT）

不要问"哪个更好"，要问"我的场景需要什么"。大多数企业两者都需要，关键是搞清楚各自的位置和边界。

---

参考资源

• Ralph Kimball，《数据仓库工具箱》（The Data Warehouse Toolkit）
• Bill Inmon，《构建数据仓库》（Building the Data Warehouse）
• Google Cloud: Data Warehouse vs Database
• Martin Fowler, Data Lake vs Data Warehouse