数仓维度建模之维度表设计（设计实操一）

维度设计基本方法

1、设计步骤：

1）第一步：选择维度或新建维度。

作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。以淘宝商品维度为例，有且只允许有一个维度定义。

2）第二步：确定主维表。

此处的主维表一般是 ODS 表，直接与业务系统同步。以淘宝商品维度为例，s_auction_ auctions是与前台商品中心系统同步的商品表，此表即是主维表。

3）第三步：确定相关维表。

数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。以淘宝商品维度为例，根据对业务逻辑的梳理，可以得到商品与类目、 SPU、卖家、店铺等维度存在关联关系。

4）第四步：确定维度属性。

本步骤主要包括两个阶段，其中第一个阶段是从主维表中选择维度属性或生成新的维度属性；第二个阶段是从相关维表中选择维度属性或生成新的维度属性。 以淘宝商品维度为例，从主维表（ s_auction_auctions）和类目、 SPU、卖家、店铺等相关维表中选择维度属性或生成新的维度属性。确定维度属性的几点提示：比如淘宝商品维度有近百个维度属性，为下游的数据统计、分析、探查提供了良好的基础。
尽可能多地给出包括一些富有意义的文字性描述，比如商品维度中的商品ID 和商品标题、类目 ID 和类目名称等。 ID 一般用于不同表之间的关联，而名称一般用于报表标签，比如商品价格，可以用于查询约束条件或统计价格区间的商品数量，此时是作为维度属性使用的；也可以用于统计某类目下商品的平均价格，此时是作为事实使用的。另外，如果数值型字段是离散值，则作为维度属性存在的可能性较大；如果数 值型宇段是连续值，则作为度量存在的可能性较大，但并不绝对，需要 同时参考宇段的具体用途。
区分数值型属性和事实 数值型宇段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或分组统计，则是作为维度属性；如果通常
用于参与度量的计算， 则是作为事实。
尽量沉淀出通用的维度属性 有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通过单表的不同宇段混合处理得到，或者通过对单表的某个字段进行解析得到。此时，需要将尽可能多的通用的维度属性进行沉淀。一方面，可以提高下游使用的方便性，减少复杂度；另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不一致。例如，淘宝商品的property 字段，使用 key:value 方式存储多个商品属性。 商品品牌就存存储在此字段中，而商品品牌是重要的分组统计和查询约束 的条件，所以需要将品牌解析出来，作为品牌属性存在。例如，商品是 否在线，即在淘宝网站是否可以查看到此商品，是重要的查询约束的条件，但是无法直接获取，需要进行加工，加工逻辑是：商品状态为0 和 l且商品上架时间小于或等于当前时间，则是在线商品g否则是非在线
商品。所以需要封装商品是否在线的逻辑作为一个单独的属性字段。

5）第五步：反规范化 将维度的属性层次合并到单个维度中的操作称为反规范化。

分析系统的主要目的是用于数据分析和统计，如何更方便用户进行统计分析决定了分析系统的优劣。采用雪花模式，用户在统计分析的过程中需要大量的关联操作，使用复杂度高，同时查询性能很差；而采用反规范化处理，则方便、易用且性能好。

2、维度整合

1）垂直整合：

" 即不同的来源表包含相同的数据集，只是存储的信息不同时，进行垂直整合。" “比如淘宝会员在源系统中有多个表，如会员基础信息表、会员扩展信息表、淘宝会员等级信息表、天猫会员等级信息表，这些表都属于会员相关信息表，依据维度设计方法，尽量整合至会员维度模型中，丰富其维度属性。”
水平整合：“即不同的来源表包含不同的数据集，不同子集之间无交叉，也可以存在部分交叉。此时才用水平整合。” “比如针对蚂蚁金服的数据仓库，其采集的会员数据有淘宝会员、 1688 会员、国际站会员、支付宝会员等，是否需要将所有的会员整合到一个会员表中呢？如果进行整合，首先需要考虑各个会员体系是否有交叉，如果存在交叉，则需要去重；如果不存在交叉，则需要考虑不同子集的自然键是否存在冲突，如果不冲突，则可以考虑将各子集的自然键作为整合后的表的自然键；另一种方式是设置超自然键，将来源表各子集的自然键加工成一个字段作为超自然键。在阿里巴巴，通常采用将来源表各子集的自然键作为联合主键的方式，并且在物理实现时将来源字段作为分区字段。”

3、维度拆分

3.1水平拆分

3.1.1何时需要拆分？

由于维度分类的不同而存在的特殊的维度属性，可以通过水平拆分的方式来解决此问题。

3.1.2两种方案

方案一：将维度的分类实例化成不同的维度，同时在主维度表中保存公共属性；
方案二：维护单一维度，包含所有可能的属性。

3.2.3两个拆分依据

“依据一：是维度的不同分类的属性差异情况。
当维度属性随类型变化较大时，将所有可能的属性建立在一个表中是不切合实际的，也没有必要这样做，此时建议采用方案一” “比如在阿里巴巴数据仓库维度体系中，依据此方法，构建了商品维度、航旅商品维度等。公共属性一般比较稳定，通过核心的商品维度，保证了核心维度的稳定性；通过扩展子维度的方式，保证了模型的扩展性。”
“依据二：是业务的关联程度。
两个相关性较低的业务，耦合在一起弊大于利，对模型的稳定性和易用性影响较大。也要进行拆分，直接拆分成两个维度。” “比如在阿里巴巴数据仓库维度体系中，对淘系商品和 1688 商品构建两个维度。虽然淘系和1688 在底层技术实现上是统一的，但属于不同的BU，业务各自发展；在数据仓库层面，淘系和1688属于不同的数据集市，一般不会相互调用，业务分析人员一般只针对本数据集市进行统计分析。”

3.2 垂直拆分

为何做垂直拆分 “某些维度属性的来源表产出时间较早，而某些维度属性的来源表产出时间较晚；或者某些维度属性的热度高、使用频繁，而某些维度属性的热度低、较少使用；
或者某些维度属性经常变化，而某些维度属性比较稳定。在“水平拆分”中提到的模型设计的三个原则同样适合解决此问题。”
出于扩展性、产出时间、易用性等方面的考虑，设计主从维度。主维表存放稳定、产出时间早、热度高的属；从维表存放变化较快、产出时间晚、热度低的属性。 “比如在阿里巴巴数据仓库中，设计了商品主维度和商品扩展维度。其中商品主维度在每日的1 :30 左右产出，而商品扩展维度由于有冗余的产出时间较晚的商品品牌和标签信息，在每日的 3:00 左右产出。”