文章目录
- 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)统一为一个标准。此外,我们还可能需要决定是否将具有部分重合字段的表合并,或者保持它们独立以避免产生大量空值。
维度整合:构建数据的统一视图
维度整合是数据仓库设计中的精妙手法,它帮助我们将分散的数据汇聚成一个易于理解和使用的统一视图。
- 垂直整合:集中同一主题的信息
垂直整合就像是将同一主题的不同信息层次叠加起来。以会员数据为例,源系统中可能分散着会员的基础信息、扩展信息以及不同平台的会员等级信息等多个表。这些表虽然都关注同一实体——会员,但每个表都存储着不同的细节。垂直整合的目的,就是将这些分散的信息汇集到一个统一的会员维度模型中,让我们对会员的了解更加全面。
- 水平整合:合并不同来源的数据集
水平整合则是将关注不同实体且可能存在交集的数据集进行合并。设想一下,一个大型电商平台的数据仓库,它可能收集了来自不同购物平台的会员数据。面对这种情况,我们需要决定是否将这些数据合并到一个统一的会员表中。
如果选择进行整合,我们首先需要检查这些不同的会员数据集之间是否有重叠,并相应地进行去重处理。接下来,如果不存在重叠,我们还需要考虑不同数据集的自然键是否会冲突。如果自然键不冲突,我们可以将它们作为整合后表的自然键。如果存在冲突,我们可能需要创建一个超自然键,将不同来源的自然键合并为一个新的字段。
在实践中,一种常见的方法是将不同来源的自然键作为联合主键,并在物理实现时将来源字段用作分区字段。这种方法的好处在于,它既保留了数据的原始来源信息,又提高了数据查询的效率。
4.1 维度拆分
当一张维度表变得太庞大,就像一本厚重的电话簿,用起来很不方便时,我们就需要考虑把它拆分成几张表。这就好比把电话簿按字母顺序分开,查找起来就快多了。
拆分的方法有好几种,比如我们可以按照商品的类型来拆分,普通商品和特殊商品各一张表;或者按照属性的使用频率来拆分,常用的信息放在一张表,不常用的放在另一张表。常见的拆分方法包括:
-
水平拆分:在数据层面上,根据类别或类型细分维度,如将特殊商品和普通商品分别维护在不同的子维度表中。
-
垂直拆分:在维度属性层面上,根据属性的重要性、使用频率或稳定性进行拆分。
-
历史归档:对积累的大量过时或不再使用的维度记录进行归档,以优化性能和存储。
5. 写在最后
在本章,我们像搭积木一样,一块块地搭建起对维度表的理解。维度表,这个数据仓库里的重要角色,其实就是个大目录,帮我们把数据整理得井井有条。
首先,我们明白了维度表的基本构成:它就像个故事背景,告诉我们事实表里数字背后的故事。每个维度表都有个独一无二的“身份证”——主键,它可能是个没特殊意义的编号,也可能是和业务紧密相关的实际ID。
接着,我们一步步走进了维度表的设计世界。好比挑选食材做大餐,我们得从业务需求出发,挑出最合适的维度属性,还得考虑怎么让这个大餐更易消化——也就是让数据模型既灵活又易于理解。
我们还聊到了维度表的层次结构,这就像是给数据分门别类,让我们能从不同的角度看问题,无论是时间的流转还是商品的分类,都能轻松应对。
最后,我们探讨了维度表整合和拆分的高级策略。就像是整理衣橱,有时候我们需要把相似的衣服挂在一起,有时候又需要把不合季节的衣服收起来。整合和拆分让我们的数据模型更加高效,也更适应变化。
通过本章的内容,希望你能像拿着一张地图一样,对维度表设计有清晰的认识。。