DIM 层（Dimension Layer，公共维度层） 是数据仓库架构（如阿里的 OneData 体系或 Kimball 维度建模）中非常关键的一层。

简单来说，DIM 层存放的是描述性数据，用来解释业务过程中的“环境”。如果说事实表（Fact Table）记录的是“发生了什么（比如下了一单）”，那么 DIM 层记录的就是谁（Who）、在哪里（Where）、什么时间（When）、什么商品（What）。

具体来说，DIM 层通常存放以下几类数据：

1. 核心业务实体数据 (Entities)

这是 DIM 层最主要的内容，对应业务中的具体对象。

• 用户/会员维表 (Dim_User):
  • 包含：用户ID、姓名、性别、年龄、手机号、注册时间、会员等级、所属行业、偏好标签等。
• 商品/SKU维表 (Dim_Sku):
  • 包含：商品ID、商品名称、品牌、重量、颜色、尺寸、上架时间、成本价等。
• 商家/店铺维表 (Dim_Shop):
  • 包含：店铺ID、店铺名称、主营类目、店铺星级、开店时长、法人信息等。

2. 时间维度数据 (Time/Date)

时间是数据分析中最常用的维度，通常会构建一张全局通用的时间维表。

• 日期维表 (Dim_Date):
  • 包含：日、周、月、季度、年。
  • 特殊属性： 是否周末、是否节假日（春节、国庆）、是否大促日（双11、618）、财政年度、星期几等。
  • 作用：方便分析师直接按“周”或“节假日”聚合数据，而不需要写复杂的日期函数。

3. 地理位置/区域数据 (Geography)

用于空间维度的分析。

• 地区维表 (Dim_Area):
  • 包含：国家、省份、城市、区县、街道、邮编、行政区划代码。
  • 层级关系： 明确的层级结构（中国 -> 浙江省 -> 杭州市 -> 余杭区）。

4. 组织架构与分类数据 (Hierarchy & Organization)

用于公司内部管理或商品归类的层级数据。

• 组织架构维表: 部门ID、部门名称、上级部门、负责人、所属事业群 (BG)。
• 商品类目维表: 一级类目（如家电）、二级类目（如电视）、三级类目（如OLED电视）。

5. 字典与码表数据 (Dictionaries/Lookups)

业务系统中各种状态码的解释。

• 订单状态维表: 10=未支付, 20=已支付, 30=发货, 40=完成, 50=取消。
• 支付方式维表: 1=支付宝, 2=微信, 3=银联。
• 注意：在大数据场景下，简单的码表有时会直接退化（冗余）到事实表中，或者合并到大宽表中，不一定单独建表。

---

DIM 层设计的关键特征（技术视角）

为了让数据更好用，DIM 层的数据通常具备以下特征：

1. 高基数与低基数并存：
   • 用户表可能有数亿行（高基数）。
   • 省份表可能只有几十行（低基数）。
2. 反规范化（Denormalization / 宽表化）：
   • 这是大数据数仓与传统关系型数据库最大的区别。
   • 例子： 在 DIM 层，我们通常不使用雪花模型（Snowflake Schema），而是使用星型模型（Star Schema）。
   • 做法： 会将“商品表”、“品牌表”、“三级类目表”合并成一张商品维度宽表。这样分析师在使用时，只需要查一张表就能获取品牌和类目信息，避免了大量的 JOIN 操作，提高查询性能。
3. 处理缓慢变化维 (SCD - Slowly Changing Dimensions)：
   • 维度属性是会随时间变化的（例如：用户从“北京”搬到了“上海”）。
   • DIM 层通常使用拉链表（SCD Type 2）来记录历史。
   • 记录方式： 增加 start_date 和 end_date 字段，你可以查询到该用户在 2022 年是“北京用户”，在 2023 年是“上海用户”。

总结

DIM 层存放的是企业一致性的、共享的、描述性的基础数据。

它的核心价值在于： 保证全公司看数据时口径一致（比如大家用的“一级类目”都是同一套标准），并简化下游（DWS/ADS）的开发难度。