关于Delta 增量 (转）

文章写得很详细，系统。原地址： http://kongfanming009.blog.163.com/blog/static/8277204320123246624720/

标准数据源增量

增量管理是向数据仓库提供数据时所必需的，其作用在于及时加载数据仓库的源系统中更改的数据，以及把需要传输到数据仓库的数据缩小到最相关的数据范围。此外，增量管理将有助于您对各自应用程序更改数据的访问，在某些情况下，还将使您第一时间获取这些数据。

下图说明了哪些BI 源系统类型支持增量管理。增量管理意味着能够在单个数据请求中只将新建、已更改的数据记录提取到BI 系统中。从技术角度而言，这表示请求DataSource 的“增量更新”。标有“DQ” = 增量队列的表表明由增量队列使用的源系统暂时储存新建、已更改的数据记录（下面再做详细解释）。

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

BI 增量队列基于SAP Web 应用程序服务器(qRFC) RFC 技术中的队列功能。

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

· 对标准SAP数据源增量

· 对LO后勤数据增量

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

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

详细查看所有字段可输入T-Code SE11，在输入下面表名称查看详细信息）。 
) R- T7 s' i) w NROOSOURCE表：定义了每个数据源的基本属性。下面我们先来分析一下这个表，

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

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

· EXMETHOD：Extraction Method(抽取方法)

· TFMETHODS：Transfer Methods(传输方法)

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

· DETLA(Delta Process for a DataSource) （这个字段很重要）

增量流程是指数据的传输过程。它指定如何在BI中确定数据目标的数据。例如，这使您能设计出DataSource 适合的数据目标、更新方法以及序列化的完成方法

从上图可以看到它有20种增量流程，我们接着开始了解下一些重要的增量流程。增量过程字段都存储在下面这个表中。 
RODELTAM表：定义了每种增量提取方式的方法，这里的增量过程表也是需要讲解一些重要字段，方便对增量有更深入和全方位的了解。

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

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

 

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

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

AIE 采用后镜像模式，只支持覆盖，不支持累加，所以该类型数据源不能直接加载到CUBE，一般会先加载到DSO; 在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” 的增量流程。但是，需要符合某些前提条件。必须具有一种确认已传输数据记录的方式，以便能够确定增量。也就是说怎么去判断记录是增量产生的。一般来说非后勤和主数据还有自建的数据源都是Generic Delta。

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

进入下图界面：

这个界面是做什么用的哪？这里就是前面说的设置判断数据是否为增量数据的地方。

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

1 Time stamp (UTC) 世界通用时间

2 Time stamp (Local) 本地时间

3 Calendar Day 日历日

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

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

安全间隔上限

如果此值为初始值，则存在提取期间产生的记录无法提取的危险。示例：使用时戳指定增量。上次读取的时戳是12:00:00。下次增量提取从12:30:00 开始。因此，选择间隔从12:00:00 到12:30:00。提取结束时，计数器设置为12:30:00。比如文档记录的创建时间是12:25，保存时间是12:35。此记录不包括在已提取数据范围之内，但下次由于记录的时戳，也不提取此记录。

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

安全间隔下限

此字段包括必须从上次增量提取的最大值进行提取的值，以确定下次增量提取的时戳下限。示例：使用时戳指定增量。提取的数据为主数据：仅传输后像，覆盖BI 中的状态。对于此类数据，记录可能提取到BI 两次而不会出现问题。

考虑到这一情况，总是将当前时戳用作提取期间的上限：然后，下次提取的下限不会无缝连接到上次提取的上限。然而，它接受与此上限减去安全间隔相符合的值。此安全间隔必须足够大，以便提取可以包含上次提取时已经收到时戳但未读取的所有值。当然，记录或许可以传输两次，但这不会因上述原因而带来任何影响。

· 也可以选择增量的类型，如New Status for Changed Reocrds(适合DSO和Cube), Additive Delta（适合DSO）.

同事我们也可以查看设置增量的队列状态信息。RSA7进入增量队列管理，如下图

上面穿插的介绍了通用数据源的增量方法。下面接着讲解标准数据源的参数。

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

增量类型字段(RODELTAM-DELTATYPE) 是增量流程的属性。它描述了如何在增量流程中加载增量。

以下特性值是允许的：

? ' ': 未定义增量类型。

