今天在解釋下主數(shù)據(jù)和數(shù)據(jù)中臺的區(qū)別。對于主數(shù)據(jù)和數(shù)據(jù)中臺我在頭條前面文章都有專門的描述，可以先參考下我前面發(fā)布過的文章。今天重點還是解釋下兩者的區(qū)別。

在講解區(qū)別下，還是先看下兩個概念的定義。

主數(shù)據(jù)概述

主數(shù)據(jù)是描述核心業(yè)務(wù)實體（如客戶、供應(yīng)商、地點、產(chǎn)品和庫存）的一個或多個屬性。所以主數(shù)據(jù)即是在進行企業(yè)業(yè)務(wù)架構(gòu)分析中發(fā)現(xiàn)的核心業(yè)務(wù)對象。或者講主數(shù)據(jù)是企業(yè)已經(jīng)存在的涉及到價值鏈核心業(yè)務(wù)流程的各個IT系統(tǒng)的基礎(chǔ)數(shù)據(jù)。

對于主數(shù)據(jù)一般來說具備如下三個特征。

其一是靜態(tài)基礎(chǔ)數(shù)據(jù)

其二是變化不頻繁

其三是一般跨多個業(yè)務(wù)流程或系統(tǒng)使用

對于ERP系統(tǒng)客戶，供應(yīng)商，物料，BOM，產(chǎn)品，合同，訂單等都應(yīng)該是最基礎(chǔ)的數(shù)據(jù)，對于項目管理系統(tǒng)而言項目信息，WBS信息則是最基本的基礎(chǔ)數(shù)據(jù)。而對于CRM系統(tǒng)則客戶，銷售項目是最基本的基礎(chǔ)數(shù)據(jù)。基礎(chǔ)數(shù)據(jù)要上升到主數(shù)據(jù)的高度還有一個條件，即該數(shù)據(jù)產(chǎn)生在一個基礎(chǔ)IT系統(tǒng)中，但是會在多個其它的IT系統(tǒng)中使用到。

對主數(shù)據(jù)進行管理的系統(tǒng)即是主數(shù)據(jù)系統(tǒng)。

傳統(tǒng)IT架構(gòu)下如何建設(shè)MDM系統(tǒng)？

簡單來說就是傳統(tǒng)IT架構(gòu)下，各個業(yè)務(wù)系統(tǒng)使用的基礎(chǔ)數(shù)據(jù)不統(tǒng)一，這些數(shù)據(jù)可能是各個業(yè)務(wù)系統(tǒng)都在自己創(chuàng)建，自己管理。導(dǎo)致基礎(chǔ)數(shù)據(jù)重復(fù)，基礎(chǔ)數(shù)據(jù)不統(tǒng)一，而基礎(chǔ)數(shù)據(jù)本身又是核心業(yè)務(wù)數(shù)據(jù)，比如訂單，合同等的關(guān)鍵引用信息。

基礎(chǔ)數(shù)據(jù)不統(tǒng)一，數(shù)據(jù)不一致，直接到了核心業(yè)務(wù)協(xié)同出現(xiàn)問題。

舉個簡單的例子來說，你在采購系統(tǒng)里面制作了一個采購訂單，準(zhǔn)備通過接口導(dǎo)入到ERP系統(tǒng)中。但是在導(dǎo)入的時候卻出現(xiàn)異常，原因是訂單明細(xì)中的物料基礎(chǔ)數(shù)據(jù)，在ERP系統(tǒng)中當(dāng)前處于失效狀態(tài)。這就是典型的基礎(chǔ)數(shù)據(jù)信息不一致導(dǎo)致的業(yè)務(wù)協(xié)同問題。

也正是這個原因，很多企業(yè)開始規(guī)劃建設(shè)MDM系統(tǒng)，實現(xiàn)對主數(shù)據(jù)的統(tǒng)一管理。這個統(tǒng)一管理實際上包括了集中式管理和共享式管理兩種方式。

在集中模式下，主數(shù)據(jù)的申請，創(chuàng)建，變更，分發(fā)全生命周期全部納入到MDM系統(tǒng)進行管理。而在共享模式下，一般來說主數(shù)據(jù)源頭還是在業(yè)務(wù)系統(tǒng)中，MDM系統(tǒng)只負(fù)責(zé)進行數(shù)據(jù)抽取和清洗，形成統(tǒng)一視圖后進行數(shù)據(jù)分發(fā)。

