企业所面临的数据问题
企业都会使用不止一个系统（除非是非常小的企业），同一个现实实体的细节会出现在不止一个系统中，例：员工会被定义在财务系统、OA系统等。因此就会带来如下问题：
可能需要在每个系统中重新存储数据
系统之间可能不同步（新数据，更新数据）
重复数据："ABC Ltd"和"ABC Limited"是同一个东西么？
报表或者分析：难以从多个系统去合并数据
因此以下场景，屡见不爽
为了解决上述问题，我们需要为企业的信息集成、管理和共享提供一个系统化的解决方案。MDM（Master Data Management）便是方案之一。
主数据的定义
主数据可以简单理解成，数据被一处以上的应用所使用到，此类数据就可以成为主数据
主数据管理系统
MDM是在业务和IT协同工作下确保企业业务关键的主数据资产(如员工、组织、地理信息等)的权威、可靠、可持续、精确、安全的数据环境。
MDM的主要功能分为四类：
1. Master Data Lifecycle Management（Master Data 生命周期管理）
2. Data Quality Management（数据质量管理）
3. Master Data Harmonization（Master Data 协调与分发）
4. Analysis and InsightCapabilities（分析功能）
主数据管理系统核心功能
主数据管理的成熟度等级
Level 0 ：没有实施任何主数据管理(MDM)
在Level 0的情况下，意味着企业的各个应用之间没有任何的数据共享，整个企业没有数据定义元素存在。各个系统间不共享、数据不互通是常态。
Level 1 ：提供列表
不管公司大还是小，列表管理是我们常用的一种方式。在公司内部，会通过手工的方式维护一个逻辑或物理的列表。当各个异构的系统和用户需要某些数据的时候，就可以索取该列表了。对于这个列表的维护，包括数据添加、删除、更新以及冲突处理，都是由各个部门的工作人员通过一系列的讨论和会议进行处理的。业务规则(Business Rules)是用来反映价值的一致性，当业务规则发生改变或者出现类似的情况时，这样高度手工管理的流程容易发生错误。由于列表管理是通过手工管理的，其列表维护的质量取决于谁参加了变更管理流程，一旦某人缺席，将会影响列表的维护。
Level 2 ：同等访问(通过接口的方式，各个系统与主数据主机之间直接互联)
MDM Level 2与MDM Level 1相比，引入了对主数据的(自动)管理。通过建立数据标准，定义对存储在中央知识库(Central Repository)中详细数据的访问和共享，为各个系统间共享使用数据提供了严密的支持。中央知识库(Central Repository)通常会被称为“主数据主机(Master Data Host)”。这个知识库可以是一个数据库或者一个应用系统，通过在线的方式支持数据的访问和共享。
Level 3 ：集中总线处理
与MDM Level 2相比，MDM Level 3打破了各个独立应用的组织边界，使用各个系统都能接受的数据标准统一建立和维护主数据(MDM Level 2的主数据主机上存储的数据还是按照各个系统分开存储的，没有真正的整合在一起)。
集中处理意味着为MDM构建了一个通用的、基于目标构建的平台。大多数公司发现MDM正在挑战他们现有的IT架构：他们拥有太多的独立平台处理主数据。MDM Level 3 集中数据访问、控制跨不同应用和系统使用数据。集中MDM处理-通过一个公共的平台作为一个总线(HUB)-说明一个共识，从多个系统整合主题域数据，意味着使用集中、标准化的方法转换异构操作数据，不管其在源系统中是什么样子，都会被整合起来。在MDM Level 3，公司对主题域内容采用集中管理方式。这意味着应用系统，作为消费者或使用主数据，拥有一个共识就是数据是主题数据内容的映像，打破了各个独立应用的组织边界。MDM Level 3支持分布主参考数据的存在。
Level 4 ：业务规则和政策支持
一旦数据从多个数据源整合在一起，主题域视图超越单独的应用并表现为一个企业视图，你将获得事实的单一版本。当事实的单一版本已经能够提供出来时，来自业务主管和执行人员的必然反应经常是：“证明它”。MDM Level 4可以保证主数据反映一个公司业务规则和流程，并证实其正确性。MDM Level 4通过引入主数据来支持规则，并对MDM总线以及其它外部系统进行完整性检查。
举例来说，在一个HMO内，需要多个应用来支持一个病人的护理。一个单一的访问(visit)可能包括入院、房间和床位分配、监控设备、化验、身体检查以及其他程序等。一旦一个病人准备离开医院，出院流程需要确保和这个病人相关的所有活动、资源都被结清。MDM技术在召集多个应用系统一起保证病人辨识方面是十分有效的，处理是正确的。虽然病人辨识很重要，业务规则整合同样重要。临床系统依靠一系列的业务流程和数据规则来辨别所有显著的病人详细资料。这包括返回所有基于房间的资源(监护设备、床位等)以得到有用的详细目录，当病人要出院时分解其所有的费用。MDM保证当John Smith出院时，正确的房间和设备放入到该John Smith的详细目录中，而不是其他的John Smith(正在另一个楼层做身体治疗)。
MDM系统必须不仅支持基于规则的整合，还要能够整合外部的工作流。MDM Level 4支持集中规则管理，但是规则本身和相关的处理是可以分开的。换句话说，MDM总线需要保证规则是集中应用的，即便这个规则是在总线外居住的。
Level 5 ：企业数据集中
在MDM Level 5 ， 总线和相关的主数据被集成到独立的应用中。主数据和应用数据之间没有明显的分隔。他们是一体的，当主数据记录详细资料被修改后，所有应用的相关数据元素都将被更新。因此，MDM Level 5提供一个集成的，同步的架构，当一个有权限的系统更新一个数据值时，公司内所有的系统将反映这个变更。系统更新完数据值后不要单选其他系统中相应值的更新：MDM将使这种更新变的透明。
MDM Level 5是把数据概念作为一种service来实现。MDM Level 5保证了一个一致的主数据主题域企业映像。定义“客户”和其他应用接受客户主数据业务规则变化实际上是一回事。MDM Level 5移走了主数据的最后一个障碍：统一采用数据定义、授权使用和变更传播。
企业主数据生态构建
主数据的生态圈，包括数据的提供方，主数据系统及其使用数据的下游系统。
主数据
主数据安全问题
主数据中会保存一些敏感数据，一旦泄露将会造成不同程度的影响。因此，如何安全访问主数据，是建设主数据的关键环节。
一般来说，可以通过以下策略来进行基本的安全访问控制
支持数据的行列权限控制
支持离线脱敏，包括数仓脱敏和下线环境数据脱敏
尽量减少高密类型数据的下发
支持数据安全定期审核与分析
支持元数据的管理审批权限
对于敏感数据的使用，往往会和业务产生一定冲突。假设员工的邮箱为敏感数据，而给人员发送邮箱是一个非常合理的需求，自然也就需要获取邮箱数据。在不下发邮箱的前提下，如何满足业务使用？这里有一种简单的做法。一般来说，邮件服务，是一个公共能力。因此我们可以在此基础上，抽象出一个邮件代理服务，业务系统只需要传递员工ID，再由此代理服务，通过调用主数据来获取邮箱数据，将数据获取和泄露的风险降低至一个服务。以上是借助代理服务，来避免主数据系统中敏感数据下发。
业务系统在进行一些关键操作，比如查询薪资，可能就需要员工的手机验证码校验后才能查询。自然的，就需要从主数据获取员工手机号，而不巧的是，手机号也是敏感数据。我们是否可以参考上述例子，通过抽象一个上层代理服务，来完成手机验证码的发送和验证？ 如果公司的验证码服务，除了给公司内部使用，又支持外部用户使用。此时，员工ID就非唯一标识。这时，主数据系统就要承载起业务服务化的能力，自身去提供代理业务的能力。因此，在缺少代理服务的情况下，主系统系统自身要承载起重担，保证满足下游业务的同时，减少数据泄露的风险。
小结
如何建设好主数据，是中大型企业都需要去思考和解决的。本文只是简单提及了主数据系统的一些概念，在安全管控方面的一些简单实践经验。对于主数据本身来说，还有非常多的点可以去挖掘，例如主数据的生命周期管控、数据权威验证等等。
往期推荐
深度解读阿里“新六脉神剑”：价值观如何产生？如何落地？
用敏捷开发搞7遍，把我4小时的活压进27分钟
程序员自我欺骗的9个谎言
从业务架构梳理到技术架构设计
DDD如何讲清楚，做出来？
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。
————————————————
版权声明：本文为CSDN博主「大家叫我导演」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u013527895/article/details/103813763