小发展谈Delta.doc

小生长谈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 ERP系统针对后勤数据建立的信息系统，可以实时的收集数据，进行数据分析。而LIS的数据来源都是那些原始的后勤单据。所以当执行完V1后，系统会有一个V2过程，将类似VBAP、VBAK之类的数据更新到我们的LIS中。所以这个过程明显是V1之后，即有了所谓的异步的意思。在这里SAP对这类，时间性要求不高，相关性不严，重要性略低的数据更新过程定义为V2。 说到这里，可能大家觉得有点因果倒置，概况的讲不是有了LIS的更新才有V2，而是LIS的更新模式有异于之前的V1，所以重新又定义了一类更新即V2。但是V2的触发必须是V1执行之后，并且无需外力参与的。而这一点是和后面要说的V3的重要区别。 V3：Batch asynchronous update，批次异步更新。从定义上来说，V3和V2是可以等同的，都是对那类时效性要求不高的数据更新的统称。 当然还是有区别的，之前我们提到V2的触发是V1执行之后，程序自动触发。而V3的触发必须通过定义的相关程序，而相关程序的执行，必须借助任务管理。这也是我们需要通过LBWE去设置Job Control的原因。这里的批次有一重很重要的意思，就是数据是整批的执行的，甚至有聚集（就是同类汇总），而这一点也是可以减轻系统的负荷。 通过以上的论述，大家对Update Mode应该有了一个初步的认识，知道V1-V3只是对数据更新的一个类型定义。 下一节我们将移玉步到真正的Delta 更新模