一、 參考數據與主數據

最近湊巧參與了一次某行業的業務共創會議，期間討論到了主數據系統，還有我們該如何參與主數據系統建設的話題。說實話，我一直以為我不會有機會參與到主數據與參考數據系統的話題中去，所以，又去把DAMA的書籍翻了翻。順便也重新思考了一下主數據與參考數據這個數據治理的課題。

1. 基本定義

在DAMA指南中對主數據和參考數據的基本定義如下：

參考數據和主數據管理是對參考數據和主數據進行持續的協調一致和維護工作。

參考數據管理是對定義的數據域值（也稱為詞匯、術語）進行控制，包括對標準化術語、代碼值和其他唯一標識符一級每個取值的業務定義的控制，和對數據域值列表內部和跨不同列表之間的業務關系的控制；并且對準確、及時和相關參考數據值的一致、共享使用進行控制，以進行數據分類和目錄整編。

主數據管理對主數據值進行控制，以時序跨系統的一致、共享、上下文相關地使用主數據，以及對核心業務實體的真實情況的最準確、集市和相關的版本進行控制。

這段話，大部分人其實看了有點懵。換個簡單的說法：主數據管理就是管理交易系統中的各種核心活動對象實體（常見的對象有組織、個人、產品等）在一個大型組織內部的一致性，參考數據管理就是管理交易系統中各種實體的屬性的定義（代碼值或者枚舉值）的一致性。

2. 簡明定義

在DAMS中國數據智能管理峰會的官網一篇文章中這樣簡明的描述了主數據管理和參考數據管理，內容如下（引用文章地址在本文最后）。

主數據--企業黃金數據記錄

主數據（master data）主要是指經實例化的企業關鍵數據。

如上圖，我們在上面設計完成數據模型設計的“城市表”中填寫了相應的城市數據，例如，北京、上海、廣州、南寧等等。這些在城市表中填充的數據，正是組織中國地理協會的主數據，因為這些數據是中國地理協會這個組織的關鍵業務實體，它為組織的業務開展提供關聯環境，而且它可能在企業業務開展過程中被反復引用。針對這些核心關鍵數據，組織和企業無論從數據的質量、一致性、可用性、管理規范等方面都應該有著最嚴格的數據要求。

那么一般而言，以下涉及企業經營的人、財、物的數據最有可能納入企業主數據管理的范疇，例如：

企業產品及其相關信息：包括企業相關產品、服務、版本、價格、標準操作等等；

企業財務信息：包括業務、預算、利潤、合同、財務科目等等 ；

企業相關利益相關者：如客戶、供應商、合作伙伴、競爭對手等；

企業組織架構：如員工、部門等；

可見，主數據就是企業被不同運營場合反復引用關鍵的狀態數據，它需要在企業范圍內保持高度一致。它可以隨著企業的經營活動而改變，例如，客戶的增加，組織架構的調整，產品下線等；但是，主數據的變化頻率應該是較低的。所以，企業運營過程產生過程數據，如生產過程產生各種如訂購記錄、消費記錄等，一般不會納入主數據的范圍。當然，在不同行業，不同企業對主數據有不同的看法和做法，正如我們與國內大型航空企業的實施相關數據項目時，也在為航班動態是不是主數據而糾結不已。

因此，有鑒于主數據對于企業的重要性，企業和組織需要對其主數據進行有效的管理：包括理解主數據應用需求，識別主數據來源及源頭，梳理主數據上下游關系，數據整合和發布，提升主數據的數據質量等。

參考數據-數據的字典

在本文引用的假設案例中，我們將會注意到剛才填寫的地市這類數據有些列，如省份、城市類型等。如果沒有缺少上下文的環境，我們是無法理解其具體含義，這時候我們往往引入參考數據（reference data）加以解釋和理解，如下圖紅色標注所示。

