一个对象对应多个对象如何在一个界面里实现新增_谈MDM主数据管理系统设计和实现关键点...

作者：人月神话，新浪博客同名

简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践

今天准备谈下MDM主数据系统设计的一些关键点，在前面我分享了一个MDM主数据平台解决方案的PPT，但是篇解决方案层面，而且很多技术实现的关键内容没有展开描述，因此今天会对MDM主数据管理系统设计和实现进一步进行说明。

MDM主数据管理概述

主数据是描述核心业务实体(如客户、供应商、地点、产品和库存)的一个或多个属性。所以主数据即是在进行企业业务架构分析中发现的核心业务对象。或者讲主数据是企业已经存在的涉及到价值链核心业务流程的各个IT系统的基础数据。

对于ERP系统客户，供应商，物料，BOM，产品，合同，订单等都应该是最基础的数据，对于项目管理系统而言项目信息，WBS信息则是最基本的基础数据。而对于CRM系统则客户，销售项目是最基本的基础数据。基础数据要上升到主数据的高度还有一个条件，即该数据产生在一个源IT系统中，但是会在多个其它的IT系统中使用到。

企业缺乏主数据管理造成的最大问题就是完整性和一致性，有些是本身主数据不完整或缺失，有些则是主数据在多个系统中存在拷贝和更新，导致数据不一致。引起企业主数据问题的重要因素之一是信息彼此隔离。在许多企业中，主数据分布在众多彼此隔离的系统中。客户服务部门、生产部门以及采购部门都有各自的系统。

即使在一个业务部门里，也有众多前端和后端系统，这些系统包含对业务至关重要的数据，但通常情况下无法与其他系统共享这些信息。正是由于构建在各种架构之上的不兼容系统中的这种部门化数据，使得企业几乎不可能创建和维护主数据的“单一”视图。

对于原有的关于主数据管理的解决方案，一个方面是建立数据中心和数据仓库，数据仓库可以极为高效地保存系统数据。遗憾的是，数据仓库中所包含的数据通常都经过了清理，用于分析和生成报告，因此数据仓库是主数据管理解决方案的有益补充，但不是解决方案本身。

也有提出以ERP为核心系统，其他为外围系统，则ERP的基础数据管理上升为主数据管理。 但是企业资源规划(ERP)解决方案旨在管理特定的应用流程，同样，这些解决方案需要使用主数据，而不是主数据管理解决方案。而且，非ERP 系统不能访问 ERP 解决方案中的数据。

因此IBM的MDM提出了超越单一视图，使用正确的视图的新的主数据管理思路。 适时地将正确的信息以正确的视图提供给正确的对象。这才是主数据管理(MDM)的目标。 主数据管理描述了一组规程、技术和解决方案，这些规程、技术和解决方案用于为所有利益相关方(如用户、应用程序、数据仓库、流程以及贸易伙伴)创建并维护业务数据的一致性、完整性、相关性和精确性。

主数据管理的关键就是“管理”。主数据管理不会创建新的数据或新的数据纵向结构。相反，它提供了一种方法，使企业能够有效地管理存储在分布系统中的数据。主数据管理使用现有的系统，它从这些系统中获取最新信息，并提供了先进的技术和流程，用于自动、准确、及时地分发和分析整个企业中的数据，并对数据进行验证。

主数据管理解决方案具有以下特性：

• 在企业层面上整合了现有纵向结构中的客户信息以及其他知识和深层次信息
• 共享所有系统中的数据，使之成为一系列以客户为中心的业务流程和服务
• 实现对于客户、产品和供应商都通用的主数据形式，加速数据输入、检索和分析支持数据的多用户管理，包括限制某些用户添加、更新或查看维护主数据的流程的能力
• 集成产品信息管理、客户关系管理、客户数据集成以及可对主数据进行分析的其他解决方案。

MDM主数据平台总体设计

今年的一个重要工作就是对已有的MDM主数据管理平台进行重新的架构调整和功能设计，形成一个完整的主数据管理空平台。该平台既能够满足主数据整合和分发，同时能够完整的满足主数据日常内容管理，以及结合服务共享层能力，实现主数据服务的共享和发布。

在原有架构的基础上，对主数据管理平台进行重新分层，即分为基础层，应用层和共享层三层。基础层主要是提供基础引擎和技术服务能力，对于应用层则围绕主数据全生命周期展开，在应用层形成了完整的主数据视图后，再通过最上层的服务共享层提供的能力实现主数据数据服务的对外快速发布和共享。

