标准数据源增量.docx

1、标准数据源增量For personal use only in study and research; not for commercial use经典教材标准数据源增量增量管理是向数据仓库提供数据时所必需的，其作用在于及时加载数据仓库的源系统中更改的数据，以及把需要传输到数据仓库的数据缩小到最相关的数据范围。此外，增量管理将有助于您对各自应用程序更改数据的访问，在某些情况下，还将使您第一时间获取这些数据。下图说明了哪些BI 源系统类型支持增量管理。增量管理意味着能够在单个数据请求中只将新建、已更改的数据记录提取到BI 系统中。从技术角度而言，这表示请求DataSource 的“增量更新”。标

2、有“DQ” = 增量队列的表表明由增量队列使用的源系统暂时储存新建、已更改的数据记录（下面再做详细解释）。增量队列是SAP 源系统中用于增量记录（即新记录和已更改的记录）的临时中央资源库。BI 增量队列基于SAP Web 应用程序服务器(qRFC) RFC 技术中的队列功能。Delta增量管理分为（看下图）： 对标准SAP数据源增量 对LO后勤数据增量 对其他数据源增量，如文件等既然我们要对数据进行增量，那么首先就应该找到存放数据的数据源，也就是说要找到一个数据源的目录，也就是下面第一个表。详细查看所有字段可输入T-Code SE11，在输入下面表名称查看详细信息）。 ROOSOURCE表：定

3、义了每个数据源的基本属性。下面我们先来分析一下这个表，这里我们只分析一些重要的字段。 TYPE（表示数据源的类型） EXMETHOD：Extraction Method(抽取方法) TFMETHODS：Transfer Methods(传输方法) ZDD_ABLE字段表示是否支持“早期增量初始化”，这个表示在初始化时候是否继续收集增量； DETLA(Delta Process for a DataSource) （这个字段很重要）增量流程是指数据的传输过程。它指定如何在BI中确定数据目标的数据。例如，这使您能设计出DataSource 适合的数据目标、更新方法以及序列化的完成方法从上图可以看到

4、它有20种增量流程，我们接着开始了解下一些重要的增量流程。增量过程字段都存储在下面这个表中。 RODELTAM表：定义了每种增量提取方式的方法，这里的增量过程表也是需要讲解一些重要字段，方便对增量有更深入和全方位的了解。（下面图中的X表示Yes的意思，“ ”空表示NO）下图是每个字段的解释（看不懂没关系，后面会有更深入的介绍）。好的我们继续介绍几种重要的增量流程方法的详细含义：ABR采用前镜像、后镜像和反转镜像的更新模式，既支持覆盖又支持累加，所以数据源可以更新到DSO或者CUBE；AIE 采用后镜像模式，只支持覆盖，不支持累加，所以该类型数据源不能直接加载到CUBE，一般会先加载到DSO;

5、在FI-AR/AP中此种增量处理方式应用较多；ADD只支持累加，采用的是附加镜像的更新方式，所以既可以更新到DSO又可以更新到CUBE。一般来说：CO的数据源都是ADD的，差额镜像，E FI的基本都是AIE，后镜像，E LO的基本都是ABR，这个就不用说了，很明细，新、前、后、翻转的镜像都存，量很大，D 自建的默认是AIE，同FI（BT的是没有提供更改方法，所以自建的统一都是AIE），E 主数据的一般采用AIE、AIM和NEWE，说明比较侧重结果和新增数据。Generic Delta 通用增量流程服务如果需要，您也可以集成“通用DataSource” 的增量流程。但是，需要符合某些前提条件。必

6、须具有一种确认已传输数据记录的方式，以便能够确定增量。也就是说怎么去判断记录是增量产生的。一般来说非后勤和主数据还有自建的数据源都是Generic Delta。输入T-Code“RSO2”进入数据源管理，如果要使用“通用增量流程”，点击下图中红圈按钮。进入下图界面：这个界面是做什么用的哪？这里就是前面说的设置判断数据是否为增量数据的地方。 有四中字段类型来选择：1 Time stamp (UTC) 世界通用时间2 Time stamp (Local) 本地时间3 Calendar Day 日历日4 Numeric Pointer 数字指针（例如凭证编号等） 设置增量选择的安全间隔上下限安全间隔