數(shù)據(jù)中臺概述

首先我們看下數(shù)據(jù)中臺常用的一個定義：

數(shù)據(jù)中臺是一套可持續(xù)地讓企業(yè)的數(shù)據(jù)用起來的機制，是一種戰(zhàn)略選擇和組織形式，是依據(jù)企業(yè)特有的業(yè)務(wù)模式和組織架構(gòu)，通過有形的產(chǎn)品和實施方法論支撐，構(gòu)建的一套持續(xù)不斷的把數(shù)據(jù)變成資產(chǎn)并服務(wù)于業(yè)務(wù)的機制。數(shù)據(jù)來源于業(yè)務(wù)并反哺業(yè)務(wù)，不斷的迭代循環(huán)，實現(xiàn)數(shù)據(jù)可見，可用和可運營。

對于業(yè)務(wù)中臺相對來說比較好理解，簡單一句話就是共性業(yè)務(wù)能力下沉形成的多個微服務(wù)化的業(yè)務(wù)能力提供中心供上層應(yīng)用使用。而對于數(shù)據(jù)中臺，我們也可以總結(jié)為一句話就是，把數(shù)據(jù)變成資產(chǎn)并服務(wù)于業(yè)務(wù)的機制。數(shù)據(jù)來源于業(yè)務(wù)并反哺業(yè)務(wù)，不斷地迭代循環(huán)。

數(shù)據(jù)中臺是實現(xiàn)業(yè)務(wù)中臺核心共享數(shù)據(jù)的跨域整合，再通過加工后提供整合后的數(shù)據(jù)服務(wù)能力。這里面有兩個重點，即第一數(shù)據(jù)要跨域整合，第二數(shù)據(jù)要加工處理后再提供增值服務(wù)能力，這個加工可能簡單的匯總表，也可能是復(fù)制的底層數(shù)據(jù)模型和智能分析算法。

業(yè)務(wù)中臺重點是業(yè)務(wù)數(shù)據(jù)化，而數(shù)據(jù)中臺重點是數(shù)據(jù)業(yè)務(wù)化，數(shù)據(jù)來源于業(yè)務(wù)又反哺業(yè)務(wù)。就建設(shè)和支撐層面來說我原來也總結(jié)過，即業(yè)務(wù)中臺是基礎(chǔ)業(yè)務(wù)能力支撐，必須要有，數(shù)據(jù)中臺是增值能力支撐，剛開始沒有也不會影響到業(yè)務(wù)本身的運作。

在上面圖里面可以基本看清楚數(shù)據(jù)中臺應(yīng)該覆蓋的四大塊內(nèi)容。即：

數(shù)據(jù)技術(shù)平臺：各種ETL，數(shù)據(jù)采集，大數(shù)據(jù)平臺，流處理等數(shù)據(jù)處理存儲技術(shù)融合

數(shù)據(jù)資產(chǎn)：數(shù)據(jù)中臺的核心

數(shù)據(jù)資產(chǎn)管理：對數(shù)據(jù)資產(chǎn)進行全生命周期的管理

數(shù)據(jù)服務(wù)：對數(shù)據(jù)資產(chǎn)的共享服務(wù)能力進行開放和共享

主數(shù)據(jù)和數(shù)據(jù)中臺的區(qū)別

在了解清楚了兩者的基本定義后，再來看區(qū)別。如下圖：

對兩者的區(qū)別點進一步說明如下：

對于主數(shù)據(jù)一般出現(xiàn)在傳統(tǒng)架構(gòu)中，在當(dāng)前的中臺和微服務(wù)架構(gòu)里面已經(jīng)很少提及主數(shù)據(jù)的概念，因此兩者實際不在一個比較的層面。

主數(shù)據(jù)在傳統(tǒng)架構(gòu)里面屬于業(yè)務(wù)系統(tǒng)，在中臺和微服務(wù)架構(gòu)下可能會被拆分為多個微服務(wù)。即原來主數(shù)據(jù)管理的物料，供應(yīng)商，人員可能會拆分中臺架構(gòu)里面的物料中心，供應(yīng)商中心，人員中心。也就是說傳統(tǒng)架構(gòu)的一個MDM系統(tǒng)本身也進行了微服務(wù)化拆分，對于不同的主數(shù)據(jù)管理能力，實際拆分為了多個微服務(wù)。

