关于数据增量抽取问题

hellogogo 2010-01-11 10:12:04

http://www.ahuoo.com/wp-content/uploads/2010/01/%E6%9C%AA%E5%91%BD%E5%90%8D1.jpg
以上为个人会员注册主题的事实表和维度表，所要表达的事实是会员来源这个事实，因为会员一旦注册，这个来源的事实将不会改变。如果大家觉得有什么问题，大家可以拍砖讨论。我希望大家是从数据仓库构建的原理上来分析解决问题，因为我现在为止还没有用过任何一个工具。

现在遇到的问题是，我如何进行数据的增量抽取，关于各个抽取的方式我了解的有：
全库比较、程序日志、数据库日志、时间戳、位图索引几种确定方式，这些方式基本都建立在原业务系统的冗余操作之上，例如时间戳是给业务数据记录额外的增加一个字段。我认为在实际操作过程中是不可取的，这必然会增加业务操作的复杂度，更为痛苦的是很多公司都是跨部门操作，难度更大。

我现在所想的抽取方式：
1、维表抽取更新方式：除日期维可以事先建立以外，其他维可以根据其时间戳来按天更新
2、事实表抽取更新方式：

代理键讨论：关于维表关键字的利用上，我在考虑是否需要另外添加序列化号来记录，在数据仓库的设计理论上说不应该利用原业务系统的ID，但我在这里发现利用原ID好像没有什么不妥，相反对于查取数据挺方便，因为我们原业务系统的ID是唯一且不会改变的，还请大家指点@@@。

事实表数据更新讨论：我这里想的是任何一个维表的数据发生了更新，都要通过关键字关联到事实表的更新所影响的数据。但这样的话就必然产生一些冗余的更新，例如会员维表添加了数据，则需要更新事实表，伙伴维表添加了数据，也需要更新事实表，如果时间区间一样，这两者很可能是重复的更新，其实只需要更新一次就OK，望拍砖@@@

3、最后一个问题，关于涉及到维表里面的业务数据发生修改以后，大家的维度表是如何更新的，难道大家在业务系统数据表里面添加一个触发器？还是有别的更好的办法，望指点@@@

O(∩_∩)O~ 高手们请出来吧，感觉这里气氛不是很浓，大家一起蹦起来吧

...全文

803 20 打赏收藏转发到动态举报

写回复

用AI写文章

20 条回复

切换为时间正序

请发表友善的回复…

发表回复

ORAClE SE 2012-08-24

打赏
举报

不知应该怎么搞呢。。。

mhm044 2012-08-23

打赏
举报

对我有用，学孞

mhm044 2012-08-23

打赏
举报

认真学习

taxueboy 2012-08-08

打赏
举报

学习需诶！加油！

nicholas_liang 2012-08-03

打赏
举报

[Quote=引用楼主的回复:]
代理键讨论：关于维表关键字的利用上，我在考虑是否需要另外添加序列化号来记录，在数据仓库的设计理论上说不应该利用原业务系统的ID，但我在这里发现利用原ID好像没有什么不妥，相反对于查取数据挺方便，因为我们原业务系统的ID是唯一且不会改变的，还请大家指点@@@。
[/Quote]

你的仓库的源库是唯一的，这样用源库的ID没有问题，但有多个源的时候就会出现问题了。

亚信联创大数据平台li 2011-04-19

打赏
举报

DB2有专门的工具，标记增量数据。具体是什么记不清了

chaoya 2010-03-16

打赏
举报

虽然不知道，帮顶，让高手看到

fb777 2010-03-15

打赏
举报

数据库日志不是挺好的吗？

hellogogo 2010-03-15

打赏
举报

回复5 楼 rt112000
对于我的第二个问题，你说不需要更新事实表，有何理？例如地区与用户的关系变了，难道不去更新事实表了，难道对事实表进行SCD2操作，建立冗余记录。

chyf212 2010-03-12

打赏
举报

认真学习
这个问题确实很值得钻研

yagebu1983 2010-02-04

打赏
举报

在SQLServer2008里，可通过时间戳来实现，只要你开启数据库的一个设置来完成

hbjlwhl 2010-02-02

打赏
举报

说实话，我们就是利用触发器来增加冗余字段来判断增量更新的。谢谢！！

rt112000 2010-01-31

打赏
举报

[Quote=引用楼主 hellogogo 的回复:]

代理键讨论：关于维表关键字的利用上，我在考虑是否需要另外添加序列化号来记录，在数据仓库的设计理论上说不应该利用原业务系统的ID，但我在这里发现利用原ID好像没有什么不妥，相反对于查取数据挺方便，因为我们原业务系统的ID是唯一且不会改变的，还请大家指点@@@。
[/Quote]
数据仓库记录的数据是不可（不应该）改变的（Nonvolatile) ，但事实上，常常维表上记录的信息是会变的。如一个用户在原来住山东，注册了一个公司得会员。后搬到湖北，注册了另一个公司的会员，在数据仓库中反应这种历史变化了（即所谓的slow changing dimension)？
3种方法：
1. Type 1：不反应，直接在原维表中对应的用户记录中修改地址。这种方法不适用此例，如果要查询所有湖北用户的注册信息，他在原来在山东注册的会员信息也会被包括。。。（当然，估计用户不关心，注重这点，也可以了）。。此法适用修改输入错误，或类似电话号码的改变的变化（因为你不会关心电话号码的改变）

2. Type 2：在维表中添加新的用户记录，一切不变的信息照旧，地址信息改为新地址。新的注册与新的用户记录相关联，由于表中的ID键是唯一的，所以你不能用原用户ID当做表的ID，要用到代理键。这样，这个用户在维表中有2条记录，不同只是代理键，和用户地址。这是最常见的方法。

3. Type 3：修改维表结构。在维表中加入另一套地址项，和修改时间项。吧用户的新地址加到该用户记录中新添的表项中，填入修改时间。这种方法影响了整个维表，扩大了维表篇幅。（不适用此例，我还没看到过这种方法比较合理的应用）

说了这么多，其实就是想说：为什么维表中最好用代理键。
[Quote=引用楼主 hellogogo 的回复:]

事实表数据更新讨论：我这里想的是任何一个维表的数据发生了更新，都要通过关键字关联到事实表的更新所影响的数据。但这样的话就必然产生一些冗余的更新，例如会员维表添加了数据，则需要更新事实表，伙伴维表添加了数据，也需要更新事实表，如果时间区间一样，这两者很可能是重复的更新，其实只需要更新一次就OK，望拍砖@@@
[/Quote]
不需要更新事实表。。。。
[Quote=引用楼主 hellogogo 的回复:]

3、最后一个问题，关于涉及到维表里面的业务数据发生修改以后，大家的维度表是如何更新的，难道大家在业务系统数据表里面添加一个触发器？还是有别的更好的办法，望指点@@@

O(∩_∩)O~ 高手们请出来吧，感觉这里气氛不是很浓，大家一起蹦起来吧
[/Quote]

是在做实时数据仓库么？估计要用ETL软件来控制了。。

个人拙见。。。