标准数据源增量.docx

标准数据源增量.docx

《标准数据源增量.docx》由会员分享，可在线阅读，更多相关《标准数据源增量.docx（21页珍藏版）》请在冰豆网上搜索。

标准数据源增量

Forpersonaluseonlyinstudyandresearch;notforcommercialuse

经典教材

标准数据源增量

增量管理是向数据仓库提供数据时所必需的，其作用在于及时加载数据仓库的源系统中更改的数据，以及把需要传输到数据仓库的数据缩小到最相关的数据范围。

此外，增量管理将有助于您对各自应用程序更改数据的访问，在某些情况下，还将使您第一时间获取这些数据。

下图说明了哪些BI源系统类型支持增量管理。

增量管理意味着能够在单个数据请求中只将新建、已更改的数据记录提取到BI系统中。

从技术角度而言，这表示请求DataSource的“增量更新”。

标有“DQ”=增量队列的表表明由增量队列使用的源系统暂时储存新建、已更改的数据记录（下面再做详细解释）。

增量队列是SAP源系统中用于增量记录（即新记录和已更改的记录）的临时中央资源库。

BI增量队列基于SAPWeb应用程序服务器（qRFC）RFC技术中的队列功能。

Delta增量管理分为（看下图）：

·对标准SAP数据源增量

·对LO后勤数据增量

·对其他数据源增量，如文件等

既然我们要对数据进行增量，那么首先就应该找到存放数据的数据源，也就是说要找到一个数据源的目录，也就是下面第一个表。

详细查看所有字段可输入T-CodeSE11，在输入下面表名称查看详细信息）。

ROOSOURCE表：

定义了每个数据源的基本属性。

下面我们先来分析一下这个表，

这里我们只分析一些重要的字段。

·TYPE（表示数据源的类型）

·EXMETHOD：

ExtractionMethod（抽取方法）

·TFMETHODS：

TransferMethods（传输方法）

·ZDD_ABLE字段表示是否支持“早期增量初始化”，这个表示在初始化时候是否继续收集增量；

·DETLA（DeltaProcessforaDataSource）（这个字段很重要）

增量流程是指数据的传输过程。

它指定如何在BI中确定数据目标的数据。

例如，这使您能设计出DataSource适合的数据目标、更新方法以及序列化的完成方法

从上图可以看到它有20种增量流程，我们接着开始了解下一些重要的增量流程。

增量过程字段都存储在下面这个表中。

RODELTAM表：

定义了每种增量提取方式的方法，这里的增量过程表也是需要讲解一些重要字段，方便对增量有更深入和全方位的了解。

（下面图中的X表示Yes的意思，“”空表示NO）

下图是每个字段的解释（看不懂没关系，后面会有更深入的介绍）。

好的我们继续介绍几种重要的增量流程方法的详细含义：

ABR采用前镜像、后镜像和反转镜像的更新模式，既支持覆盖又支持累加，所以数据源可以更新到DSO或者CUBE；

AIE采用后镜像模式，只支持覆盖，不支持累加，所以该类型数据源不能直接加载到CUBE，一般会先加载到DSO;在FI-AR/AP中此种增量处理方式应用较多；

ADD只支持累加，采用的是附加镜像的更新方式，所以既可以更新到DSO又可以更新到CUBE。

一般来说：

CO的数据源都是ADD的，差额镜像，EFI的基本都是AIE，后镜像，ELO的基本都是ABR，这个就不用说了，很明细，新、前、后、翻转的镜像都存，量很大，D自建的默认是AIE，同FI（BT的是没有提供更改方法，所以自建的统一都是AIE），E主数据的一般采用AIE、AIM和NEWE，说明比较侧重结果和新增数据。

GenericDelta通用增量流程服务

如果需要，您也可以集成“通用DataSource”的增量流程。

但是，需要符合某些前提条件。

必须具有一种确认已传输数据记录的方式，以便能够确定增量。

也就是说怎么去判断记录是增量产生的。

一般来说非后勤和主数据还有自建的数据源都是GenericDelta。

输入T-Code“RSO2”进入数据源管理，如果要使用“通用增量流程”，点击下图中红圈按钮。

进入下图界面：

这个界面是做什么用的哪？

