在目前的大数据时代，企业之间各个部门的数据权限划分模糊，不同应用系统对于相同的字段在数据库中命名非常随意，很难保证统一，并且在进行数据统一时，很多应用系统的数据表的表结构需要进行变更，而修改数据的存储样式，很可能会对企业造成不可评估的影响，因此越来越多的企业进入到了数据治理阶段，对于主数据治理的需求越来越明确。
MDM作为主数据平台，主要是通过数据建模、数据维护、数据质量、数据分析等进行基础数据的维护，保证各个系统基础数据的同源，使企业的主数据具有唯一性、准确性、一致性、及时性，使企业的各项信息更加完善，也使得各项业务之间可以形成闭环。源头系统的数据存在重复的可能性，因此在同步至主数据平台后需要对数据进行清洗，将问题数据进行处理，保障数据的可靠性。
整体说明主数据平台提供数据清洗功能，可以对数据进行治理，将问题数据过滤出来，保障项目中实际使用的数据是准确且可靠，同时将数据统一进行分发操作，以此保障各系统间的数据统一且可靠。
1.整体介绍
本次数据集成为实现企业内部数据的集成与统一，达成集团公司内组织、人员、岗位、客户、供应商、资产、项目、合同等基础数据的统一。从当前各应用系统以及线下Excel表格获取数据信息，使用ESB企业数据总线创建主数据同步流程，各应用系统服务接口将数据同步到MDM主数据平台，在各业务系统需要主数据信息时将其进行分发。
2.功能架构
由于人力资源管理系统、NCC财务管理系统无法实时推送，所以采用提供视图的方式，由ESB定时拉取。当关键应用系统以及投资、建筑、房地产、信息化系统发生变更时调用ESB企业数据总线的接口进行实时推送。同时，各业务系统复用一套主数据，主数据平台将清洗过后的数据进行分发，将数据分发至上述描述的消费系统中。各系统就像一个大系统的各个业务功能模块，实现企业IT架构的柔性调整、升级、改造，从而支撑企业的业务战略目标落地。
客商主数据集成架构如图：
3.功能需求
主数据核心功能需求如下：
1.主数据平台保障数据的一致性、完整性以及准确性，同时保障数据质量，杜绝“一物多码”的情况发生；
2.数据同步流程应严谨，考虑数据为空的情况、数据批量同步的情况；
3.为保障主数据实施的落地，各业务系统应配合提供数据的同步接口以及数据接收接口，如果不能提供接口可提供对应的数据库及视图；
4.主数据平台应记录数据同步日志，便于后续问题排查；
5.对于各业务系统承接主数据编码相关问题，各业务系统自行处理。
数据清洗由于客商源头系统不能保障数据的质量，所以需要由主数据平台对数据进行治理，进行数据治理时需要考虑两个方面，一是历史数据如何治理，二是后续新增的数据如何进行治理。
1.清洗原则
1.数据清洗主要包括两部分内容：一是历史数据的清洗，二是增量数据的清洗；
2.历史数据清洗：主要针对目前提供的历史数据进行清洗校验，包括字段必填校验、合法校验，校验时需要根据天眼查/企查查进行校验；
3.增量数据清洗：主要针对源头实时同步到数据中台的数据进行校验，包括必填、引用等，同时对于新增的数据需要通过天眼查/企查查进行校验。
2.历史数据
1.将财务提供的客户、供应商数据先进行清洗，主要校验数据的合法性，包括非空、格式等；
2.对清洗后的客户、供应商数据通过天眼查/企查查进行校验，确认数据准确性；
3.根据校验结果输出校验不通过数据，并且需要包括源头数据（财务提供），校验数据（天眼查/企查查的查询结果）；
4.将校验的结果发给源头系统进行数据检查确认，确认后重新提供初始化数据导入数据中台。
3.增量数据
1.增量数据主要是源头系统同步到数据中台的数据校验；
2.源头系统新增数据时将新增数据推送至数据中台，数据中台通过天眼查/企查查对数据进行合法性校验，校验通过后写入数据中台，如果校验不通过则返回校验错误的信息；
3.源头系统变更数据时将变更数据推送至数据中台，数据中台根据已有数据进行更新，更新时对数据进行必填校验、格式校验。
对接标准客商数据现如今存在源头系统，且源头系统中存在大量历史数据，因此在实际进行对接时，应考虑到历史数据如何进行对接，以及后续新增的数据如何对接，同时需要提供相应的字段说明清单。
1.对接流程
由于目前增量数据如何进行同步尚未确定，因此需要先将历史数据全量进行拉取，同时确定增量数据的同步方式，客户方是否有其他需求，完成确定后，方可进行实际的开发操作。
> > > > 全量数据
1.历史数据通过全量拉取并校验后导入数据中台进行统一管理；
2.上下游系统初始化时通过数据中台的全量接口拉取全量数据，拉取后获取主数据编码并更新到上下游系统中，作为后续主数据同步分发的统一映射编码。
> > > > 增量数据
1.源头系统录入数据后进行提交，提交时将数据推送至数据中台；
2.数据中台接收数据后，通过主数据编码判断数据是否已存在，已存在则进行更新操作（更新的同时检验数据）；
3.主数据编码不存在时则先通过天眼查/企查查校验数据，检验通过后写入数据中台，校验不通过直接返回异常信息给源头系统；
4.天眼查校验时的校验策略需要确认，具体见4.2数据校验；
5.数据同步中台后回写结果时回写字段包括哪些需要确认，具体见4.3属性补充。
2.客户数据同步
在正式进行客户数据同步的开发工作前，需要确定客户数据的字段明细清单，以及同步时的参数格式，在本小节中将对客户数据同步的基本信息以及相关的字段清单、参数格式进行整理。
> > > > 基本信息
> > > > 请求报文参数
> > > > 响应报文
1.报文参数：
2.响应样例：
3.供应商数据同步
在正式进行供应商数据同步的开发工作前，需要确定供应商数据的字段明细清单，以及同步时的参数格式，在本小节中将对供应商数据同步的基本信息以及相关的字段清单、参数格式进行整理。
> > > > 基本信息
> > > > 请求报文参数
> > > > 响应报文
1.报文参数:
2.响应样例:
主数据平台支持多种数据分发的场景，可以由主数据平台进行统一的数据分发，分发的数据可以为taskId以及Json数据，如下游系统无接收数据接口也可以调用主数据平台提供的数据查询接口进行数据的获取并完成数据的分发操作。
1.枚举类数据
数据查询接口对于数据查询接口中的枚举类数据的输出格式做出了调整，查询接口包括：任务解析接口、全量数据接口、单条查询接口（CODE）、单条查询接口（ID），对于枚举类数据，现如今包括三种显示格式：
一是不添加入参，枚举类数据直接以code进行输出；
二是JSON格式，添加入参（KEY：referFormat，VALUE：json）；
三是平铺格式，添加入参（KEY：referFormat，VALUE：flat）。
本次以其中一个接口用作样例，所有数据查询接口都可以添加此入参对获取的枚举类数据格式做出修改，具体调用方式如下：
> > > > JSON格式
在这里以组织的单条查询接口用作展示，此接口通过业务系统编码以及数据编码作为入参进行查询，获取该数据的明细信息。接口地址为：
调用请求：GET。
调用样例：
入参说明：
出参：
postman调用样例：
> > > > FLAT格式
在这里以组织的单条查询接口用作展示，此接口通过业务系统编码以及数据编码作为入参进行查询，获取该数据的明细信息。接口地址为：
调用请求：GET。
调用样例：
入参说明：
出参：
postman调用样例：
2.客户主数据
客户主数据服务调用地址如下:
可以通过SaopUI、Postman等工具进行调用查看接口。
注意：建议相关系统将IP地址配置成变量的形式，便于后续更改。
> > > > 获取tokenId
调用主数据的任何一个接口都需要获取一个密匙作为请求头，这个密匙为tokenId，其调用服务如下：
其接口地址如下：
调用请求：POST。
接口入参：
参数说明：
出参类型：application/x-www-form-urlencoded
接口出参：
SoapUI调用样例：
> > > > 全量数据接口
全量数据接口主要针对本期数据接收相关系统进行数据初始化所用，接口地址如下，注意只能获取主数据已发布的数据：
调用请求：GET。
接口入参：
入参参数说明：
接口出参(Json)：
SoapUI调用样例：
> > > > 任务解析接口
在主数据向接收系统传入taskId时可以通过task进行数据解析，接口地址如下：
调用请求：GET。
接口入参：
入参参数说明：
出参(Json)，其中data参数是打包好的数据，可以通过key值解析：
出参参数说明：
SoapUI调用样例：
> > > > 日志回写接口
在业务系统解析任务同步数据成功后需要返回成功或者失败日志到主数据内。接口地址为：
调用请求：Post。
入参(Json)：
入参说明：
出参：
出参说明：
> > > > 单条查询接口(CODE)
通过业务系统编码以及数据编码作为入参进行查询，获取该数据的明细信息。接口地址为：
调用请求：GET。
调用样例：
入参说明：
出参：
postman调用样例：
> > > > 单条查询接口(ID)
通过业务系统编码以及数据ID作为入参进行查询，获取该数据的明细信息。接口地址为：
调用请求：GET。
调用样例：
入参说明：
出参：
postman调用样例：
3.供应商主数据
供应商主数据服务调用地址如下:
可以通过SaopUI、Postman等工具进行调用查看接口。
注意：建议相关系统将IP地址配置成变量的形式，便于后续更改。
> > > > 获取tokenId
调用主数据的任何一个接口都需要获取一个密匙作为请求头，这个密匙为tokenId，其调用服务如下：
其接口地址如下：
调用请求：POST。
接口入参：
参数说明：
出参类型：application/x-www-form-urlencoded
接口出参：
SoapUI调用样例：
> > > > 全量数据接口
全量数据接口主要针对本期数据接收相关系统进行数据初始化所用，接口地址如下，注意只能获取主数据已发布的数据：
调用请求：GET。
接口入参：
入参参数说明：
接口出参(Json)：
SoapUI调用样例：
> > > > 任务解析接口
在主数据向接收系统传入taskId时可以通过task进行数据解析，接口地址如下：
调用请求：GET。
接口入参：
入参参数说明：
出参(Json)，其中data参数是打包好的数据，可以通过key值解析：
出参参数说明：
SoapUI调用样例：
> > > > 日志回写接口
在业务系统解析任务同步数据成功后需要返回成功或者失败日志到主数据内。接口地址为：
调用请求：Post。
入参(Json)：
入参说明：
出参：
出参说明：
> > > > 单条查询接口(CODE)
通过业务系统编码以及数据编码作为入参进行查询，获取该数据的明细信息。接口地址为：
调用请求：GET。
调用样例：
入参说明：
出参：
postman调用样例：
> > > > 单条查询接口(ID)
通过业务系统编码以及数据ID作为入参进行查询，获取该数据的明细信息。接口地址为：
调用请求：GET。
调用样例：
入参说明：
出参：
postman调用样例：
基础数据在完成集成开发后，数据可从源头系统同步至主数据平台，由主数据平台统一进行管理，进行对数据的维护、清洗、分发等操作，保障数据的可靠性、上下游系统数据的一致性。
1.数据清洗
1.通过数据中台的清洗可以对历史数据进行规范化，清洗掉重复、不规则、不一致、信息缺失的历史数据，并通过数据补充维护，保证历史数据的准确性；
2.能够对日常维护的数据进行清洗校验，针对业务人员手工录入的数据进行规范化，最大可能避免因人工维护导致的数据异常。
2.数据导入
1.对于清洗后的历史数据，可以直接通过Excel的方式导入到客商主数据中；
2.对于源头系统日常维护的数据，可以通过接口的方式导入到客商主数据中；
3.主数据平台提供数据维护功能，可以直接在主数据平台进行数据新增、变更、启用、禁用等操作；
4.主数据平台提供编码规则体系，能够配置编码规则，支持编码的生成、同步、分发，构建客商数据的编码体系，从而保证上下游系统编码的一致，避免数据重复。
3.数据分发
1.提供全量数据查询接口，可以支持外部系统的全量数据查询，并支持接口的安全控制机制；
2.提供基于任务的单条、批量数据查询功能，可以通过任务接口获取数据，并能控制接口的安全和数据范围；
3.提供实时推送的机制，对于同步或手动修改的客商数据，能自动或手动推送到下游系统，保证数据实时性；
4.内置BPM工作流机制，可以图形化配置工作流，增加数据新增、变更等操作时的审批控制。
个人总结客商主数据的使用频率较高，同时由于客商主数据涉及到工商及付款等操作，其数据的准确性就尤为重要，因此需要对历史数据及后续新增的数据进行清洗操作，以确保最后使用的数据可靠。
1.集成整合
数据中台的重点不仅是进行管理，还要创建对应的标准，而数据中台中的数据都是从业务系统中抽取，无论数据清洗、基础数据和业务数据的管理都离不开集成，数据中台作为一个中间系统，需要做到打通上游系统数据，并将获取的数据提供至其他业务系统。数据中台对于这些数据只是进行数据的落地存储和数据管理分析，可以说数据管理与数据集成密不可分。
2.产品价值
数据中台可以打通各业务链条，消除不同部门重复录入数据造成的数据冗余。统一数据语言，统一数据标准，实现数据同源、数据共享，最大程度提高数据的权威性。同时还实现了数据动态自动整理、复制，解决了各部门数据及版本不一致的问题，极大减少了人工整理数据的时间和工作量，提高工作效率。并且打通企业业务系统之间的信息孤岛后还能够实现信息集成与共享，提高公司整体的战略协同力。
3.总结分析
企业需要打通不同业务系统之间信息孤岛、帮助企业完成主数据治理，所以需要不断地与源头系统、下游系统进行沟通确认。在这个过程中也是需要项目团队与企业之间相互配合、相互协作，最终由企业认可主数据的建设，才能真正地帮助企业进行主数据的管控。
在进行数据治理时，可能已经完成部分数据的同步，此时就需要先完成对历史数据的清洗，完成历史数据的清洗之后，再根据一定的策略保障后续同步数据的准确性，以此保障数据在从上游系统到下游系统的整个集成过程中准确、可靠。
本文由@数通畅联原创，欢迎转发，仅供学习交流使用，引用请注明出处！谢谢~
,
