在之前的文章中，我们已经深入探讨了数据 数据仓库核心：揭秘事实表与维度表的角色与区别 和 解锁数据潜能：深入理解数据仓库建模及其模型对比 。这两篇文章为我们奠定了数据仓库的基础知识，让我们对数仓的架构和模型有了初步的认识。

在本章中，我们将聚焦于维度表——维度建模中不可或缺的核心元素。维度表不仅为事实表提供了丰富的上下文信息，更是数据仓库查询性能和易用性的关键。本文将带你深入了解维度表的设计要点，帮助你构建一个高效、灵活且易于维护的数据仓库。

1. 引言

1.1基本概念

维度表则是用来描述事实的表，它提供了分析数据的上下文。维度表通常包含描述性的信息，如产品名称、客户信息、时间等。

维度表就是你观察该事物的角度, 维度表就像故事中的背景，它包含了描述事实表中数据的上下文信息，比如时间、地点、产品、顾客等等，这些信息帮助我们理解事实表中的数据。维度表通常描述了事实表中数据的各种属性，比如产品的类别，客户的地理位置等。

维度表就像是事实表的说明书。它们帮助我们理解事实表中的数字背后的故事。例如，我们可能会有一个产品维度表，它包含了产品的详细信息：

CREATE TABLE Product_Dimension (
    ProductID INT PRIMARY KEY,
    ProductName VARCHAR(255),
    Category VARCHAR(100),
    SupplierID INT
);

在这个产品维度表中，ProductID 是产品的唯一标识，它与事实表中的 ProductID 相匹配，ProductName 和 Category 提供了产品的描述性信息，SupplierID 可能与另一个维度表相关联。

具体维度表和事实表的区别可以看这篇文章 ：数据仓库核心：揭秘事实表与维度表的角色与区别

1.2 维度表定义

说回维度表，它承载着丰富的描述性信息，是连接事实表的桥梁。在维度表中，我们能够找到两样宝贵的东西：

• 主键：它是维度表的“身份证”，一个独特的标签，确保了每一行数据的唯一性。
• 描述性属性：这些属性是维度表的灵魂，它们描绘了维度的细节，比如时间的流逝、地点的特色、产品的特性等。

其就像一个精心编排的目录，它通过主键来确保每个条目都是独一无二的。这个主键就像是一把钥匙，不仅打开了数据的大门，还确保了与它相连的任何事实表之间的联系是牢固和完整的。主键有两种类型：代理键和自然键，它们都是用来标识维度表中的特定条目的。

• 想象一下，代理键就像是图书馆里的索引号，它没有特定的业务意义，但是它能够确保我们能够快速找到想要的书籍。在数据仓库中，代理键通常用来处理那些会随着时间变化的维度，比如缓慢变化维。这样，即使业务数据发生变化，代理键也能保持稳定，帮助我们追踪数据的历史。

• 而自然键则像是书的ISBN号，它与书的内容紧密相关，具有实际的业务意义。比如，对于商品这个维度来说，商品的自然键可能是商品ID，这个ID在业务中有着明确的含义。

有趣的是，对于前台应用系统来说，商品ID可能是代理键，因为它只是用来标识商品的一个符号。但对于数据仓库系统来说，商品ID则变成了自然键，因为它代表了商品的实际业务属性。

总的来说，无论是代理键还是自然键，它们都是数据仓库中不可或缺的部分，帮助我们确保数据的准确性和完整性。通过合理地使用这两种键，我们可以构建一个既灵活又稳定的数据仓库，为业务决策提供强有力的支持。

2. 设计方法

让我们以商品维度表的设计为例，一步步揭开维度设计的神秘面纱。

2.1 选择或新建维度

在构建维度表时，我们首先需要确保它在数据仓库中的唯一性。这意味着，对于商品这一维度，整个数据仓库中只能有一个商品维度表，以保证数据的一致性和准确性。

2.2 确定维度主维表