基础层

在基础层主要实现最基本的底层技术能力，一个是在数据进行收集，清洗和整合的时候需要用到的ETL引擎部分的数据集成能力；其次是MDM平台应该有一个标准的工作流引擎技术组件，实现在主数据内容管理的时候需要的可视化流程设计和建模；最后即是4A和权限管理方面的能力，当然对于组织，用户，权限的统一也是一个完整的工作流引擎所需要具备的能力。

应用层

任何主数据的管理都会涉及到两个方面的内容。一个是动态流程维度，一个是静态数据模型维度。

对于数据模型维度，在进行主数据管理实施的时候，往往会首先进行主数据的识别和详细定义，如基于标准的企业架构和数据架构规划思路，会首先进行流程分析，通过流程找到关键的数据域，然后通过数据域识别关键的数据对象，再进行完整的概念模型，逻辑模型和物理模型的设计。

对于MDM系统而言，针对数据建模这部分全部能力，都将体现在元数据管理模块中，其中包括了数据目录定义，数据对象定义，子对象定义，数据层次和关联关系的定义，数据对象中每一个详细的数据项和属性的定义，数据校验规则的定义，数据源定义，数据收集和分发规则的定义等。这些内容都将在进行主数据对象建模的时候通过可配置的方式进行灵活定义。

简单来讲，只要完整的定义了主数据模型，那么主数据就可以完整自动生成后台数据库对象和结构，自动可配置的方式实现数据的采集，匹配和清洗等各种操作。

其次对于流程部分，主要包括了常说的主数据内容管理，包括了主数据的创建，变更，废弃，编码申请等各种主数据管理流程。这部分流程首先是要在业务上定义清楚，包括涉及到的业务组织和岗位，实际的数据产生者，使用者和认责者等。在流程定义清楚后我们可以通过流程引擎的能力实现流程的灵活可视化设计和配置。

对于表单部分有部分MDM产品会提供完整的主数据界面建模能力，这块类似BPM业务系统提供的能力。但是对于我们的MDM不包括这部分能力，其核心的原因还是对于界面建模和设计，不是简单的一个界面生成，而是涉及到大量的复杂业务规则的实现，这部分很难通过类似快速开发平台方式完全实现自动化和零编码。

对于流程中第二部分是数据的收集和集成内容，对于这部分内容MDM平台可以完全做到灵活配置数据采集任务和调度，并实现数据的自动化采集和清洗。

共享层

在主数据管理形成了完整的主数据视图后，更加重要的是能够快速灵活的将已有的完整的主数据开放和共享出去供其它业务系统使用。因此在这里涉及到将主数据快速发表为数据接口服务的能力，同时也涉及到第三方业务系统查看和申请主数据服务的服务开通和管控能力。

当前的MDM平台可以支持灵活的将系统里面已有的一个主数据对象发表为一个Web Service服务接口，该接口可以灵活配置输入参数和输出的数据项，同时也支持发表为SOAP WebService或Http WebService等多种服务接口模式。

为了实现服务接口的发布，则需要从服务元数据的数据对象定义-》服务定义，从数据集成接口-》服务接口，并在数据对象和服务接口间形成完整的映射，该部分内容在MDM平台我们已经做了完整的集成。即形成了一整套从服务全生命周期管理到数据服务能力快速开放共享的完整解决方案。

基于元数据驱动构建MDM主数据平台

本部分主要谈下元数据驱动下的MDM主数据管理平台的核心构建思路。因为对于一个MDM系统更多应该理解为结合了元数据驱动和建模，结合了流程引擎和ETL服务能力的一个快速开发和配置平台。

这个思路和原来我们谈到IBM-CQ变更和缺陷管理系统的构建思路完全是一致的。即在当前我们要想做一个覆盖所有业务场景的快速开发和配置平台是相当困难的，但是在某一个业务领域类似变更管理，类似表单化工作流，类似主数据管理等，这些业务场景本身已经对可能出现的需求和规则范围进行了限制，如果理解清楚实际的业务场景和底层核心模型是比较容易实现一个快速开发和配置平台的。

再次强调下主数据管理平台的核心是元数据建模，这和快速开发平台里面的对象建模是类似的。因此我们还是要首先谈下元数据和对象建模的核心内容。

