数据仓库核心：维度表设计的艺术与实践

文章目录

- 1. 引言
- - 1.1基本概念
  - 1.2 维度表定义
- 2. 设计方法
- - 2.1 选择或新建维度
  - 2.2 确定维度主维表
  - 2.3 确定相关维表
  - 2.14 确定维度属性
- 3. 维度的层次结构
- - 3.1 举个例子
  - 3.2 什么是数据钻取？
  - 3.3 常见的维度层次结构
- 4. 高级维度策略
- - 4.1 维度整合
  - 维度整合：构建数据的统一视图
  - 4.1 维度拆分
- 5. 写在最后

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

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

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 什么是数据钻取？

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

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

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

3.3 常见的维度层次结构

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

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

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

4. 高级维度策略

4.1 维度整合

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

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

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

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

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

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