通用的企业级数据仓（Data Warehouse）通常采用 “四层架构”（也有分为三层或五层的变体，但核心逻辑一致）。这种分层设计的目的是为了解耦、减少重复计算、保证数据口径一致性以及便于数据追溯。

以下是业界最通用的分层架构详解：

---

1. ODS 层 (Operational Data Store) —— 源数据层/贴源层

• 定义：这是数据进入数仓的第一层，数据结构与业务系统（如 MySQL 业务库、埋点日志）基本保持一致。
• 主要工作：
  • 同步：将业务数据库的数据（全量或增量）和日志数据同步到数仓（如 Hive/HDFS/S3）。
  • 备份：起到数据备份的作用，防止业务库数据丢失。
  • 分区：通常按日期（Day）进行分区存储。
• 特点：
  • “原汁原味”：不做清洗，或者只做最基础的格式转换（如 JSON 解析）。
  • 数据量大：保留历史所有数据。
• 表命名示例：ods_order_info_df (df代表日全量), ods_log_inc (inc代表增量)

2. DW 层 (Data Warehouse) —— 数仓层（核心层）

这一层是数仓的核心，通常会进一步细分为 DWD 和 DWS（有时中间还会加一个 DWM 层）。

2.1 DIM 层 (Dimension) —— 维度层

• 定义：存储公共的维度信息（环境、人、物）。
• 内容：用户维表、商品维表、地区维表、时间维表等。
• 特点：全公司公用，通常采用缓慢变化维（SCD）策略来记录历史变化。
• 表命名示例：dim_user_info, dim_sku_info

2.2 DWD 层 (Data Warehouse Detail) —— 明细数据层

• 定义：基于 ODS 层进行清洗、规范化后的明细数据。
• 主要工作 (ETL)：
  • 清洗：去除脏数据、空值处理、异常值处理。
  • 规范化：统一字段命名、统一枚举值编码（如性别 0/1 转为 M/F）。
  • 维度退化：将部分维度信息整合到事实表中（例如把商品一级二级分类直接放到订单表中），减少后续关联查询。
• 特点：
  • 粒度最细：保持与业务交易一致的粒度（如每一行是一条订单明细）。
  • 主题建模：通常采用星型模型构建。
• 表命名示例：dwd_fact_order_detail

2.3 DWS 层 (Data Warehouse Service / Summary) —— 汇总数据层/服务层

• 定义：基于 DWD 层，按照特定的业务主题（Subject）进行聚合汇总。
• 主要工作：
  • 宽表制作：将多个相关的 DWD 表关联，形成“大宽表”（如用户行为宽表：包含用户当天的下单、支付、浏览、点击等所有行为）。
  • 轻度汇总：按天、按用户、按商品进行聚合（Group By）。
• 特点：
  • 以“对象”为核心：如“用户主题”、“商品主题”。
  • 指标统一：计算出通用的原子指标（如：用户单日支付金额、商品单日销量）。
• 表命名示例：dws_user_action_day_count (用户行为日统计)

---

3. ADS 层 (Application Data Store) —— 应用数据层

• 别名：APP 层、DM 层 (Data Mart / 数据集市)。
• 定义：面向具体的业务应用场景，提供最终的数据报表。
• 主要工作：
  • 基于 DWS 或 DWD 计算出最终的 KPI 指标（如 GMV、DAU、转化率）。
  • 数据通常会推送到性能较高的数据库中（如 MySQL, ClickHouse, Doris, Elasticsearch）供 BI 报表、大屏或业务系统直接查询。
• 特点：
  • 高度聚合：数据量通常较小。
  • 业务强相关：只包含业务部门需要的字段，不包含无关明细。
• 表命名示例：ads_gmv_trend_report, app_user_retention

---

总结图示

为什么要这样分层？

1. 空间换时间：通过预先计算（DWS层），避免每次查询报表都从海量明细数据（ODS/DWD）重新计算，极大提升查询速度。
2. 解耦与复用：DWS 层构建了公共指标，不同的业务部门（ADS层）可以复用同一个 DWS 表，避免重复开发。
3. 口径统一：所有报表都基于 DWS 层的统一口径计算，避免“财务算出的销售额”和“运营算出的销售额”对不上的尴尬。
4. 血缘追溯：当数据出现问题时，可以清晰地一层层排查是源头问题、清洗问题还是计算逻辑问题。