解析BW:数据源提取数据的原理

题记:忽然想到这么个问题,后勤数据源和非后勤数据初始化有何区别,然后进行周边的拓展,所以就形成了下文。大部分知识源于TBW350和SAP SDN。

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

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

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

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

这里三种简单的说一下,更新方式的解释详见附件:Gist of LO Cockpit Delta,据说本来还有个Serialized V3,7.0后就被取缔了。

Direct Delta:这是一种V1,直接V1到Delta Queue,我们目前的LO数据源统统采用这个 
Queue 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 Queue(SM12/SM13),也就是SMQ1 
之后呢,会有一个周期性的Job,来把数据提取到Delta Queue中(如果是V1的话就不用啦) 
当Delta上载执行时,会去读这个Delta Queue。

二、Delta机制

Time Stamp

我们的R/3系统提供了这么一种功能,来标记新旧数据的差别,可以通过Time stamp,Calendar Day,Numeric Pointer来标注。

设置方法:

数据源要提供字段,用来填充Delta Specific Field 
RSO2àGeneric DeltaàTime stamp,有需求可以设置Safety Interval Upper/Lower 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:为什么不是所有的都有呢?因为这个叫做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 target 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 TID's by using 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 Process共有20种,于是需要第二张表:

RODELTAM

这里的几个列,控制了Delta方式对镜像的操作,序列化方式,Delta处理类型等等。

需要着重的是DeltaType:

D Generic Delta for Service API

E Extractor Delivers OLTP Source Delta——这种方式叫做PULL

means the delta data records are determined during the delta update by the data source extractor, updated to the delta queue and passed on to BI directly from there.

一般来说:

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

ABR的方式注定了,不仅适合直接上载到DSO,可以直接上载到CUBE,不通过DSO,因为不仅序列化,而且是连带各种镜像。 
AIE不同,只支持后镜像,也就是说,只能首先加载到DSO,然后进行分析,会在激活数据时帮我们补齐前镜像,到DSO的LOG表里,从而保证了DSO的明细要求,又能在CUBE提取LOG表的时候获得正确的数据。因为CUBE只有汇总,没有覆盖功能。 
最后还要说明一下,FI与其他模块的数据抽取方式不太一样。

FI是通过BW的请求,到R3中执行对应的FM,然后获得数据,写入DELTA队列,这种方式就叫做PULL。自定义数据源也是这样的方式。一般来说,时间都是1h。如下图:RSA2

对于其他模块,如MM,是通过将数据写入DELTA队列,BW请求后,并不直接读取真实的数据源,而是读取DETLA队列。 
对MM,激活信息结构的时候,会让我们选择,更新类型,也就是V1,V2,V3的方式,与FI的抽取方式差别太大,而且需要我们在源系统进行必要的操作。感觉好像不是一批人开发的,实现DELTA的逻辑从本质上不同,SAP的解释是说,对于不能直接实现DELTA抽取的数据源,可以采用这种方式。 
另外,关于FI的Delta方式,有如下解释:节选自SAP HELP,另外附件里还有一些Notes,有兴趣可以看下

Delta Method

Delta extraction enables you to load into the BW system only that data that has been added or has changed since the last extraction event. Data that is already loaded and is not changed is retained. This data does not need to be deleted before a new upload. This procedure enables you to improve performance unlike the periodic extraction of the overall dataset.

Financial Accounting line items are read by extractors directly from the tables in the SAP R/3 system. A time stamp on the line items serves to identify the status of the delta data. Time stamp intervals that have already been read are then stored in a time stamp table. The delta dataset is transferred to the BW system directly, without records being transferred to the delta queue in the SAP R/3 system (extractor delta method).

The Financial Accounting line items are extracted from the SAP R/3 system in their most recent status (after-image delta method). This data method is not suitable for filling InfoCubes directly in the BW system. To start with therefore, the line items must be loaded in the BW system in an ODS object that identifies the changes made to individual characteristics and key figures within a delta data record. Other data destinations (InfoCubes) can be provided with data from this ODS object.