? 'A':DataSource 使用ALE 更新指针确定增量。此方法主要与DataSource 结合使用，用于SAP 源系统的属性和文本中。它也用于使通用DataSource 能够提供增量值（提供基础主数据表支持通用DataSource）。主数据的ALE 更新指针已经提供了很多年。在过去，它们用于协调SAP 系统外的主数据。

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

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

? ‘F‘:通过平面文件加载增量数据记录。这种增量类型仅用于平面文件源系统的DataSource 中。在执行InfoPackage 时，将平面文件导入到PSA。然后开始数据加载流程。这里不使用增量队列。

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

重要的Delta Type：

· D Generic Delta for Service API --- PUSH方式

· E Extractor Delivers OLTP Source Delta --- PULL 方式

序列化请求DREQSER字段。

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

1 无序列化。

2 对请求序列化。

3 对数据包的序列化。

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

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

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

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

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

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

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

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

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

现在记录模式描述了数据记录包含的更改类型。各种增量流程间的差异是每个增量流程仅支持七个可能特性值的子集。如果DataSource 实施的增量流程使用多个特性值，则字段ROCANCEL（保存记录模式）自动成为此DataSource 的一部分。DataSource 的此字段会分配到BI 系统的InfoObject 0RECORDMODE 中。

特性值如下：

? ' ': 记录提供后像。

在更改记录或添加数据后传输记录状态。只有在请求相应的前像时，才会将记录直接更新到InfoCube（稍后解释）。

? 'X':记录提供前像。

在更改或删除记录前传输记录状态。所有可以汇总（关键值）的记录属性必须用加/减冲销符号进行传输。冲销加/减符号由提取器（缺省）或服务Service API 负责。这些记录在DataStore 对象的非附加（覆盖）更新中予以忽略。前像补充后像。

? 'A':记录提供附加图像。

如果属性可以集合，则仅传输更改。如果属性无法集合，则传输数据更改或创建后的状态。记录可以无限制地更新到InfoCube，但需要对DataStore 对象进行附加更新。

? 'D':记录必须删除。

仅传输代码。此记录只能更新到DataSource 对象（因此DataStore也只能更新到DataSource 对象）。

? 'R':记录提供倒像。

此记录的内容与前像相同。唯一的区别是更新DataStore 对象时：删除代码相同的现有记录。

? 'N':记录提供新像。

此记录的内容与没有前像的后像相同。创建记录时，应传输新像而不是后像。新像补充倒像。

在表RODELTAM中，可以确定增量更新（列UPDM_NIM、UPDM_BIM、UPDM_AIM、UPDM_ADD UPDM_DEL 和UPDM_RIM）所使用的特性值。该表必须确保增量流程中只使用上述有用的特性值组合。在以“增量更新”模式提取数据时，使用增量流程的DataSource 仅为记录模式提供增量流程中指定的、已提取记录的特性值。

文件增量流程

如果增量流程使用平面文件，数据不会通过增量队列传输到BI。而是直接从DataSource 加载到PSA。在此平面文件DataSource 的传输规则中设置的增量流程必须得到关于基本数据和其增量属性的通知。

FIL0 增量数据（后像）

FIL1 增量数据（增量图像）

LO增量流程

LIS的更新方法(早期更新方法)：

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

异步修改（V2）：与V1相比，写入DELTA若出现错误，不对凭证的保存产生影响。 
异步收集更新（V3）：与做凭证没有关系。在后台定义一程序，定时运行，收集产生变化的数据到DELTA队列。

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

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

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

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

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

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

? 此流程会比V3 或“队列化增量”更加重V1 的负担。对于具有上述凭证数量的客户，这实际上并不是一个因素。

? 提取与V2 更新无关。

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

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

Queue Delta:这是一种混合型，先V1到Extraction Queue，后V3到Delta Queue；

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

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

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

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

? 收集运行使用与以前相同的报告(RMBWV311,...)。

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

? V1 比V3 更难使用。

? 与V3 集中运行相比，该集中运行可实现最后的目标，且可以安排后续流程。在完成应用程序的集中运行后，会自动触发可以在后续作业开始时使用的事件(&MCEX_11,...)。

? 提取与V2 更新无关。

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

这是一种V3，先V3到Update Table，后V3到Delta Queue。

借助于此更新模式，将正在查看的应用程序的提取数据写入含有V3 更新模块的更新表，这些数据在使用更新集中运行读取和处理之前会一直保留在该更新表中。不过会从更新表读取更新集中运行中的数据且不考虑顺序，然后将其传输到增量队列。

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

直接增量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