5.4 主数据分发与共享

主数据管理系统的构建，最后要让基础数据在全局得到统一。我们之所以强调主数据管理体系，强调行政组织保障和管理规范，最终的目的就是保证各个系统中的基础数据与全局主数据保持一致。

我们需要将主数据传递到企业中每一个需要它的角落，甚至和企业外部关联业务实体进行数据交换。数据交换工作可以划分到应用集成工作的范畴。应用集成工作历来是一项麻烦的工作，涉及各个系统的改造。如果我们不对这些系统进行集成，那么就只能依靠线下的人工操作来推动数据的流转。显然这样的做法比应用集成更加麻烦且成本昂贵。

现在我们假设只有两个系统。一个是源系统，通常是主数据管理系统、专业业务系统、服务总线或数据API（应用程序接口）；另一个是数据消费系统或称目标系统。我们先将这两个系统间进行数据传递的事情说清楚，这样的话，一个源到多个目标的路线也就清晰了。一般我们不建议采用数据层层传递和网状传递的方案。

在设计数据传递方案时，有两个关键要素决定我们方案的设计内容，如下。

（1）实时性要求：要求数据在变动时及时让消费系统获取。

（2）健壮性要求：保证数据能够传递到消费系统中，不会丢失。

常用的几种数据传递方式如表5-1所示。

表5-1

1.数据推送（推式）

数据推送指的是将主数据推送到应用系统中，数据所有者为主动方，数据目标系统为被动方。此种方式是由主动方主动调用接收方的数据接口，将数据推送到接收方的应用系统中的。按照面向服务的设计理念，应用系统需要开发出一个能够接收主数据的服务，这样数据推送方在进行数据推送时就能够调用这个服务将数据传递给应用系统。

数据推送方并不关心数据接收方具体的业务逻辑，它只负责把数据交给应用系统，至于应用系统如何处理都交给数据接收方。

此种方式的特点：数据实时性较强，主数据一旦发生变动就能够把变动信息传播到体系内的各个角落，而每一个对应的基础数据都能够在第一时间进行更新。

对于数据传递异常的情况，由数据推送方处理。数据如果没有推送成功，那么数据推送方将决定异常处理方式。比如，重新推送，或者过一段时间再次推送（一般会约定补充推送的时间点），或者直接改为手工处理。所以数据推送按照其具体的技术手段，又分为自动推送和手动推送两种。

2.数据拉取（拉式）

数据拉取指的是由主数据源头发布数据获取服务，静待数据使用者调用服务将主数据调至目标系统。主数据源头没有将数据信息进行实时广播，而是等待第三方使用者来调取。主数据源头一般需要提供以下服务组合：“获取全部数据”“获取单条数据”“获取某个时间点以后的所有最新数据”等相关服务，而数据使用者需要自己编写代码来获取数据，一般来讲需要支持定时获取和手动获取两种模式。

数据拉取方式较为稳定，并且把异常处理工作交由第三方来完成。如果第三方支持数据拉取方式，那么数据传递的准确性就得到了很大程度的保证。只是此种方式的数据实时性较差，可以与定时获取方式结合使用，通常系统会将自动获取时间设置为一天左右。

3.在底层数据库层面进行数据拷贝

通过数据服务让数据在信息系统间进行传递是相对标准的一套做法，数据源头、数据使用者的定位和分工都相对明确，但是采用这种做法，开发工作量会比较大，运维成本也相对较高。我们还可以通过数据层面进行数据同步，即通过ETL工具（支持数据抽取、转换和装载的工具）在数据库之间进行数据传递。需要强调的是，这个方案中不应当操作第三方系统中的任何原有表，只是把数据存储在新建的表中。这类似于供应链的一种处理模式：供应商并不等收到甲方的采购单后再发货，而是直接在甲方的生产车间建立自己的仓库，甲方随用随取。

在很多极端的情况下，我们甚至需要这几种模式同时支持，这样才能同时满足所有要素的需求。总结下来，我们需要结合实际的业务情况来最终确定应用集成的方案（这个方案应当由主数据厂商、系统服务商和甲方共同制订），最终依据方案进行应用集成的改造和集成。