MDM主數據管理概述
主數據是描述核心業務實體（如客戶、供應商、地點、產品和庫存）的一個或多個屬性。因此主數據便是在進行企業業務架構分析中發現的核心業務對象。或者講主數據是企業已經存在的涉及到價值鏈核心業務流程的各個IT系統的基礎數據。前端
對於ERP系統客戶，供應商，物料，BOM，產品，合同，訂單等都應該是最基礎的數據，對於項目管理系統而言項目信息，WBS信息則是最基本的基礎數據。而對於CRM系統則客戶，銷售項目是最基本的基礎數據。基礎數據要上升到主數據的高度還有一個條件，即該數據產生在一個源IT系統中，可是會在多個其它的IT系統中使用到。web
企業缺少主數據管理形成的最大問題就是完整性和一致性，有些是自己主數據不完整或缺失，有些則是主數據在多個系統中存在拷貝和更新，致使數據不一致。引發企業主數據問題的重要因素之一是信息彼此隔離。在許多企業中，主數據分佈在衆多彼此隔離的系統中。客戶服務部門、生產部門以及採購部門都有各自的系統。數據庫
即便在一個業務部門裏，也有衆多前端和後端系統，這些系統包含對業務相當重要的數據，但一般狀況下沒法與其餘系統共享這些信息。正是因爲構建在各類架構之上的不兼容系統中的這種部門化數據，使得企業幾乎不可能建立和維護主數據的「單一」視圖。後端
對於原有的關於主數據管理的解決方案，一個方面是創建數據中心和數據倉庫，數據倉庫能夠極爲高效地保存系統數據。遺憾的是，數據倉庫中所包含的數據一般都通過了清理，用於分析和生成報告，所以數據倉庫是主數據管理解決方案的有益補充，但不是解決方案自己。數組
也有提出以ERP爲核心系統，其餘爲外圍系統，則ERP的基礎數據管理上升爲主數據管理。可是企業資源規劃（ERP）解決方案旨在管理特定的應用流程，一樣，這些解決方案須要使用主數據，而不是主數據管理解決方案。並且，非ERP 系統不能訪問 ERP 解決方案中的數據。安全
所以IBM的MDM提出了超越單一視圖，使用正確的視圖的新的主數據管理思路。適時地將正確的信息以正確的視圖提供給正確的對象。這纔是主數據管理（MDM）的目標。主數據管理描述了一組規程、技術和解決方案，這些規程、技術和解決方案用於爲全部利益相關方（如用戶、應用程序、數據倉庫、流程以及貿易伙伴）建立並維護業務數據的一致性、完整性、相關性和精確性。微信
主數據管理的關鍵就是「管理」。主數據管理不會建立新的數據或新的數據縱向結構。相反，它提供了一種方法，使企業可以有效地管理存儲在分佈系統中的數據。主數據管理使用現有的系統，它從這些系統中獲取最新信息，並提供了先進的技術和流程，用於自動、準確、及時地分發和分析整個企業中的數據，並對數據進行驗證。架構
主數據管理解決方案具備如下特性：併發
在企業層面上整合了現有縱向結構中的客戶信息以及其餘知識和深層次信息app
共享全部系統中的數據，使之成爲一系列以客戶爲中心的業務流程和服務
實現對於客戶、產品和供應商都通用的主數據形式，加速數據輸入、檢索和分析支持數據的多用戶管理，包括限制某些用戶添加、更新或查看維護主數據的流程的能力
集成產品信息管理、客戶關係管理、客戶數據集成以及可對主數據進行分析的其餘解決方案。
MDM主數據平臺整體設計
今年的一個重要工做就是對已有的MDM主數據管理平臺進行從新的架構調整和功能設計，造成一個完整的主數據管理空平臺。該平臺既可以知足主數據整合和分發，同時可以完整的知足主數據平常內容管理，以及結合服務共享層能力，實現主數據服務的共享和發佈。
在原有架構的基礎上，對主數據管理平臺進行從新分層，即分爲基礎層，應用層和共享層三層。基礎層主要是提供基礎引擎和技術服務能力，對於應用層則圍繞主數據全生命週期展開，在應用層造成了完整的主數據視圖後，再經過最上層的服務共享層提供的能力實現主數據數據服務的對外快速發佈和共享。
基礎層
在基礎層主要實現最基本的底層技術能力，一個是在數據進行收集，清洗和整合的時候須要用到的ETL引擎部分的數據集成能力；其次是MDM平臺應該有一個標準的工做流引擎技術組件，實如今主數據內容管理的時候須要的可視化流程設計和建模；最後便是4A和權限管理方面的能力，固然對於組織，用戶，權限的統一也是一個完整的工做流引擎所須要具有的能力。
應用層
任何主數據的管理都會涉及到兩個方面的內容。一個是動態流程維度，一個是靜態數據模型維度。
對於數據模型維度，在進行主數據管理實施的時候，每每會首先進行主數據的識別和詳細定義，如基於標準的企業架構和數據架構規劃思路，會首先進行流程分析，經過流程找到關鍵的數據域，而後經過數據域識別關鍵的數據對象，再進行完整的概念模型，邏輯模型和物理模型的設計。
對於MDM系統而言，針對數據建模這部分所有能力，都將體如今元數據管理模塊中，其中包括了數據目錄定義，數據對象定義，子對象定義，數據層次和關聯關係的定義，數據對象中每個詳細的數據項和屬性的定義，數據校驗規則的定義，數據源定義，數據收集和分發規則的定義等。這些內容都將在進行主數據對象建模的時候經過可配置的方式進行靈活定義。
簡單來說，只要完整的定義了主數據模型，那麼主數據就能夠完整自動生成後臺數據庫對象和結構，自動可配置的方式實現數據的採集，匹配和清洗等各類操做。
其次對於流程部分，主要包括了常說的主數據內容管理，包括了主數據的建立，變動，廢棄，編碼申請等各類主數據管理流程。這部分流程首先是要在業務上定義清楚，包括涉及到的業務組織和崗位，實際的數據產生者，使用者和認責者等。在流程定義清楚後咱們能夠經過流程引擎的能力實現流程的靈活可視化設計和配置。
對於表單部分有部分MDM產品會提供完整的主數據界面建模能力，這塊相似BPM業務系統提供的能力。可是對於咱們的MDM不包括這部分能力，其核心的緣由仍是對於界面建模和設計，不是簡單的一個界面生成，而是涉及到大量的複雜業務規則的實現，這部分很難經過相似快速開發平臺方式徹底實現自動化和零編碼。
對於流程中第二部分是數據的收集和集成內容，對於這部份內容MDM平臺能夠徹底作到靈活配置數據採集任務和調度，並實現數據的自動化採集和清洗。
共享層
在主數據管理造成了完整的主數據視圖後，更加劇要的是可以快速靈活的將已有的完整的主數據開放和共享出去供其它業務系統使用。所以在這裏涉及到將主數據快速發表爲數據接口服務的能力，同時也涉及到第三方業務系統查看和申請主數據服務的服務開通和管控能力。
當前的MDM平臺能夠支持靈活的將系統裏面已有的一個主數據對象發表爲一個Web Service服務接口，該接口能夠靈活配置輸入參數和輸出的數據項，同時也支持發表爲SOAP WebService或Http WebService等多種服務接口模式。
爲了實現服務接口的發佈，則須要從服務元數據的數據對象定義-》服務定義，從數據集成接口-》服務接口，並在數據對象和服務接口間造成完整的映射，該部份內容在MDM平臺咱們已經作了完整的集成。即造成了一整套從服務全生命週期管理到數據服務能力快速開放共享的完整解決方案。
基於元數據驅動構建MDM主數據平臺
本部分主要談下元數據驅動下的MDM主數據管理平臺的核心構建思路。由於對於一個MDM系統更多應該理解爲結合了元數據驅動和建模，結合了流程引擎和ETL服務能力的一個快速開發和配置平臺。
這個思路和原來咱們談到IBM-CQ變動和缺陷管理系統的構建思路徹底是一致的。即在當前咱們要想作一個覆蓋全部業務場景的快速開發和配置平臺是至關困難的，可是在某一個業務領域相似變動管理，相似表單化工做流，相似主數據管理等，這些業務場景自己已經對可能出現的需求和規則範圍進行了限制，若是理解清楚實際的業務場景和底層核心模型是比較容易實現一個快速開發和配置平臺的。
再次強調下主數據管理平臺的核心是元數據建模，這和快速開發平臺裏面的對象建模是相似的。所以咱們仍是要首先談下元數據和對象建模的核心內容。
以供應商主數據來舉例，常規作法多是在後臺創建供應商數據庫表和相關的關聯子表，而後再根據需求進行供應商CRUD各自管理功能，流程處理功能的開發。那麼在對象建模思想下，咱們要考慮的是供應商是一個完整的主數據對象，應該經過什麼方式把這個對象建模清楚。
對象建模
經過完整的對象建模一方面是能夠直接生成後臺數據庫表，一方面是用於後續的界面建模和主數據質量管理。
對象就有屬性，即首先應該清楚的定義出對象的屬性信息。對應到具體的字段。
每一個對象屬性咱們應該清楚的定義出屬性的業務完整性和數據約束規則。
對象自己可能有子對象，咱們應該能夠進一步對某一個對象的子對象進行詳細定義。子對象將對應到後臺數據庫表中主表下的關聯從表。
對象和對象之間有關聯和映射信息，咱們應該能夠對應對象間的關聯和映射。
對象屬性和對象之間存在關聯信息，應該能夠定義屬性和對象之間的關聯和映射。
其中能夠看到對象建模的核心仍是在於對象和子對象，對象屬性的業務規則定義，對象和對象之間的關聯映射等內容。固然咱們也能夠經過數據庫表逆向生成對象。在對象建模完成對象建模的相關信息都應該存儲到元數據管理的相關數據表中，這是最核心的內容。完整的元數據能夠作到基本基於對象的簡單CRUD功能均可以徹底自動生成。
表單建模
在對象建模完成後接着要考慮的就是表單建模，經過表單建模來實現主數據對象的CRUD功能界面是能夠靈活配置的。這個相似於快速開發平臺中的自定義表單，即詳細的定義CRUD各自表單的佈局，表單中每個屬性元素具體呈現的UI組件。
經過表單建模就能夠實現一個具體的主數據錄入表單中如何佈局，而後實現各個屬性的輸入，具體是錄入仍是選擇框，仍是說須要從關聯子表中進行選擇等。表單建模後的元數據建議是要和對象建模數據進行分離，即在獨立的元數據表中進行存放。
流程建模
在一個完整的主數據管理平臺中必定涉及到主數據的內容和流程管理，相似主數據的建立，變動或廢棄均可能涉及到相應的流程審批操做，在審批完成後才最終生效。所以完整的表單功能實現後接着要考慮的就是經過工做流引擎進行流程建模，最終創建的工做流模板可以和表單掛接。而流程引擎自己又涉及到組織，人員，角色等4A相關的內容，對於這部份內容能夠在MDM系統中維護，也應該能夠從4A或門戶系統進行同步。
談到這個地方基本能夠看到一個完整的供應商主數據管理功能，經過圍繞供應商基礎業務對象進行了對象建模，界面建模和流程建模後應該就能夠徹底自動生成相應的CRUD功能，包括審批流程的實現。可是任何快速開發平臺都很難真正作到對特殊業務規則的進一步處理。
對於複雜業務規則的處理，相似一個供應商基礎數據的廢棄，在廢棄前可能須要首先校驗下該供應商在其它業務系統中的使用狀況。遇到這種場景咱們原來的作法是在原有模型的基礎上能夠本身定義相應的腳本語句進行二次處理，可是帶來的最大問題即便後期的腳本至關難以維護。所以更加更新的方案便是咱們能夠在標準功能的基礎上擴展相應的插件或業務規則邏輯實現的攔截器。這種攔截器在對象屬性輸入，對象保存先後，查詢先後等均可以攔截相應的事件。而具體攔截器的業務規則和邏輯咱們仍是經過自定義的擴展類來實現。經過這種方式能夠保證整個主數據管理平臺足夠的可擴展性。
在早期的MDM主數據管理平臺中，並不建議立刻引入複雜的規則引擎來實現規則建模和規則的可配置，這部份內容仍是經過本身開發擴展代碼來實現每每更加容易維護和擴展。
前面的基礎能力實現後再接着談兩個重點，即主數據集成管理和主數據質量管理。
數據集成管理
對於主數據集成管理其實包括兩個部分的內容，一個是ETL，一個SOA服務接口，對於ETL主要是實現初始化數據的採集和清理入庫。對於SOA服務接口便是可以將主數據服務能力經過接口服務暴露出去，或者說經過消息發佈訂閱機制可以實現MDM主數據管理平臺中主數據的實時分發和事件通知。
對於ETL部分的功能不須要多談，咱們能夠集成和內置一個輕量的ETL工具和功能。而對於SOA服務部分的功能則涉及到基於前面對象建模定義的元數據實現標準服務的發表。即咱們在定義的完整的對象後，咱們能夠經過嚮導的方式將主數據發佈爲WebService服務接口，既能夠是rest服務接口，也能夠是soap webservice服務接口。而具體發佈的接口須要哪些輸入，哪些輸出應該均可以進行靈活的配置來完成。固然咱們也能夠在MDM平臺維護主數據的消息發佈訂閱機制，即將MDM主數據的變動內容經過消息訂閱的模式實時分發給業務系統。
數據質量管理
數據質量管理是主數據管理裏面的一個難點，其中包括了兩個方面的內容，一個是單數據對象的數據質量分析，這個經過在對象建模時候定義的業務規則和完整性規則就能夠進行。固然咱們也能夠將數據質量單獨拿出來進行定義，咱們能夠將一個規則綁定到具體的業務對象或者業務對象的屬性上面。而後基於這些規則進行單對象的數據質量分析。其次是多表間的數據稽覈，咱們談到過主數據管理平臺最終是爲了解決多業務系統主數據不一致的問題，可是即便上了主數據平臺也還須要對多業務系統中的同一數據對象進行數據內容稽覈，並實時發現數據不一致的狀況並進行預警。對於數據稽覈的核心思路，我前面有一篇文章專門談到過能夠參考。
若是以上的內容都已經實現，那麼最終提供出來的主數據平臺就是一個能夠快速實施各種企業主數據的基礎平臺。該平臺基本能夠作到80%的主數據實施工做均可配置，同時咱們也能夠將更多的精力放在主數據業務流程和管控規範的梳理，主數據集成，主數據特殊業務規則的實現上。
從主數據定製開發到快速配置開發
對於最近1到2年的MDM主數據交流來看，不少企業但願的是一個徹底高度靈活可配置的主數據平臺產品，可是非主數據規劃諮詢和實施能力。
而對於咱們來講，更加劇要的能力是在規劃諮詢和實施能力，裏面包括了主數據管理規範體系，流程，數據模型，主數據質量管理，歷史數據的清洗和導入，數據能力的共享等，這些每每都不是一個標準產品就可以覆蓋的，而是須要有經驗的諮詢顧問和實施顧問的現場投入。
固然，對於一個標準的主數據產品，咱們能夠看到已經逐步相似一個快速開發平臺能力，咱們能夠再次簡單總結下一個標準的MDM主數據平臺須要具有的快速開發和可配置能力。
4A和權限模型：實現組織，用戶，權限等靈活配置
流程引擎：實現審批流程的靈活可配置
對象建模：實現主數據對象模型的靈活建立和配置，包括對象和數據表的鏈接和映射
表單建模：實現表單的自定義和可視化設計配置，表單和對象模型間的映射
規則建模：底層有一個規則引擎，可以實現規則的靈活配置或腳本定義
集成模型：實現對象到接口服務的自動化發佈，可以實現數據集成的自動化配置和集成
以上這些內容看着會感受特別熟悉，即這些和咱們常常看到的快速開發平臺很相似，即一個產品和的主數據平臺基本涵蓋了快速開發平臺須要具有的全部能力。
那麼企業在實施主數據平臺的時候，當須要實施一類新的主數據的時候，好比咱們須要實施物料主數據，咱們但願的就是物料的數據模型，表單，流程，集成接口都徹底可以配置出來而不須要開發代碼。在這種狀況下主數據平臺具有了最大的靈活性，可是實際上咱們看到對於界面和規則，每每是很難經過配置的方式完成的，特別是一些複雜規則的實現更難簡單的配置完成。
主數據平臺在具有了快速開發平臺的關鍵基礎能力後，又增長了關鍵的技術基礎能力，即
ETL數據集成：可以實現數據集成，數據清洗轉化和入庫
SOA集成：可以實現數據對象快速的發佈爲接口服務，標準化的消息發佈訂閱
在增長了這兩方面能力基本就具有一個標準化的主數據管理平臺能力。
而實際上咱們當前的主數據平臺對於4A，流程引擎，對象建模，集成建模，ETL這些關鍵技術能力所有具有，而比較欠缺的就是動態表單建模和規則建模，雖然咱們在前面也實現過一個簡單的技術組件，可是經過實施咱們仍然發現對於一些複雜場景的主數據管理，很難簡單的經過配置就完成功能的設計和開發。
咱們咱們已經有表單設計器和自定義表單，可是即對於表單和規則仍是須要定製化開發，其它技術組件和能力可以實現徹底的靈活可配置。這便是當前咱們主數據平臺的能力現狀，對於比較強調規劃諮詢和實施能力的企業，咱們仍然具有足夠的優點。
主數據平臺趨勢必定是從技術平臺轉到業務平臺
舉一個簡單的例子來講，若是你一直作汽車製造行業的MDM主數據系統，那麼實施多了後，你天然就很清楚對於汽車製造行業涉及到哪些主數據，每個主數據對象究竟應該包括哪些通用基礎字段和擴展字段。這些通用化的主數據模型每每也適用於其它的汽車製造行業。
那麼這個時候你的主數據平臺就單純的從一個技術平臺變成了一個業務平臺，即已經通過你多年的MDM主數據平臺的建設和實施，將實施經驗沉澱爲主數據平臺的數據資產。這個數據資產自己就是有價值的。
MDM系統-數據建模
在前面已經談到，MDM平臺後續的建設思路都是圍繞數據模型這個關鍵元數據驅動進行建設的，從數據建模再延伸到了業務規則建模，流程建模和界面建模等內容，最後擴展到外圍的接口服務集成能力。建模能力是否強大，是否靈活和可擴展，每每直接影響到一個MDM平臺的易用性和擴展性。
下面再來解釋下如何進行主數據建模，對於主數據建模其本質應該是一個樹狀的層級可展開結構，方便進行子對象和層次的自動掛接，以適合一個主數據有多層子對象的狀況。
整個主數據建模的關鍵過程和步驟應該以下：
建立數據對象，如供應商，物料數據對象。數據對象能夠有多層結構。
建立數據對象的子對象，即該數據對象能夠存在子對象，子對象還可存在子子對象。
建立數據對象或子對象的數據項信息，包括數據項目的名稱，類型，其它擴展屬性等。
上面三個關鍵步驟就可以實現基本的數據對象建立，每一個數據對象和子對象對應到數據庫中一張表，這個數據對象很相似咱們領域設計中的領域對象。子對象單獨沒有存在的意義，必須連同父對象存在。對於建模中對應的各個數據項，便是實際數據表中的數據字段信息。
這樣數據建模完成後能夠直接造成動態Sql語句，直接建立後臺的數據庫表結構。
在數據對象建模中咱們能夠考慮增長一個文件夾建立的功能，或者說咱們單獨增長一個針對數據對象建立屬性分組的功能，便可以將不一樣的屬性和子對象進行分組管理。這個分組一個是方面咱們進行維護和管理，一個是後續在界面建模的時候直接將不一樣的分組屬性映射到不一樣的tab頁簽上面。
數據項自己的類型應該至少包括以下幾種：
簡單的錄入類數據類型：字符型，數字型，日期型
列表類數據類型，從下拉列表中選擇：支持從數據字典中選擇，也支持從獨立的另外數據表對象中選型
跳窗選擇型：即支持關聯到另一個外部數據表對象
文件型：支持上傳文件，注意能夠支持一個數據對象上傳多個附件文件的能力。
表格型：對於數據對象維護過程當中，子對象應該默認映射到表格類型
對於列表數據類型每每還須要支持多級分類聯動模式，好比物料信息維護的時候可能出現先選擇物料大類，再選擇小類，再選擇次小類，就存在三個小拉列表框的聯動關係。
以上是最基本的數據項類型的維護能力，其次是基礎的字段完整性校驗能力，其中就包括了場景的是否爲空檢驗，數字類型檢驗，長度檢驗，值大小檢驗，自定義腳本檢驗（if a>0 and b>0 then c>0）等。這些能夠確保數據錄入的基礎完整性。
以上全部這些校驗都是單條主數據記錄錄入的時候就能夠完成的校驗，其次就是多行記錄之間的相互校驗，最多見的就是爲了不主數據錄入重複，咱們須要進行類似性校驗，對於類似的主數據給出提醒。
好比在錄入供應商錄入的時候咱們能夠根據名稱進行類似性校驗，在物料信息錄入的時候能夠根據規格型號，參數組合進行類似性驗證等。類似性校驗功能既能夠用於在數據清理階段的查重，也能夠用於後續的新數據錄入和修改檢查。
還有就是跨多個數據對象之間的校驗，好比當存在在途數據的時候，供應商的類型或名稱不容許變動或刪除，這就是最多見的外部業務規則檢驗，對於這種能力也須要進行支持。
一個完整的主數據模型定義，實際是應該包括了數據類元數據，業務規則類元數據和界面類元數據，列入界面上應該展示什麼樣子，展示和佈局規則等都屬於界面元數據。這些也能夠在數據模型維護的時候進行統一維護。
而對於對象這個層面的主數據，也還須要進行額外屬性信息的維護，其中包括了：
數據集成類（數據採集，數據分發，集成接口等）
關聯關係類（該數據對象和其它數據對象的管理關係）
數據類（對應的數據庫，數據源或數據表信息的定義）
元數據定義完成後要達到的一個效果就是能夠生成底層的數據庫表，能夠用來自動化生成界面，能夠用來作數據此採集和集成，同時還能夠根據業務規則進行主數據質量管理。
數據質量管理
數據質量管理（Data Quality Management），是指對數據從計劃、獲取、存儲、共享、維護、應用、消亡生命週期的每一個階段裏可能引起的各種數據質量問題，進行識別、度量、監控、預警等一系列管理活動，並經過改善和提升組織的管理水平使得數據質量得到進一步提升。
數據質量的評估維度主要包括以下幾個方面的內容：
完整性 Completeness：完整性用於度量哪些數據丟失了或者哪些數據不可用。
規範性 Conformity：規範性用於度量哪些數據未按統一格式存儲。
一致性 Consistency：一致性用於度量哪些數據的值在信息含義上是衝突的。
準確性 Accuracy：準確性用於度量哪些數據和信息是不正確的，或者數據是超期的。
惟一性 Uniqueness：惟一性用於度量哪些數據是重複數據或者數據的哪些屬性是重複的。
關聯性 Integration：關聯性用於度量哪些關聯的數據缺失或者未創建索引。
而以上這些內容咱們在作MDM主數據管理系統的數據質量管理模塊，包括實施ETL工具裏面的數據轉換和清洗等時候，都是須要考慮和支持的內容。
而對於數據質量管理，應該是覆蓋數據生老病死的全生命週期管理，爲了方便重點談下常見的兩個實施數據質量管理的階段，一個是藉助ETL工具實現的數據採集和整合階段，一個是平常實時進行的數據檢查和稽覈。下面就這兩個常見階段分開再來談下。
數據採集和整合階段
如今的ETL操做不少已經轉變爲了ELT操做，即咱們說的Transform轉換這塊的內容有些事在ETL傳輸過程當中完成，而有些已經轉變到數據採集到目標數據庫後再在目標數據庫端完成數據轉換。
注意轉換的做用更多的是將數據標準化和規範化，好比經過轉換和映射，將名稱轉換爲代碼，或者作兩個數據項內容的合併等，這些都是能夠在轉換的時候執行的事情。
數據惟一性裏面有一個重點就是去重和去類似性，對於去重咱們能夠在ETL工具裏面經過轉換配置完成，而對於去類似性每每則須要後續數據採集完成後編寫獨立的代碼或腳原本分析類似性數據，並經過手工確認後再完成去除類似性數據或對數據進行合併操做。
一類主數據每每涉及到多張表，好比供應商主數據，涉及到基本信息，聯繫人信息，帳號信息等多個子對象。這些子對象能夠是一種層次關係，也能夠是一種關聯關係。這個咱們在進行主數據對象和關聯關係定義的時候會詳細定義。這種關聯性帶來的就是參照完整性約束，好比供應商聯繫人信息在，可是對應的供應商頭找不到了，對於這種數據不能在ETL上完成處理，可是能夠經過腳本找出這種異常數據並手工處理和清洗。
平常進行的數據檢查
主數據自己也是不斷在增長，所以在數據清洗初始化完成，主數據平臺開始正常運行後，咱們還須要對主數據內容進行平常的數據檢查和管控。這也是數據質量管理的一個重要內容。
對於平常數據檢查和審計，總體的步驟能夠考慮爲
定義數據檢查規則，包括單表屬性檢查，跨行重複檢查，多表關聯依賴檢查，一致性檢查
定義檢查任務和檢查單
將檢查單配置爲一種計劃調度，自動按期按時執行
查看數據檢查報表，對於異常數據進行手工處理或自動化處理
前面已經談到過的數據準確性，惟一性，數據的重複或類似等檢查也均可以在這個階段作。同時咱們看到還有一個核心工做，即數據自己的一致性檢查和數據稽覈。
好比從兩個系統都採集到供應商數據，如何去匹配和檢查兩個系統的供應商數據的差別和一致性，這就須要有獨立的數據稽覈功能。數據稽覈首先對數據對象有惟一的匹配關鍵字，其次是定義須要進行數據稽覈的字段。對於A和B兩個數據表而言，常見的數據稽覈和比對結果主要包括以下幾個方面。
A和B兩個表哪些數據是徹底相同的？
哪些數據A表有，B表沒有，或者相反。
哪些數據A和B兩個都有，可是存在數據項內容不一致的狀況。
以上就是最簡單的數據稽覈，對於數據稽覈的結果首先是能夠由系統觸發自動化的進行再次的數據同步和集成，包括數據集成過程當中的清洗和轉換；其次能夠輸出數據稽覈報表，供業務人員手工處理異常數據。
最後再強調下雖說數據質量管理是一個全生命週期的事情，可是數據質量真正要提高必定不是過後進行數據檢查和稽覈，而是真正從產生數據問題的源頭抓起。好比解決數據源多個多點錄入問題，解決一樣的數據能夠在多個系統發起修改的問題，解決數據模型中定義的數據約束在數據錄入的時候沒有進行完整性控制的問題等。
MDM系統-接口和數據服務
談到主數據平臺，接口和數據服務或者說集成管理是MDM必須具有能力，在MDM的解決方案中，更多會配合ETL和ESB服務總線來談這兩部分是如何實現的。
首先能夠看到MDM涉及到外部集成，主要包括兩個方面，一個就是數據的採集過程，一個就是數據的分發和數據服務能力的提供過程，所以須要分這兩個方面來談集成過程。
數據的採集
對於數據的採集過程，自己又須要分爲兩種不一樣的場景來講明：
數據初始化採集：須要經過ETL來完成，一是數據量大，一是須要在ETL過程當中進行清洗。
數據增量採集：經過實時的註冊到ESB總線的接口服務來完成。確保採集數據的實時性。
能夠看到在初始化階段經過ETL工具完成採集和初始化數據的導入，而在正式上線後，因爲主數據變更頻率自己不高，所以能夠直接經過服務接口進行服務採集，MDM提供數據導入接口服務，數據源產生系統在有主數據變動的時候實時調用服務接口將數據導入到MDM。
固然若是是採用的集中化建設模式，即主數據自己就是在MDM系統建立產生的，那麼在這種狀況下就不存在主數據還須要採集的過程了。
數據的分發
對於數據的分發自己又分爲兩種狀況：
數據落地分發：採用消息發佈訂閱模式進行分發，或者直接採用WS同步實時服務分發。
數據不落地：MDM系統之間提供主數據實時查詢服務接口便可。
當前使用的比較多的仍是數據落地分發，對於數據落地分發，若是訂閱MDM的業務系統相對多，最好是採用消息發佈訂閱模式進行主數據分發，固然仍然採用WS服務進行分發也能夠，可是就須要MDM系統調用屢次服務接口進行數據的分發操做，以方面對分發過程進行監控。
對於數據分發，若是存在批量數據的分發，好比人員或組織主數據出現了批量變動，那麼這種場景下采用消息或WS分發均可能存在大數據下的性能問題。或者說一個數據分發涉及到更高的安全要求後跨網段集成，那麼這個時候還能夠採用將須要分發的主數據導出爲文件格式，經過文件將主數據分發給目標系統。
對於數據不落地狀況下，MDM系統只須要提供標準的數據查詢服務接口便可。在這種狀況下須要確保該接口服務自己在大併發調用下的性能問題。
主數據平臺如何提供數據接口和服務集成能力？
在前面談MDM的文章的時候，我已經談到過，咱們但願的是MDM系統自己就集成了接口和服務集成的能力，最大化的建設接口集成時候的實施工做量。更好的模式就是MDM自己也具有了部分ETL和ESB服務集成的功能在裏面，而不是要徹底依賴於外部的能力。
對於數據採集模塊，咱們能夠集成最基本的數據集成能力，即在MDM系統裏面就能夠配置簡單的ETL操做，任務調度操做，將外部數據源的數據根據某種業務規則採集到MDM平臺中來。
對於數據分發模塊，有兩種狀況
1. 數據分發場景
1.1 由MDM制定導入服務接口，生成服務規範和契約，MDM將數據模型映射到服務規範。
1.2 外部已有的WSDL服務，MDM直接進行服務映射和分發服務配置，無需編碼。
1.3 將MDM數據模型直接發佈到JMS消息中間件，同時支持外部系統進行消息訂閱。
2. 數據不落地場景
2.1 由MDM提供數據模型直接發佈爲主數據服務的功能，即模型能夠直接發佈爲服務。
2.2 仍然採用契約先行模式，先定義數據查詢接口契約，MDM數據模型映射到服務規範上面。
對於發佈的接口自己還須要支持場景的SOAP WS和Rest兩種服務接口模式。同時MDM系統自己還須要提供對服務接口的實時監控能力，分發異常告警能力，分發日誌的詳細統計分析能力等。
物流IT圈
泛物流行業IT知識分享傳播、從業人士互幫互助，覆蓋快遞快運/互聯網物流平臺/城配/即時配送/3PL/倉配/貨代/冷鏈/物流軟件公司/物流裝備/物流自動化設備/物流機器人等細分行業。長按二維碼即刻加入咱們，若是你是以上行業公司中的IT從業人士加運營小哥微信後可入羣交流。
公衆號
運營小哥
本文分享自微信公衆號 - 物流IT圈（exiter18）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。