维度的主维表表通常是ODS层（操作数据存储）中的表，它与业务系统的表结构保持一致。例如，商品表jd_items_info，就是商品维度的主维表。

2.3 确定相关维表

数据仓库的设计遵循高内聚低耦合的原则。在确定了主来源表之后，我们还需要根据实际的业务需求，扩展商品的相关信息。这可能包括类目、所属卖家、所属店铺等维度。

高内聚原则：维度表中的属性应该高度相关。
低耦合原则：不同维度表之间的属性应该尽量独立。
一致性原则：相同含义的属性在不同维度表中应保持一致。
可理解性原则：维度表的命名和属性应该易于理解和使用。

2.14 确定维度属性

在主来源表和相关维表的基础上，我们开始创建或补充维度属性：

• 生成新的维度属性：尽可能地从现有数据中派生出新的维度属性，以丰富维度表的内容。
• 文字描述属性：提供包含文字描述的属性，而不仅仅是编码。例如，除了一级类目ID之外，还应该包含一级类目名称，使得维度表更加易于理解和使用。
• 度量作为维度：某些数字度量也可以作为维度属性。例如，商品单价既可以作为观察商品价格段的维度，也可以在计算平均商品价格时作为事实。
• 沉淀常用字段：尽量沉淀出常用和公用的字段，如商品状态，这通常需要通过上架时间等信息来判断。

通过这样的设计过程，我们不仅能够确保维度表的完整性和可用性，还能够提升数据仓库的分析能力。

3. 维度的层次结构

3.1 举个例子

以商品维度表为例，我们可以看到这样的层次结构：

CREATE TABLE IF NOT EXISTS dw.dw_commodity_jd_items_info_td (
  product_id INT COMMENT '商品ID',
  product_name STRING COMMENT '商品名称',
  product_category STRING COMMENT '商品类目',
  first_level_category_id INT COMMENT '一级类目ID',
  first_level_category_name STRING COMMENT '一级类目名称',
  second_level_category_id INT COMMENT '二级类目ID',
  second_level_category_name STRING COMMENT '二级类目名称',
  third_level_category_id INT COMMENT '三级类目ID',
  third_level_category_name STRING COMMENT '三级类目名称',
  listing_time TIMESTAMP COMMENT '上架时间'
)
COMMENT '商品维度表'

在这里，类目层次清晰地展示了从宏观到微观的划分：

• 一级类目 → 二级类目 → 三级类目

而时间层次则按照时间的流逝，由大到小排列：

• 年 → 月 → 季度 → 周 → 天

这种层次结构在什么场景下大放异彩呢？答案就是数据钻取。

3.2 什么是数据钻取？

数据钻取是一种强大的数据分析技术，它包括两个方向的操作：

1. 上钻（Roll-up）：减少维度的详细程度，从更细的粒度提升到更粗的粒度。例如，从每天的数据提升到按季度或年度来查看数据。
2. 下钻（Drill-down）：增加维度的详细程度，深入到更细的数据粒度。比如，从年度数据深入到具体的月份或天。

简单来说，如果你想从年份数据中查看更详细的月度或日度数据，这个过程就是下钻；相反，如果你从每天的数据转向查看季度或年度数据，那就是上钻。

3.3 常见的维度层次结构

在数据仓库中，有几个常见的维度层次结构，它们极大地方便了数据钻取操作：

• 日期维度：年、月、日、季度等，方便按时间序列进行数据分析。
• 地址维度：国家、省、市、区等，有助于地理空间分析。
• 类目维度：如商品的一级、二级、三级类目，有助于了解商品的分类和层次。

通过这些层次化的设计，维度表不仅仅是数据的存储容器，它们成为了数据分析的有力工具，帮助我们从不同角度和深度洞察业务的各个方面。

4. 高级维度策略

4.1 维度整合

想象一下，如果你的团队成员来自世界各地，大家说不同的语言，沟通起来肯定费劲。维度整合的目的，就是要让大家说同一种“语言”。比如，不同系统可能用不同的方式表示用户ID或性别，我们的任务就是把它们统一起来，这样无论数据来自哪里，我们都能轻松识别。

