谈笑间学会数仓—维度层设计④

谈笑间学会数仓—维度层设计④

特殊维度

1.1、递归层次

上篇博客已经了解了维度的层次结构，即维度属性以层次方式或一对多的方式相互关联；或者描述为不同维度之间的主从关系，比如商品和类目的关系、商品和品牌的关系等。递归层次指的是某维度的实例值的层次关系，比如淘宝类目体系，如下图所示：

维度的递归层次，按照层级是否固定分为均衡层次结构和非均衡层次结构。比如类目，有固定数量的级别，分别是叶子类目、五级类目、四级类目、三级类目、二级类目、一级类目；地区，分别是乡镇/街道、区县、城市、省份、国家，对于这种具有固定数量级的递归层次称为“均衡层次结构”。比如公司之间的关系，每个公司可能存在一个母公司，但可能没有固定的一级、二级等层级关系。对于这种数量级别不固定的递归层次，称为“非均衡层次结构”。

淘宝交易事实表通过叶子类目和类目维表关联，如何统计类目ID为21的最近一天的GMV？第一步，获取父类目ID等于20的所有类目，称为子类目。第二步，对于每个子类目，如果为叶子类目，则终止；如果非叶子类目，则此类目ID作为父类目ID执行第一步，直到找到所有叶子类目，如圣诞服饰（50026579）、台历（121456022）等。将所有的叶子类目和交易事实表关联进行统计汇总，即可得到类目ID等于21的最近一天的GMV，也就是家具日用类目的最近一天的GMV。在物理实现时，可以使用递归SQL实现，如Oracle中的connect by 语句。

通过数据探查得知ID等于21的类目属于一级类目（父类目ID等于0），统计其最近一天的GMV的过程，成为上钻；在递归层次中进行上钻和下钻是很常见的。由于很对数据仓库系统和商业智能工具不支持递归SQL，且用户使用递归SQL的成本较高，所以在维度模型中，需要对此层次结构进行处理。

1、层次结构扁平化

降低递归层次使用复杂度的最简单和有效的方法是层次结构的扁平化，通过建立维度的固定数量级别的属性来实现，可以在一定程度上解决上钻和下钻的问题。对于均衡层次结构，采用扁平化最有效。

对于淘宝商品类目，通过层次结构扁平化之后，类目维表如下图所示，每个类目保存一条记录，并将其所属的各类目层级属性化。其中，对于高层类目，由于其无低层级类目，则低层级类目置为空值。

具体数据存储示例如表10.12所示，其中四级和五级类目省略。

如何统计类目ID为21的最近一天的GMV？将淘宝交易事实表通过椰汁类目和类目维表的类目ID关联之后，限制一级类目ID等于21之后进行汇总统计，即可以得到类目ID等于21的最近一天的GMV。其使用方便性得到大大提高，但存在如下三个方面的问题：

• 针对某类目上钻和下钻之前，必须知道其所属的类目层级，然后才能决定限制哪一级类目。如上述示例，限制一级类目ID等于21。
• 假设分三级类目统计最近一天的GMV，由于某些叶子类目直接是一级类目或者二级类目（比如类目ID等于12145022的类目，其是叶子类目），和交易事实表关联之后，其对应的三级类目为空，导致根据三级类目统计最近一天的GMV时，类目ID等于121456022的交易无法被统计到。下游数据统计时，为了规避此问题，如果此类目对应的三级类目为空，则取二级类目；如果二级类目仍为空，则取一级类目。

所以针对此问题，下游数据统计时，类目层次结构扁平化的另一种方式是回填，将类目向下虚拟，具体存储实例如下表所示，其中粗体部分为回填内容。（阿里中文站的类目体系使用此种方式）

• 扁平化仅包含固定数量的级别，对于非平衡层次结构，可以通过预留级别的方式来解决，但扩展性较差。

2、层次桥接表

针对层次结构扁平化所存在的问题，可以采用桥接表的方式来解决，不需要预先知道所属层级，不需要回填，也可以解决非均衡层次结构的问题。与扁平化方法相比，该方法适合解决更宽泛的分析问题，灵活性好；但复杂性高，使用成本高。

仍然以类目为例，模型设计如下图所示

类目使用树形结构表示如下图所示

针对此类目树，类目桥接表的内容如下表所示

假设对类目21进行下钻操作，步骤如下：

限制类目表的类目ID等于21，通过类目ID和类目桥接表的父类目ID关联，使两表建立连接；通过类目桥接表的子类目ID和交易事实表的类目ID关联，使两表建立连接；接下来即可针对订单事实表进行下钻操作。涉及类目桥接表的数据见表10.14中“父类目ID”字段的粗体部分（21）

假设针对类目50026579进行上钻操作，步骤如下：

限制类目表的类目ID等于50026579，通过类目ID和类目桥接表的子类目ID关联，使两表建立连接；接下来即可针对订单事实表进行上钻操作，涉及类目桥接表的数据见表10.14中的“子类目ID”字段的粗体部分（50026579）

可以看到层次桥接表解决了层次结构扁平化带来的一些问题；但是其加工逻辑复杂，使用逻辑复杂，而且由于事实表和桥接表的多对多关系而带来了双重计算的隐患。在实际应用中可以根据具体的业务需求来选择技术方案，比如在同级分析或者报表中，一般都是按照固定级别进行，如按照一级类目统计GMV、按照省份统计GMV等，现在扁平化设计完全可以满足需求，而不需要引入复杂的桥接表。很多时候，简单、直接的技术方案确实最好的解决方案。

行为维度

在阿里的数据仓库中，存在很多维表，如卖家主营类目维度、卖家主营品牌维度、用户常用地址维度。其中卖家主营类目和主营品牌通过卖家的商品分布和交易分布情况，采用算法计算得到；卖家常用地址通最近一段时间内物流中卖家的发货地址和卖家的收货地址进行统计得到。类似的维度都和事实相关，如交易、物流等，称之为“行为维度”，或“事实衍生的维度”。

按照加工方式，行为维度可以划分为以下几种：

• 另一个维度的过去行为，如买家最近一次访问淘宝的时间、买家最近一次发生淘宝交易的时间等。
• 快照事实行为维度，如买家从年初截至当前的淘宝交易金额、买家信用分值、卖家信用分值等。
• 分组事实行为维度，将数值型事实转换为枚举值。如买家从年初截至当前的淘宝交易金额按照金额划分的等级、买家信用分值按照分数划分得到的信用等级等。
• 复杂逻辑事实行为维度，通过复杂算法加工或多个事实综合加工得到。如前面提到的卖家主营类目，商品热度根据访问、收藏、加入购物车、交易等情况综合计算得到。

对于行为维度，有两种处理方式，其中一种是将冗余至现有的维表中，如将卖家信用等级冗余至卖家维表中；另一种是加工成单独的行为维表，如卖家主营类目。具体采用哪种方式主要参考如下两个原则：

第一、避免维度过快增长。比如对商品表进行极限存储，如果将商品热度假如现有商品维表中，则可能会使每日商品变更占比过高，从而导致极限存储效果较差。

第二、避免耦合度过高。比如卖家主营类目，加工逻辑异常复杂，如果融合进现有的卖家维表中，那么过多的业务耦合会导致卖家维表刷新逻辑复杂、维护性差、产出延迟等。

参考：《大数据之路-阿里巴巴大数据实践》