缓慢变化维的提出是因为维度的属性并不是静态的,他会随着时间线延长发生缓慢的变化。
常用的三种处理方式:
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.第三种方式,暂时没怎么用过,对于这种显而易见,优点:对于特殊场景下比较可用,比如查看商品变更前的价格,缺点:不便利,变一次加一个字段。
网友评论