參考數據是增加數據可讀性、可維護性以及后續應用的重要數據。例如，你看到“性別”的這個字段，很可能是1代表男性、2代表女性。在許多企業中有這樣的約定俗成，而更多的參考數據可能記錄在開發人員和運營人員的大腦當中。但問題是一旦這些人離開，您系統里面的數據就成了一堆沒有注釋的天書。

大家可能覺得，這所謂參考數據不就是數據字典嗎？對，我們在很多系統里面都會有這樣和那樣的數據字典。但是正是由于這些數據字典局僅限于個別系統而沒有統一標準，從一個側面間接造就了大量的數據孤島。企業為了進行更有效率的數據整合、數據共享和數據分析應用，開始嘗試對參考數據進行企業或者部門層面的整合和管理，利用參考數據集記錄系統嘗試為范圍內的IT系統中的數據庫提供統一的參考數據。

l 小結

主數據則是真實的企業業務數據，是企業的關鍵業務數據。

參考數據則是對數據的解釋，針對一些數據范圍和取值的數據解釋，讓人們容易讀取相關的數據。

3. 驅動因素

在任何組織中，都存在一些需要跨業務領域、跨系統使用的數據。如果這些數據實現了共享，所有的業務部門就可以訪問相同的客戶清單、地理位置代碼、業務不么清單、交付選項、部件清單、成本核算中心代碼、政府稅收代碼以及用于運營業務的其他數據，那么整個組織及其客戶都會從中受益。數據使用者在看到不一致的數據之前，通常會建設這些數據在整個組織中具有一定的一致性。

在大數據多組織中，系統和數據的變化速度比數據管理專業人員所希望的要快。特別是大型組織中，各種項目和方案、合并和收購以及其他商業活動導致存在多套在本質上作業相同的系統，它們相互隔離，無法溝通。以上這些情況不可避免地導致了系統間數據結構和數據值的不一致，從而增加了成本和風險。組織可以通過對參考數據和主數據進行管理來降低成本和風險。

參考數據管理和主數據管理都是專門的數據質量改進規劃，依賴有效的數據管理制度和數據治理活動。是一項持續的質量改進計劃才能獲得成功，不可能畢其功于一役。

參考數據和主數據質量改進計劃的成本和復雜性由業務驅動決定，常見的業務驅動因素是：

a) 跨數據源、應用和技術的條件下提升數據治理和整合度。

b) 對于重要的業務相關方、角色和產品提供綜合的360度視圖，特別是提供更有效的報表和分析。

參考數據和主數據管理的目標包括：

a) 確保組織在各個流程中都擁有完整、一致、最新且權威的參考數據和主數據。

b) 促使企業在各個業務單元和各個應用系統之間共享參考數據和主數據。

c) 通過采用標準的、通用的數據模型和整合模式，降低數據使用和數據整合的成本及復雜性。

二、 與其他系統關系

1. 現實情況

理論上在聯機事物處理（OLTP）系統和數據倉庫及商務智能系統都存在參考數據和主數據管理。理論上組織內所有的聯機事物處理（OLTP）系統都使用相同的黃金記錄和數據值，實際上在所有的大型企業內部跨交易系統環境中都存在不一致的參考數據和主數據。這不僅需要數據倉庫系統來確認最真實的記錄系統，同時還有確定最準確的參考數據和主數據。數據倉庫構建構成中要花很大的代碼用于清晰和整合不同來源的主數據，或者在數據倉庫和商務智能環境中使用維度表維護主數據和參考數據，而不是在主操作系統數據庫中維護并復制到其他業務數據庫和數據倉庫中。

如上所述，理論上參考數據和主數據管理是在聯機事物處理（OLTP）系統層面需要去治理和解決的問題，但是實際上很多時候在數據倉庫與決策分析系統使用數據的時候才會花很大的代價去解決。