维度整合是数据仓库的核心之一，它要求我们将来自不同源系统的维度属性统一起来。这包括统一表名、字段名，以及同步公共代码和编码值。例如，将不同系统中表示性别的不同代码（如1：TRUE、0：FALSE）统一为一个标准。此外，我们还可能需要决定是否将具有部分重合字段的表合并，或者保持它们独立以避免产生大量空值。

维度整合：构建数据的统一视图

维度整合是数据仓库设计中的精妙手法，它帮助我们将分散的数据汇聚成一个易于理解和使用的统一视图。

• 垂直整合：集中同一主题的信息

垂直整合就像是将同一主题的不同信息层次叠加起来。以会员数据为例，源系统中可能分散着会员的基础信息、扩展信息以及不同平台的会员等级信息等多个表。这些表虽然都关注同一实体——会员，但每个表都存储着不同的细节。垂直整合的目的，就是将这些分散的信息汇集到一个统一的会员维度模型中，让我们对会员的了解更加全面。

• 水平整合：合并不同来源的数据集

水平整合则是将关注不同实体且可能存在交集的数据集进行合并。设想一下，一个大型电商平台的数据仓库，它可能收集了来自不同购物平台的会员数据。面对这种情况，我们需要决定是否将这些数据合并到一个统一的会员表中。

如果选择进行整合，我们首先需要检查这些不同的会员数据集之间是否有重叠，并相应地进行去重处理。接下来，如果不存在重叠，我们还需要考虑不同数据集的自然键是否会冲突。如果自然键不冲突，我们可以将它们作为整合后表的自然键。如果存在冲突，我们可能需要创建一个超自然键，将不同来源的自然键合并为一个新的字段。

在实践中，一种常见的方法是将不同来源的自然键作为联合主键，并在物理实现时将来源字段用作分区字段。这种方法的好处在于，它既保留了数据的原始来源信息，又提高了数据查询的效率。

4.1 维度拆分

当一张维度表变得太庞大，就像一本厚重的电话簿，用起来很不方便时，我们就需要考虑把它拆分成几张表。这就好比把电话簿按字母顺序分开，查找起来就快多了。

拆分的方法有好几种，比如我们可以按照商品的类型来拆分，普通商品和特殊商品各一张表；或者按照属性的使用频率来拆分，常用的信息放在一张表，不常用的放在另一张表。常见的拆分方法包括：

• 水平拆分：在数据层面上，根据类别或类型细分维度，如将特殊商品和普通商品分别维护在不同的子维度表中。

• 垂直拆分：在维度属性层面上，根据属性的重要性、使用频率或稳定性进行拆分。

• 历史归档：对积累的大量过时或不再使用的维度记录进行归档，以优化性能和存储。

5. 写在最后

在本章，我们像搭积木一样，一块块地搭建起对维度表的理解。维度表，这个数据仓库里的重要角色，其实就是个大目录，帮我们把数据整理得井井有条。

首先，我们明白了维度表的基本构成：它就像个故事背景，告诉我们事实表里数字背后的故事。每个维度表都有个独一无二的“身份证”——主键，它可能是个没特殊意义的编号，也可能是和业务紧密相关的实际ID。

接着，我们一步步走进了维度表的设计世界。好比挑选食材做大餐，我们得从业务需求出发，挑出最合适的维度属性，还得考虑怎么让这个大餐更易消化——也就是让数据模型既灵活又易于理解。

我们还聊到了维度表的层次结构，这就像是给数据分门别类，让我们能从不同的角度看问题，无论是时间的流转还是商品的分类，都能轻松应对。

最后，我们探讨了维度表整合和拆分的高级策略。就像是整理衣橱，有时候我们需要把相似的衣服挂在一起，有时候又需要把不合季节的衣服收起来。整合和拆分让我们的数据模型更加高效，也更适应变化。

通过本章的内容，希望你能像拿着一张地图一样，对维度表设计有清晰的认识。。