以供应商主数据来举例，常规做法可能是在后台建立供应商数据库表和相关的关联子表，然后再根据需求进行供应商CRUD各自管理功能，流程处理功能的开发。那么在对象建模思想下，我们要考虑的是供应商是一个完整的主数据对象，应该通过什么方式把这个对象建模清楚。

对象建模

通过完整的对象建模一方面是可以直接生成后台数据库表，一方面是用于后续的界面建模和主数据质量管理。

1. 对象就有属性，即首先应该清楚的定义出对象的属性信息。对应到具体的字段。
2. 每个对象属性我们应该清楚的定义出属性的业务完整性和数据约束规则。
3. 对象本身可能有子对象，我们应该可以进一步对某一个对象的子对象进行详细定义。子对象将对应到后台数据库表中主表下的关联从表。
4. 对象和对象之间有关联和映射信息，我们应该可以对应对象间的关联和映射。
5. 对象属性和对象之间存在关联信息，应该可以定义属性和对象之间的关联和映射。

其中可以看到对象建模的核心还是在于对象和子对象，对象属性的业务规则定义，对象和对象之间的关联映射等内容。当然我们也可以通过数据库表逆向生成对象。在对象建模完成对象建模的相关信息都应该存储到元数据管理的相关数据表中，这是最核心的内容。完整的元数据可以做到基本基于对象的简单CRUD功能都可以完全自动生成。

表单建模

在对象建模完成后接着要考虑的就是表单建模，通过表单建模来实现主数据对象的CRUD功能界面是可以灵活配置的。这个类似于快速开发平台中的自定义表单，即详细的定义CRUD各自表单的布局，表单中每一个属性元素具体呈现的UI组件。

通过表单建模就可以实现一个具体的主数据录入表单中如何布局，然后实现各个属性的输入，具体是录入还是选择框，还是说需要从关联子表中进行选择等。表单建模后的元数据建议是要和对象建模数据进行分离，即在独立的元数据表中进行存放。

流程建模

在一个完整的主数据管理平台中一定涉及到主数据的内容和流程管理，类似主数据的创建，变更或废弃都可能涉及到相应的流程审批操作，在审批完成后才最终生效。因此完整的表单功能实现后接着要考虑的就是通过工作流引擎进行流程建模，最终建立的工作流模板能够和表单挂接。而流程引擎本身又涉及到组织，人员，角色等4A相关的内容，对于这部分内容可以在MDM系统中维护，也应该可以从4A或门户系统进行同步。

谈到这个地方基本可以看到一个完整的供应商主数据管理功能，通过围绕供应商基础业务对象进行了对象建模，界面建模和流程建模后应该就可以完全自动生成相应的CRUD功能，包括审批流程的实现。但是任何快速开发平台都很难真正做到对特殊业务规则的进一步处理。

对于复杂业务规则的处理，类似一个供应商基础数据的废弃，在废弃前可能需要首先校验下该供应商在其它业务系统中的使用情况。遇到这种场景我们原来的做法是在原有模型的基础上可以自己定义相应的脚本语句进行二次处理，但是带来的最大问题即使后期的脚本相当难以维护。因此更加更新的方案即是我们可以在标准功能的基础上扩展相应的插件或业务规则逻辑实现的拦截器。这种拦截器在对象属性输入，对象保存前后，查询前后等都可以拦截相应的事件。而具体拦截器的业务规则和逻辑我们还是通过自定义的扩展类来实现。通过这种方式可以保证整个主数据管理平台足够的可扩展性。

在早期的MDM主数据管理平台中，并不建议马上引入复杂的规则引擎来实现规则建模和规则的可配置，这部分内容还是通过自己开发扩展代码来实现往往更加容易维护和扩展。

前面的基础能力实现后再接着谈两个重点，即主数据集成管理和主数据质量管理。

数据集成管理

对于主数据集成管理其实包括两个部分的内容，一个是ETL，一个SOA服务接口，对于ETL主要是实现初始化数据的采集和清理入库。对于SOA服务接口即是能够将主数据服务能力通过接口服务暴露出去，或者说通过消息发布订阅机制能够实现MDM主数据管理平台中主数据的实时分发和事件通知。