7、上限如果此值为初始值，则存在提取期间产生的记录无法提取的危险。示例：使用时戳指定增量。上次读取的时戳是12:00:00。下次增量提取从12:30:00 开始。因此，选择间隔从12:00:00 到12:30:00。提取结束时，计数器设置为12:30:00。比如文档记录的创建时间是12:25，保存时间是12:35。此记录不包括在已提取数据范围之内，但下次由于记录的时戳，也不提取此记录。为此，读取和传输数据之间的安全间隔应总是大于为此DataSource（为时戳增量）创建记录所需的最大时间范围，或应该是足够大的数据间隔（使用连续的数字指定增量）。安全间隔下限此字段包括必须从上次增量提取的最大值进行提

8、取的值，以确定下次增量提取的时戳下限。示例：使用时戳指定增量。提取的数据为主数据：仅传输后像，覆盖BI 中的状态。对于此类数据，记录可能提取到BI 两次而不会出现问题。考虑到这一情况，总是将当前时戳用作提取期间的上限：然后，下次提取的下限不会无缝连接到上次提取的上限。然而，它接受与此上限减去安全间隔相符合的值。此安全间隔必须足够大，以便提取可以包含上次提取时已经收到时戳但未读取的所有值。当然，记录或许可以传输两次，但这不会因上述原因而带来任何影响。 也可以选择增量的类型，如New Status for Changed Reocrds(适合DSO和Cube), Additive Delta（适合

9、DSO）.同时我们也可以查看设置增量的队列状态信息。RSA7进入增量队列管理，如下图上面穿插的介绍了通用数据源的增量方法。下面接着讲解标准数据源的参数。我们接着RODELTAM表其他字段来讲解。增量类型字段(RODELTAM-DELTATYPE) 是增量流程的属性。它描述了如何在增量流程中加载增量。以下特性值是允许的： : 未定义增量类型。 A:DataSource 使用ALE 更新指针确定增量。此方法主要与DataSource 结合使用，用于SAP 源系统的属性和文本中。它也用于使通用DataSource 能够提供增量值（提供基础主数据表支持通用DataSource）。主数据的ALE 更新指

10、针已经提供了很多年。在过去，它们用于协调SAP 系统外的主数据。 D:SAP 应用程序将增量数据记录直接写入至DataSource 的增量队列（“推送”）。每条数据记录a) 在保存/更新应用程序的相应事务时单独储存在增量队列中（例如，FI-AR/AP 或LO Cockpit 中的直接增量） b) 通过应用程序特定的作业写入至增量队列的增量数据记录组中（在更新事务后）。但是，在每一种情况下，增量数据记录在执行增量更新前仍然是SAP 源系统增量队列中的记录。如果是DataSource 增量更新，则读取此增量队列，并将增量队列中的数据记录传输到BI 系统。此增量类型通常用于通过字段或控制表无法为基础

11、应用程序表确定增量数据记录的应用程序中。 E:DataSource 在请求时通过提取器确定增量。这表示请求时提取器必须能够为DataSource 提供增量记录（“拉取”）。提取器将已经确定的增量数据记录放在增量队列中，然后再从增量队列中传输到请求的BI 目标系统。如果已经为多个BI 系统执行了增量初始化，或为同个BI 系统执行了多次增量初始化，则提取器必须加载所有增量初始化的增量记录，并将增量记录保存在特定于BI 目标系统的所有增量队列中。此增量类型通常用于通过字段或控制表能够为基础应用程序表确定增量数据记录的应用程序中（例如，每个增量记录的时戳信息）。 F:通过平面文件加载增量数据记录。这种

