Change Log 前世今生

本文深入探讨了ODS(操作数据存储)及其ChangeLog的工作原理。解释了ODS中的三个关键表:NewDataTable、ActiveDataTable 和 ChangeLogTable 的作用及相互关系。并通过实例展示了数据加载、激活和变更记录的过程。

       再说Change Log之前,我们有必要了解它的母体ODSBI 7 之后称为DSO)。从外界看来,ODS就像一个普通的Table,而我们常常访问ODS也是通过读取他的Active Data Table来获取ODS的数据。因为我们单纯只是了解DataODS中的存放结构,所以不会去探讨ODS的其他特性。


      上面我们提到了一个Active Data Table,事实上ODS的相关的数据会存放在三个Table中,分别是New Data Table 存放导入ODS且尚未激活的数据,Active Data table 存放激活后的ODS的数据,Change Log Table存放激活过程中产生的数据变动。这个三个表的命名规则为:
New Data Table:  /BIC/A*40   
(系统描述为 Active Records
Active Data Table: /BIC/A*00   
(系统描述为Update
Change Log Table:
流水号       (系统描述为Transfer Structure Application 8*


其中*表示具体的ODS名称。
那么怎么去理解这个三个表的关系呢。
首先我们假设当前某个ODS,暂且名为ZRL_001,它的结构为:

      现在我们来进行几次数据的加载,从中我们可以看到几个表的变化过程。
Step 1
:导入一批数据
    FISCPER   MATERIAL    AMOUNT   CURRENCY
   2010001      MAT001          100               RMB
   2010001      MAT002          100               RMB
   2010001      MAT003         100               RMB

各个表的数据情况:
/BIC/AZRL_O0140
New Data Table

其他两个表都暂时没有数据。
然后我们把这批数据激活。
这时候,New Data Table的数据被清空了,而其他两个表的数据如下:
/BIC/AZRL_O0100
Active Data Table

/BIC/B0004352000Change Log Table

      从上面几个表的变化,我们暂时只能知道,数据激活后会清空New Data Table,并加载到其他两个表,那么加载的逻辑是什么?既然名中有个Log,自然是有记录的意思,那么我们就加载如下记录,看看数据怎么变?
FISCPER   MATERIAL   AMOUNT    CURRENCY
2010001      MAT001      100            RMB
2010001      MAT002      200            RMB
2010001     MAT003       300            RMB

       在尚未加载之前,我们有必要预测一下未来,这也是一个程序员良好的思维习惯。我们知道这个ODS的关键字有时间、物料号,所以按照ODS的特性,它存放某笔记录时,只能存放唯一一条相同时间且相同物料号的数据行。所以单我们把最新的数据加载后,很明显,新旧三笔的关键字都是一一对应的,也就是说最终记录也就是只有三笔。
/BIC/AZRL_O0140
New Data Table

     激活后,New Data Table清空,我们再看看其他两个表的情况,
/BIC/AZRL_O0100: Active Data Table

/BIC/B0004352000Change Log Table

       Active Data Table的表的结果我们可以很好理解,因为它保存的就是最后的记录,我们这个认认真真看看Change Log发生了什么。
1. 
数据有原来的3行变成现在的7
2. 
我们上传的都是正数金额,但是出现了两行记录的金额是负数
3. 
最后一列的数据是我们没有关心的,但是现在看上去很碍眼,也很神奇


      首先看看从3行变成7行,都增加了哪些记录数。从Request这个一列我们可以很情况的看到,新增的是哪4行。从关键字方面考虑,它们都是成对出现的,日期因为都是一样我们就不管它。所以是料号MAT002MAT0032笔记录,因为清晰起见,我把MAT0023行记录先拿出来看看。

       我们应该知道,记录先后是没有区别的,所以大家不要被它们的先后顺序迷惑。在第二次上次过程我们把MAT002的金额改成了200,而之前的数字是100,稍微停顿思考之后,我们会发现系统在给我们上小学计算课,因为100 + 200 + -100 = 200而这个数字就是我们最后的值。所以,Change Log Table为我们展示的是一个简单而实用的补零的过程。以上只是我们自以为是推断,那么SAP BW是不是就是和我们不谋而合呢?大家回到命名规则说明的那段,系统是这样描述Change Log Table的“Transfer Structure Application 8*”(如果不知道什么是Transfer Structure,那就先找其他地方查查)。原来它是为作为一个数据源准备的,所以我们不难理解,为什么要补零。因为它导入到其它的地方的数据都是从Change Log Table来的(这里其实有一个前提,那就是导入到其他地方用的是delta机制),假设原来的100已经在Cube中了,现在要变成200,它不是先做一个计算,200-100 = 100,然后加载一个100进去,当然这样做我觉得也是行的通的,因为从数值上来讲,就是这样,但是为什么不这样做,因为没找到官方的书面说明(口头就更谈不上了),我们不知道,我们只能顺着结果去倒推来由。
    开始的三点疑问,大家应该已经知道一二了,所以在来看看三。RECORDMODE栏位放的到底是什么东西。

       看到上述帮助,以及之前我们对的观察,可以发现,它是对数据的状态描述。
        第一次出现,是“N”,第二次出现时为空代表最新数据,“X”代表之前的数据。这个描述有什么用?当删除Request的时候,ODS要返回到之前的值的时候,那么它可以通过这个RECORDMODE知道,之前之后的数据分别是什么,所以可以删的很坚决。如果爱热闹,可能还会问其他几个值是什么意思,抱歉,我们以后再说。


      
到目前为止,大家对Change Log Table应该有一定了解了。我们来说另外一个话题,删除Change Log Data


      
进入ODSManagement界面从菜单Environment中可以看到一个“Delete Change Log Data”子菜单。大家可能会想,上面说的把Change Log Table顶了天,这个既然可以删除里面的数据。没搞错?没错。那么到底是怎么回事?为什么可以删除?有什么局限?


      
为什么要删除?从前面我们的介绍,我们看到Active Data Table放了三笔记录,而Change Log Table却有七笔,因为它把数据的变化过程以及最新的数据都记录下来了,所以保守估计,它一定等于或多余Active Data Table的记录行。所以从数据存储方面来讲,它的空间占有大小,不容忽视。而实际上,我们使用ODS的过程中,也没有去用Change Log Table,所以想当然的想:应该要删,应该可以删。


    
说它没用到,是因为它的使用过程对我们来讲比较透明,如果真的没用到BW也不会多这个东西,所以一定有用,也一定要用。怎么用?如果你怎么问的话,说明没有好好看我之前的介绍。1. 它的补零用于后面的数据更新 2. 它的变动log,可以用于Request删除后的数据回退。


     当然它真的是可以删的,前提:1.我永远不用删Request  2.补零的作用已经完成。

     得出以上结论的原因是:1. 如果你要删Request,那么数据无法正确的回退,那么Active Data Table放的就是一个错误的值;2. 当把数据往其它地方导入用Change Log的数据,而它实际上已经被你删除,自然倒得的是错误数据。


   
所以我们再把删除Change Log Table的前提具体一点:1. 以后不会去删除已经删除在Change Log Table中对应Request的Request ; 2. 到删除点为止,ODS要导入其他地方的数据已全部导完,新的Request进来,会产生新的Change Log,而这些Change Log是彼此独立的。这时候你可以大胆的删了。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值