因此主數(shù)據(jù)在整個架構(gòu)演進后會轉(zhuǎn)變?yōu)闃I(yè)務(wù)中臺各個中心，這些模塊仍然屬于業(yè)務(wù)中臺內(nèi)容而不是數(shù)據(jù)中臺的內(nèi)容。

主數(shù)據(jù)在傳統(tǒng)架構(gòu)里面由于存在數(shù)據(jù)共享模式，因此一般也包括ETL，數(shù)據(jù)集成等功能。但是轉(zhuǎn)到中臺架構(gòu)后，由于在業(yè)務(wù)中臺核心是數(shù)據(jù)不落地實時開放共享，因此已經(jīng)不存在這種集成點，即老架構(gòu)里面的【1】這個點在中臺架構(gòu)中已經(jīng)不存在。

一定要注意新微服務(wù)架構(gòu)倡導(dǎo)的是數(shù)據(jù)不落地，不多點同步，這個是和我們傳統(tǒng)實施主數(shù)據(jù)，對數(shù)據(jù)進行采集，分發(fā)，數(shù)據(jù)多點落地很大的不同點。

原來主數(shù)據(jù)系統(tǒng)可能存在提供某類主數(shù)據(jù)全局視圖的數(shù)據(jù)服務(wù)能力，或者存在涉及查詢多個主數(shù)據(jù)對象后的整合數(shù)據(jù)服務(wù)能力，該部分能力在新架構(gòu)中轉(zhuǎn)移到數(shù)據(jù)中臺中的數(shù)據(jù)服務(wù)能力開放來提供，如上圖紅線部分。也就是說如果你原來規(guī)劃建設(shè)MDM系統(tǒng)本身就是全部采用共享模式，僅僅解決數(shù)據(jù)服務(wù)能力統(tǒng)一提供，那么演變到中臺架構(gòu)后，這部分能力可以完全轉(zhuǎn)移到數(shù)據(jù)中臺的數(shù)據(jù)服務(wù)層來解決。

但是對于主數(shù)據(jù)常說的主數(shù)據(jù)申請，變更，廢棄，審批流程管理等，這些是無法在數(shù)據(jù)中臺中提供的，仍然需要你在傳統(tǒng)業(yè)務(wù)系統(tǒng)或業(yè)務(wù)中臺的各個微服務(wù)中去解決。

先建設(shè)主數(shù)據(jù)平臺還是先建設(shè)數(shù)據(jù)中臺？

這是很多傳統(tǒng)企業(yè)IT架構(gòu)轉(zhuǎn)型中經(jīng)常會遇到的問題。

對于主數(shù)據(jù)我在前面已經(jīng)談到過實際解決兩個方面的問題，一個是主數(shù)據(jù)本身的申請，創(chuàng)建，變更，廢棄等內(nèi)容管理和審批流程管理。其二是形成統(tǒng)一的數(shù)據(jù)視圖，對外提供統(tǒng)一的數(shù)據(jù)服務(wù)能力。

如果你當(dāng)前的問題是第二點，那么可以不建設(shè)MDM，直接規(guī)劃建設(shè)數(shù)據(jù)中臺，由數(shù)據(jù)中臺來提供統(tǒng)一的數(shù)據(jù)服務(wù)能力。但是如果你本身數(shù)據(jù)內(nèi)容管理就沒有做好，短期也不需要實施大的微服務(wù)架構(gòu)轉(zhuǎn)型，那么還是老老實實的建設(shè)MDM系統(tǒng)。

主數(shù)據(jù)平臺和數(shù)據(jù)中臺是否共存？

可以看到，兩者完全可以共存。

在講數(shù)據(jù)中臺的時候，我們談到對于數(shù)據(jù)中臺底層實際是一個分布式的ODS庫，這個分布式ODS共享庫，既包括了基礎(chǔ)靜態(tài)主數(shù)據(jù)，也包括類似訂單，合同等需要共享的動態(tài)數(shù)據(jù)。當(dāng)存在MDM系統(tǒng)的時候，數(shù)據(jù)中臺可以直接對接MDM系統(tǒng)，即通過對MDM系統(tǒng)的數(shù)據(jù)采集和集成來形成自己ODS庫的基礎(chǔ)數(shù)據(jù)能力。