这里就是前面说的设置判断数据是否为增量数据的地方。

·有四中字段类型来选择：

1Timestamp（UTC）世界通用时间

2Timestamp（Local）本地时间

3CalendarDay日历日

4NumericPointer数字指针（例如凭证编号等）

·设置增量选择的安全间隔上下限

安全间隔上限

如果此值为初始值，则存在提取期间产生的记录无法提取的危险。

示例：

使用时戳指定增量。

上次读取的时戳是12:

00:

00。

下次增量提取从12:

30:

00开始。

因此，选择间隔从12:

00:

00到12:

30:

00。

提取结束时，计数器设置为12:

30:

00。

比如文档记录的创建时间是12:

25，保存时间是12:

35。

此记录不包括在已提取数据范围之内，但下次由于记录的时戳，也不提取此记录。

为此，读取和传输数据之间的安全间隔应总是大于为此DataSource（为时戳增量）创建记录所需的最大时间范围，或应该是足够大的数据间隔（使用连续的数字指定增量）。

安全间隔下限

此字段包括必须从上次增量提取的最大值进行提取的值，以确定下次增量提取的时戳下限。

示例：

使用时戳指定增量。

提取的数据为主数据：

仅传输后像，覆盖BI中的状态。

对于此类数据，记录可能提取到BI两次而不会出现问题。

考虑到这一情况，总是将当前时戳用作提取期间的上限：

然后，下次提取的下限不会无缝连接到上次提取的上限。

然而，它接受与此上限减去安全间隔相符合的值。

此安全间隔必须足够大，以便提取可以包含上次提取时已经收到时戳但未读取的所有值。

当然，记录或许可以传输两次，但这不会因上述原因而带来任何影响。

·也可以选择增量的类型，如NewStatusforChangedReocrds（适合DSO和Cube）,AdditiveDelta（适合DSO）.

同时我们也可以查看设置增量的队列状态信息。

RSA7进入增量队列管理，如下图

上面穿插的介绍了通用数据源的增量方法。

下面接着讲解标准数据源的参数。

我们接着RODELTAM表其他字段来讲解。

增量类型字段（RODELTAM-DELTATYPE）是增量流程的属性。

它描述了如何在增量流程中加载增量。

以下特性值是允许的：

•'':

未定义增量类型。

•'A':

DataSource使用ALE更新指针确定增量。

此方法主要与DataSource结合使用，用于SAP源系统的属性和文本中。

它也用于使通用DataSource能够提供增量值（提供基础主数据表支持通用DataSource）。

主数据的ALE更新指针已经提供了很多年。

在过去，它们用于协调SAP系统外的主数据。

•'D':

SAP应用程序将增量数据记录直接写入至DataSource的增量队列（“推送”）。

每条数据记录a）在保存/更新应用程序的相应事务时单独储存在增量队列中（例如，FI-AR/AP或LOCockpit中的直接增量）b）通过应用程序特定的作业写入至增量队列的增量数据记录组中（在更新事务后）。

但是，在每一种情况下，增量数据记录在执行增量更新前仍然是SAP源系统增量队列中的记录。

如果是DataSource增量更新，则读取此增量队列，并将增量队列中的数据记录传输到BI系统。

此增量类型通常用于通过字段或控制表无法为基础应用程序表确定增量数据记录的应用程序中。

•'E':

DataSource在请求时通过提取器确定增量。

这表示请求时提取器必须能够为DataSource提供增量记录（“拉取”）。

提取器将已经确定的增量数据记录放在增量队列中，然后再从增量队列中传输到请求的BI目标系统。

如果已经为多个BI系统执行了增量初始化，或为同个BI系统执行了多次增量初始化，则提取器必须加载所有增量初始化的增量记录，并将增量记录保存在特定于BI目标系统的所有增量队列中。

此增量类型通常用于通过字段或控制表能够为基础应用程序表确定增量数据记录的应用程序中（例如，每个增量记录的时戳信息）。

•‘F‘:

通过平面文件加载增量数据记录。

这种增量类型仅用于平面文件源系统的DataSource中。

在执行InfoPackage时，将平面文件导入到PSA。

然后开始数据加载流程。

这里不使用增量队列。

