接上一篇：《大数据之路》读书笔记：维度设计
缓慢变化维
这个应该是知名度最高的，“缓慢变化”也是经常会被提起的一个场景。随着时间的变化，有一些维度是会变的，就像商品维度，经常有新商品上架，有商品下架，所以要看某一天在线的商品，就需要用缓慢变化维的方式来处理。
反映历史变化也是数仓的特性之一，为了应对这种变化，有几种处理方式：
重写维度值
如果我不关心历史数据，当属性变化了，那我就看最新的数据，不管历史是什么的话，我就可以直接去更新维度数据。
比如商品A，它原来叫矿泉水，后来改成矿物质水，直接更新就好了，这时候维度表会只存有一份最新的数据。插入新的维度行
当我们需要关注维度的历史数据的时候，我们就不能采取直接更新的方式了，我们可以通过新增记录的方式来解决，这样老的数据还在，新的数据也有。
这里要注意的是唯一建的问题，业务系统在更新维度信息的时候，很可能是直接更新掉，数仓中需要维护历史数据，所以在新增记录的时候如果没有代理键，要注意key值的唯一性，这种方法一般是需要代理键的，像上面说的商品修改名称，商品的业务key可能还是101，但是数仓中需要使用代理键来保证key值一致，但是代理键不同，这样才可以让事实表中的数据老数据使用老的代理键，新数据使用新的代理键。
这种方式也会有些问题，就是单独来看维度数据的话，同一个商品会有多条记录，会产生歧义；还有一点就是从维度表中可能看不出来记录的变化过程，并不清楚某一天该商品到底是哪一条记录为准，因为变化的特征都在事实表中。添加维度列
这个算是一种延伸的方法，类似方法一，为了让方法一可以存历史数据，除了新增记录（纵向），还可以采用横向的方式，就是新增字段（列），来记录变化前的记录，这样通过一条记录，就可以记录商品变化前和变化后的数据了。
这样可以保证key值唯一，但是缺点也显而易见，只能记录有限次数的变化，而且要提前规划好，保留几次历史记录。拉链表
还有一种常用的方式是拉链表，这种方式类似第2种方法，算是拓展版，也有点儿麻烦，简单来说，就是需要新增两个字段，start_date，end_date，用来记录这条就的有效周期，从哪一天开始，哪一天结束，使用的时候用这两个字段一过滤就好了。
在实际应用时，还是要考虑业务场景，根据实际情况选择，当然还有其他的方式，同样后面会再更新。
快照维度
上面说到了代理键，这个东西是很复杂的，按照维度建模的理论来，是需要搞一套代理键的，而实际操作起来会增加复杂度和维护成本，阿里采用的这种快照方式，也可以解决缓慢变化的问题。
以商品维度为例，就是每天都对商品维度生成一个快照，这样每天的商品信息都有了，key值也是唯一的，我想要看哪天的记录就看哪天，而且非常简单，使用也方便，就当前存储价格很便宜，这种方法最实用，当前公司也是使用这种方式，每天搞个分区，全量的快照，想用最新的就用最新的，想用历史的就用历史的。
当然它的缺点也明显，就是时间久了，历史数据非常庞大，有一定的存储浪费，需要注意对历史数据归档或清理。
极限存储
这个应该是阿里自己的一套实践方案，上面拉链表的方式，有几个缺点，一个是下游用户理解起来会稍有问题，需要一些解释成本，还有一个是使用start_date和end_date做分区的话，会有分区数量的限制，为了解决这些问题，阿里使用极限存储的方式来解决。
首先是在拉链表上层做了一层处理，让下游使用起来和每天一个快照的方式一样，方便使用；
然后是分月做历史拉链表，我感觉书上这里写的有点儿问题，或者是我还没理解，详情看看书吧。
微型维度
微型维度是为了解决维度属性频繁变化的问题，如果维度中有些属性经常会发生变化，可以将他们抽取出来，放到一个新维度表中，我觉这里说的也不是很好，看书中的意思，感觉和下面那个杂项维度差不多，思路是一样的，这里不过是将频繁变化的属性抽取出来，然后通过笛卡尔积生成所有记录，然后用代理键去关联。
递归维度
维度的递归问题，一般是业务系统中，开发的同学会这样设计。像类目或者组织架构这种，一般是有上下级关系的，除了设计成类似雪花那样的多个表，还会设计成递归存储的这种，这种维度，到数仓中，是需要处理下的。哦，这里会晕倒两种类型，一种是“均衡层次结构”，一种是“非均衡层次结构”。
扁平化
就是将维度数据打平，变成一张宽表，数据会冗余，但是使用起来非常方便。以商品维度来说，就是商品ID，商品名称、一级品类ID、一级品类名称、二级品类ID、二级品类名称......层级桥接表
这个方式到是没有用过，相比扁平化操作更加的灵活。
这种方式需要搞一个桥接表，就是个映射关系表，用父、子关系和父子之间相隔的层级数来记录。
这种方式还是需要一个扁平化的表，只是又搞了一个中间表。
书中有说到，选择哪一种方法的时候，要考虑实际应用，比如上钻、下钻是怎样实现的，和前端也会有些关系。
行为维度
这个不是直接存在于业务中的维度，而是通过其他业务梳理出来或者衍生出来的维度，这些维度是通过某种计算规则统计出来的，而不是原生存在的，可以分为几种：
- 另一个维度的过去行为
买家最近一次访问淘宝的时间、买家最近一次发生交易行为的时间 - 快照事实行为维度
买家从年初至今的淘宝交易金额、买家信用值 - 分组事实行为维度
买家从年初至今的淘宝交易金额划分的等级、买家信用值等级 - 复杂逻辑事实行为维度
通过复杂算法或加工多个事实输出的维度
实际处理这种维度时，可以增加到当前类似的维度表中，或者新增维度。需要注意维度的变化频率和耦合性，后期维护成本等。
多值维度
这个主要是事实表和维度表粒度的不一致的问题，书中举的例子是订单主表和订单明细表，一笔订单会购买多个商品。有几种处理方式：
- 降低事实表粒度
像上面的例子，直接以订单明细为最细粒度 - 采用多字段
有些场景下对应的多维度可能是可确定的，比如两个、三个等，可以通过增加字段的形式。比如我一单只会买两种商品，那就可以设计为第一种商品和第二种商品了。 - 桥接表
更加灵活，但是复杂度高。
多属性维度
这个是说维度的某个属性会有多个值，比如同一件商品它的颜色、尺寸会有多个。
我看书中的意思是没有使用最细粒度，如果都是sku粒度，这些都是唯一的，没有什么问题，把这些属性都作为sku的一个属性即可，这是最方便的，但是数据量会增加很多。
- 将多属性使用key-value的形式存在一个字段中
这样粒度不变，处理方便，但是使用的时候有点儿复杂 - 将多属性放在多个字段中
前面也说过，拆成多个字段，第一、第二、第三等，这样的缺点是拓展性不好。 - 使用最细的sku粒度
就是上面说的最细粒度数据，使用方便，需要关注下数据量的问题。
杂项维度
Junk Dimension，这个杂项维度和印象中的不太一样，忘了以前从哪儿看到的，或者是记错了，我记忆中是这样用的：
建模过程中，有很多小维度，分开建成独立的维度的话，显得很多，很杂乱，所以就讲这些维度放到一个维度下面，统一管理。
而从目前的书中来看，有些不太对。
杂项维度的确是用来处理一些标志位，或者状态像0、1，Y、N这种描述性维度，支付转态、物流状态等，为了不让维度过多，就建立一个杂项维度，就是将这些维度整合成一个维度，通过笛卡尔积的形式生成记录。
就是将整合的多个维度记录，通过笛卡尔积的形式覆盖所有情况。
