缓慢变化维的提出是因为维度的属性并不是静态的，他会随着时间线延长发生缓慢的变化。
常用的三种处理方式：
1.重写维度值，不保留历史，始终取最新数据。
2.插入新的维度行，历史事实数据与历史维度关联，新的事实数据与新的维度关联。
3.插入新的维度列。
举个：有一个商店店铺，20191101类目是A,20191102更改为B。
| 商店id | 类目 | 其他属性 | 日期 |
|---|---|---|---|
| 1000 | A | ... | 20191101 |
第一种处理方式，结果如下：
| 商店id | 类目 | 其他属性 | 日期 |
|---|---|---|---|
| 1000 | B | ... | 20191102 |
第二种处理方式，结果如下：
| 商店id | 类目 | 其他属性 | 开始日期 | 结束日期 |
|---|---|---|---|---|
| 1000 | A | ... | 20190101 | 20191101 |
| 1000 | B | ... | 20191102 | 99991202 |
第三种处理方式，结果如下：
| 商店id | 类目 | 其他属性 | 新类目 | 日期 |
|---|---|---|---|---|
| 1000 | A | ... | B | 20191102 |
三种方式在建模时择优使用，对比一下这三种方式
1.第一种方式，比较常用的就是快照，每个分区保留一份全量数据，使用时间维度限制关联维度key，优点：简单有效，开发维护成本低，使用方便清晰，缺点：存储浪费， 但可使用生命周期管理，对其做一定的优化，这也是一般常用的方法。
2.第二种方式，比较常用的就是拉链表，通过时间范围对其做进行关联，优点：极大地压缩了存储的成本，又保留了历史数据，缺点：对于下游使用不友好，可通过视图的方式进行打平的方式进行透明化操作，如同使用全量表，对于变化频率高的数据达不到节约成本的效果。对于变化频率高的字段需过滤单独处理。
3.第三种方式，暂时没怎么用过，对于这种显而易见，优点：对于特殊场景下比较可用，比如查看商品变更前的价格，缺点：不便利，变一次加一个字段。
