数仓建模系列：关于维度，别再傻傻分不清楚啦！

背景

本篇文章笔者以Kimball维度建模方法论为前提关于维度展开的讨论，写一点关于维度的看法。在实际维度建模过程中，建模工程师在做维度设计时，往往分不清哪些是维度、哪些算事实或度量，同时也会产生这样或那样的疑问。到底什么是维度，可能有人会给出这样描述：

• 维度是描述事实的场景
• 维度是字符串，事实是数字
• 维度是数据分析的入口
• 维度是数据的灵魂
• 维度是描述事实的上下文
• 维度是可group by的分组的
• 维度是可写where限制条件的
• ......

上述回答是都没有问题的，但有些片面或抽象的。这里先卖个关子，下面笔者会斗胆总结一下给出更通用的说法。接下来继续列举了一些在维度建模的实践过程中，或许有人对此产生过关于维度一系列的疑问：

• 对用户打标，带有属性信息是否算维度？
• 订单表是算维度表？
• 维度一定在维度表？
• 维度表为什么一定要有主键，而事实表不一定要有主键？
• 事实表里含有度量，但指标为什么可从维度表出？
• 年龄是数字算是维度属性？
• .....

这样的疑问还有很多，就不再一一列举。笔者给出上述几个疑问一点自己观点：

• 用户打标签不是很稳定，也不是算用户固有的天然属性信息，不在数据仓库建模范围，这个算是数据应用；
• 订单表本质是下单的业务过程，只是各种维度信息的集合并下单的业务过程；
• 维度信息基于实际情况考虑数据易用性常用性可以退化到事实表，但要考虑到数据的一致性；
• 维度表内记录不能重复，重复会导致数据发散，要有主键约束，其主键是事实表的外键，而事实表的粒度是某个业务对象，在某个时刻发生一个事件产生的记录，也可能发生多次，如事件流水表，所以不一定要主键；
• 指标同样可从维度来计算，如用户维度表计算用户数等；
• 年龄同样可做维度，如基于年龄段的数据分析，不能因为看着是数字就是度量，要根据实际场景来判断。
• ......

何为维度

在实际维度建模过程，如何清晰识别维度是非常关键，维度是数据分析的入口，保证数据仓库模型通用性、易用性和回答业务用户范围前提条件之一。kimball认为，维度建模首先会将现实情况划分为测量和上下文开始，通常将指标的度量称之为“事实”，将产生度量的环境称之为“维度”。度量离开了维度或上下文也没有意义的，如给一个数字3646.13，无法知道这个数字的意义。

但是，一旦给这个度量添加了上下文，其就有了意义，如拉萨市海拔3646.13米

虽然Kimball理论给出维度描述定义，但是实际建模过程中，还有建模工程师在设计维度表时，还会产生各种疑问，为了帮助建模工程师对维度的理解或作为维度判断依据，这里笔者关于维度斗胆给出的定义（或许不全面，大家可一起讨论）：

相对稳定的、可抽象具有共性的、固有的（天然的）描述度量或事实的上下文属性信息。除了理解度量上下文外，还有以下三个特性：

• 相对稳定的：不会大规模的经常性变化的，正式相对稳定特性，维度SCD缓慢变化维度处理技术正是针对稳定属性缓慢变化的处理。
• 可抽象具有共性的：分组、分类分析，group by，条件限制，否则是看明细没太多分析价值
• 固有的（天然的）：静态的、与生俱来的 （企业经营活动中目标主体有关），如用户、手机号，成为我们用户时就有带有手机号（app经营活动、不是线下网点经营），没有手机，也无法成为我们的用户，我们不是针对全球的人都作为我们用户来分析（和我们企业经营范围有关，没必要收集全球饭都吃不上的人的信息，也不现实）。身份证号、手机号虽说是唯一的，但它们也含有共性的、通用的信息如归属地、运营商等。

总结

维度是相对稳定的、可抽象具有共性的、固有的（天然的）描述度量或事实的上下文属性信息。希望这些关于维度的阐述，能对建模工程师在实际维度模型设计时有所帮助。