解析BW:数据源提取数据的原理相关推荐

  1. python从csv提取需要的数据_使用Python从文本(CSV文件)中提取数据

    我正在帮助一个狗救助小组分析他们即将被收养的申请.所有应用程序都是通过在线系统输入的,每个应用程序都将获得一个自动生成的表单ID.然后将申请分配给不同的志愿者进行处理. 大多数信息都很简单,我可以使用 ...

  2. 【学习笔记】37、用正则表达式解析和提取数据

    用正则表达式解析和提取数据 正则表达式是一种非常好用的信息提取手段,它可以高效的从文本中提取所需信息. 1.findall()函数 基本语法格式: re.findall(匹配规则,原始文本) 例子:提 ...

  3. python读取word指定内容_python解析html提取数据,并生成word文档实例解析

    简介 今天试着用ptyhon做了一个抓取网页内容,并生成word文档的功能,功能很简单,做一下记录以备以后用到. 生成word用到了第三方组件python-docx,所以先进行第三方组件的安装.由于w ...

  4. poi 顺序解析word_JavaPOI解析word提取数据到excel

    Java POI解析Word提取数据存储在Excel 一.了解POI POI以前有了解,这次需求是解析word读取其中标题,还有内容赛选获取自己想要的内容 经过两天的学习,开始熟悉Java这么读取wo ...

  5. Java POI解析Word提取数据存储在Excel

    JavaPOI解析word提取数据到excel 一.了解POI POI以前有了解,这次需求是解析word读取其中标题,还有内容赛选获取自己想要的内容 经过两天的学习,开始熟悉Java这么读取word和 ...

  6. 大数据项目之电商数仓DataX、DataX简介、DataX支持的数据源、DataX架构原理、DataX部署

    文章目录 1. DataX简介 1.1 DataX概述 1.2 DataX支持的数据源 2. DataX架构原理 2.1 DataX设计理念 2.2 DataX框架设计 2.3 DataX运行流程 2 ...

  7. Python爬虫入门之爬虫解析提取数据的四种方法

    本文主要介绍了Python爬虫入门之爬虫解析提取数据的四种方法,通过具体的内容向大家展现,希望对大家Python爬虫的学习有所帮助. 基础爬虫的固定模式 笔者这里所谈的基础爬虫,指的是不需要处理像异步 ...

  8. 【Hadoop】HDFS操作、数据上传与下载原理解析、高级特性及底层原理

    HDFS操作.数据上传与下载原理解析.高级特性及底层原理 1 HDFS操作 1.1 Web Console网页工具 1.2 命令行 1.2.1 普通的操作命令 1.2.2 管理员命令 1.3 Java ...

  9. Hadoop技术内幕:深入解析MapReduce架构设计与实现原理 (大数据技术丛书) - 电子书下载(高清版PDF格式+EPUB格式)...

    Hadoop技术内幕:深入解析MapReduce架构设计与实现原理 (大数据技术丛书)-董西成著 在线阅读                   百度网盘下载(ihhy) 书名:Hadoop技术内幕:深 ...

最新文章

  1. ASP.NET中使用多个runat=server form
  2. 深度学习(一)深度学习学习资料
  3. php文件上传实验总结,53 PHP文件处理(六)文件上传--总结---细说php
  4. 面向对象(静态成员内部类的调用)
  5. leetcode 778. 水位上升的泳池中游泳(并查集)
  6. kvm、qemu-kvm、ibvirt及openstack,之间的关系
  7. matlab中的g2(t)是什么,matlab实验1-8带答案,,
  8. 网络_简单实现远程唤醒与远程控制(Teamviewer)
  9. Kaggle实战之房价预测
  10. shell基础入门1.1shell特性
  11. 汉字转拼音首字母大写
  12. Android逐帧动画的实现
  13. 千千静听打开卡拉OK功能和弹窗广告过滤
  14. app自动化测试appium教程之三——appium基础命令(python)
  15. 树莓成长记4:docker基本操作
  16. 四个干净高效的搜索引擎
  17. 全球十大最顶尖的数据中心
  18. Linux TimeZone设置
  19. IGV-GSAman |「功能基因组时代」的高效率科研工具
  20. Eclipse 安装反编译插件jadclipse

热门文章

  1. 为什么微软溢价50%并购LinkedIn:估值、增长、变现和背后的魔法
  2. 推荐干货 | 我在阿里做运营:八一八运营经典误区
  3. 全球最高龄男性去世享年113岁 生前喜欢泡温泉(图)
  4. C++ STL vector(向量)
  5. “物联网”架构有多重要?
  6. Python PhantomJS 爬虫 示例
  7. 【重要更新】MyEclipse 2017 Stable 1.0发布|附下载
  8. ubuntu完全卸载apache2
  9. 19、SQL Server 数据修改之Insert into
  10. 关于c++的文件编码的研究