MDM主数据管理概述
主数据是描述核心业务实体（如客户、供应商、地点、产品和库存）的一个或多个属性。因此主数据便是在进行企业业务架构分析中发现的核心业务对象。或者讲主数据是企业已经存在的涉及到价值链核心业务流程的各个IT系统的基础数据。前端
对于ERP系统客户，供应商，物料，BOM，产品，合同，订单等都应该是最基础的数据，对于项目管理系统而言项目信息，WBS信息则是最基本的基础数据。而对于CRM系统则客户，销售项目是最基本的基础数据。基础数据要上升到主数据的高度还有一个条件，即该数据产生在一个源IT系统中，可是会在多个其它的IT系统中使用到。web
企业缺少主数据管理形成的最大问题就是完整性和一致性，有些是自己主数据不完整或缺失，有些则是主数据在多个系统中存在拷贝和更新，致使数据不一致。引发企业主数据问题的重要因素之一是信息彼此隔离。在许多企业中，主数据分布在众多彼此隔离的系统中。客户服务部门、生产部门以及采购部门都有各自的系统。数据库
即便在一个业务部门里，也有众多前端和后端系统，这些系统包含对业务相当重要的数据，但一般状况下没法与其余系统共享这些信息。正是因为构建在各类架构之上的不兼容系统中的这种部门化数据，使得企业几乎不可能建立和维护主数据的“单一”视图。后端
对于原有的关于主数据管理的解决方案，一个方面是创建数据中心和数据仓库，数据仓库能够极为高效地保存系统数据。遗憾的是，数据仓库中所包含的数据一般都通过了清理，用于分析和生成报告，所以数据仓库是主数据管理解决方案的有益补充，但不是解决方案自己。数组
也有提出以ERP为核心系统，其余为外围系统，则ERP的基础数据管理上升为主数据管理。可是企业资源规划（ERP）解决方案旨在管理特定的应用流程，一样，这些解决方案须要使用主数据，而不是主数据管理解决方案。并且，非ERP 系统不能访问 ERP 解决方案中的数据。安全
所以IBM的MDM提出了超越单一视图，使用正确的视图的新的主数据管理思路。适时地将正确的信息以正确的视图提供给正确的对象。这才是主数据管理（MDM）的目标。主数据管理描述了一组规程、技术和解决方案，这些规程、技术和解决方案用于为全部利益相关方（如用户、应用程序、数据仓库、流程以及贸易伙伴）建立并维护业务数据的一致性、完整性、相关性和精确性。微信
主数据管理的关键就是“管理”。主数据管理不会建立新的数据或新的数据纵向结构。相反，它提供了一种方法，使企业可以有效地管理存储在分布系统中的数据。主数据管理使用现有的系统，它从这些系统中获取最新信息，并提供了先进的技术和流程，用于自动、准确、及时地分发和分析整个企业中的数据，并对数据进行验证。架构
主数据管理解决方案具备如下特性：并发
在企业层面上整合了现有纵向结构中的客户信息以及其余知识和深层次信息app
共享全部系统中的数据，使之成为一系列以客户为中心的业务流程和服务
实现对于客户、产品和供应商都通用的主数据形式，加速数据输入、检索和分析支持数据的多用户管理，包括限制某些用户添加、更新或查看维护主数据的流程的能力
集成产品信息管理、客户关系管理、客户数据集成以及可对主数据进行分析的其余解决方案。
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各自管理功能，流程处理功能的开发。那么在对象建模思想下，咱们要考虑的是供应商是一个完整的主数据对象，应该经过什么方式把这个对象建模清楚。
对象建模
经过完整的对象建模一方面是能够直接生成后台数据库表，一方面是用于后续的界面建模和主数据质量管理。
对象就有属性，即首先应该清楚的定义出对象的属性信息。对应到具体的字段。
每一个对象属性咱们应该清楚的定义出属性的业务完整性和数据约束规则。
对象自己可能有子对象，咱们应该能够进一步对某一个对象的子对象进行详细定义。子对象将对应到后台数据库表中主表下的关联从表。
对象和对象之间有关联和映射信息，咱们应该能够对应对象间的关联和映射。
对象属性和对象之间存在关联信息，应该能够定义属性和对象之间的关联和映射。
其中能够看到对象建模的核心仍是在于对象和子对象，对象属性的业务规则定义，对象和对象之间的关联映射等内容。固然咱们也能够经过数据库表逆向生成对象。在对象建模完成对象建模的相关信息都应该存储到元数据管理的相关数据表中，这是最核心的内容。完整的元数据能够作到基本基于对象的简单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主数据平台须要具有的快速开发和可配置能力。
4A和权限模型：实现组织，用户，权限等灵活配置
流程引擎：实现审批流程的灵活可配置
对象建模：实现主数据对象模型的灵活建立和配置，包括对象和数据表的链接和映射
表单建模：实现表单的自定义和可视化设计配置，表单和对象模型间的映射
规则建模：底层有一个规则引擎，可以实现规则的灵活配置或脚本定义
集成模型：实现对象到接口服务的自动化发布，可以实现数据集成的自动化配置和集成
以上这些内容看着会感受特别熟悉，即这些和咱们常常看到的快速开发平台很相似，即一个产品和的主数据平台基本涵盖了快速开发平台须要具有的全部能力。
那么企业在实施主数据平台的时候，当须要实施一类新的主数据的时候，好比咱们须要实施物料主数据，咱们但愿的就是物料的数据模型，表单，流程，集成接口都彻底可以配置出来而不须要开发代码。在这种状况下主数据平台具有了最大的灵活性，可是实际上咱们看到对于界面和规则，每每是很难经过配置的方式完成的，特别是一些复杂规则的实现更难简单的配置完成。
主数据平台在具有了快速开发平台的关键基础能力后，又增长了关键的技术基础能力，即
ETL数据集成：可以实现数据集成，数据清洗转化和入库
SOA集成：可以实现数据对象快速的发布为接口服务，标准化的消息发布订阅
在增长了这两方面能力基本就具有一个标准化的主数据管理平台能力。
而实际上咱们当前的主数据平台对于4A，流程引擎，对象建模，集成建模，ETL这些关键技术能力所有具有，而比较欠缺的就是动态表单建模和规则建模，虽然咱们在前面也实现过一个简单的技术组件，可是经过实施咱们仍然发现对于一些复杂场景的主数据管理，很难简单的经过配置就完成功能的设计和开发。
咱们咱们已经有表单设计器和自定义表单，可是即对于表单和规则仍是须要定制化开发，其它技术组件和能力可以实现彻底的灵活可配置。这便是当前咱们主数据平台的能力现状，对于比较强调规划咨询和实施能力的企业，咱们仍然具有足够的优点。
主数据平台趋势必定是从技术平台转到业务平台
举一个简单的例子来讲，若是你一直作汽车制造行业的MDM主数据系统，那么实施多了后，你天然就很清楚对于汽车制造行业涉及到哪些主数据，每个主数据对象究竟应该包括哪些通用基础字段和扩展字段。这些通用化的主数据模型每每也适用于其它的汽车制造行业。
那么这个时候你的主数据平台就单纯的从一个技术平台变成了一个业务平台，即已经通过你多年的MDM主数据平台的建设和实施，将实施经验沉淀为主数据平台的数据资产。这个数据资产自己就是有价值的。
MDM系统-数据建模
在前面已经谈到，MDM平台后续的建设思路都是围绕数据模型这个关键元数据驱动进行建设的，从数据建模再延伸到了业务规则建模，流程建模和界面建模等内容，最后扩展到外围的接口服务集成能力。建模能力是否强大，是否灵活和可扩展，每每直接影响到一个MDM平台的易用性和扩展性。
下面再来解释下如何进行主数据建模，对于主数据建模其本质应该是一个树状的层级可展开结构，方便进行子对象和层次的自动挂接，以适合一个主数据有多层子对象的状况。
整个主数据建模的关键过程和步骤应该以下：
建立数据对象，如供应商，物料数据对象。数据对象能够有多层结构。
建立数据对象的子对象，即该数据对象能够存在子对象，子对象还可存在子子对象。
建立数据对象或子对象的数据项信息，包括数据项目的名称，类型，其它扩展属性等。
上面三个关键步骤就可以实现基本的数据对象建立，每一个数据对象和子对象对应到数据库中一张表，这个数据对象很相似咱们领域设计中的领域对象。子对象单独没有存在的意义，必须连同父对象存在。对于建模中对应的各个数据项，便是实际数据表中的数据字段信息。
这样数据建模完成后能够直接造成动态Sql语句，直接建立后台的数据库表结构。
在数据对象建模中咱们能够考虑增长一个文件夹建立的功能，或者说咱们单独增长一个针对数据对象建立属性分组的功能，便可以将不一样的属性和子对象进行分组管理。这个分组一个是方面咱们进行维护和管理，一个是后续在界面建模的时候直接将不一样的分组属性映射到不一样的tab页签上面。
数据项自己的类型应该至少包括以下几种：
简单的录入类数据类型：字符型，数字型，日期型
列表类数据类型，从下拉列表中选择：支持从数据字典中选择，也支持从独立的另外数据表对象中选型
跳窗选择型：即支持关联到另一个外部数据表对象
文件型：支持上传文件，注意能够支持一个数据对象上传多个附件文件的能力。
表格型：对于数据对象维护过程当中，子对象应该默认映射到表格类型
对于列表数据类型每每还须要支持多级分类联动模式，好比物料信息维护的时候可能出现先选择物料大类，再选择小类，再选择次小类，就存在三个小拉列表框的联动关系。
以上是最基本的数据项类型的维护能力，其次是基础的字段完整性校验能力，其中就包括了场景的是否为空检验，数字类型检验，长度检验，值大小检验，自定义脚本检验（if a>0 and b>0 then c>0）等。这些能够确保数据录入的基础完整性。
以上全部这些校验都是单条主数据记录录入的时候就能够完成的校验，其次就是多行记录之间的相互校验，最多见的就是为了不主数据录入重复，咱们须要进行类似性校验，对于类似的主数据给出提醒。
好比在录入供应商录入的时候咱们能够根据名称进行类似性校验，在物料信息录入的时候能够根据规格型号，参数组合进行类似性验证等。类似性校验功能既能够用于在数据清理阶段的查重，也能够用于后续的新数据录入和修改检查。
还有就是跨多个数据对象之间的校验，好比当存在在途数据的时候，供应商的类型或名称不容许变动或删除，这就是最多见的外部业务规则检验，对于这种能力也须要进行支持。
一个完整的主数据模型定义，实际是应该包括了数据类元数据，业务规则类元数据和界面类元数据，列入界面上应该展示什么样子，展示和布局规则等都属于界面元数据。这些也能够在数据模型维护的时候进行统一维护。
而对于对象这个层面的主数据，也还须要进行额外属性信息的维护，其中包括了：
数据集成类（数据采集，数据分发，集成接口等）
关联关系类（该数据对象和其它数据对象的管理关系）
数据类（对应的数据库，数据源或数据表信息的定义）
元数据定义完成后要达到的一个效果就是能够生成底层的数据库表，能够用来自动化生成界面，能够用来作数据此采集和集成，同时还能够根据业务规则进行主数据质量管理。
数据质量管理
数据质量管理（Data Quality Management），是指对数据从计划、获取、存储、共享、维护、应用、消亡生命周期的每一个阶段里可能引起的各种数据质量问题，进行识别、度量、监控、预警等一系列管理活动，并经过改善和提升组织的管理水平使得数据质量得到进一步提升。
数据质量的评估维度主要包括以下几个方面的内容：
完整性 Completeness：完整性用于度量哪些数据丢失了或者哪些数据不可用。
规范性 Conformity：规范性用于度量哪些数据未按统一格式存储。
一致性 Consistency：一致性用于度量哪些数据的值在信息含义上是冲突的。
准确性 Accuracy：准确性用于度量哪些数据和信息是不正确的，或者数据是超期的。
惟一性 Uniqueness：惟一性用于度量哪些数据是重复数据或者数据的哪些属性是重复的。
关联性 Integration：关联性用于度量哪些关联的数据缺失或者未创建索引。
而以上这些内容咱们在作MDM主数据管理系统的数据质量管理模块，包括实施ETL工具里面的数据转换和清洗等时候，都是须要考虑和支持的内容。
而对于数据质量管理，应该是覆盖数据生老病死的全生命周期管理，为了方便重点谈下常见的两个实施数据质量管理的阶段，一个是借助ETL工具实现的数据采集和整合阶段，一个是平常实时进行的数据检查和稽核。下面就这两个常见阶段分开再来谈下。
数据采集和整合阶段
如今的ETL操做不少已经转变为了ELT操做，即咱们说的Transform转换这块的内容有些事在ETL传输过程当中完成，而有些已经转变到数据采集到目标数据库后再在目标数据库端完成数据转换。
注意转换的做用更多的是将数据标准化和规范化，好比经过转换和映射，将名称转换为代码，或者作两个数据项内容的合并等，这些都是能够在转换的时候执行的事情。
数据惟一性里面有一个重点就是去重和去类似性，对于去重咱们能够在ETL工具里面经过转换配置完成，而对于去类似性每每则须要后续数据采集完成后编写独立的代码或脚原本分析类似性数据，并经过手工确认后再完成去除类似性数据或对数据进行合并操做。
一类主数据每每涉及到多张表，好比供应商主数据，涉及到基本信息，联系人信息，帐号信息等多个子对象。这些子对象能够是一种层次关系，也能够是一种关联关系。这个咱们在进行主数据对象和关联关系定义的时候会详细定义。这种关联性带来的就是参照完整性约束，好比供应商联系人信息在，可是对应的供应商头找不到了，对于这种数据不能在ETL上完成处理，可是能够经过脚本找出这种异常数据并手工处理和清洗。
平常进行的数据检查
主数据自己也是不断在增长，所以在数据清洗初始化完成，主数据平台开始正常运行后，咱们还须要对主数据内容进行平常的数据检查和管控。这也是数据质量管理的一个重要内容。
对于平常数据检查和审计，总体的步骤能够考虑为
定义数据检查规则，包括单表属性检查，跨行重复检查，多表关联依赖检查，一致性检查
定义检查任务和检查单
将检查单配置为一种计划调度，自动按期按时执行
查看数据检查报表，对于异常数据进行手工处理或自动化处理
前面已经谈到过的数据准确性，惟一性，数据的重复或类似等检查也均可以在这个阶段作。同时咱们看到还有一个核心工做，即数据自己的一致性检查和数据稽核。
好比从两个系统都采集到供应商数据，如何去匹配和检查两个系统的供应商数据的差别和一致性，这就须要有独立的数据稽核功能。数据稽核首先对数据对象有惟一的匹配关键字，其次是定义须要进行数据稽核的字段。对于A和B两个数据表而言，常见的数据稽核和比对结果主要包括以下几个方面。
A和B两个表哪些数据是彻底相同的？
哪些数据A表有，B表没有，或者相反。
哪些数据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圈
泛物流行业IT知识分享传播、从业人士互帮互助，覆盖快递快运/互联网物流平台/城配/即时配送/3PL/仓配/货代/冷链/物流软件公司/物流装备/物流自动化设备/物流机器人等细分行业。长按二维码即刻加入咱们，若是你是以上行业公司中的IT从业人士加运营小哥微信后可入群交流。
公众号
运营小哥
本文分享自微信公众号 - 物流IT圈（exiter18）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。