这里再穿插介绍下平面文件的增量流程。

重要的DeltaType：

·DGenericDeltaforServiceAPI---PUSH方式

·EExtractorDeliversOLTPSourceDelta---PULL方式

序列化请求DREQSER字段。

下图是是增量流程中的序列化请求的3种方式。

1无序列化。

2对请求序列化。

3对数据包的序列化。

通过上面学习我们知道了：

·一个数据源支持什么样的增量更新；

·数据能更新到什么样的对象中；

·增量更新的类型和序列化方式；

我们来简单列一下增量提取的操作步骤：

1分析要提取的数据源（RSO2），然后查看其是否可以做Delta，它的增量流程用哪个，增量类型用哪个，增量怎样序列化。

2到BI数据源（RSA1）进行复制数据源。

3创建InfoPackage，对其进行增量参数选择，要匹配在R/3数据源端的配置。

4然后抽取数据到对应的DSO或者Cube中。

现在记录模式描述了数据记录包含的更改类型。

各种增量流程间的差异是每个增量流程仅支持七个可能特性值的子集。

如果DataSource实施的增量流程使用多个特性值，则字段ROCANCEL（保存记录模式）自动成为此DataSource的一部分。

DataSource的此字段会分配到BI系统的InfoObject0RECORDMODE中。

特性值如下：

•'':

记录提供后像。

在更改记录或添加数据后传输记录状态。

只有在请求相应的前像时，才会将记录直接更新到InfoCube（稍后解释）。

•'X':

记录提供前像。

在更改或删除记录前传输记录状态。

所有可以汇总（关键值）的记录属性必须用加/减冲销符号进行传输。

冲销加/减符号由提取器（缺省）或服务ServiceAPI负责。

这些记录在DataStore对象的非附加（覆盖）更新中予以忽略。

前像补充后像。

•'A':

记录提供附加图像。

如果属性可以集合，则仅传输更改。

如果属性无法集合，则传输数据更改或创建后的状态。

记录可以无限制地更新到InfoCube，但需要对DataStore对象进行附加更新。

•'D':

记录必须删除。

仅传输代码。

此记录只能更新到DataSource对象（因此DataStore也只能更新到DataSource对象）。

•'R':

记录提供倒像。

此记录的内容与前像相同。

唯一的区别是更新DataStore对象时：

删除代码相同的现有记录。

•'N':

记录提供新像。

此记录的内容与没有前像的后像相同。

创建记录时，应传输新像而不是后像。

新像补充倒像。

在表RODELTAM中，可以确定增量更新（列UPDM_NIM、UPDM_BIM、UPDM_AIM、UPDM_ADDUPDM_DEL和UPDM_RIM）所使用的特性值。

该表必须确保增量流程中只使用上述有用的特性值组合。

在以“增量更新”模式提取数据时，使用增量流程的DataSource仅为记录模式提供增量流程中指定的、已提取记录的特性值。

文件增量流程

如果增量流程使用平面文件，数据不会通过增量队列传输到BI。

而是直接从DataSource加载到PSA。

在此平面文件DataSource的传输规则中设置的增量流程必须得到关于基本数据和其增量属性的通知。

FIL0增量数据（后像）

FIL1增量数据（增量图像）

LO增量流程

LIS的更新方法（早期更新方法）：

同步更新（V1）：

DELTA队列与凭证同步更新，如果DELTA队列写入出现错误，那么凭证也被取消。

异步修改（V2）：

与V1相比，写入DELTA若出现错误，不对凭证的保存产生影响。

异步收集更新（V3）：

与做凭证没有关系。

在后台定义一程序，定时运行，收集产生变化的数据到DELTA队列。

知道了早期3种更新模式后，再来看LBWE中的几种增量模式：

DirectDelta:

这就是一种V1模式，数据同步更新到增量队列，这种模式系统负荷很重，特别是对于业务量大的凭证；

这是一种V1，直接V1到DeltaQueue，我们目前的LO数据源统统采用这个；

“直接增量”的好处与属性：

•通过在V1过帐流程中写入增量队列，使用应用程序的排队概念来保证按凭证进行的序列化。

•对于凭证较少的客户，如果在重组期间的初始化流程和增量初始化请求中出现停机时间，则建议采用该流程。

