功能视角
从功能上看，主数据无非就是把乱七八糟的数据统一起来，形成统一的核心数据，然后使得这份数据在各个系统中都能通用。还有人说：主数据就是编码系统，对数据进行统一编码，One ID是在主数据之上做编码的。也有人说：主数据是系统内，One ID的跨系统的。这些观点怎么说呢？也对，但不全面。比如：你知道全球范围内最牛的主数据体系是那个公司么？不是什么teradata、oracle、IBM之类的，而是一个你可能没听过，但是好像又听过的公司：
华夏邓白氏。
这家奇特的公司不卖产品，不卖服务，卖“编码”。这么说吧，但凡要做全球标准的，基本上都跟“邓氏编码”脱不了干洗，比如：
欧洲委员继联合国、国际标准组织后会于1995认可邓白氏编码是欧洲贸易中电子数据交换的标准
邓氏编码使用于美国政府的总务管理局，美国邮政、食品及药品管理局，教育部门等
从2003年起任何联邦基金的申请都必须提交邓氏编码
邓氏编码是国际近30个行业协会在电子商务及EDI中推荐使用的商业代码
沃尔玛将邓白氏的自查报告作为供应商筛选的必须步骤
可口可乐的供应商都需要提供邓白氏编码
西门子所有的供应商都必须提供邓氏编码
你就说牛不牛？就这家公司的编码，是属于主数据还是属于One ID？所以从功能层面，真的不能简单的用上面的判断标准区分开。
项目视角
做过数据中台项目的人都知道，中台项目是不包含主数据系统的。即便要做，项目规划的时候一般都要求单独立一个主数据项目。这又是为什么呢？面对我的这个问题，有些做过数据中台项目的人也很奇怪。有些实操的朋友只会说：主数据可以作为One ID的来源。他们在建中台的时候说：甲方建了主数据系统，我们就省事儿点。没主数据系统，我们就费事点，反正有没有主数据系统，我们都能做。
但是也有些数据中台把主数据也集成到里面了：
我也遇到过没做过数据中台项目的甲方朋友，他们没建主数据系统，听说数据中台很牛批，就想用数据中台代替主数据系统，给客户、产品主数据进行统一编码，然后再让其他业务系统实用。怎么说呢？这么走一圈，理论上是可以的，但是你不觉得怪怪的么？后来我们给他解释一圈之后，他就主动熄灭了这个想法。这又是为什么？
架构视角
想要了解这一切，单纯从功能视角和项目视角是无法理解的。因为功能层面，他俩非常类似，尤其是统一编码的功能，几乎是一样的。
从项目层面，怎么说的都有，先建主数据项目、后建中台的逻辑能行，中台建设时同时包含主数据也不是不可以。
所以我们必须要切换一个视角：架构视角。从这个视角我们能区分的非常清楚。先放一个阿里中台DataPhin的示意图：
其中，OneID是在萃取数据那一步完成的。而主数据完全没有在这里体现出来，而是隐藏在数据源中。而OneID的目的在于业务系统只上，跨系统打通数据，而非仅仅是统一编码。
其实现方式是在现有ID之上，用代理键的方式加一个ID，这样便于从N个系统中打通数据孤岛。
那主数据系统是什么情况呢？来看这张图：
来源：信通院《 主数据管理实践白皮书》
我没有找到现成的主数据与数据中台架构的图，这张图也是一样的意思。从上图可以看出，主数据为各业务系统提供物料代码、项目代码、单位代码、员工代码等主数据服务。所以主数据是在业务系统之间，实现核心数据的代码统一，降低内部数据协同成本，提升数据标准化程度。这张图能看的更清楚一些：
如果在数据中台项目中集成主数据系统，会怎样呢？每个业务系统本来只需要在主数据系统那边调用一下就行。但放到中台之后，则需要到数据中台中的主数据系统中确认一下，然后再调用。这个弯就绕的太大了。更重要的是主数据系统放在数据中台这边，会导致OLTP和OLAP耦合的太紧密，会造成各种耦合的问题。最后总结一下：
主数据的核心目的是在单一业务领域中，各系统进行核心数据的统一，两个关键词：业务系统和统一。
One ID的核心目的是跨业务领域的数据连通，两个关键词：跨业务领域、连通。
所以，OneID是放大版的主数据，主数据可以作为OneID的输入。
