一、主數(shù)據(jù)系統(tǒng)的必要性

隨著企業(yè)信息化的不斷深入，企業(yè)建設的業(yè)務系統(tǒng)、辦公系統(tǒng)等信息系統(tǒng)越來越多。由于規(guī)劃、預算、實施計劃等原因限制，各信息系統(tǒng)建設的步調不一致，規(guī)劃不統(tǒng)一，導致一個嚴重的問題：一些基礎數(shù)據(jù)，比如商品編碼、客戶編碼等，在不同信息系統(tǒng)內取值不一致，甚至定義也不一致，為各業(yè)務系統(tǒng)打通，以及數(shù)據(jù)中心建設帶來極大的障礙。這些基礎數(shù)據(jù)一般稱為主數(shù)據(jù)，對主數(shù)據(jù)的規(guī)范和梳理需要建設“主數(shù)據(jù)系統(tǒng)”。

主數(shù)據(jù)問題主要有幾個方面：

1、各系統(tǒng)基礎數(shù)據(jù)定義不一，集中的數(shù)據(jù)處理（比如BI、大數(shù)據(jù)、機器學習等）需要經過繁瑣的數(shù)據(jù)清洗、格式化、一致性檢查和轉換等步驟，代價巨大；

2、數(shù)據(jù)字典各自為政，甚至存在無法調和的邏輯矛盾，比如在A系統(tǒng)是主鍵的字段在B系統(tǒng)卻允許不唯一；

3、有時候盡管定義了統(tǒng)一的規(guī)范，但各系統(tǒng)獨立維護，也無法保證主數(shù)據(jù)的一致性。

由此，主數(shù)據(jù)系統(tǒng)的建設宜早不宜晚，特別是對于已經在使用ERP的傳統(tǒng)企業(yè)。但是，由于主數(shù)據(jù)系統(tǒng)偏重于“技術優(yōu)化”的范疇，很難在業(yè)務上見到立竿見影的效果，甚至對于業(yè)務人員都是“透明”的，而且還投入不小，所以對于如何申請到資源并立項，是個不小的挑戰(zhàn)。但這不在本文討論的范圍內。

二、主數(shù)據(jù)系統(tǒng)設計的基本原則

主數(shù)據(jù)系統(tǒng)的設計方法很多，但大多數(shù)都需要對原有信息系統(tǒng)進行傷筋動骨的改動。因此，各企業(yè)在主數(shù)據(jù)系統(tǒng)的實施上都比較保守，寧愿花費大量的人工處理，以及諸多的各系統(tǒng)補丁，進行數(shù)據(jù)清理和轉換，這種方案效率低而且無法解決根本性問題。

在結構上，由于多個應用系統(tǒng)之間，都可能存在提供數(shù)據(jù)和使用數(shù)據(jù)兩種角色，一般采用點對點兩兩交互的網狀結構，這種結構對同步時序、轉換規(guī)則、系統(tǒng)復雜度等均提出了極高的要求，也帶來——復雜性高，實施周期長，無法分步實施，容易失敗等問題。

圖1.網狀結構和星形結構

很顯然，星形結構明顯由于網狀結構，而且必然對原信息系統(tǒng)的修改更少。

主數(shù)據(jù)系統(tǒng)設計原則幾個要點如下：

1、數(shù)據(jù)同步從一般的“網狀結構”改為穩(wěn)定性高的“星形結構”，打破點對點兩兩交叉的復雜結構；

2、通過“數(shù)據(jù)代理”方式，不侵入原信息系統(tǒng)，不需要對原系統(tǒng)進行大量改動，可以進行有計劃的分步實施；

3、主數(shù)據(jù)系統(tǒng)對每一條數(shù)據(jù)記錄，設置全域范圍唯一的uuid記錄識別碼，用于主數(shù)據(jù)記錄全生命周期的識別、映射和轉換；

