这篇文章给大家介绍大数据中缓慢变化维常见解决方案是什么，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
缓慢变化维：
数据仓库的重要特点之一是反映历史变化，所以如何处理维度的变化是维度设计的重要工作之一。缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化，与数据增长较为快速的事实表相比，维度变化相对缓慢。
在一些情况下，保留历史数据没有什么分析价值，而在另一些情况下,保留历史数据是非常重要的，在kimball理论中，有三种处理缓慢变化维的方式
采用此种方式，不保留历史数据，始终取最新数据
###变化前商品表和订单表
商品key | 商品id | 商品标题 | 所属类目 | 其他维度属性 |
1000 | item1 | titile1 | 类目1 | ... |
订单key | 日期key | 商品key | 交易金额 | 其他事实 |
9000 | 2020-04-10 | 1000 | 131.00 | ... |
###变化后商品表和订单表
商品key | 商品id | 商品标题 | 所属类目 | 其他维度属性 |
1000 | item1 | titile1 | 类目2 | ... |
订单key | 日期key | 商品key | 交易金额 | 其他事实 |
9000 | 2020-04-10 | 1000 | 131.00 | ... |
9001 | 2020-04-13 | 1000 | 52.00 | ... |
2.插入新的维度行
插人新的维度行。采用此种方式，保留历史数据，
维度值变化前的事实和过去的维度值关联，维度值变化后的事实和当前的维度值关联
###变化后商品表和订单表
商品key | 商品id | 商品标题 | 所属类目 | 其他维度属性 |
1000 | item1 | titile1 | 类目1 | ... |
1001 | item1 | titile1 | 类目2 | ... |
订单key | 日期key | 商品key | 交易金额 | 其他事实 |
9000 | 2020-04-10 | 1000 | 131.00 | ... |
9001 | 2020-04-13 | 1001 | 52.00 | ... |
3.添加维度列
采用第二种处理方式不能将变化前后记录的事实归一为变化前的维度或者归一为变化后的维度。比如根据业务需求，需要将4月份的交易金额全部统计到类目2上，采用第二种处理方式无法实现。针对此问题，采用第三种处理方式，保留历史数据，可以使用任何一个属性列
###变化前商品表和订单表
商品key | 商品id | 商品标题 | 所属新类目 | 所属旧类目 | 其他维度属性 |
1000 | item1 | titile1 | 类目1 | 类目1 | ... |
订单key | 日期key | 商品key | 交易金额 | 其他事实 |
9000 | 2020-04-10 | 1000 | 131.00 | ... |
###变化后商品表和订单表
商品key | 商品id | 商品标题 | 所属新类目 | 所属旧类目 | 其他维度属性 |
1000 | item1 | titile1 | 类目2 | 类目1 | ... |
订单key | 日期key | 商品key | 交易金额 | 其他事实 |
9000 | 2020-04-10 | 1000 | 131.00 | ... |
9001 | 2020-04-13 | 1000 | 52.00 | ... |
对于选择哪种方式处理缓慢变化维，并没有一个完全正确的答案，可以根据业务需求来进行选择。比如根据商品所属的类目统计2020年4月的成交额，商品所属的类目于 2020年4月 13 日由 类目 1变成类目2 ，假设业务需求方不关心历史数据，将所有的成交额都统计到最新的类目2上 ，则不需要保存历史数据：假设类目1属于某个业务部门 ，类目2属于另一个业务部门，不同业务部门需要统计各自的业绩，则需要保留历史数据。
关于大数据中缓慢变化维常见解决方案是什么就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
