前言?
主數據被普遍定義為組織/系統間共享的描述業務實體的數據， 屬性相對穩定， 變化緩慢。

主數據管理是對為了保證主數據的質量（準確性，完整性）和合理使用而建設或者實施的制度， 流程、系統。主數據管理不是一個單一的短期項目，而是一個長期的，貫穿整個企業發展歷程的一系列的活動。

比較早關于主數據的討論起源與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部門可以承擔起對應主數據的權責。

主數據管理成功的目標
屆時，各主數據都有歸屬的業務線上系統（含對應的業務負責人，產品，技術負責人），所有的變更都在對應的業務系統中實施，其他系統需要就實時調用對應業務系統。

標準就是，當大家不再頻繁提起主數據管理（治理）時，就是主數據管理成功之時。筆者在互聯網行業從業多年，極少聽到主數據一詞。