如下所述，這是《數據倉庫》一書中對數據轉換和集成復雜性的描述。這些多源不一致的描述在數據倉庫中去解決并不是從根本上解決了不一致的問題，只是利用這個整合的平臺進行了一次表面上的掩蓋，并未真實從源頭解決主數據和參考數據的一致性與質量問題。

轉換和集成的復雜性

a) 存在多個輸入數據源。在某些情況下數據倉庫中數據項的來源是一個文件，而在另外一些情況下，則為另外一個文件。邏輯上必須分清楚，以便由適當的數據源提供正確條件下的數據。

b) 當存在多個輸入文件時，進行文件合并之前要首先進行鍵碼解析。這意味著如果不同的輸入文件使用不同的鍵碼結構。那么，完成文件合并的程序必須提供鍵碼解析功能。

c) 當存在多個輸入文件時，這些文件的順序可能不相同甚至互不相容。在這種情況下這些輸入文件需要進行重新排序。當有許多記錄需要進行重新排序時可能有些困難，但可惜的是，通常都是這種情況。

d) 存在多個輸入數據源。在某些情況下數據倉庫中數據項的來源是一個文件，而在另外一些情況下，則為另外一個文件。邏輯上必須分清楚，以便由適當的數據源提供正確條件下的數據。

e) 當存在多個輸入文件時，進行文件合并之前要首先進行鍵碼解析。這意味著如果不同的輸入文件使用不同的鍵碼結構。那么，完成文件合并的程序必須提供鍵碼解析功能。

f) 當存在多個輸入文件時，這些文件的順序可能不相同甚至互不相容。在這種情況下這些輸入文件需要進行重新排序。當有許多記錄需要進行重新排序時可能有些困難，但可惜的是，通常都是這種情況。

2. 層次關系

從上一部分的介紹可以了解到，參考數據和主數據管理是涵蓋數據產生的“聯機事物處理（OLTP）系統”和“數據倉庫及商務智能系統”的。但是應該是在“聯機事物處理（OLTP）系統”這個層次去解決，并把標準化的數據同步給“數據倉庫及商務智能系統”去使用。

作為一個做數據倉庫的數據研發人員，我其實一直都認為參考數據和主數據管理是“聯機事物處理（OLTP）系統”（業務系統）范圍內的事情，而不是分析型系統需要去實施的。很多時候如果所服務的企業內部有參考數據和主數據管理系統，做了參考數據和主數據管理，對于我的“數據倉庫及商務智能系統”工作來說是大大有益的。雖然很多時候這個主數據和參考數據的識別和標準化的工作，會被帶到數據倉庫與商務智能環境中來解決，但是從數據使用者的角度來看還是希望在底層解決。

之前服務過的某銀行在08年實施了“統一客戶管理系統”，實現了銀行間多個業務系統的唯一客戶識別，并對不同系統的遺留客戶的歸一做了識別。這是我接觸過的一個主數據識別的業務系統，這個系統解決了銀行之前個貸、理財、基金等多個業務系統的客戶唯一識別。但是，后來我還是遇到了一個個人信息是以個貸的個人信息為準還是信用卡的個人信息為準的主數據識別的問題。是組合著來還是以某個為準，真是難以入目。個貸的數據是一個歷史數據，都是在辦理貸款業務的時候錄入的，這個信息相對要準確真實，但是如果這是一筆10年前的貸款，這些數據可能早就不能使用了。信用卡的數據一般比較新，更新也相對頻繁一點，但是信用卡的數據質量可能不太好，可信度要低一些。這是數據倉庫能解決的問題么？同一個信息不一致的情況下，不管使用哪個數據都是猜的。我本人看了一些業務人員給的規則計算后的結果，只能說湊合著用吧，也沒得選（我的選擇最后就變成了數據倉庫中的用戶主數據信息）。這也是參考數據和主數據系統建設的重要意義，如果從源頭解決這個問題，何必這么為難。