对于ETL部分的功能不需要多谈，我们可以集成和内置一个轻量的ETL工具和功能。而对于SOA服务部分的功能则涉及到基于前面对象建模定义的元数据实现标准服务的发表。即我们在定义的完整的对象后，我们可以通过向导的方式将主数据发布为WebService服务接口，既可以是rest服务接口，也可以是soap webservice服务接口。而具体发布的接口需要哪些输入，哪些输出应该都可以进行灵活的配置来完成。当然我们也可以在MDM平台维护主数据的消息发布订阅机制，即将MDM主数据的变更内容通过消息订阅的模式实时分发给业务系统。

数据质量管理

数据质量管理是主数据管理里面的一个难点，其中包括了两个方面的内容，一个是单数据对象的数据质量分析，这个通过在对象建模时候定义的业务规则和完整性规则就可以进行。当然我们也可以将数据质量单独拿出来进行定义，我们可以将一个规则绑定到具体的业务对象或者业务对象的属性上面。然后基于这些规则进行单对象的数据质量分析。其次是多表间的数据稽核，我们谈到过主数据管理平台最终是为了解决多业务系统主数据不一致的问题，但是即使上了主数据平台也还需要对多业务系统中的同一数据对象进行数据内容稽核，并实时发现数据不一致的情况并进行预警。对于数据稽核的核心思路，我前面有一篇文章专门谈到过可以参考。

如果以上的内容都已经实现，那么最终提供出来的主数据平台就是一个可以快速实施各类企业主数据的基础平台。该平台基本可以做到80%的主数据实施工作都可配置，同时我们也可以将更多的精力放在主数据业务流程和管控规范的梳理，主数据集成，主数据特殊业务规则的实现上。

从主数据定制开发到快速配置开发

对于最近1到2年的MDM主数据交流来看，很多企业希望的是一个完全高度灵活可配置的主数据平台产品，但是非主数据规划咨询和实施能力。

而对于我们来说，更加重要的能力是在规划咨询和实施能力，里面包括了主数据管理规范体系，流程，数据模型，主数据质量管理，历史数据的清洗和导入，数据能力的共享等，这些往往都不是一个标准产品就能够覆盖的，而是需要有经验的咨询顾问和实施顾问的现场投入。

当然，对于一个标准的主数据产品，我们可以看到已经逐步类似一个快速开发平台能力，我们可以再次简单总结下一个标准的MDM主数据平台需要具备的快速开发和可配置能力。

1. 4A和权限模型：实现组织，用户，权限等灵活配置
2. 流程引擎：实现审批流程的灵活可配置
3. 对象建模：实现主数据对象模型的灵活创建和配置，包括对象和数据表的连接和映射
4. 表单建模：实现表单的自定义和可视化设计配置，表单和对象模型间的映射
5. 规则建模：底层有一个规则引擎，能够实现规则的灵活配置或脚本定义
6. 集成模型：实现对象到接口服务的自动化发布，能够实现数据集成的自动化配置和集成

以上这些内容看着会感觉特别熟悉，即这些和我们经常看到的快速开发平台很类似，即一个产品和的主数据平台基本涵盖了快速开发平台需要具备的所有能力。

那么企业在实施主数据平台的时候，当需要实施一类新的主数据的时候，比如我们需要实施物料主数据，我们希望的就是物料的数据模型，表单，流程，集成接口都完全能够配置出来而不需要开发代码。在这种情况下主数据平台具备了最大的灵活性，但是实际上我们看到对于界面和规则，往往是很难通过配置的方式完成的，特别是一些复杂规则的实现更难简单的配置完成。

主数据平台在具备了快速开发平台的关键基础能力后，又增加了关键的技术基础能力，即

1. ETL数据集成：能够实现数据集成，数据清洗转化和入库
2. SOA集成：能够实现数据对象快速的发布为接口服务，标准化的消息发布订阅

在增加了这两方面能力基本就具备一个标准化的主数据管理平台能力。

而实际上我们当前的主数据平台对于4A，流程引擎，对象建模，集成建模，ETL这些关键技术能力全部具备，而比较欠缺的就是动态表单建模和规则建模，虽然我们在前面也实现过一个简单的技术组件，但是通过实施我们仍然发现对于一些复杂场景的主数据管理，很难简单的通过配置就完成功能的设计和开发。

我们我们已经有表单设计器和自定义表单，但是即对于表单和规则还是需要定制化开发，其它技术组件和能力能够实现完全的灵活可配置。这即是当前我们主数据平台的能力现状，对于比较强调规划咨询和实施能力的企业，我们仍然具备足够的优势。

