Change Log 前世今生

原址: http://space.itpub.net/554557/viewspace-630678

Change Log 前世今生
再说Change Log之前，我们有必要了解它的母体ODS（BI 7 之后称为DSO）。从外界看来，ODS就像一个普通的Table，而我们常常访问ODS也是通过读取他的Active Data Table来获取ODS的数据。因为我们单纯只是了解Data在ODS中的存放结构，所以不会去探讨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/B0004352000：Change 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/B0004352000：Change Log Table
 
Active Data Table的表的结果我们可以很好理解，因为它保存的就是最后的记录，我们这个认认真真看看Change Log发生了什么。
1. 数据有原来的3行变成现在的7行
2. 我们上传的都是正数金额，但是出现了两行记录的金额是负数
3. 最后一列的数据是我们没有关心的，但是现在看上去很碍眼，也很神奇
首先看看从3行变成7行，都增加了哪些记录数。从Request这个一列我们可以很情况的看到，新增的是哪4行。从关键字方面考虑，它们都是成对出现的，日期因为都是一样我们就不管它。所以是料号MAT002和MAT003个2笔记录，因为清晰起见，我把MAT002的3行记录先拿出来看看。
 
我们应该知道，记录先后是没有区别的，所以大家不要被它们的先后顺序迷惑。在第二次上次过程我们把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。
 进入ODS的Management界面从菜单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是彼此独立的。这时候你可以大胆的删了。