数据中台的OneID是个什么鬼

如题！

这个问题一直困扰了我很久，在阿里的数据中台中，有三个主要的组成部分OneID、OneData和OneService。我之前写的一篇文章曾对阿里的数据中台做过解读，见《什么是One Data体系？阿里数据中台解读》。

在这篇文章中，笔者曾提到OneID的本质就是主数据，只是用的不是传统的主数据管理技术。

这篇文章发布后，很多读者朋友给我留言，告诉我OneID和主数据不是一回事，但没有一个人给我讲清楚这两个概念为什么不是一回事。

今天我们好好捋一下这个问题！

— 01 —

OneID和主数据到底是不是一回事？

在阿里巴巴 OneData 体系中，OneID 指统一数据萃取，是一套解决数据孤岛问题的思想和方法。

如果单看这个定义，你一定也会和我一样懵逼，啥是数据萃取？解决数据孤岛问题，主数据不也是干这个事情的吗？

别急，我们慢慢分解，先来看OneID到底是干啥的。

OneID也叫 ID-Mapping，就是将设备ID（例如手机MAC、IMEI、IMSI等），手机号、身份证号、邮箱地址、PC端的Cookie，用户名等信息，结合标签体系、知识图谱、机器学习等技术和算法，将各种 ID 都映射到统一的ID上。也就是说不论用户用什么ID登陆，不论登陆的是PC端还是手机APP，都能识别到他的一个唯一身份。

OneID干的这个事情是不是和主数据有点类似？主数据也是给数据对象赋予一个唯一的编码（身份）。

但是，不得不承认，OneID和主数据还是有很大区别的，如下：

第一，解决问题的环境不同。OneID主要是解决ToC业务，不同渠道、不同数据来源的用户身份的统一映射和识别问题，例如：PC端、移动APP，微信小程序、相关应用系统等。而主数据是对相同数据对象进行标准化定义并赋予唯一编码，更多的是用ToB业务中，解决企业内部异构系统之间数据不一致问题。

第二，解决问题的“地点”不同。OneID是把各类UID信息汇聚在一起，在一个地方进行加工和处理，最后形成统一的Mapping关系，阿里管这个地方叫做“数据中台”。而主数据强调的是从源头统一标准，定义唯一编码，各异构系统都依据统一的标准执行，映射关系是建立在各异构系统中的。

第三，解决问题的技术不同。OneID是典型的OLAP技术，是在产生数据之后通过大数据分析、人工智能算法等技术将各种 UID 都映射到统一的ID上。而主数据是典型的OLTP技术，其本身是对数据的增删改查操作，例如客户主数据的定义和编码。

— 02 —

数据中台为什么需要OneID？

说起这个问题可能要追溯到“遥远”的互联网PC时代了。

在PC时代，各大网站都是通过Cookie记录用户信息的，网站为每一个访问者赋予一个唯一的ID，并将这个ID以文本的形式写入用户本地，这个文本就是Cookie。

笔者最早接触这项技术已经是18年前了，当时笔者所在公司的主要业务是网站运营和企业建站。笔者有幸参与了一个澳洲购物的电商网站开发，那时候，公司小、团队分工也不明确，一个人要干N个人的活，但真的很锻炼人，网页设计、裁图、前台页面、后台程序都摸了一个遍。因此，也摸清了互联网公司记录用户信息的技术和手段。

实际上，从用户第一次访问网站开始，无论浏览的是哪个页面都会调用网页的一个脚本程序，这个程序给访问者定义一个唯一ID并写入到Cookie中，之后用户的一些关键操作都可以记录Cookie中，例如：加入购物车、下单等。互联网网站就是通过Cookie来进行用户的身份鉴别和跟踪会话。

这项技术一直沿用至今，它为互联网公司收集和积累用户信息，建立标签体系、实现用户画像起到了重要的作用。

后来，随着智能手机的兴起，移动互联网的时代来了，人们访问网站的渠道更加丰富和多样。在移动互联时代，对用户ID的识别，不再是单一的Cookie，而是不同类型设备的ID，例如：Android设备的唯一编号（IMEI，MEID，ESN，IMSI），IOS系统的设备的唯一编号（UDID、UUID）等。同时，不同APP的用户登陆ID也不同，例如：手机号、电子邮箱、用户名等。