4、所有數(shù)據(jù)轉換、映射均由主數(shù)據(jù)系統(tǒng)實現(xiàn)，對原系統(tǒng)完全“透明”；

5、關聯(lián)記錄通過uuid多次映射的方式，確保任何現(xiàn)有系統(tǒng)以及將來接入的系統(tǒng)，都無需關心源數(shù)據(jù)的關聯(lián)關系，復雜度大大降低。

三、主數(shù)據(jù)系統(tǒng)的具體實現(xiàn)

下面結合一種實現(xiàn)方法，給出完整的數(shù)據(jù)庫設計和流程圖。并對其中的關鍵點進行詳細闡述。該項目已經上線運行半年多，可靠性和數(shù)據(jù)一致性均經過嚴格驗證。

本項目幾個前提如下：

（1）所有業(yè)務系統(tǒng)數(shù)據(jù)庫都是MySQL；

（2）所有業(yè)務系統(tǒng)數(shù)據(jù)提供者的主數(shù)據(jù)表都有id主鍵，但字段名不一定為“id”，也不一定具有自增屬性；

（3）所有業(yè)務系統(tǒng)數(shù)據(jù)提供者的主數(shù)據(jù)表都有最后更新時間戳，同樣字段名各不相同；

（4）所有業(yè)務系統(tǒng)數(shù)據(jù)提供者均以標志位標識“刪除”，而不進行記錄的物理刪除。

1、總體架構

總體架構為星形結構，如圖2：

圖2.主數(shù)據(jù)系統(tǒng)總體架構圖

其中：

（1）? ?為簡化設計，基于前提的第2、3點，數(shù)據(jù)代理直接采用數(shù)據(jù)庫連接方式，定時對數(shù)據(jù)提供者的數(shù)據(jù)庫表進行輪詢。由此，對于數(shù)據(jù)提供者對應主數(shù)據(jù)表必須具有讀權限，對于數(shù)據(jù)消費者的對應主數(shù)據(jù)表必須具有insert/update權限；

（2）? ?數(shù)據(jù)代理（1~n），每個均連接主數(shù)據(jù)數(shù)據(jù)庫和唯一一個信息系統(tǒng)數(shù)據(jù)庫。業(yè)務系統(tǒng)數(shù)據(jù)庫的“數(shù)據(jù)消費者”和“數(shù)據(jù)提供者”角色可能只有一種，例如，辦公自動化（OA）系統(tǒng)，可能只作為“數(shù)據(jù)提供者”角色，提供組織架構、人員等主數(shù)據(jù)。這種情況下，該“數(shù)據(jù)代理”無需配置和調度“數(shù)據(jù)消費者”功能。

（3）? ?MySQL數(shù)據(jù)庫表結構定義可以從information_schema.COLUMNS直接獲取，其他數(shù)據(jù)庫可以找類似系統(tǒng)表，如果沒有，則需要單獨填充字段定義。

（4）? ?數(shù)據(jù)庫設計如下：

tb_columns_def：表結構定義，從information_schema.COLUMNS直接復制

tb_data_role：數(shù)據(jù)角色定義

tb_data_role

2、數(shù)據(jù)提供者拉取

功能流程如圖3：

圖3.數(shù)據(jù)提供者拉取流程

其中：

（1）被定時調度（本項目設置1分鐘一次）激活后，連接對應的信息系統(tǒng)數(shù)據(jù)庫，檢查是否有新增或更新記錄，如有，則進行數(shù)據(jù)拉取——從源數(shù)據(jù)數(shù)據(jù)庫拉取并存入主數(shù)據(jù)數(shù)據(jù)庫，同時記錄“同步輪次”。

（2）一個信息系統(tǒng)可能提供多個“數(shù)據(jù)提供者”，在全部數(shù)據(jù)提供者都輪詢并處理結束后，流程結束。

（3）數(shù)據(jù)庫設計如下：

tb_data_sync_log：同步日志表，保存同步控制數(shù)據(jù)

tb_data_sync_log

