数仓模型之维度表技术

维度表概念

维，是人们观察数据的特定角度，是考虑问题时的一类属性，属性集合构成一个维。

维度是维度建模的基础和灵魂。

维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。

维度的作用一般是查询约束、分类汇总以及排序等。

维度使用主键标识其唯一性，主键也是确保与之相连的任何事实表之间存在引用完整性的基础。

维表通常较宽，扁平型非规范表，包含大量的低粒度的冗余文本属性

主键的分类

代理键：代理键是不具有业务含义的键。在Kimball的维度建模领域里，是强烈推荐使用代理关键字的

⭐提示：《大数据之路》中提到阿里巴巴不使用！

 优点:多个操作型系统的数据进行整合时，这些系统中的数据有可能缺乏一致的关键字编码，即有可能出现重复(或者主键规则不一致)用代理关键字可以带来性能上的优势。和自然关键字相比，代理关键字很小，是整型的,作为外键联接的效率也很高使用代理关键字可以用来处理缓慢变化维。维度表数据的历史变化信息的保存是数据仓库设计的实施中非常重要的一部分。缺点：代理关键字的使用使数据加载变得非常复杂，使用代理键会大大增加 ETL的复杂性，对 ETL 任务的开发和维护成本很高，全局唯一难度大

自然键：具有业务含义的键。

维度的基本设计方法

维度的设计过程就是确定维度属性的过程，如何生成维度属性，以及所生成的维度属性的优劣，决定了维度使用的方便性，成为数据仓库
易用性的关键。正如 Kimball 所说的，数据仓库的能力直接与维度属性的质量和深度成正比。

维度设计方法步骤

选择维度或新建维度。作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性
确定主维表。此处的主维表一般是 ODS 表，直接与业务系统同步。以淘宝商品维度为例， s_auction_auctions 是与前台商品中心
系统同步的商品表，此表即是主维表。
确定相关维表。确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。
确定维度属性。本步骤主要包括两个阶段，其中第一个阶段是从主维表中选择维度属性或生成新的维度属性；第二个阶段是从相
关维表中选择维度属性或生成新的维度属性。
- 尽可能生成丰富的维度属性 ——尽量冗余
- 尽可能多地给出包括一些富有意义的文字性描述 ——编码文字化
- 区分数值型属性和事实
  
  如果数值型字段是离散值，则作为维度属性存在的可能性较大；如果数
  值型宇段是连续值，则作为度量存在的可能性较大，但并不绝对，需要
  同时参考宇段的具体用途。
- 尽量沉淀出通用的维度属性

维度变化处理

缓慢变化维（Slowly Changing Dimensions ）

缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。例如一项合同的发生变更

处理缓慢变化维的方法通常有三种方式：

直接覆盖原值：这样处理最容易实现，始终取最新数据，但是没有保留历史数据，无法分析历史变化信息。

场景：若A商家签订了租赁合同100平米，当合同内容发生修改为120平米，因合同主键不变，但只保留最新的120平米，历史数据坪效只能按照120平米分母计算

合同编号§	合同面积
N001	100 120

添加维度行：这样处理需要代理键的支持。实现方式是当有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原维度记录保持关联。

优点：可以记录分段事实表表关联记录
缺点:难点在于代理键的维护，有些场景不分段计算不适用

合同代理键§	合同编号	合同面积
1	N001	100
2	N001	120

添加维度列 :这种处理的实现方式是对于需要分析历史信息的属性添加一列，来记录该属性变化前的值，这种方式的优点是可以同时分析当前及前一次变化的属性值，缺点是只保留了最后一次变化信息。最终只能按其中一列维度进行计算

合同编号§	合同面积（旧）	合同面积（新）
N001	100	120

快照维表

处理缓慢变化维的方法是采用快照方式。

数据仓库的计算周期一般是每天一次，基于此周期，处理维度变化的方式就是每天保留一份全量快照数据。比如商品维度，每天保留一份全量商品快照数
据。任意一天的事实均可以获取到当天的商品信息，也可以获取到最新的商品信息，通过限定日期，采用自然键进行关联即可。

⭐提示：阿里巴巴推荐使用，由于现在存储成本远低于 CPU、内存等的成本，此方法弊大于利

优点：简单有效，开发和维护成本低；使用方便，理解性好。

缺点：存储浪费大。

合同编号(p1)	日期(p2)	合同面积
N001	2021-05-01	100
N001	2021-05-02	120

极限存储