互联网公司为了数据的最大化利用，就需要将这些不同渠道、不同来源的“ID”进行统一拉齐和打通，将PC时代累计下的数据资产进行跨渠道共享，从而实现用户的精准画像、多渠道触达和智能推荐。数据中台的OneID体系干的就是这个事情，为数据资源的最大化利用奠定了基础。例如：阿里数据中台就是基于OneID技术，实现了消费端、广告端、支付端、娱乐端等业务板块用户ID的打通，并通过这个统一 ID，关联起各个孤岛的数据，实现数据通融，进一步实现完整的用户画像和准确的数据应用。这就有了你在百度上搜索了“养生”，到淘宝网站上就会给你推荐“枸杞”。

— 03 —

OneID和主数据的实现原理

OneID是对不同渠道、不同来源的的“ID”进行统一拉齐和打通，其实现原理如下：

为了方便理解，这里给出的例子是比较简单的，但在实际实施过程中，其应用要复杂很多，例如：相同ID的值不一致怎么办，重复的ID如何合并，ID信息发生变化如何更新，Mapping表的更新频率如何设置等等，这些问题就需要结合具体场景解决了。

我们再来看看主数据管理（MDM）的工作原理：

主数据管理强调在源头治理，即：在数据源系统定义实现主数据的标准化，生成唯一主数据编码，并通过主数据系统分发标准数据到相关消费系统进行使用，消费系统只有查询和使用权不能对主数据进行“增删改”。另外，不同主数据的来源系统不同，如在这个例子中的客户主数据来源为CRM，物料主数据的来源为MDM，ERP系统和数据仓库是主数据的消费系统。

— 04 —

有了数据中台，还需要主数据吗？

在很多数据中台的解决方案中，主数据是数据中台的一个组成部分。例如在SAP的数字平台解决方案中，数据中台是由数据集成、数据存储、数据仓库、开发建模、数据资产管理、数据管控、人工智能与行业模版等多个部分组成。其中，数据管控模块中就包含了主数据治理，如下图：

图：SAP 数字平台解决方案（来源：SAP天天事）

不止SAP，很多厂商的数据中台解决方案中都能够看到主数据的身影，如元年、袋鼠云等。

很多人都有个疑问，数据中台中既包含了数据采集/数据移动的能力，也包含数据服务共享的能力，同时还具备元数据、数据质量、数据安全等数据治理能力，有了数据中台，为什么还需要主数据管理？

数据中台通过数据采集、清洗、治理，再以标准接口服务的形式提供出去，供其他系统调用，这确实是数据中台的核心能力。从功能的角度，主数据管理也的确有类似的功能，例如：主数据采集、主数据清洗、主数据服务等。

但是，我们之前也说过，主数据与数据中台解决的问题并不相同。

数据中台是在有了数据之后，在中台进行数据治理，形成数据资产并提供数据服务。而主数据更强调在数据产生之前定义数据标准，建立数据管理流程，并在数据产生的过程中对数据质量进行校验，从源头进行数据治理。

因此，相对于数据中台来讲，主数据管理是一个后台系统，它可以作为数据中台的一个数据源为数据中台供应高质量的数据。

设想一下：如果没有主数据管理，从各个异构系统中采集到数据中台的主数据（如：客户、产品、供应商等）将有不同的定义和编码，这就需要在数据中台对这些不一致的数据进行统一治理，这将是一件非常痛苦的事情，而且不能从源头上解决问题。因此在笔者看来，站在整体解决方案的角度，将主数据治理提前，对于传统企业来讲可能是不错的解决方案。

写在最后的话

广义理解OneID，是指一个数据对象有且仅有一个ID。在本质上，OneID解决的问题和主数据编码其实是一样的，都是定义数据对象在一定数据环境下的唯一身份。它们是在不同的应用场景下（ToC或ToB），采用的两个不同技术架构（OLAP或OLDP）的解决方案！

举个不太恰当的例子，就如同我们饿了去吃饭一样，不论是吃中餐还是吃西餐，不论用刀叉还是用筷子，最终目的都是解决饥饿问题。但是，吃中餐的时候我们一般用筷子，而吃西餐的时候一般用刀叉。当然，你用刀叉去吃中国火锅也没问题，只要你不嫌麻烦。同样，你用OneID去解决主数据问题或者你用主数据解决OneID问题，都会一样麻烦！