3、數(shù)據(jù)消費者推送

功能流程如圖4：

圖4.數(shù)據(jù)消費者推送流程

其中：

（1）被定時調度激活后，檢查主數(shù)據(jù)系統(tǒng)“同步輪次”是否有新增，如有，則進行數(shù)據(jù)推送。連接數(shù)據(jù)消費者信息系統(tǒng)數(shù)據(jù)庫，從主數(shù)據(jù)數(shù)據(jù)庫推送新增或更新數(shù)據(jù)記錄到信息系統(tǒng)數(shù)據(jù)庫，同時記錄“同步輪次”。

（2）檢查主數(shù)據(jù)系統(tǒng)“同步輪次”是否有新增，通過tb_data_sync_log.relative_cycle_no與對應主數(shù)據(jù)(main_role)記錄的最新倫次比較。

（3）一個信息系統(tǒng)可能需要多個“數(shù)據(jù)消費者”，在全部數(shù)據(jù)消費者都輪詢并處理結束后，流程結束。

（4）數(shù)據(jù)庫設計同數(shù)據(jù)提供者（參見第2節(jié)）。

4、數(shù)據(jù)轉換

功能流程如圖5：

圖5.數(shù)據(jù)轉換流程

其中：

（1）數(shù)據(jù)轉換是不同信息系統(tǒng)與主數(shù)據(jù)之間，字段類型、長度、格式轉換的核心模塊。

（2）數(shù)據(jù)轉換通過參數(shù)配置和附加處理函數(shù)，實現(xiàn)高度靈活性。

（3）數(shù)據(jù)轉換首先獲取源和目標數(shù)據(jù)表的字段定義，其次獲取對應字段的轉換規(guī)則。對所有已定義轉換規(guī)則的字段進行處理：

A、對字段類型、長度進行通用轉換；

B、調用附加處理函數(shù)（如果有），進行特殊轉換；

C、按照關聯(lián)id規(guī)則（如果有），讀取主數(shù)據(jù)數(shù)據(jù)庫的id映射，進行對應關聯(lián)id處理；

D、循環(huán)處理所有字段。

（4）數(shù)據(jù)庫設計如下：

tb_transfer_def：轉換規(guī)則定義表

tb_transfer_def

tb_transfer_rule：轉換規(guī)則字段映射表

tb_transfer_rule

tb_id_mapping：id映射表

tb_id_mapping

四、關鍵點總結

主數(shù)據(jù)系統(tǒng)涉及多個系統(tǒng)的數(shù)據(jù)同步，由于各異構系統(tǒng)的差異性，導致主數(shù)據(jù)系統(tǒng)復雜度較高，成功的案例不多。本項目基于前述前提，取得較好的效果。現(xiàn)將關鍵點總結分享如下：

1、數(shù)據(jù)提供者的新增id和更新時間戳，對于不具備這兩個條件的數(shù)據(jù)提供者，無法辨識新增和更新，不能進行增量同步，必須進行改造。如果由于種種原因源數(shù)據(jù)無法改造，則可以考慮變通方法，利用數(shù)據(jù)庫自有同步工具(例如Oracle的DGG等)，在同步的副本中增加新增和更新標識；

2、不管數(shù)據(jù)提供者還是數(shù)據(jù)消費者，無法進行數(shù)據(jù)庫直接連接的，則“數(shù)據(jù)代理”需要以外掛應用的形式存在，與主數(shù)據(jù)系統(tǒng)的通訊采用WebService方式。將帶來緩存、重試、冪等……多個復雜度的大大提高。

3、由于不同主數(shù)據(jù)表之間字段上存在映射關系，比如人員的所屬部門的，需要在id映射上做多次轉換，基本原則就是以落地主數(shù)據(jù)的uuid為“唯一權威”，其他關系都通過與uuid映射獲得。

4、待補充——從數(shù)據(jù)庫設計中，經過思考可以去發(fā)現(xiàn)，不再贅述。