主數據的問題其實非常廣泛。在稅務領域，我們遇到了不同企業在異地注冊的識別問題。多地注冊企業是否一個企業的問題，在缺乏主數據系統的情況下這個問題回答的極為艱難。在公共安全領域，不同個人使用不同證件在多個不同場合，如何識別是同一個個人的問題，也是非常有挑戰。所以，在業務系統這層做好主數據系統，真是非常的必須。

3. 與中臺關系

數據中臺概念和阿里提出ONEID概念后，突然間整個數據治理的事情都是阿里中臺化的革命使命了。所以，我們在越來越多的項目中遇到了參考數據和主數據管理的事情。

談到阿里的主數據管理，一定會提到ONEID的概念。阿里的ONEID是給阿里系的諸多APP識別同一個用戶的一套個人身份識別的規則算法，如果對應在主數據管理系統中應該是對應“匹配規則”這個概念。在《DAMA數據管理知識體系指南》8.2.7章節中指出“主數據管理在未來面臨的最大挑戰是在多個系統中對于通一個人、群組和事物的數據進行匹配、合并、連接”。ONEID的實現與純在交易型系統去解決主數據問題有一些形式上的區別：第一，ONEID是根據實際業務需求提出的主數據數據治理的一個小應用，而不是主數據管理系統，其覆蓋的范圍是傳統主數據管理的“客戶數據”。第二，ONEID的實現利用了數據倉庫和機器學習與算法規則，是一種相對交易規則更加復雜的規則算法，是一種事后（數據倉庫和商務智能）與事前（聯機事物處理（OLTP）系統）共用的相對弱規則。

從數據中臺和業務中臺拆分的角度來看，主要從事數據中臺工作的我對主數據和參考數據管理這個領域的劃分還是在業務中臺，不是自己的日常工作范圍。因為業務中臺的概念提出后，就提出了業務中心的概念。像“用戶中心”、“產品中心”、“參數中心”這種中心化的業務系統全局設計，已經可以從根本上解決了主數據的企業級標準化的問題。

但是從實現的角度來說，只有少量大型企業能把全局的業務系統全部重構一遍？大多是漸進式和改造式。何況很多大型企業還有很多收購公司與關聯公司，很難做到覆蓋全面的管控。所以，主數據管理和參考數據管理，還是我們眼前大型企業必備核心數據治理工作。只是我們是否能利用當前技術上的更多的進步，來改善我們的治理工作實施方法和治理效果。

從另外一個角度來看，數據倉庫或者數據中臺所面臨的數據整合的問題其實也是主數據和參考數據的問題。我們在數據倉庫中構建了全局一致的業務模型，實現了數據中臺中數據倉庫級別的主數據和參考數據識別，并以此向下游的數據集市發布了數據倉庫中甄別的主數據和參考數據。很多參考數據和主數據系統本身就有數據模型管理、數據采集、實體解析、數據共享等工作，其實很多時候也是利用數據倉庫平臺來實現的（或者自己構建了一個小型數據平臺）。只是從最終服務對象上來說，服務的系統是主數據和參考數據管理系統。

看了兩個傳統的MDM系統供應商，STIBO SYSTEMS(思迪博)和IBM。從這兩個公司對MDM系統的介紹來看STIBO SYSTEMS(思迪博)似乎在行業能力上更加領先，介紹也更加傳統第一眼看到的是其涉及多領域的能力。IBM似乎更注重宣傳功能，介紹諸如自助訪問、更深入的洞察、同意管理、使用直觀的儀表板來更主動地管理數據。總的來說，感覺落地一套這種系統從交付角度來說難度會非常有挑戰，需要非常厚的行業沉淀，需要日積月累的持續的協調推進這個數據治理活動。我一直記得曾經坐在我對面的一個負責數據治理的同事，好像一年搞的事情就是幾張代碼表，我也不知道她最后搞完了沒有。對于做這個事情的同事，我覺得心態一定要平穩，做好持續推進的運營計劃，不用想著一次性解決問題，這樣才能把事情做成。