主数据平台趋势一定是从技术平台转到业务平台

举一个简单的例子来说，如果你一直做汽车制造行业的MDM主数据系统，那么实施多了后，你自然就很清楚对于汽车制造行业涉及到哪些主数据，每一个主数据对象究竟应该包括哪些通用基础字段和扩展字段。这些通用化的主数据模型往往也适用于其它的汽车制造行业。

那么这个时候你的主数据平台就单纯的从一个技术平台变成了一个业务平台，即已经经过你多年的MDM主数据平台的建设和实施，将实施经验沉淀为主数据平台的数据资产。这个数据资产本身就是有价值的。

MDM系统-数据建模

在前面已经谈到，MDM平台后续的建设思路都是围绕数据模型这个关键元数据驱动进行建设的，从数据建模再延伸到了业务规则建模，流程建模和界面建模等内容，最后扩展到外围的接口服务集成能力。建模能力是否强大，是否灵活和可扩展，往往直接影响到一个MDM平台的易用性和扩展性。

下面再来解释下如何进行主数据建模，对于主数据建模其本质应该是一个树状的层级可展开结构，方便进行子对象和层次的自动挂接，以适合一个主数据有多层子对象的情况。

整个主数据建模的关键过程和步骤应该如下：

1. 创建数据对象，如供应商，物料数据对象。数据对象可以有多层结构。
2. 创建数据对象的子对象，即该数据对象可以存在子对象，子对象还可存在子子对象。
3. 创建数据对象或子对象的数据项信息，包括数据项目的名称，类型，其它扩展属性等。

上面三个关键步骤就能够实现基本的数据对象创建，每个数据对象和子对象对应到数据库中一张表，这个数据对象很类似我们领域设计中的领域对象。子对象单独没有存在的意义，必须连同父对象存在。对于建模中对应的各个数据项，即是实际数据表中的数据字段信息。

这样数据建模完成后可以直接形成动态Sql语句，直接创建后台的数据库表结构。

在数据对象建模中我们可以考虑增加一个文件夹创建的功能，或者说我们单独增加一个针对数据对象创建属性分组的功能，即可以将不同的属性和子对象进行分组管理。这个分组一个是方面我们进行维护和管理，一个是后续在界面建模的时候直接将不同的分组属性映射到不同的tab页签上面。

数据项本身的类型应该至少包括如下几种：

1. 简单的录入类数据类型：字符型，数字型，日期型
2. 列表类数据类型，从下拉列表中选择：支持从数据字典中选择，也支持从独立的另外数据表对象中选型
3. 跳窗选择型：即支持关联到另外一个外部数据表对象
4. 文件型：支持上传文件，注意可以支持一个数据对象上传多个附件文件的能力。
5. 表格型：对于数据对象维护过程中，子对象应该默认映射到表格类型

对于列表数据类型往往还需要支持多级分类联动模式，比如物料信息维护的时候可能出现先选择物料大类，再选择小类，再选择次小类，就存在三个小拉列表框的联动关系。

以上是最基本的数据项类型的维护能力，其次是基础的字段完整性校验能力，其中就包括了场景的是否为空检验，数字类型检验，长度检验，值大小检验，自定义脚本检验(if a>0 and b>0 then c>0)等。这些可以确保数据录入的基础完整性。

以上所有这些校验都是单条主数据记录录入的时候就可以完成的校验，其次就是多行记录之间的相互校验，最常见的就是为了避免主数据录入重复，我们需要进行相似性校验，对于相似的主数据给出提醒。

比如在录入供应商录入的时候我们可以根据名称进行相似性校验，在物料信息录入的时候可以根据规格型号，参数组合进行相似性验证等。相似性校验功能既可以用于在数据清理阶段的查重，也可以用于后续的新数据录入和修改检查。

还有就是跨多个数据对象之间的校验，比如当存在在途数据的时候，供应商的类型或名称不允许变更或删除，这就是最常见的外部业务规则检验，对于这种能力也需要进行支持。

一个完整的主数据模型定义，实际是应该包括了数据类元数据，业务规则类元数据和界面类元数据，列入界面上应该展现什么样子，展现和布局规则等都属于界面元数据。这些也可以在数据模型维护的时候进行统一维护。

而对于对象这个层面的主数据，也还需要进行额外属性信息的维护，其中包括了：

• 数据集成类(数据采集，数据分发，集成接口等)
• 关联关系类(该数据对象和其它数据对象的管理关系)
• 数据类(对应的数据库，数据源或数据表信息的定义)

