《大数据之路》读书笔记：维度设计（续）

接上一篇：《大数据之路》读书笔记：维度设计

缓慢变化维

这个应该是知名度最高的，“缓慢变化”也是经常会被提起的一个场景。随着时间的变化，有一些维度是会变的，就像商品维度，经常有新商品上架，有商品下架，所以要看某一天在线的商品，就需要用缓慢变化维的方式来处理。
反映历史变化也是数仓的特性之一，为了应对这种变化，有几种处理方式：

1. 重写维度值
   如果我不关心历史数据，当属性变化了，那我就看最新的数据，不管历史是什么的话，我就可以直接去更新维度数据。
   比如商品A，它原来叫矿泉水，后来改成矿物质水，直接更新就好了，这时候维度表会只存有一份最新的数据。

2. 插入新的维度行
   当我们需要关注维度的历史数据的时候，我们就不能采取直接更新的方式了，我们可以通过新增记录的方式来解决，这样老的数据还在，新的数据也有。
   这里要注意的是唯一建的问题，业务系统在更新维度信息的时候，很可能是直接更新掉，数仓中需要维护历史数据，所以在新增记录的时候如果没有代理键，要注意key值的唯一性，这种方法一般是需要代理键的，像上面说的商品修改名称，商品的业务key可能还是101，但是数仓中需要使用代理键来保证key值一致，但是代理键不同，这样才可以让事实表中的数据老数据使用老的代理键，新数据使用新的代理键。
   这种方式也会有些问题，就是单独来看维度数据的话，同一个商品会有多条记录，会产生歧义；还有一点就是从维度表中可能看不出来记录的变化过程，并不清楚某一天该商品到底是哪一条记录为准，因为变化的特征都在事实表中。

3. 添加维度列
   这个算是一种延伸的方法，类似方法一，为了让方法一可以存历史数据，除了新增记录（纵向），还可以采用横向的方式，就是新增字段（列），来记录变化前的记录，这样通过一条记录，就可以记录商品变化前和变化后的数据了。
   这样可以保证key值唯一，但是缺点也显而易见，只能记录有限次数的变化，而且要提前规划好，保留几次历史记录。

4. 拉链表
   还有一种常用的方式是拉链表，这种方式类似第2种方法，算是拓展版，也有点儿麻烦，简单来说，就是需要新增两个字段，start_date，end_date，用来记录这条就的有效周期，从哪一天开始，哪一天结束，使用的时候用这两个字段一过滤就好了。

在实际应用时，还是要考虑业务场景，根据实际情况选择，当然还有其他的方式，同样后面会再更新。

快照维度

上面说到了代理键，这个东西是很复杂的，按照维度建模的理论来，是需要搞一套代理键的，而实际操作起来会增加复杂度和维护成本，阿里采用的这种快照方式，也可以解决缓慢变化的问题。
以商品维度为例，就是每天都对商品维度生成一个快照，这样每天的商品信息都有了，key值也是唯一的，我想要看哪天的记录就看哪天，而且非常简单，使用也方便，就当前存储价格很便宜，这种方法最实用，当前公司也是使用这种方式，每天搞个分区，全量的快照，想用最新的就用最新的，想用历史的就用历史的。
当然它的缺点也明显，就是时间久了，历史数据非常庞大，有一定的存储浪费，需要注意对历史数据归档或清理。

极限存储

这个应该是阿里自己的一套实践方案，上面拉链表的方式，有几个缺点，一个是下游用户理解起来会稍有问题，需要一些解释成本，还有一个是使用start_date和end_date做分区的话，会有分区数量的限制，为了解决这些问题，阿里使用极限存储的方式来解决。
首先是在拉链表上层做了一层处理，让下游使用起来和每天一个快照的方式一样，方便使用；
然后是分月做历史拉链表，我感觉书上这里写的有点儿问题，或者是我还没理解，详情看看书吧。

微型维度

