主数据ETL - 01 数据同步场景分析

背景

这几年经历的项目，大量的需求都是和第三方系统集成，SAP ECC是名副其实的主数据系统。
一旦涉及集成，都离不开主数据同步的问题，SAP有MDM系统（自己也没用过，从一些资料上来看还是要一定的二次开发），上MDM公司的好像也不多。既然数据就在ECC，使用ABAP来完成ETL，并搭建一个分发的框架。

以物料主数据为例，手头的这个系统，至少要同步OA、BPM、WMS、MES、CMS、SRM六套系统！维护代码就是一个萝卜一个坑，同步方式差别也比较大。

数据接口主要考虑的问题

所有的开发都是在应用程序服务器层面，ECC屏蔽了底层数据库细节，无法应用数据库机制，比如触发器，数据库日志等。
要考虑的问题很多，归纳了主要的三类：

1. 接口方向

就SAP而言，就PUSH和PULL两种模式：

• PULL模式 第三方系统调用SAP接口
  常见场景SAP 提供RFC接口 或者 Webservice，新一点的平台可以提供Odata服务。

• PUSH模式

  • 直接调用第三方接口
    webservice和http的接口比较常见,SAP内部还有idoc，也有一些比较偏门的需要调用控件（必须基于SAP GUI）。

  • 输出到"中间载体"

    • 文件
      配合目录监控，FTP服务等，有时也手工导入导出文件。

    • 中间表
      第三方系统直接访问中间表，这个表可以是SAP系统的自定义表，也可以不是。

    • 运行脚本
      ABAP有时候限制很多，不妨考虑SAP输出一个脚本文件，比如python，再调用这个脚本文件，同理的windows下还有bat脚本。
      如果SAP GUI的话，还可以调用js，vbs！

      思路是GUI调用 windows的MSHTA 命令。

• 混合模式
  SAP通过增强或者后台程序，写入中间表，并提供接口供第三方系统从中间表取值。

2. 时效性要求

• 高

  允许一定的时间差，比如1H，轮询PULL或者实时PUSH均可，要求实时同步就是实时PUSH模式。

• 中低

  推荐第三方系统轮询SAP接口

实时方式与其他方式的对比

实时一般就是SAP PUSH模式，直接调用第三方接口

简单的对比：

	实时PUSH模式	其他PULL模式
实时性	好	一般
查找增强	是	否
额外推送接口	是	否
监控及预警	是	否
数据包顺序控制	增量时需要	不需要

总而言之，实时模式对业务来说最理想，对开发而言需要的开发工作量可能是RFC接口模式的2~3倍，甚至更多。

• 第三方系统差异很大，调用难易程度不等，有些系统调用先要通过认证，然后才能调用，这部分系统一般没有abap的包，登录认证公钥加密私钥解密，特定格式的数据包等等都要从零开始开发。

• 要想实时模式运行顺畅，额外的监控程序是必不可少的。

• 在增量数据同步时，还要考虑数据包顺序发送，以及上个数据包是否发送成功，实际项目中有限的人天，挑战比较大。

3. 数据组织方式

全量

整张表的所有数据直接覆盖。简单粗暴，实现难度低。
适合数据量不大，抽取时间代价明显小于增量算法的代价。同步过程即使存在失败也没问题，只要最新一次同步ok就行，不需要额外的纠错机制。

第三方系统在处理时，还有一定的操作空间，比如发现数据库已有就忽略，仅关注新增，不考虑删除。
适合基础数据的同步，比如公司代码，科目表之类。

对于变化频率极低的表，不妨直接考虑手动+全量同步。

增量

增量同步似乎更容易让人接受，仅更新变化的部分。抽取的代价和更新的代价都比较小，难度都集中在增量算法上。增量算法太复杂，可能就是个无底洞。

定义几种常见的增量级别：

• 业务对象级别(伪增量) Business Object

  这个业务对象，任意属性有变更，更新整个业务对象的所有数据。在业务对象的级别，就是全量，只不过相较于全表更新的模式算是增量。好处就是相对简单，不需要考虑变化过程。

• 组件级别 Component Of Business Object

  简单的说，就是业务对象有几张表，仅关注发生更改的表，把具体的更改记录（整行数据）一起同步。 这种比较常见，难点还是在增量算法，并且考虑实际业务场景中是否关注删除操作。

• 字段级别 Field Of Component

  相当于数据库更新操作日志，哪张表具体哪个字段，发生了变更。SAP的话利用标准的Change Document 技术。

增量算法

不考虑DB层面，都是基于AS层面考虑。

• 基于时间戳
  如果是目标数据表上本身的时间戳，删除操作是无能为力的。

• 全表对比
  可以在SAP实现，也可以在第三方实现。

SAP有个非常有用的函数 CTVB_COMPARE_TABLES；第三方系统中的话，考虑基于MD5值得校验。

• 自定义变更日志表

  • 基于增强

    按标准增强中产生增量数据，写入变更日志表。

  • 基于后台任务

    后台任务大多也是基于时间戳，提取变更数据，然后生成变更日志。

4. 综述

涉及数据同步时，分析步骤如下：

• 按照业务场景，确定接口方向

• 确定数据包格式（增量 or 全量）

• 确认数据包生成机制

• 考虑监控及纠错机制

个人认为，简单稳定优先，开发交付快的优先，牺牲点性能其实也能接受。
数据同步允许一定的差异，允许垃圾数据存在，有时能大大简化方案，比如删除数据不需要同步。