百万级的大维表如何做缓慢变化维？
0
没有找到相关结果
重要提示：提问者不能发表回复，可以通过评论与回答者沟通，沟通后可以通过编辑功能完善问题描述，以便后续其他人能够更容易理解问题.
没有找到相关结果
推荐一份编程学习资源，包含了各类编程语言学习进阶路线图、视频教程、配套书籍文档、数百份面经，各大厂面试真题。编程语言包括：Java、前端、PHP、Python、Linux运维、软件测试、数据解构与算法、C语言、go语言等
微信扫码关注公众号，发送 "编程"获取资源
2 个回复
BAO胖子 - 15年BI经验，涉足电力，快消品，医药，信息服务等行业的BI老兵。 2015-11-16 回答
赞同来自: 梁勇 、BIWORK
其次，你得弄明白你那些变化的维度真的是缓慢变化的吗？
基本上，大部分的维度的属性其实都不是需要保留历史的，如果你的需求只是保留历史，而不是为了分析变化，那么就把历史表拆出来，万一用了的时候再用，其他时候不用。如果真是有个别需要分析变化的维度成员，要看变化的频率，如果你的有很多列，按SCD2，每个成员平均一周就要增加一行的话，一年下来，这张表就编程1M*50，脑补一下还是原来你期待的数据级别吗？一种建议是，变得快的，拆出来单独处理，或者把那一列加到FACT Table里面去，维度表不记录变化。对于变得慢的，比如一年变个1-2次的，可以考虑SCD2的标准做法，然后...历史数据你要酌情来看保存多久。还有一种是周期性很强的，比如每个季度就搞一次，就再派生一个带时间键的表。总之，你得根据需求走，这方面要引导客户，很多客户的愿望是维表保留所有历史，然后他们一辈子都不用。
天善小编 - 微信直播问题收集 2015-11-16 回答
赞同来自:
老头子：首先百万级的维表要看有多少字段，其次要看需要缓慢变化的有哪些字段，然后只针对这几个字段进行处理即可。具体你说的缓慢，是处理方式问题，基本使用ETL进行缓慢变化处理，不把压力放在数据库中，比如在Datastage里进行合并然后MD5check。
广州~BI~冬：老师的意思是使用专业的ETL工具会比在oracle中效率高？还是效率相当，只是纯粹把压力转向ETL服务器呢？？
老头子：意思是把压力转向ETL服务器，自己如果能写出更棒的算法，那是更好，如果没有，就不要把所有压力给数据库，不过这要看系统的性能瓶颈在哪儿，如果瓶颈在ETL，那我们就应该在数据库中处理，这个要分情况来看。