12、增量类型仅用于平面文件源系统的DataSource 中。在执行InfoPackage 时，将平面文件导入到PSA。然后开始数据加载流程。这里不使用增量队列。这里再穿插介绍下平面文件的增量流程。重要的Delta Type： D Generic Delta for Service API - PUSH方式 E Extractor Delivers OLTP Source Delta - PULL 方式序列化请求DREQSER字段。下图是是增量流程中的序列化请求的3种方式。1 无序列化。2 对请求序列化。3 对数据包的序列化。通过上面学习我们知道了： 一个数据源支持什么样的增量更新； 数据能更新到什

13、么样的对象中； 增量更新的类型和序列化方式；我们来简单列一下增量提取的操作步骤：1 分析要提取的数据源（RSO2），然后查看其是否可以做Delta，它的增量流程用哪个，增量类型用哪个，增量怎样序列化。2 到BI数据源（RSA1）进行复制数据源。3 创建InfoPackage，对其进行增量参数选择，要匹配在R/3数据源端的配置。4 然后抽取数据到对应的DSO或者Cube中。现在记录模式描述了数据记录包含的更改类型。各种增量流程间的差异是每个增量流程仅支持七个可能特性值的子集。如果DataSource 实施的增量流程使用多个特性值，则字段ROCANCEL（保存记录模式）自动成为此DataSourc

14、e 的一部分。DataSource 的此字段会分配到BI 系统的InfoObject 0RECORDMODE 中。特性值如下： : 记录提供后像。在更改记录或添加数据后传输记录状态。只有在请求相应的前像时，才会将记录直接更新到InfoCube（稍后解释）。 X:记录提供前像。在更改或删除记录前传输记录状态。所有可以汇总（关键值）的记录属性必须用加/减冲销符号进行传输。冲销加/减符号由提取器（缺省）或服务Service API 负责。这些记录在DataStore 对象的非附加（覆盖）更新中予以忽略。前像补充后像。 A:记录提供附加图像。如果属性可以集合，则仅传输更改。如果属性无法集合，则传输数据

15、更改或创建后的状态。记录可以无限制地更新到InfoCube，但需要对DataStore 对象进行附加更新。 D:记录必须删除。仅传输代码。此记录只能更新到DataSource 对象（因此DataStore也只能更新到DataSource 对象）。 R:记录提供倒像。此记录的内容与前像相同。唯一的区别是更新DataStore 对象时：删除代码相同的现有记录。 N:记录提供新像。此记录的内容与没有前像的后像相同。创建记录时，应传输新像而不是后像。新像补充倒像。在表RODELTAM中，可以确定增量更新（列UPDM_NIM、UPDM_BIM、UPDM_AIM、UPDM_ADD UPDM_DEL 和UP

16、DM_RIM）所使用的特性值。该表必须确保增量流程中只使用上述有用的特性值组合。在以“增量更新”模式提取数据时，使用增量流程的DataSource 仅为记录模式提供增量流程中指定的、已提取记录的特性值。文件增量流程如果增量流程使用平面文件，数据不会通过增量队列传输到BI。而是直接从DataSource 加载到PSA。在此平面文件DataSource 的传输规则中设置的增量流程必须得到关于基本数据和其增量属性的通知。FIL0 增量数据（后像）FIL1 增量数据（增量图像）LO增量流程LIS的更新方法(早期更新方法)：同步更新（V1）：DELTA队列与凭证同步更新，如果DELTA队列写入出现错误，

17、那么凭证也被取消。异步修改（V2）：与V1相比，写入DELTA若出现错误，不对凭证的保存产生影响。 异步收集更新（V3）：与做凭证没有关系。在后台定义一程序，定时运行，收集产生变化的数据到DELTA队列。知道了早期3种更新模式后，再来看LBWE中的几种增量模式：Direct Delta:这就是一种V1模式，数据同步更新到增量队列，这种模式系统负荷很重，特别是对于业务量大的凭证；这是一种V1，直接V1到Delta Queue，我们目前的LO数据源统统采用这个；“直接增量”的好处与属性： 通过在V1 过帐流程中写入增量队列，使用应用程序的排队概念来保证按凭证进行的序列化。 对于凭证较少的客户，如果

