前言
主数据被普遍定义为组织/系统间共享的描述业务实体的数据， 属性相对稳定， 变化缓慢。
主数据管理是对为了保证主数据的质量（准确性，完整性）和合理使用而建设或者实施的制度， 流程、系统。主数据管理不是一个单一的短期项目，而是一个长期的，贯穿整个企业发展历程的一系列的活动。
比较早关于主数据的讨论起源与20世纪90年代中后期，热度持续到21世纪的第一个十年左右。背景是由于部分数字化先行的海外企业，在企业信息化建设过程中，建设大量的烟囱式业务系统。 受限与经验和技术的制约等因素， 企业各个系统数据并不互通，从而导致的各种数据问题（
数据质量，数据口径，数据安全等）。
近两年由于疫情的催化和国家层面的倡导， 传统企业纷纷加快数字化步伐。 数据资产被做为重要生产要素， 主数据，主数据管理、
数据治理等相关概念又被变得流行起来。
本文的讨论范围限定如何通过技术和系统层面进行主数据管理，不涉及相关组织，规范部分的讨论。
主数据管理方案
关于主数据的管理，
数据仓库大师Ralph Kimball 团队 在2007总结讨论了三种常见方法，现在仍未完全过时。
基于数据仓库构建与管理主数据
数据仓库在建设之处就是为了解决数据集成的问题，通过ELT过程，数据仓库得到集成后的数据。这部分可能涵盖了企业主数据（一般存储在维度表中），天然的 各个系统从数据仓库中获取需要共享的，被清洗和集成后的数据。
此方案流程图可以参考如下图1：
图1：基于数仓的主数据管理
通过数仓承担主数据管理的方案直观并且相当想当然，它能解决部分问题， 但有非常明显的弊端。kimball团队提到，
数据清洗在ETL过程中而非源业务系统完成，是其主要弊端之一。 本文稍后讨论此方案更多的弊端。
MDM集成中心
相对与数仓被动的承担了主数据管理的部分职责，这种方案引入了专门的集成中心来完成主数据的收集，清理和分发工作。数据仓库成为了MDM的下游系统之一。
图2：集成式MDM系统
集成的MDM相对数据仓库，从架构上相对清晰了一些。从功能上，也可以提供一些接口服务（大部分数据都是T-1的数据）， 满足一些对主数据时效性的要求。
这种架构，仍然不是从源头处清洗数据， 而是在MDM中存数据。
现在我们看到很多专业的MDM系统都是基于这种架构实现的。
企业级MDM系统
第三种方案是企业级MDM系统，相对集成中心MDM设计。这种方案需要创建一个集中式数据库,它会保存主数据所有属性主版本并提供接口供事务系统调用。 MDM直接作为业务系统的数据库。
业务系统不在单独维护（改成存储比较合适）主数据，而是集中式在企业MDM系统中创建、查询和更新。
图3: 企业级MDM系统
相较于前两种方案，这种方案在数据源头进行数据清洗，并提供服务。不存在数据被转移后再次清理分发的弊端。
这种方案在方向上是先进和前瞻的（考虑到这是2007年的文章），从技术层面讲可以比较好的解决主数据管理的问题。但是集中的管理要求事务（业务）系统不在单独存储业务主数据，哪怕是它业务范畴的主数据。
想象一下让CRM放弃对客户主数据的存储，转而统一到MDM系统中维护，就能理解这个方案的实施难度。 实际上，这对MDM维护者也是一个挑战，他需要了解几乎所有系统的逻辑。
第四种方法-把主数据还给业务系统
随着微服务和服务治理技术方向的进步，让第四种方案成为可能。企业级MDM的最大难点是让让业务系统放弃对其拥有主数据的管理权, 统一到MDM管理分发， 我们可以考虑在做一次分离，将集中式的系统分散到各个业务系统自管理，并自行对外提供服务。
图4：分布式主数据管理
各业务自行维护统一的主数据， 每一类主数据都有统一的系统承载， 其它系统需要使用就通过实时接口的方式互相调用。
传统的ERP系统（CS架构）往往对此方案的第一反应是技术维护难度大， 需要大量的接口查找和开发调用工作。 在微服务体系下， 这些不再是不可逾越的难点。
这和业务中台的设计思想和定位是一致的。
对比与选型
对比
当我们仔细对比在四种方案， 实际上代表了两类实现思想：集中式第三方管理 和 业务自治。
方案1和方案2是典型的集中式管理，所有的主数据均流入到第三方系统（数仓， 集成MDM）, 有第三方系统实现收集， 清理， 集成，分发工作。
方案4是彻底的业务自治，每个主数据都有专门承载管理对应实体的业务系统和业务负责人（业务负责人，产品经理，技术），在系统内实现自给管理并对外提供服务。
方案3更像是在某种技术背景下的折中方案， 它意识到第三方管理的弊端，识别到主数据应该是由对应的业务系统负责。但是集中式数据库的解决方案，在落地上会有诸多问题， 同时它将所有主数据工作集成到一个MDM系统中，违背了架构设计高内聚，低耦合的原则。
选型
现在到了讨论如何选型的阶段了，我们知道第四种方案是主数据管理的理论上的理想形态。理想很饱满，现实很骨感，如何选型仍需要考虑企业自身现状，数字化所处的阶段，人才和技术储备等多因素考虑。
在传统企业，进行数据化建设早期，各业务系统还未完全建立，大部分业务实体还未有对应的业务系统，企业IT人员也没有足够的精力去快速建设。在这一阶段一个集中式的MDM系统可以快速的集成一些没有系统承载的主数据管理能力。
随着数字化建设的深入， 越来越多的业务系统被建设起来。 此时，集中式MDM管理的弊端将会放大(参考：)， 此时应该根据企业的IT实力和长远规划判断。如果有一定的企业IT能力， 仍然需深入数字化的目标的和决心（有数字孪生口号的团队都要仔细思考），是时候应该考虑把业务数据还给业务系统了。
至于成本，拉长来看。不论是外包还是自建，二者的投入成本都不会相差太远。
延展话题
稳定不变的主数据?
所有对于主数据的定义都提到，主数据的属性是稳定的， 缓慢变化的。这里似乎隐含了两层含义：1. 缓慢变化意味着不怎么需要专门管理，甚至不需要一个专门的系统，2，其是和快速变化事务数据是不一样的，所以需要区分管理。
在这一定程度上误导了决策者， 缓慢变化仍然是需要被关注和管理的，更需要被系统化。 因为常常缓慢变化的属性都是非常重要的属性，它一旦变化，影响面会非常广。能管理快速变化数据的系统， 同样可以管理缓慢变化的属性， 我们不需要刻意从系统层面区分。
实施MDM时的其他讨论
不论采用集中式统一MDM系统管理， 还是分布式各业务自治。 在进行主数据管理时，有以下点我们都应该关注：
1. 主数据确保全局只存一份。
在一些现实实践中，各业务系统经常会在自己的业务db存储一份主数据，这会导致很多隐患。
• 业务系统可能不会定期去MDM中拉取， 当主数据发生变化时，业务对历史数据的处理也是一个棘手的难题。
• 业务系统可能会修改自己存储的主数据
保证数据的最终一致性，需要做大量的管理工作， 数仓往往是最大受害者。
1. 主数据应该实时获取
为了实现主数据目标和确保数据全局存储一份， 业务系统在获取主数据时都应该实时获取，而不是通过离线分发的方式。
2. 主数据的归属
在一些传统企业中，部分主数据常常找不对应的业务归属，此时IT部门可以承担起对应主数据的权责。
主数据管理成功的目标
届时，各主数据都有归属的业务线上系统（含对应的业务负责人，产品，技术负责人），所有的变更都在对应的业务系统中实施，其他系统需要就实时调用对应业务系统。
标准就是，当大家不再频繁提起主数据管理（治理）时，就是主数据管理成功之时。笔者在互联网行业从业多年，极少听到主数据一词。
（部分内容来源网络，如有侵权请联系删除）
