主資料系統的必要性
随着企業資訊化的不斷深入，企業建設的業務系統、辦公系統等資訊系統越來越多。由于規劃、預算、實施計劃等原因限制，各資訊系統建設的步調不一緻，規劃不統一，導緻一個嚴重的問題：一些基礎資料，比如商品編碼、客戶編碼等，在不同資訊系統内取值不一緻，甚至定義也不一緻，為各業務系統打通，以及資料中心建設帶來極大的障礙。這些基礎資料一般稱為主資料，對主資料的規範和梳理需要建設“主資料系統”。
主資料問題主要有幾個方面：
- 各系統基礎資料定義不一，集中的資料處理（比如 BI、大資料、機器學習等）需要經過繁瑣的資料清洗、格式化、一緻性檢查和轉換等步驟，代價巨大；
- 資料字典各自為政，甚至存在無法調和的邏輯沖突，比如在 A 系統是主鍵的字段在 B 系統卻允許不唯一；
- 有時候盡管定義了統一的規範，但各系統獨立維護，也無法保證主資料的一緻性。
由此，主資料系統的建設宜早不宜晚，特别是對于已經在使用 ERP 的傳統企業。但是，由于主資料系統偏重于“技術優化”的範疇，很難在業務上見到立竿見影的效果，甚至對于業務人員都是“透明”的，而且還投入不小，是以對于如何申請到資源并立項，是個不小的挑戰。但這不在本文讨論的範圍内。
2
主資料系統設計的基本原則
主資料系統的設計方法很多，但大多數都需要對原有資訊系統進行傷筋動骨的改動。是以，各企業在主資料系統的實施上都比較保守，甯願花費大量的人工處理，以及諸多的各系統更新檔，進行資料清理和轉換，這種方案效率低而且無法解決根本性問題。
在結構上，由于多個應用系統之間，都可能存在提供資料和使用資料兩種角色，一般采用點對點兩兩互動的網狀結構，這種結構對同步時序、轉換規則、系統複雜度等均提出了極高的要求，也帶來——複雜性高，實施周期長，無法分步實施，容易失敗等問題。
圖 1 網狀結構和星形結構
很顯然，星形結構明顯由于網狀結構，而且必然對原資訊系統的修改更少。
主資料系統設計原則幾個要點如下：
- 資料同步從一般的“網狀結構”改為穩定性高的“星形結構”，打破點對點兩兩交叉的複雜結構；
- 通過“資料代理”方式，不侵入原資訊系統，不需要對原系統進行大量改動，可以進行有計劃的分步實施；
- 主資料系統對每一條資料記錄，設定全域範圍唯一的 uuid 記錄識别碼，用于主資料記錄全生命周期的識别、映射和轉換；
- 所有資料轉換、映射均由主資料系統實作，對原系統完全“透明”；
- 關聯記錄通過 uuid 多次映射的方式，確定任何現有系統以及将來接入的系統，都無需關心源資料的關聯關系，複雜度大大降低。
3
主資料系統的具體實作
下面結合一種實作方法，給出完整的資料庫設計和流程圖。并對其中的關鍵點進行詳細闡述。該項目已經上線運作半年多，可靠性和資料一緻性均經過嚴格驗證。
本項目幾個前提如下：
（1）所有業務系統資料庫都是 MySQL；
（2）所有業務系統資料提供者的主資料表都有 id 主鍵，但字段名不一定為“id”，也不一定具有自增屬性；
（3）所有業務系統資料提供者的主資料表都有最後更新時間戳，同樣字段名各不相同；
（4）所有業務系統資料提供者均以标志位辨別“删除”，而不進行記錄的實體删除。
3.1
總體架構
總體架構為星形結構，如圖 2：
圖 2 主資料系統總體架構圖
其中：
（1）為簡化設計，基于前提的第 2、3 點，資料代理直接采用資料庫連接配接方式，定時對資料提供者的資料庫表進行輪詢。由此，對于資料提供者對應主資料表必須具有讀權限，對于資料消費者的對應主資料表必須具有 insert/update 權限；
（2）資料代理（1~n），每個均連接配接主資料資料庫和唯一一個資訊系統資料庫。業務系統資料庫的“資料消費者”和“資料提供者”角色可能隻有一種，例如，辦公自動化（OA）系統，可能隻作為“資料提供者”角色，提供組織架構、人員等主資料。這種情況下，該“資料代理”無需配置和排程“資料消費者”功能。
（3）MySQL 資料庫表結構定義可以從 information_schema.COLUMNS 直接擷取，其他資料庫可以找類似系統表，如果沒有，則需要單獨填充字段定義。
（4）資料庫設計如下：
- tb_columns_def ：表結構定義，從 information_schema.COLUMNS 直接複制
- tb_data_role ：資料角色定義
3.2
資料提供者拉取
功能流程如圖 3：
圖 3“資料提供者”拉取流程
其中：
（1）被定時排程（本項目設定 1 分鐘一次）激活後，連接配接對應的資訊系統資料庫，檢查是否有新增或更新記錄，如有，則進行資料拉取——從源資料資料庫拉取并存入主資料資料庫，同時記錄“同步輪次”。
（2）一個資訊系統可能提供多個“資料提供者”，在全部資料提供者都輪詢并處理結束後，流程結束。
（3）資料庫設計如下：
- tb_data_sync_log ：同步日志表，儲存同步控制資料
3.3
資料消費者推送
功能流程如圖 4：
圖 4 資料消費者推送流程
其中：
（1）被定時排程激活後，檢查主資料系統“同步輪次”是否有新增，如有，則進行資料推送。連接配接資料消費者資訊系統資料庫，從主資料資料庫推送新增或更新資料記錄到資訊系統資料庫，同時記錄“同步輪次”。
（2）檢查主資料系統“同步輪次”是否有新增，通過 tb_data_sync_log.relative_cycle_no 與對應主資料(main_role)記錄的最新倫次比較。
（3）一個資訊系統可能需要多個“資料消費者”，在全部資料消費者都輪詢并處理結束後，流程結束。
（4）資料庫設計同資料提供者（參見第 2 節）。
3.4
資料轉換
功能流程如圖 5：
圖 5 資料轉換流程
其中：
（1）資料轉換是不同資訊系統與主資料之間，字段類型、長度、格式轉換的核心子產品。
（2）資料轉換通過參數配置和附加處理函數，實作高度靈活性。
（3）資料轉換首先擷取源和目标資料表的字段定義，其次擷取對應字段的轉換規則。對所有已定義轉換規則的字段進行處理：
A、對字段類型、長度進行通用轉換；
B、調用附加處理函數（如果有），進行特殊轉換；
C、按照關聯 id 規則（如果有），讀取主資料資料庫的 id 映射，進行 對應關聯 id 處理；
D、循環處理所有字段。
（4）資料庫設計如下：
- tb_transfer_def：轉換規則定義表
- tb_transfer_rule：轉換規則字段映射表
- tb_id_mapping ：id 映射表
4
關鍵點總結
主資料系統涉及多個系統的資料同步，由于各異構系統的差異性，導緻主資料系統複雜度較高，成功的案例不多。本項目基于前述前提，取得較好的效果。現将關鍵點總結分享如下：
1、資料提供者的新增 id 和更新時間戳，對于不具備這兩個條件的資料提供者，無法辨識新增和更新，不能進行增量同步，必須進行改造。如果由于種種原因源資料無法改造，則可以考慮變通方法，利用資料庫自有同步工具(例如 Oracle 的 DGG 等)，在同步的副本中增加新增和更新辨別；