文档介绍：小生长谈Delta
很多年以后,有人看到这篇文章,知道Delta原来就是那么儿戏,会不会是BW白菜价的时候?有可能,信不信由你,我是信的。
数据仓库无法逃避,或者正是鹤立鸡群之处,就在于她的“海量”数据。从外部抽取数据,我们常常亲切地说成“吃数据“,而要求其他系统提供数据的时候则说成”喂数据“,因为这简直就是饕餮吗-自豪呀。
可是外部系统的数据量也是一天一天的在长大,会不会哪一天因为“吃“的太慢,“吃“不了呢?不会。信不信由你,我是信的,因为有Delta。
所谓的Delta其实就是增量的意思,有限增量。
不知道大家有没有听过一个术语“CDC”,全称“Changed Data Captured”,即变动数据捕获。说白了就是,把那些新增的,修改的标识出来。目前从技术层面来讲,CDC有好几种实现的方式,鉴于讨论的范围,我选择其中四种进行简单说明。
触发器:这个做过数据库开发的人都应该相当的熟悉,就是对表变动动作进行事件触发。这里我们要求至少对插入,修改,删除等三个事件进行触发。方法简单,性能也应该不错,不过这个不是原生态,需要技术人员后期加入,所以对业务表必须熟悉。当然,因为是触发器,对原系统多少还是有影响的。
时间戳:简单来说,就是在每一条记录上加上时间点,基于快照比较的方式来获取变动数据。性能自然不用说了,抽取逻辑也相当之简单。不过必须原系统自带时间戳管理(这里原系统不单单是DB,还要ERP系统本身)。
全表对比:典型的全表对比,采用MD5检验的方式。说白了,就是全表扫描。好处就是,不麻烦别人,缺点就是太麻烦了,获取增量数据的性能很差。
日志对比:通过日志来获取增量数据,不用麻烦别人,也不用自己麻烦,但是必须要原系统支持日志管理。
说完上面增量获取的方法后,我们就言归正传。BW就是通过上述的几种方法获取R/3的增量数据(目前增量仅限于R/3系统)。
那么到底如何实现呢?在讲之前,我们先来了解一下SAP ERP系统数据写入过程,举个例子,当用户用VA01开一张销售订单并千方百计输完后,选择保存,接下来其实是非常复杂的数据写入过程,只是我们都不会体察到,闪两下就过了。那么到底这写入过程,有什么讲究呢? -未完待续
当然有讲究!
SAP BW: 小生长谈Delta - 2 (Update Mode)
Robin Lei
Update Mode 即更新模式,ERP作为信息系统,自然免不了数据的存储,这里就涉及到几种。目前有三种更新模式,V1、V2、V3.
V1:Synchronous update , 同步更新。用户在完成单据保存的动作之后,ERP系统第一时间做出的数据更新动作。所以具有非常的时效性。比如说,用户完成销售订单后点击保存,系统将数据存入到VBAK和VBAP的过程(注意是过程)。整个过程时效性要求非常高,必须及时、快速、准确无误的执行。那么SAP就将这种类型的更新定义为V1。所以它的同步可以理解为保存单据的过程同时执行数据的更新保存。
V2:Asynchronous update,异步更新。按道理ERP系统那个单据不重要,应该都是采用V1模式来进行呀,事实上V2也是另作它用的。这里要稍微提一下LIS(Logistics Information System),这个可以认为是SAP BW的前身,是SAP ER