一、属性与度量

在介绍维表之前，我们首先要明白一点属性与度量的区别。属性是指是对象的性质或特性，它因对象而异，或随时间而变化，比如姓名和年龄。姓名因人而异，年龄会不断变化。而度量是对属性的标量刻画。并且度量具有统计意义，而属性并不具有统计意义，比如25岁的我在超市买了1瓶300ML农夫山泉，花了2元。这里的1瓶和2块就是对我买水的这个业务过程的度量。超市是（地理维度）属性，25岁是描述实体的属性，300ML是描述农夫山泉的属性。所以我们可以通过2个点来区分属性和度量，1.是否具有统计意义，2.是否会随时间变化。

二、维度表类型

维度表分两种，星型模型和雪花模型。在星型模型中，维表只和事实表关联，维表之间没有关联，查询性能好，但冗余度高。雪花模型是星型模式中的维度表进行规范化处理，进一步分解到附加表（维表）中冗余度小，但是查询性能差。一般而言，我们都使用星型模型。因为存储资源的成本会远远小于计算资源，我们会优先考虑这一点。而雪花模型也是会使用的，比如我们的维表中包括了太多的属性，为了确保及时产出，又或者某些字段相比而言会经常发生变动，我将一个维表拆成核心表和拓展表。又或者某些维度属性经常发生变化，我们可以考虑将快速变化的维度属性抽象出微型表，用业务主键或者代理键[1]进行关联。

星型模型（左）雪花模型（右）

三、维度表的设计

设计流程：

1. 选择维度。要确保维度一致性有且只允许有一个维度定义。

2. 确定主维表。主维表一般是ODS 表，直接与业务系统同步。

3. 确定相关维表。确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。

4. 确定维度属性。一方面，尽可能生成丰富的维度属性，另一方面，尽量沉淀出通用的维度属性，确定那些是核心属性。

设计要点：

1. 一致性维度&交叉探查

数据仓库总线架构的重要基石之一就是一致性维度。如果不同数据域的计算过程使用的维度不一致，就会导致交叉探查 存在问题。 为了确保上述问题不会产生。我们主要就是要确保1. 共享维表。 重要的公共维度维表只能有一个 所以基于这些公共维度进行的交叉探 查不会存在任何问题。2. 一致性上卷。保证两个维度的公共维度属性结构和内容相同。

2. 如何处理变化维[2]

•直接覆盖，使用的较少，主要用于及其缓慢变化的维度表。

•新增一列，用以存储新、旧两次属性，适用于变化的维度属性较少。

•新增一行，每次变化都会新增一行。适用场景：维表数据量较大，且用户关注历史变化。(一般采用拉链表的方式实现)

•天级快照，当维度数量较少时，可以每天保留一份全量快照数据，缺点是重复存储严重。

3. 维度整合与拆分

维度整合/拆分原则：出于扩展性、产出时间、易用性等方面的考虑，保证主维表信息的全面性和稳定性。（不因为个别维度的加入而导致维表产出不稳定）

整合：

•水平整合：是指不同的来源表包含不同的数据集，会使得维度本身的记录数变多，是对原有维度的记录数上的补充。这里我们需要考虑1.多个来源表是否存在重复，如果有就需要去重。2.多个数据源表的自然键是否存在冲突，是否需要重新组合形成新的超自然键。

•垂直整合：简单来说就是增加字段。是指不同的来源表包含相同的数据集，维度本身记录数不会变，只是会对维度属性进行补充。

拆分：

•水平拆分：两个业务相关性低，整合在一起会对模型的稳定性和易用性产生影响。比如路上的出租车。有一类是网约车，受到公司的管理和调度，还有一类是贴标的广告车。我们经常可以看到那种车身贴着橙心优选，货拉拉等等车贴的车，但是车本身并不做相关的工作。只是贴着车贴拿广告费。这两者在管理运营和注重点都有很大的区别。所以合并成一张车辆维表很难维护。导致大量的空字段，没有意义。

•垂直拆分：考虑到某些维度属性的来源表产出时间早，某些产出晚；某些属性位数使用频率高，某些频率低；某些属性稳定性高，某些经常变化。把产出时间早、使用频率高、稳定性高的属性放在主维度中，把产出时间晚、使用频率低、经常变化的属性放在子维度中。

4. 特殊维度处理

        1. 递归层次。如服务记录的叶节点和根节点，可以选择打平或者降低粒度。

        2. 行为维度。这类维表一般是快速变化维。如果维表太大且采用了拉链表时，可以考虑把快速变化的维度属性拆出来。

        3. 多值维度。一条记录的一个维度属性有多个值，比如一笔电商订单有多个商品，每笔订单能关联到商品维表多条记录。这里我们一般采用降低粒度、多字段、桥接表的方式。

       4. 多值属性。维表中的某个属性字段同时有多个值，称之为“多值属性”。这种一般要么降低粒度，每个值一条，要么不拆，将字段整合到一个字段或者多个字段当中。

      5. 杂项维度。由操作型系统中的指示符或者标志宇段组合而成的维度。这种一般来说是会保留在事实表当中较好。

总结

维度是维度建模的基础和灵魂。在维度建模中，将度量称为“事实” ， 将环境描述为“维度”，维度是用于分析事实所需要的多样环境。我们在设计维表时要充分考虑其他各个域的使用需要进行建设。在设计之时要充分调研相关的需求，与组内的人员多沟通交流，打好底层基础。

[1]：代理键是不具有业务含义的键， 一般用于处理缓慢变化维，但也可以用于其他没有主键场景（比较难维护）；自然键是具有业务含义的键。比如商品，在ETL 过程中，对于商品维表的每一行，可以生成一个唯一的代理键与之对应；商品本身的自然键可能是商品ID 等。其实对于前台应用系统来说，商品ID 是代理键：而对于数据仓库系统来说，商品ID 则属于自然键。

[2]:维度的属性并不都是静态的，随着时间的流逝维度属性会发生缓慢变化的称为缓慢变化维；反之，称为快速变化维。