18、在重组期间的初始化流程和增量初始化请求中出现停机时间，则建议采用该流程。 此流程会比V3 或“队列化增量”更加重V1 的负担。对于具有上述凭证数量的客户，这实际上并不是一个因素。 提取与V2 更新无关。 对更新数据或提取队列进行其他监控是没有必要的。Queued Delta：类似于V3的更新模式，与V3更新的区别在于，数据先被收集到一个抽取队列中（V1模式），然后被送到增量队列（V3模式）。Queue Delta:这是一种混合型，先V1到Extraction Queue，后V3到Delta Queue；借助于此更新模式，在提取队列中收集受影响应用程序中的提取数据，而不是在更新数据中收集，并且可

19、以将这些提取数据通过更新集中运行以类似于V3 更新的方式传输到增量队列。根据应用程序，可以将多达10,000 次的凭证增量提取集中到每DataSource 增量队列中的LUW。“队列化增量”的好处和属性： 通过在V1 更新流程中写入提取队列，使用应用程序的排队概念来确保按凭证进行的序列化。 由于在定期处理（SAP 建议每小时执行一次）的提取队列中收集数据，所以特别建议凭证数量很多的客户采用该流程。 收集运行使用与以前相同的报告(RMBWV311,.)。 在初始化过程中，在增量初始化请求过程中收集新凭证数据会减少重组运行的停机时间（填充设置表）。 V1 比V3 更难使用。 与V3 集中运行相比，

20、该集中运行可实现最后的目标，且可以安排后续流程。在完成应用程序的集中运行后，会自动触发可以在后续作业开始时使用的事件(&MCEX_11,.)。 提取与V2 更新无关。Unserialized V3 Update：此类型的最大特征是没有序列化，就是说增量队列中凭证是无序的，这个对于采用覆盖模式的模型来说是最致命的，所以如果目标队列是DSO的话，还是不要采用这种模式好。这是一种V3，先V3到Update Table，后V3到Delta Queue。借助于此更新模式，将正在查看的应用程序的提取数据写入含有V3 更新模块的更新表，这些数据在使用更新集中运行读取和处理之前会一直保留在该更新表中。不过会从

21、更新表读取更新集中运行中的数据且不考虑顺序，然后将其传输到增量队列。三种增量区别，你参照小结里的这些内容直接增量V1： order(VA01)-delta queue(rsa7)队列化增量V2： order(va01) -extractor queue(LBWO) -job control(LBWE) -delta queue(rsa7)未序列化的V3： order(VA01)-update table(SM13) -job control(LBWE) -delta queue(RSA7) update table-delta queue对数据源抽取机制的深入探讨 一、什么数据源需要初始化，为

22、什么要进行初始化 有增量机制的数据源就需要初始化，初始化的目的是为了给系统一个时间点，来生成Delta队列。 怎样进行初始化：其实当我们跑I包的时候，Delta队列就建立了，这个和Setup table没有关系 Setup table是怎么回事儿：在LO（Logistic，后勤）的抽取中，Extractor不允许直接操作应用表，也许是为了方式读写的冲突，也许是为了保证凭证的安全，也许是为了减轻负载反正就是不行，所以就得在initialization的时候Delete然后Fill Setup table。仅限于LO的数据源。 Reasons for why setup tables is : 1

23、) Main reason is HUGE VOLUMES OF LO data. 2) To avoid interdependency, while still making changes transactional tables in R/3. 3) Customized cluster and pool tables enhancing extraction easier. FI的为什么不用Setup table：因为FI的数据可以直接从Table里抽取。 RSA7(Delta Queue)，这是虚拟的，真实存放数据的是SMQ1 (Out bound Queue) V3 Update

