主數據方法論之數據分發與共享

主數據方法論之數據分發與共享

當筆者介紹主數據流轉步驟的時候，突然想起了宋丹丹小品中的提到的一個問題，大象裝進冰箱裏，一共分幾步？打開冰箱，裝進大象，關上冰箱。主數據在主數據管理體系內的流轉也一樣分紅三步，找到數據源頭，把數據存儲在主數據系統中，而後再從主數據系統中分發出去。如何把大象裝進冰箱中，是第一個場景中的問題難點。而在主數據流轉過程當中，最體現價值的是數據的分發與共享過程。若是咱們購買了主數據管理系統，但是各類副本數據依然我行我素，那主數據管理的價值就大打折扣了。之因此咱們強調主數據管理體系，強調行政組織保障和管理規範，最終的目的就是保證副本數據與主數據的一致。

這篇文章談論主數據分發共享工做中的三個問題。第一，數據如何傳遞。第二，應用系統獲取數據後應當如何處理。第三，如何經過技術手段監督副本數據質量。

問題1、主數據的傳遞：

Ø 方式一：數據推送

將主數據推送到應用系統中，數據全部者爲主動方，數據分享者爲被動方。此種方式，是由MDM或者企業服務總線主動的將數據推送到應用系統中。按照面向服務設計理念，應用系統須要開發出一個可以接收主數據的服務，這樣數據推送方在進行數據推送的時候就可以調用這個服務將數據傳遞給應用。與以往的數據推送方式不一樣，數據推送者並不關心數據接收者的具體業務邏輯處理，它只負責把數據交給應用，至於應用如何處理都交給接受者處理。此種方式的特色是：數據實時性較強，主數據一發生變更就可以把變更信息廣播到體系內的各個角落，而沒一個副本數據擁有者都可以在第一時間發生調整。對於數據傳遞異常的狀況，數據推送方作處理，數據若是沒有推送成功，那麼主動方將決定異常的處理方式。好比，重新推送，或者過段時間再次推送或者直接改成手工處理。

Ø 方式二：數據靜態獲取（拉式）

主數據源頭髮布數據獲取服務，靜等副本數據擁有者來獲取數據。主數據將沒有第三方有權限的數據所有暴露出來，等待第三方使用者來調取。主數據源頭通常須要提供獲取所有數據，獲取單條數據，獲取某個時間點後的全部最新數據等服務，而數據調用方須要本身編寫代碼獲取數據。通常須要支持自動定時獲取和手動同步等模式。數據靜態獲取方式較爲穩定，而且把異常處理的工做交由第三方來完成，若是第三方支持手動獲取方式，那麼數據傳遞的準確性就大大的獲得了保證。只是此種方式數據實時性較差，一般系統都將同步時間設置爲一天左右。

Ø 方式三：在底層數據庫層面進行數據拷貝

面向服務的應用集成方式是用友應用集成的特色和亮點，可是在長期的實踐過程當中，咱們發現形而上學纔是最大的問題，面向服務要知其然還要知其因此然。因此在筆者最新的項目中打算採用ETL工具將主數據管理系統的主數據表在每一個副本數據庫中都創建一個實時映射的對照表。這樣每一個系統就不須要在費力的開發webservice，並且要考慮推送和拉取的方式了。數據直接傳到應用的數據庫中，第三方應用的開發難度下降很多。須要強調的是，這個方案中絕對不對操做第三方系統中的任何表，只是把數據存儲在了新建的幾個表中。這個有點像是供應鏈中的一種模式，供應商並不等待收到甲方的採購單再發貨，而是直接在甲方的生產車間創建本身的倉庫，甲方隨用隨取。

問題2、應用系統獲取主數據後的處理：

從主數據管理的角度看，各個應用系統中的基礎數據是標準數據的副本數據，然而這些數據在各自的業務系統中都有本身的定義和定位，這就必然致使了這些基礎數據可能存在須要獨立維護的私有字段和私有數據。例如：

n HR系統中的黨員屬性和專業軍人屬性，這個屬性沒有出如今主數據標準中，可是在人力資源管理系統卻又專門對應的模塊管理和維護。

n 帳號主數據中有100條記錄，而在某個應用系統中還須要其餘可以進行系統的帳號，那麼這個系統就應該在這100條記錄以外獨立維護被系統所需的其餘帳號信息。

只有有效的區分主數據的影響範圍和私有字段，私有數據的做用範圍纔可以即享受到主數據管理帶來的便利又保證了系統業務的獨立性。

問題3、經過技術手段對副本數據質量進行監控：

若是可以在主數據管理系統中存儲副本數據，而且保證副本數據與數據源準相同，那麼咱們就能夠輕易的進行副本數據與主數據一致性的監控了。這樣作的好處很是明顯，能夠有效提升企業主數據管理質量。將大量線下的和有業務反推完成的數據共享工做利用極小的成原本完成。雖然理論上在設計好主數據管理體系後，數據都會在各個系統中自動共享。可是這樣的監控體系就好像是在給應用系統作測試同樣，讓咱們感到對整個體系的放心。

若是當前的主數據管理系統可以融合這部分功能，必然可以成爲產品亮點之一。