事实表的更新问题

作为数据仓库基础的事实表如何更新比较合适？

我们正在建设的数据仓库事实表数据量很大，且每天都有数据需要添加，其中新添加的数据还有可能对已经导入数据仓库的数据进行覆盖。

我们目前的实现方式是“完全更新”。但是执行时间太长了，将来数据量更大的时候，会不堪承受。

可是如果部分更新，有很难实现,比如添加哪些数据、删除哪些数据，很不好决定（因为没有限制用户删除以前上报的数据）。

大家对此问题有什么经验？

11 个解决方案

#1

你这是什么行业的数据仓库？　增量更新为什么不能实现？

#2

事实表中的数据刷新很大程度取决于粒度的级别和分割的结果。。。

建议设计好粒度的划分和分割策略，可以把简单堆积和轮转综合结合起来使用。。。

由于不了解你的实际需求，不当之处请多多讨论。。。

#3

最好还是在业务系统中做出一些调整，配合一下。只要能限定一个时间周期，保证超过这个周期的数据不会发生任何修改，就好办了。

#4

读日志文件就可以增量更新
还读时间磋来更新，比如每周一次
还有在业务表写触发器。把修改和删除的记录保存在一张表。ETL的时候读这张表就可以了

#5

数据仓库中的数据只能够增量更新，是不能进行修改或删除的，除非是删除几年前的数据。因此如果正如楼主说的：“我们正在建设的数据仓库事实表数据量很大，且每天都有数据需要添加，其中新添加的数据还有可能对已经导入数据仓库的数据进行覆盖。”说明数据仓库的设计存在问题。

也许你说的事实表实际上应该是在数据真正导入到数据仓库表前在数据仓库服务器中的数据准备用到的表（?）。。。建议楼主好好审查一下数据仓库的设计。。。

也许楼主的系统是ODS系统？？？

#6

用触发器来实现数据的更新，再用完全更新来更新Cube，个人意见。

#7

我做过一个多维的东东,
每天增加数据10万到100万之间,
我建了一个DTS包,再建一个调度,每天晚上执行一下,

#8

#9

怎么会有覆盖的情况呢？你的时间是干什么用的？？？

#10

理论上数据仓库的数据是不能覆盖的。只能增加，不能更新。如果需要更新，说明设计有问题。

#11

我的几点看法：
1：看看你的数据的粒度是否合适？是否是双重粒度？数据量大，粒度可能要粗一点。
2：看看分区是否合适？？
3：事实表更新一般要采取增量更新方式，除非数据量很少。增量的方式可以用时间戳、日志、增量文件甚至全表扫描。
4：如果事实表存在删除或更新问题，说明设计上有一定问题。我想这可能是由于维的变化引起的，即使这样事实表也不能更新或删除啊。
对于缓慢变化的维，事实表如何处理，有专门的技术处理事实表。
具体参见微软网站。

#1