元数据定义完成后要达到的一个效果就是可以生成底层的数据库表，可以用来自动化生成界面，可以用来做数据此采集和集成，同时还可以根据业务规则进行主数据质量管理。

数据质量管理

数据质量管理(Data Quality Management)，是指对数据从计划、获取、存储、共享、维护、应用、消亡生命周期的每个阶段里可能引发的各类数据质量问题，进行识别、度量、监控、预警等一系列管理活动，并通过改善和提高组织的管理水平使得数据质量获得进一步提高。

数据质量的评估维度主要包括如下几个方面的内容：

1. 完整性 Completeness：完整性用于度量哪些数据丢失了或者哪些数据不可用。
2. 规范性 Conformity：规范性用于度量哪些数据未按统一格式存储。
3. 一致性 Consistency：一致性用于度量哪些数据的值在信息含义上是冲突的。
4. 准确性 Accuracy：准确性用于度量哪些数据和信息是不正确的，或者数据是超期的。
5. 唯一性 Uniqueness：唯一性用于度量哪些数据是重复数据或者数据的哪些属性是重复的。
6. 关联性 Integration：关联性用于度量哪些关联的数据缺失或者未建立索引。

而以上这些内容我们在做MDM主数据管理系统的数据质量管理模块，包括实施ETL工具里面的数据转换和清洗等时候，都是需要考虑和支持的内容。

而对于数据质量管理，应该是覆盖数据生老病死的全生命周期管理，为了方便重点谈下常见的两个实施数据质量管理的阶段，一个是借助ETL工具实现的数据采集和整合阶段，一个是日常实时进行的数据检查和稽核。下面就这两个常见阶段分开再来谈下。

数据采集和整合阶段

现在的ETL操作很多已经转变为了ELT操作，即我们说的Transform转换这块的内容有些事在ETL传输过程中完成，而有些已经转变到数据采集到目标数据库后再在目标数据库端完成数据转换。

注意转换的作用更多的是将数据标准化和规范化，比如通过转换和映射，将名称转换为代码，或者做两个数据项内容的合并等，这些都是可以在转换的时候执行的事情。

数据唯一性里面有一个重点就是去重和去相似性，对于去重我们可以在ETL工具里面通过转换配置完成，而对于去相似性往往则需要后续数据采集完成后编写独立的代码或脚本来分析相似性数据，并通过手工确认后再完成去除相似性数据或对数据进行合并操作。

一类主数据往往涉及到多张表，比如供应商主数据，涉及到基本信息，联系人信息，账号信息等多个子对象。这些子对象可以是一种层次关系，也可以是一种关联关系。这个我们在进行主数据对象和关联关系定义的时候会详细定义。这种关联性带来的就是参照完整性约束，比如供应商联系人信息在，但是对应的供应商头找不到了，对于这种数据不能在ETL上完成处理，但是可以通过脚本找出这种异常数据并手工处理和清洗。

日常进行的数据检查

主数据本身也是不断在增加，因此在数据清洗初始化完成，主数据平台开始正常运行后，我们还需要对主数据内容进行日常的数据检查和管控。这也是数据质量管理的一个重要内容。

对于日常数据检查和审计，整体的步骤可以考虑为

1. 定义数据检查规则，包括单表属性检查，跨行重复检查，多表关联依赖检查，一致性检查
2. 定义检查任务和检查单
3. 将检查单配置为一种计划调度，自动定期按时执行
4. 查看数据检查报表，对于异常数据进行手工处理或自动化处理

前面已经谈到过的数据准确性，唯一性，数据的重复或相似等检查也都可以在这个阶段做。同时我们看到还有一个核心工作，即数据本身的一致性检查和数据稽核。

比如从两个系统都采集到供应商数据，如何去匹配和检查两个系统的供应商数据的差异和一致性，这就需要有独立的数据稽核功能。数据稽核首先对数据对象有唯一的匹配关键字，其次是定义需要进行数据稽核的字段。对于A和B两个数据表而言，常见的数据稽核和比对结果主要包括如下几个方面。

1. A和B两个表哪些数据是完全相同的？
2. 哪些数据A表有，B表没有，或者相反。
3. 哪些数据A和B两个都有，但是存在数据项内容不一致的情况。