缓慢变化维的第二种处理方式。这种处理方式是通过新增两个时间戳字段(sta rt_dt 和 end_dt ），将所有以天为粒度的变更数据都记录下来。通常
分区字段也是时间戳字段。

合同编号(p1)	sta rt_dt（p2）	end_dt（p3）	状态	合同面积
N001	2020-01-01	2021-05-01	失效	100
N001	2021-05-02	unknow	生效	120

这种存储方式对于下游使用方存在一定的理解障碍，因此会存在较高的解释成本。同时，随着时间的推移，分区数量会极度膨胀。故而引出极限存储。

微型存储

微型维度的创建是通过将一部分不稳定的属性从主维度中移出，并将它们放置到拥有自己代理键的新表中来实现的。

意思是维度表采用星型结构，将可变属性与不可变属性维度拆分出来

很少被采用的原因如下:

微型维度的局限性，将维度表进一步复杂化了，造成整体数仓雪花型结构
ETL逻辑复杂，对于分布式系统，生成代理键和使用代理键进行ETL 加工都非常复杂， ETL 开发和维护成本过高。；
破坏了维度的可浏览性。不易理解。

其他感悟和体会

关于数仓模型

数据仓库只是一套方法论，没有准备的只有适合的。目的是实现底层数据模型设计到数据服务，做到数据可管理、可追溯、可复用，取得改造成本、资源耗用、可理解性之间的平衡。

数据仓库分层也没有绝对的规范。但有几个准则

清晰数据层次结构，数据血缘追踪（定位哪个层级出现问题），减少重复开发，数据关系条理化（不允许同层、跨层、逆层的依赖）

关于日期维度表（对于公司的使用建议）

作为最最常用的维度表，其实有着重大的使用价值与意义，同时也是可以不断拓展字段维度进行使用。

存在问题

公共模型中的日期维度表中维度字段过少，满足不了各式各样的业务需求

例如以下季度可能有N种拓展写法

日期	id	2018-01-01
数值日期	int_date	20180101
年	year	2018
月	month	1
日	day	1
季度	quarter	1
季度名称中文	ch_quarter	2018年第一季度
季度名称英文	en_qurater	2018Q1
季度名称中文简写	ch_quarter_s	第一季度
季度名称英文简写	en_qurater_s	Q1
星期几	day_name	Monday
一年的第几周	weekofyear	1
一年的第几天	dayofyear	1
该月有几天	daysinmonth	31
这周第几天	dayofweek	1
是否闰年	is_leap_year	FALSE
是否月末最后一天	is_month_end	FALSE
是否月初第一天	is_month_start	TRUE
是否季度末最后一天	is_quarter_end	FALSE
是否季度初第一天	is_quarter_start	TRUE
是否年末最后一天	is_year_end	FALSE
是否年初第一天	is_year_start	TRUE
农历	lunar_date	冬月十五
干支纪年	gz_year	丁酉年
生肖年	sx_year	鸡年
干支纪日	gz_day	癸巳日
节气	solar_terms
星座	zodiac	摩羯座
节假日	holiday	元旦
特殊促销日，财务周期等等

ETL任务中较少通过连接维度表拓展需要的日期维度字段，而是通过事实表业务日期去进行SQL计算，有几点影响
- 日期维度的取用在业务需求往往是难以统一的，在事实表ETL任务中拓展非常见的日期字段往往需要冗长的SQL代码，可看性降低
- 复用性差，同时某些特殊日期是不可能通过SQL去实现的例如春节假期
- 计算资源消耗更大
最简单方式可下载特殊日期维度数据通过Excel维护上传

关于宽表

在数仓层开始引入了宽表。所谓宽表，迄今为止并没有一个明确的定义。通常做法是把很多的维度、事实上卷或者下钻之后关联到某一个事实表中，形成一张既包含了大量维度又包含了相关事实的表。

宽表的使用，有其一定的便利性。使用方不需要再去考虑跟维度表的关联，也不需要了解维度表和事实表是什么东西。

但是随着业务的增长，始终无法预见性地设计和定义宽表究竟该冗余多少维度，也无法清晰地定义出宽表冗余维度的底线在哪里。为了满足使用上的需求，要不断地将维表中已经存在的列增加到宽表中。这可能宽表的表结构频繁发生变动。
- 若取用全部维度字段则宽表字段过多，可能大多数字段不取用或弃用的情况
- 若出现宽表新增字段情况，可尽量不新增在宽表上，通过模型拓展
- 可尽量用维度模型代替宽表；
  - 事实表的粒度基本不会改变
  - 事实表和维度表解耦，维度表的变更事实表基本不会影响，结果表也只需要回刷一下数据流程即可；
  - 通过维度模型再生，可对快速的业务进行支撑

参考文献：
《大数据之路：阿里巴巴大数据实践》
数据仓库工具箱维度建模权威指南（第3版）