24、 Mode 1、Based on your delta updated mechanism, it will be either V1 or V2 or V3 2、Delta tables will be based your delta updated process ,it will be either Extraction queue or Update tables and the collective run will be either extraction collective run or V3 collective run 所谓的V1、V2、V3有如下解释，这个东西在激活LO

25、数据源的信息结构时可以看到： V1 同步更新模式，即凭证产生就更新增量，与业务数据同步更新； V2 异步更新模式，就如一个两步的操作一样，第一步业务凭证更新了，然后再更新第二步的数据源增量表 V3 异步更新模式，与V2的区别在于他的更新时通过后台事件来触发的，即定一个任务定是收集增量并更新至增量表 下图源自LBWE： 这里三种简单的说一下，更新方式的解释详见附件：Gist of LO Cockpit Delta，据说本来还有个Serialized V3，7.0后就被取缔了。 Direct Delta:这是一种V1，直接V1到Delta Queue，我们目前的LO数据源统统采用这个 Queue

26、Delta:这是一种混合型，先V1到Extraction Queue，后V3到Delta Queue Unserialized V3 Update:这是一种V3，先V3到Update Table，后V3到Delta Queue Records在Transaction tables里 在初始化时，执行一个将Transaction data存放在setup table里的setup操作，也就是我们的填充设置表 在执行初始化和Full包时读取的是设置表的内容 新的Transactions被送到Transaction tables，之后被提取到Update tables / Extraction Qu

27、eue（SM12/SM13），也就是SMQ1 之后呢，会有一个周期性的Job，来把数据提取到Delta Queue中（如果是V1的话就不用啦） 当Delta上载执行时，会去读这个Delta Queue。 二、Delta机制 Time Stamp 我们的R/3系统提供了这么一种功能，来标记新旧数据的差别，可以通过Time stamp，Calendar Day，Numeric Pointer来标注。 设置方法： 数据源要提供字段，用来填充Delta Specific Field RSO2Generic DeltaTime stamp，有需求可以设置Safety Interval Upper/Low

28、er Limit，拓展Time stamp和Calendar Day的边界。 只要在建立数据源的时候设置增量的特定字段，选取时间标记。这里拿ZMAT_ATTR做例子，选的是Calend. Day，Safety Interval Upper Limit是1Calend. Days，New Status for Changed Records，这么说来，就会每天跑一次，每次跑前两天的数据，而且以最后更改的记录为准（这个在下面会说到）。 这样做的效果可以在RSA7里看到，点Generic Delta：Current Status： 很简单，当前的Time stamp。 Notes：为什么不是所有的都

29、有呢？因为这个叫做Generic Delta，可以简单的看一下，LO的数据源一个都没有，那种比较BT，一般来说非后勤和主数据还有自建的数据源都是Generic Delta。 看几张表：ROOSPRMSC，222系统 要了解这张表，还需要知道一个概念叫做LUW， LUW is logical unit of work. The qRFC outbound queue controlled using an Outbound Scheduler (QOUT Scheduler). The QOUT Scheduler prompts the transfer of a LUW to a targe

30、t system when all previous LUWs in this queue have been processed. When one LUW has been executed, the QOUT Scheduler automatically executes the next LUW in the queue. In other words when we request delta load from BW, Source system will identify the last delta records which are in form of TIDs by u

31、sing ROOSPRMSC table and it will delete previous confirmed LUWs(repeat delta table) and Process new LUWs(delta table) 另外，想看这些请求号，可以到表RSREQDONE，这个要在200系统里。 Notes：咱们用的Time stamp叫做UTC Time Stamp，什么是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页 BW Delta Process 这个可以用两张表来做解释： 第一个： ROOSOURCE 这里的四个数据源，分别是LO（后勤），FI，主数据和自建数据源，各有不同。 这里的Delta P