•此流程会比V3或“队列化增量”更加重V1的负担。

对于具有上述凭证数量的客户，这实际上并不是一个因素。

•提取与V2更新无关。

•对更新数据或提取队列进行其他监控是没有必要的。

QueuedDelta：

类似于V3的更新模式，与V3更新的区别在于，数据先被收集到一个抽取队列中（V1模式），然后被送到增量队列（V3模式）。

QueueDelta:

这是一种混合型，先V1到ExtractionQueue，后V3到DeltaQueue；

借助于此更新模式，在提取队列中收集受影响应用程序中的提取数据，而不是在更新数据中收集，并且可以将这些提取数据通过更新集中运行以类似于V3更新的方式传输到增量队列。

根据应用程序，可以将多达10,000次的凭证增量提取集中到每DataSource增量队列中的LUW。

“队列化增量”的好处和属性：

•通过在V1更新流程中写入提取队列，使用应用程序的排队概念来确保按凭证进行的序列化。

•由于在定期处理（SAP建议每小时执行一次）的提取队列中收集数据，所以特别建议凭证数量很多的客户采用该流程。

•收集运行使用与以前相同的报告（RMBWV311,...）。

•在初始化过程中，在增量初始化请求过程中收集新凭证数据会减少重组运行的停机时间（填充设置表）。

•V1比V3更难使用。

•与V3集中运行相比，该集中运行可实现最后的目标，且可以安排后续流程。

在完成应用程序的集中运行后，会自动触发可以在后续作业开始时使用的事件（&MCEX_11,...）。

•提取与V2更新无关。

UnserializedV3Update：

此类型的最大特征是没有序列化，就是说增量队列中凭证是无序的，这个对于采用覆盖模式的模型来说是最致命的，所以如果目标队列是DSO的话，还是不要采用这种模式好。

这是一种V3，先V3到UpdateTable，后V3到DeltaQueue。

借助于此更新模式，将正在查看的应用程序的提取数据写入含有V3更新模块的更新表，这些数据在使用更新集中运行读取和处理之前会一直保留在该更新表中。

不过会从更新表读取更新集中运行中的数据且不考虑顺序，然后将其传输到增量队列。

三种增量区别，你参照小结里的这些内容

直接增量V1：

order（VA01）--->deltaqueue（rsa7）

队列化增量V2：

order（va01）--->extractorqueue（LBWO）--->jobcontrol（LBWE）--->deltaqueue（rsa7）

未序列化的V3：

order（VA01）-updatetable（SM13）--->jobcontrol（LBWE）--->deltaqueue（RSA7）updatetable--->deltaqueue

对数据源抽取机制的深入探讨

一、什么数据源需要初始化，为什么要进行初始化

有增量机制的数据源就需要初始化，初始化的目的是为了给系统一个时间点，来生成Delta队列。

怎样进行初始化：

其实当我们跑I包的时候，Delta队列就建立了，这个和Setuptable没有关系Setuptable是怎么回事儿：

在LO（Logistic，后勤）的抽取中，Extractor不允许直接操作应用表，也许是为了方式读写的冲突，也许是为了保证凭证的安全，也许是为了减轻负载…反正就是不行，所以就得在initialization的时候Delete然后FillSetuptable。

仅限于LO的数据源。

Reasonsforwhysetuptablesis:

1）MainreasonisHUGEVOLUMESOFLOdata.

2）Toavoidinterdependency,whilestillmakingchangestransactionaltablesinR/3.

3）Customizedclusterandpooltablesenhancingextractioneasier.

FI的为什么不用Setuptable：

因为FI的数据可以直接从Table里抽取。

RSA7（DeltaQueue），这是虚拟的，真实存放数据的是SMQ1（OutboundQueue）

V3UpdateMode

1、Basedonyourdeltaupdatedmechanism,itwillbeeitherV1orV2orV3

2、Deltatableswillbebasedyourdeltaupdatedprocess,itwillbeeitherExtractionqueueorUpdatetablesandthecollectiverunwillbeeitherextractioncollectiverunorV3collectiverun

   所谓的V1、V2、V3有如下解释，这个东西在激活LO数据源的信息结构时可以看到：

