如何区分数据仓库oneID和主数据

在了解 OneID 之前，得先说说阿里的 OneData 体系。其实 OneID 在整个数据服务体系里，只能算是个起点，甚至可以说是个手段——我们最终的目标，是要建起一套统一的数据资产体系。

在没有这套体系之前，数据建设普遍面临几个绕不开的坑：

1. 数据孤岛——各产品、各业务的数据相互隔离，彼此之间很难通过一个共性的 ID 打通。
2. 重复建设——同样的数据反复开发、反复计算、反复存储，成本高得吓人。
3. 数据歧义——同一个指标，口径不同，算出来的结果天差地别，应用起来更是举步维艰。

在阿里 OneData 体系中，OneID 承担的使命是“统一数据萃取”，本质上是一套用来打破数据孤岛的思路和方法。数据孤岛这玩意儿，几乎是每个企业发展到一定阶段都会撞上的墙——各个部门、业务、产品各自定义和存储数据，彼此之间老死不相往来，真正成了孤岛。

OneID 的思路很直接：通过统一的实体识别和连接，把数据孤岛打通，实现数据的融会贯通。简单说，用户、设备这些业务实体，在各自的业务数据里会有一个唯一识别（UID），而 OneID 要做的，就是把各个维度的数据通过这个 UID 串起来。

问题在于，各个部门、业务、产品对 UID 的定义和实现方式各不相同，这就导致数据之间没法直接关联，数据孤岛就这么产生了。OneID 的做法是，基于手机号、身份证、邮箱、设备 ID 这些信息，再结合业务规则、机器学习、图算法等手段，进行 ID-Mapping，把各种各样的 UID 统统映射到一个统一的 ID 上。有了这个统一 ID，各个数据孤岛之间的数据就能打通了，业务分析、用户画像这些应用才能做到既准确又全面。下面咱们就好好聊聊主数据和 OneID。

— 01 —

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

在阿里 OneData 体系里，OneID 被定义为“统一数据萃取”，是一套解决数据孤岛问题的思想和方法。

说实话，光看这个定义，估计不少人会懵。什么叫数据萃取？解决数据孤岛问题，主数据不也是干这个的吗？

别急，咱们慢慢拆解。先看 OneID 到底是干啥的。

OneID 其实就是 ID-Mapping。把设备 ID（比如手机 MAC、IMEI、IMSI 这些）、手机号、身份证号、邮箱地址、PC 端的 Cookie、用户名，结合标签体系、知识图谱、机器学习这些技术和算法，统统映射到一个统一的 ID 上。换句话说，不管用户用什么 ID 登录，不管登录的是电脑端还是手机 APP，系统都能识别出他的唯一身份。

这事儿听起来是不是跟主数据有点像？主数据也是给数据对象赋予一个唯一的编码（身份）。

不过，两者还是有明显区别的：

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

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

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

— 02 —

数据中台为什么需要 OneID？

但凡接触过企业数据平台的人都会知道，数据孤岛是企业发展到一定阶段后几乎绕不过去的坎。内部的各个部门、业务、产品各自定义和存储数据，数据之间互不相通，想发挥业务价值？难上加难。

普遍存在的数据孤岛现象，各部门用的平台不同，且数据不相通。

OneID 的建立，就是为了打破这种僵局。通过打通分散在各个平台的用户数据，整合客户全生命周期的旅程，让各平台的数据真正实现融会贯通，从而提升业务效率和用户体验。

OneID 的业务价值和数据管理价值

业务价值：通过 OneID 贯穿客户生命周期，精准识别客户行为——浏览、留资、到店这些行为轨迹一清二楚。这就相当于为每一位用户量身定制了一张完整的“身份 + 行为”名片，为广告定投、精准推送、个性化推荐、增换购、流失预警等营销场景，以及精准客户数据分析、精准人群定位、精准圈层运营、经销商客户信息溯源等精益化运营需求，提供了扎实的支持。

数据管理价值：业务价值侧重于对外带来的营销便利和利润增长，数据管理价值则侧重于对内形成的“互助”作用。OneID 的构建有助于沉淀数据资产，便于数据管理、数据资产的可视化和可评估化。同时，OneID 还能为 CDP 平台、数据中台等其他平台提供支持。

说到底，OneID 的构建目的只有一个：支撑各业务方的管理决策和应用落地，最终提升业务效率和客户体验，确保数据应用的准确性和全面性。

— 03 —

OneID 和主数据的实现原理

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

这里给出的例子相对简单，方便理解。但在实际实施过程中，情况要复杂得多。比如相同 ID 的值不一致怎么办？重复的 ID 如何合并？ID 信息发生变化后怎么更新？Mapping 表的更新频率该如何设置？这些问题都需要结合具体场景来解决。

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

主数据管理强调源头治理——在数据源系统定义和实现主数据的标准化，生成唯一的主数据编码，再通过主数据系统将标准数据分发给相关消费系统使用。消费系统只有查询和使用权，不能对主数据进行“增删改”。另外，不同主数据的来源系统也不一样——比如客户主数据可能来自 CRM，物料主数据来自 MDM，而 ERP 系统和数据仓库则是主数据的消费方。

— 04 —

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

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

不少人会问：数据中台既有数据采集和移动能力，也有数据服务共享能力，还能做元数据、数据质量、数据安全这些治理工作，那为什么还需要主数据管理？

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

但关键在于，主数据与数据中台解决的问题并不相同。

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

从这个角度看，主数据管理更像是一个后台系统，可以作为数据中台的一个数据源，给它提供高质量的数据。

试想一下：如果没有主数据管理，从各个异构系统采集到数据中台的主数据（比如客户、产品、供应商），将带着五花八门的定义和编码。到那时候，再在数据中台里对这些不一致的数据进行统一治理，那将是一个非常痛苦的过程，而且根本没法从源头上解决问题。所以从整体解决方案的角度来看，把主数据治理提前——对传统企业来说，可能是更靠谱的选择。

— 05 —

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

主数据的核心目的，是在单一业务领域中，实现各系统之间核心数据的统一。关键词有两个：业务系统和统一。

OneID 的核心目的，是跨业务领域的数据连通。关键词也有两个：跨业务领域和连通。

所以，OneID 更像是放大版本的主数据，而主数据则可以看作是一套为 OneID 提供高质量输入的基础设施。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：如何区分数据仓库oneID和主数据要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题