以上就是最简单的数据稽核，对于数据稽核的结果首先是可以由系统触发自动化的进行再次的数据同步和集成，包括数据集成过程中的清洗和转换；其次可以输出数据稽核报表，供业务人员手工处理异常数据。

最后再强调下虽然说数据质量管理是一个全生命周期的事情，但是数据质量真正要提升一定不是事后进行数据检查和稽核，而是真正从产生数据问题的源头抓起。比如解决数据源多个多点录入问题，解决同样的数据可以在多个系统发起修改的问题，解决数据模型中定义的数据约束在数据录入的时候没有进行完整性控制的问题等。

MDM系统-接口和数据服务

谈到主数据平台，接口和数据服务或者说集成管理是MDM必须具备能力，在MDM的解决方案中，更多会配合ETL和ESB服务总线来谈这两部分是如何实现的。

首先可以看到MDM涉及到外部集成，主要包括两个方面，一个就是数据的采集过程，一个就是数据的分发和数据服务能力的提供过程，因此需要分这两个方面来谈集成过程。

数据的采集

对于数据的采集过程，本身又需要分为两种不同的场景来说明：

• 数据初始化采集：需要通过ETL来完成，一是数据量大，一是需要在ETL过程中进行清洗。
• 数据增量采集：通过实时的注册到ESB总线的接口服务来完成。确保采集数据的实时性。

可以看到在初始化阶段通过ETL工具完成采集和初始化数据的导入，而在正式上线后，由于主数据变动频率本身不高，因此可以直接通过服务接口进行服务采集，MDM提供数据导入接口服务，数据源产生系统在有主数据变更的时候实时调用服务接口将数据导入到MDM。

当然如果是采用的集中化建设模式，即主数据本身就是在MDM系统创建产生的，那么在这种情况下就不存在主数据还需要采集的过程了。

数据的分发

对于数据的分发本身又分为两种情况：

• 数据落地分发：采用消息发布订阅模式进行分发，或者直接采用WS同步实时服务分发。
• 数据不落地：MDM系统之间提供主数据实时查询服务接口即可。

当前使用的比较多的还是数据落地分发，对于数据落地分发，如果订阅MDM的业务系统相对多，最好是采用消息发布订阅模式进行主数据分发，当然仍然采用WS服务进行分发也可以，但是就需要MDM系统调用多次服务接口进行数据的分发操作，以方面对分发过程进行监控。

对于数据分发，如果存在批量数据的分发，比如人员或组织主数据出现了批量变更，那么这种场景下采用消息或WS分发都可能存在大数据下的性能问题。或者说一个数据分发涉及到更高的安全要求后跨网段集成，那么这个时候还可以采用将需要分发的主数据导出为文件格式，通过文件将主数据分发给目标系统。

对于数据不落地情况下，MDM系统只需要提供标准的数据查询服务接口即可。在这种情况下需要确保该接口服务本身在大并发调用下的性能问题。

主数据平台如何提供数据接口和服务集成能力？

在前面谈MDM的文章的时候，我已经谈到过，我们希望的是MDM系统本身就集成了接口和服务集成的能力，最大化的建设接口集成时候的实施工作量。更好的模式就是MDM本身也具备了部分ETL和ESB服务集成的功能在里面，而不是要完全依赖于外部的能力。

对于数据采集模块，我们可以集成最基本的数据集成能力，即在MDM系统里面就可以配置简单的ETL操作，任务调度操作，将外部数据源的数据根据某种业务规则采集到MDM平台中来。

对于数据分发模块，有两种情况

1. 数据分发场景

1.1 由MDM制定导入服务接口，生成服务规范和契约，MDM将数据模型映射到服务规范。

1.2 外部已有的WSDL服务，MDM直接进行服务映射和分发服务配置，无需编码。

1.3 将MDM数据模型直接发布到JMS消息中间件，同时支持外部系统进行消息订阅。

2. 数据不落地场景

2.1 由MDM提供数据模型直接发布为主数据服务的功能，即模型可以直接发布为服务。

2.2 仍然采用契约先行模式，先定义数据查询接口契约，MDM数据模型映射到服务规范上面。

对于发布的接口本身还需要支持场景的SOAP WS和Rest两种服务接口模式。同时MDM系统本身还需要提供对服务接口的实时监控能力，分发异常告警能力，分发日志的详细统计分析能力等。

---

欢迎关注@人月聊IT 分享SOA，微服务，DevOps平台规划和建设。