数据仓库中的数据形态

对于数据仓库中的数据,我们一般理解都是记录历史变化的。他的定义中也明确提到这一点,所以数据仓库中的事实表一般都有时间或时间戳字段来支持记录的历史变化,而且不光是事实表,维表也要体现历史变化,其中,代理键就起了一定的作用。但是对于ODS层表,他记录的是最近时间的原子数据,忽略了一些历史信息。
 
ODS层表的数据形态按反应历史变化情况可以分成两种,一种是快照型的,一种是事件型的。
 
系统中存在一种数据,如果用ER图表示的话,他们多是被别的数据参照,这种数据不知有没有固定的叫法,这里姑且叫做“主数据”。顾名思义,这些数据是很重要的,是系统的核心数据,被引用的越多越重要。例如产品数据、客户数据,以及一系列的代码数据,都属于主数据。而主数据在ODS层中的存储一般都是选择快照型的形态存储。快照型数据反应的是最近一点时刻,主数据的状态信息,例如客户的状态,客户的信用度等,他们都通过update操作将前次状态或信用度都更新掉了。而另一种数据形态,事件型数据,记录是事件的发生,例如记录一次通话,记录一次开帐等,日志表也属于这种形态,它反应的是对数据的历史操作。这两种形态的数据一个较大的区别就是前者会不断被更新,而后者一般不会做更新操作。
 
理解这两种数据形态对于数据抽取有一些帮助。因此在数据仓库日常的ETL工作中,不可能总是处理全量数据,那个量就太大了,必须寻找增量。这里的增量不是指增加的数据量,还包括修改的和删除的数据。增量的支持对数据源系统是一个很大的考验,对于快照型数据,数据源在实时变化,如何捕捉一个时间段内所有发生变化的数据?一种方法是加入时间戳,所有插入、更新操作都能反应到时间戳,通过选取时间戳在某个时间周期内,就可以得到该周期内的增量数据。但是这种方式没法得到删除的数据(不过一般而言,对于主数据的删除都是很少发生,因为有别的数据在引用它,多数采取删除标记的做法)。还有一种方式得到快照型数据增量,通过数据变更日志,因为每条日志反应的是记录的变化,一个时间周期内出现在日志中的主数据,就是该周期的增量。这种方式还能处理删除数据,但是到了ODS 层,通常也不建议删除任何数据。
 
通过这两种方式获取快照型数据增量都有一些问题。主要是数据源的支持程度,例如是否有时间戳字段?日志是否记录每种主数据变化?有些系统的答案是否。例如数据源的用户表、客户表就很少有时间戳,而对日志,很可能不能反应所有数据状态变化,以前遇到过一种情况,系统有用户开机日志,停机日志,但这些日志是属于营业模块的,而当另一个信用监控模块对用户作出欠费停机处理后,日志中就没有。如果数据源对这两种方式的增量抽取支持都不够的话,可就得想一些办法了,“ 宁杀一千,不放一个”。一边是全量处理的性能矛盾,一边是增量支持不力的矛盾,需要一种平衡。比如对于用户增量数据,在用户表中有一系列时间字段,如开户时间、开机时间、停机时间、销户时间等,通过这些时间的判断,也能得出一种增量,只不过略显麻烦,而且也不能保证数据源对这些时间的维护是一致的。
 
对于事件型数据,处理增量相对直观一些,因为这种数据一般都有时间字段或时间戳。但是增量抽取同样存在一些问题。主要是对历史数据的修改,严格意义上,事件发生了,既成事实,不要在修改这些数据,要修改也只是另外一次事件了。但是数据源存在这种现象去修改历史记录,甚至还有手工修改的,根本无法通过时间信息来获取增量。例如话单重批和帐务调账等操作很多都是修改历史数据。面对这种情况,有时就得作出选择,忽略这些数据变化。

摘自 http://happysboy.bokee.com/100204.html

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值