V1同步更新模式，即凭证产生就更新增量，与业务数据同步更新；V2异步更新模式，就如一个两步的操作一样，第一步业务凭证更新了，然后再更新第二步的数据源增量表V3异步更新模式，与V2的区别在于他的更新时通过后台事件来触发的，即定一个任务定是收集增量并更新至增量表下图源自LBWE：

这里三种简单的说一下，更新方式的解释详见附件：

GistofLOCockpitDelta，据说本来还有个SerializedV3，7.0后就被取缔了。

DirectDelta:

这是一种V1，直接V1到DeltaQueue，我们目前的LO数据源统统采用这个QueueDelta:

这是一种混合型，先V1到ExtractionQueue，后V3到DeltaQueueUnserializedV3Update:

这是一种V3，先V3到UpdateTable，后V3到DeltaQueue 

Records在Transactiontables里

在初始化时，执行一个将Transactiondata存放在setuptable里的setup操作，也就是我们的填充设置表在执行初始化和Full包时读取的是设置表的内容新的Transactions被送到Transactiontables，之后被提取到Updatetables/ExtractionQueue（SM12/SM13），也就是SMQ1之后呢，会有一个周期性的Job，来把数据提取到DeltaQueue中（如果是V1的话就不用啦）当Delta上载执行时，会去读这个DeltaQueue。

二、Delta机制

TimeStamp

我们的R/3系统提供了这么一种功能，来标记新旧数据的差别，可以通过Timestamp，CalendarDay，NumericPointer来标注。

设置方法：

数据源要提供字段，用来填充DeltaSpecificFieldRSO2àGenericDeltaàTimestamp，有需求可以设置SafetyIntervalUpper/LowerLimit，拓展Timestamp和CalendarDay的边界。

只要在建立数据源的时候设置增量的特定字段，选取时间标记。

这里拿ZMAT_ATTR做例子，选的是Calend.Day，SafetyIntervalUpperLimit是1Calend.Days，NewStatusforChangedRecords，这么说来，就会每天跑一次，每次跑前两天的数据，而且以最后更改的记录为准（这个在下面会说到）。

这样做的效果可以在RSA7里看到，点GenericDelta：

CurrentStatus：

很简单，当前的Timestamp。

Notes：

为什么不是所有的都有呢？

因为这个叫做GenericDelta，可以简单的看一下，LO的数据源一个都没有，那种比较BT，一般来说非后勤和主数据还有自建的数据源都是GenericDelta。

看几张表：

ROOSPRMSC，222系统

要了解这张表，还需要知道一个概念叫做LUW，

LUWislogicalunitofwork.TheqRFCoutboundqueuecontrolledusinganOutboundScheduler（QOUTScheduler）.TheQOUTSchedulerpromptsthetransferofaLUWtoatargetsystemwhenallpreviousLUWsinthisqueuehavebeenprocessed.WhenoneLUWhasbeenexecuted,theQOUTSchedulerautomaticallyexecutesthenextLUWinthequeue.

InotherwordswhenwerequestdeltaloadfromBW,SourcesystemwillidentifythelastdeltarecordswhichareinformofTID'sbyusingROOSPRMSCtableanditwilldeletepreviousconfirmedLUWs（repeatdeltatable）andProcessnewLUWs（deltatable）

另外，想看这些请求号，可以到表RSREQDONE，这个要在200系统里。

Notes：

咱们用的Timestamp叫做UTCTimeStamp，什么是UTC，等同于GMT，就是世界时，咱们要+8:

00，也就是说这个DTP的时间是2009.03.13,08:

36:

26。

PS：

不过和222那边有那么10s的时间差（RSREQDONE表里的时间小10S），我也不知道怎么回事儿，后来查了下03_BF的，也是有10s的差，知道的同志可以告诉我呀。

。

。

当然这些并不重要

接下来几张表：

ARFCSSTATE

ARFCSDATA

TRFCQOUT

不多做解释，参照附件BW_DELTA-QUEUE-详细说明，第11页

BWDeltaProcess

这个可以用两张表来做解释：

第一个：

ROOSOURCE

这里的四个数据源，分别是LO（后勤），FI，主数据和自建数据源，各有不同。

这里的DeltaP