微型维度是为了解决维度属性频繁变化的问题，如果维度中有些属性经常会发生变化，可以将他们抽取出来，放到一个新维度表中，我觉这里说的也不是很好，看书中的意思，感觉和下面那个杂项维度差不多，思路是一样的，这里不过是将频繁变化的属性抽取出来，然后通过笛卡尔积生成所有记录，然后用代理键去关联。

递归维度

维度的递归问题，一般是业务系统中，开发的同学会这样设计。像类目或者组织架构这种，一般是有上下级关系的，除了设计成类似雪花那样的多个表，还会设计成递归存储的这种，这种维度，到数仓中，是需要处理下的。哦，这里会晕倒两种类型，一种是“均衡层次结构”，一种是“非均衡层次结构”。

• 扁平化
  就是将维度数据打平，变成一张宽表，数据会冗余，但是使用起来非常方便。以商品维度来说，就是商品ID，商品名称、一级品类ID、一级品类名称、二级品类ID、二级品类名称......

• 层级桥接表
  这个方式到是没有用过，相比扁平化操作更加的灵活。
  这种方式需要搞一个桥接表，就是个映射关系表，用父、子关系和父子之间相隔的层级数来记录。

这种方式还是需要一个扁平化的表，只是又搞了一个中间表。
书中有说到，选择哪一种方法的时候，要考虑实际应用，比如上钻、下钻是怎样实现的，和前端也会有些关系。

行为维度

这个不是直接存在于业务中的维度，而是通过其他业务梳理出来或者衍生出来的维度，这些维度是通过某种计算规则统计出来的，而不是原生存在的，可以分为几种：

• 另一个维度的过去行为
  买家最近一次访问淘宝的时间、买家最近一次发生交易行为的时间
• 快照事实行为维度
  买家从年初至今的淘宝交易金额、买家信用值
• 分组事实行为维度
  买家从年初至今的淘宝交易金额划分的等级、买家信用值等级
• 复杂逻辑事实行为维度
  通过复杂算法或加工多个事实输出的维度

实际处理这种维度时，可以增加到当前类似的维度表中，或者新增维度。需要注意维度的变化频率和耦合性，后期维护成本等。

多值维度

这个主要是事实表和维度表粒度的不一致的问题，书中举的例子是订单主表和订单明细表，一笔订单会购买多个商品。有几种处理方式：

• 降低事实表粒度
  像上面的例子，直接以订单明细为最细粒度
• 采用多字段
  有些场景下对应的多维度可能是可确定的，比如两个、三个等，可以通过增加字段的形式。比如我一单只会买两种商品，那就可以设计为第一种商品和第二种商品了。
• 桥接表
  更加灵活，但是复杂度高。

多属性维度

这个是说维度的某个属性会有多个值，比如同一件商品它的颜色、尺寸会有多个。
我看书中的意思是没有使用最细粒度，如果都是sku粒度，这些都是唯一的，没有什么问题，把这些属性都作为sku的一个属性即可，这是最方便的，但是数据量会增加很多。

• 将多属性使用key-value的形式存在一个字段中
  这样粒度不变，处理方便，但是使用的时候有点儿复杂
• 将多属性放在多个字段中
  前面也说过，拆成多个字段，第一、第二、第三等，这样的缺点是拓展性不好。
• 使用最细的sku粒度
  就是上面说的最细粒度数据，使用方便，需要关注下数据量的问题。

杂项维度

Junk Dimension，这个杂项维度和印象中的不太一样，忘了以前从哪儿看到的，或者是记错了，我记忆中是这样用的：
建模过程中，有很多小维度，分开建成独立的维度的话，显得很多，很杂乱，所以就讲这些维度放到一个维度下面，统一管理。
而从目前的书中来看，有些不太对。
杂项维度的确是用来处理一些标志位，或者状态像0、1，Y、N这种描述性维度，支付转态、物流状态等，为了不让维度过多，就建立一个杂项维度，就是将这些维度整合成一个维度，通过笛卡尔积的形式生成记录。

就是将整合的多个维度记录，通过笛卡尔积的形式覆盖所有情况。