導讀：

企業(yè)數據孤島、共享數據管理、數據服務性能面臨挑戰(zhàn)，高可用的主數據管理服務越來越被企業(yè)所重視，本文內容是基于百度智能小程序主數據實戰(zhàn)經驗的一些總結，從解決百度智能小程序核心業(yè)務數據模型的質量和共享協同入手，重新定義業(yè)務數據模型邊界，提供企業(yè)高可用的數據管理服務的演進過程，希望幫助大家在主數據應用的道路上獲得更多幫助。

全文5262字，預計閱讀時間16分鐘

一、主數據概念

1.1 主數據概念介紹

主數據（Master Data 簡稱MD）， 一般指系統(tǒng)間共享數據（如客戶、賬戶和組織等有共享場景的數據內容），所以其核心的價值就是解決數據的共享與一致性的問題。

根據主數據管理實施的復雜程度，參照Jill Dyche, Evan Levy的觀點大體可以把主數據管理可以分為六個層次，從低到高反映了主數據管理(MDM)的不同成熟度。下面我們簡單介紹一下這六個層次，由于對于一般企業(yè)通常主要應用Level3，所以下面只針對Level0到Level3進行展現介紹，有興趣的同學可以閱讀主數據百科：

(https://baike.baidu.com/item/%E4%B8%BB%E6%95%B0%E6%8D%AE/7310399)

。（復制鏈接至瀏覽器打開）

Level 0 ：沒有實施任何主數據管理(MDM)

在Level 0的情況下，意味著企業(yè)的各個應用之間沒有任何的數據共享，整個企業(yè)沒有數據定義元素存在。由各個系統(tǒng)自己管理自己的數據，共享使用情況是采用網狀交換的方式進行。

Level 1 ：提供列表

提供列表，我們可理解采用了為數據執(zhí)行登記制度，采用手工的方式進行數據信息的登記，包括數據的添加，刪除，更新以及沖突處理。這種模式已經有了數據統(tǒng)一管理，維護的動機，只是模式上成本極高， 高度依賴人工管理的流程也容易發(fā)生錯誤。

Level 2 ：同等訪問(通過接口的方式，各個系統(tǒng)與主數據主機之間直接互聯)

相比提供列表， 引入對主數據的統(tǒng)一登記管理的思路。通過建立數據標準和定義并通過存儲在中央知識庫(Central Repository)中共享訪問，為各個系統(tǒng)間共享使用數據提供了元數據定義的支持。雖然存儲的數據還是按照各個系統(tǒng)分開存儲的，但是由于有了統(tǒng)一的描述定義，以及信息的同步自動更新，在管控能力與成本降低上有了極大的改進。但由于本質還是分散存儲， 管控的成本還是非常高。

Level 3 ：集中總線處理

集中總線處理打破了各個獨立應用的組織邊界，使用各個系統(tǒng)都能接受的數據標準統(tǒng)一建立和維護主數據。集中處理意味著為MDM構建了一個通用的、基于目標構建的平臺。這種方案上對主數據有了非常強的約束與保障，當然引入的建設成本與難度也會相應的提高，特別是主數據的性能、穩(wěn)定性、事務的保障等。

1.2 為何需要主數據？

為何需要主數據？要回答這個問題，我們需要先來分析一下在業(yè)務系統(tǒng)中遇到的問題，我們把問題大致可以總結為以下四類：

數據散亂且冗余浪費

企業(yè)內的每一個系統(tǒng)、應用、甚至業(yè)務部門都會建設自己版本的核心業(yè)務實體數據。最好的例子就是客戶數據的建設，不同的部門都會因為自己特有的需求分別建設客戶數據，例如合同部門的系統(tǒng)會關注客戶與合同相關信息；采購部門則會關注客戶的產品，售后等內容。但對于客戶的主要屬性如客戶名稱和地址信息在企業(yè)內各個角落都被重復的記錄著。這導致了一個很嚴重的問題（除了存儲成本之外），數據冗余導致數據質量過差，對企業(yè)來講也無法更全面去認識一個完整的客戶屬性。

數據不一致，校準難

事實上由于企業(yè)內數據的不一致，導致企業(yè)大量的資源浪費的情況時常發(fā)生，這里浪費的資源不僅包括時間、金錢和人力資源等的浪費，也包括對客戶體驗的影響， 對業(yè)務推進工作的影響等。

業(yè)務協同低效

數據散亂情況一旦發(fā)生，伴隨出現的就是低生產力，低效的業(yè)務管理，無法統(tǒng)一的客戶體驗，客戶不滿意，浪費市場部門的努力等。

變化導致數據無法沉淀

在企業(yè)中，業(yè)務的變化導致項目的啟動與中止是比較常見的情況， 這種高頻的變化中，最不應該被流失就是數據，也就是業(yè)務的沉淀，但沒有主數據業(yè)務的應用，數據流失就會被當作很理所當然的情況。

總結分析上述問題，可以看到這些問題的發(fā)生，最主要的原因就是沒有一個自頂向下的數據治理規(guī)范所導致的。主數據的產生本質也是需要企業(yè)有一個自上而下的數據治理戰(zhàn)略來配合才能高效推動，企業(yè)應該建立一個全企業(yè)范圍的主數據管理，真正去解決主數據問題，而不應該為了逃避建立企業(yè)主數據的成本問題而在原有系統(tǒng)上修修改改。

（https://wenku.baidu.com/view/b7cb9e4e2e3f5727a5e962fa.html?re=view）

。（復制鏈接至瀏覽器打開）

2. 主數據架構實戰(zhàn)總結

2.1 業(yè)務背景分析

主數據建設遇到各種問題和挑戰(zhàn)，主要包含以下幾點：

2.1.1 問題

• 隨著百度小程序業(yè)務增長，業(yè)務模塊務數量激增，都需要對數據有變更與檢索的需求。

• 各業(yè)務服務模塊SLA標準不統(tǒng)一，很難提供一個高可用服務，滿足業(yè)務需求。

• 網狀式的數據存儲，造成數據冗余、數據一致性、數據安全、數據孤島等問題。

• 對數據認知存在差異，多系統(tǒng)、跨產品、跨部門之間數據交互困難，無法做數據統(tǒng)一管理。

2.1.2 挑戰(zhàn)

• 數據邊界劃分，哪些數據要納入主數據？

• 數據模型變更，如何高效管理數據模型？如何高效滿足業(yè)務快速更新迭代？

• 如何保證數據一致性，正確性，以及服務穩(wěn)定性?

• 如何保證數據共享實時性，準確性？

2.2 整體架構設計方案與思路

主數據管理服務本身也是一個不斷優(yōu)化和演進的服務，在實戰(zhàn)過程中不斷探索，理論指導實踐，總結出一套符合百度智能小程序業(yè)務的方法論，我們首先從分析階段開始。

2.2.1 分析階段

目標從需求分析出發(fā)，將問題映射到問題空間，對需求進行梳理抽象，理解問題和需求背景，進行數據和流程分析，分析業(yè)務領域模型，采用數據流圖（Data Flow Diagram）：簡稱DFD，以圖形方式來表達系統(tǒng)的邏輯功能、數據在系統(tǒng)內部的邏輯流向和邏輯變換過程。在確定了全景事件流之后，需要鑒別出領域邊界，通常采用事件風暴方法，進行領域分析建模。

以百度小程序創(chuàng)建使用流程為例：百度小程序創(chuàng)建使用業(yè)務流程分析

百度小程序創(chuàng)建使用流程，事件風暴分析結果：

2.2.2 設計實現階段

將問題空間映射到解決方案空間，抽象業(yè)務領域，領域數據建模，劃分服務邊界，架構設計與實現，設計階段需要根據需求分析，畫出用例圖、狀態(tài)圖、實體類圖、序列圖、ER圖確保用例沒有問題，參考“主數據”設計原則，劃分服務邊界，將數據模型以“切蛋糕”的方式，劃分到不同的子服務域以及主服務域中。

參考數據層次劃分模型理論，提取關鍵概念作為子域，主要劃分了客戶域、產品域、用戶域以及基礎數據域4塊，客戶域圍繞客戶進行建模、產品域圍繞小程序進行建模、用戶域以開發(fā)者模型為主，基礎數據域提供元數據碼表。具體如下：

產品域：小程序、包、類目、等級、權益等業(yè)務的核心數據模型

基礎數據域：小程序類目、宿主等基礎數據模型

用戶域：用戶、角色、權限等用戶域

客戶域：主體、資質等客戶域

2.3 主數據架構設計目標

小程序主數據旨在解決多系統(tǒng)中共享數據問題，提煉小程序業(yè)務核心數據模型，作為基礎服務，為主數據范圍內的核心數據模型提供一套數據治理的解決方案，包括為各個業(yè)務端提供核心數據的存儲、檢索、分發(fā)等服務。

先來看一張圖，下面這張圖就是主數據服務部署架構：

2.3.1 整體設計目標

• 消除數據冗余；保證數據一致性、安全性

• 統(tǒng)一數據認知

• 統(tǒng)一數據管理，提供高可用服務

• 數據共享，提高多系統(tǒng)、跨產品、跨產品、跨部門之間數據協同力，支持數據多場景、多維度分發(fā)

2.3.2 架構設計與實戰(zhàn)

數據傳輸服務概念介紹，數據傳輸服務（Data Transmission Service），支持關系型數據庫、NoSQL、大數據(OLAP)等數據源間的數據傳輸。它是一種集數據遷移、數據實時同步和數據訂閱于一體的數據傳輸服務。數據傳輸在公有云、內部私有云、Paas私有云均有廣泛的應用場景，為用戶打造安全、易擴展、高可用的數據架構。

2.3.3 關鍵技術點實現介紹

2.3.3.1 事務/補償

事務/補償使用場景分析：多表關聯存儲操作，主從延遲敏感場景強制讀主庫，關鍵異常數據定時補償/實時重試。

系統(tǒng)開發(fā)過程中，需重點關注大事務提交，大事務會導致主從延遲、IO負載、數據庫性能下降等，需合理評估事務操作數據量級，大數據批量操作原則：

1. 事務大小要合理

2. 數據量可控

3. 接口耗時可控

對于insert/update/delete操作，每次處理100~500條，執(zhí)行commit

對于select操作，每次查詢100~500條

推薦：在業(yè)務場景可接受范圍內，分批成小事務操作

2.3.3.2 高性能讀寫，高性能檢索

服務高性能主要實現方式，緩存、數據庫優(yōu)化、數據同步解耦等，以主數據服務為例，主要使用提高服務性能手段如下：

緩存方面：對于多讀少寫場景，添加多級緩存【分布式緩存、本地緩存等】減輕數據庫壓力，保證服務橫向擴展。

數據庫優(yōu)化方面：從幾個方面入手，不合理的大批量更新寫入，導致數據庫主從延遲問題；數據庫深度分頁問題；合理使用子查詢優(yōu)化；索引排序問題。

數據庫索引，缺乏合適的索引，一個稍大的表全表掃描，稍微來些并發(fā)，就可能導致DB響應時間急劇飆升，甚至導致DB性能的雪崩。

檢索方面：對于多表檢索、模糊檢索等場景，使用Es特性來滿足高性能檢索。核心關鍵點保證數據庫到Es同步時效性以及準確性。

2.3.3.3 可用性

主數據是各個業(yè)務端對于核心數據操作的唯一服務，必須保證服務的高可用性，主數據實時服務采用微服務架構，利用百度資源虛擬化能力，實現服務治理、統(tǒng)一配置管理、分布式鏈路跟蹤等功能，支持請求負載均衡、重試，服務自我保護（限流、熔斷、降級等），并實現了無人值守的機器故障自愈，充分保障服務可用性。

2.3.3.4 流程機制

設計把關：因主數據的升級，影響面比較廣，建議有專業(yè)化的獨立團隊進行把關，確認設計的質量。

開發(fā)規(guī)范：注重編碼質量，保證編碼規(guī)范統(tǒng)一，定期組織代碼 review，提升代碼可讀性，維護性。

測試驗收：除了自測，單測等工作外，主數據還需要更完善的系統(tǒng)級測試， 能實現多方接入業(yè)務的聯動測試回歸。

上線：小流量， 灰度，自動化回退、封禁管理等能力，上線確認機制。

運維：應用生命周期管理，用戶權限管理，可觀測監(jiān)控能力， 實時監(jiān)控與高效問題定位。

2.3.3.5 高時效性數據同步

主數據實時變更數據的同步方案，基于binlog監(jiān)聽，多MQ并發(fā)寫入支持橫向擴展，保證binlog寫入速度；統(tǒng)一數據接收分發(fā)服務，基于數據版本控制，支持服務橫向擴展，保證數據消費，分發(fā)時效性；數據監(jiān)聽，補償服務保證數據共享可靠性。

下面這張圖就是主數據服務數據同步分發(fā)架構模型：

總結：百度小程序團隊早在2019年就完成主數據服務上線，基于百度小程序核心數據模型，完成數百張數據模型沉淀，最高支持9000+QPS，SLA全年可用性4個9以上，覆蓋百度10+核心業(yè)務產品線接入，保障百度智能小程序整體服務可用性達到4個9以上。數據一致性達到4個9，通過一致性監(jiān)控補償，保證數據最終一致性。

3. 主數據延展思考

3.1 主數據是否還有更多可適用場景？

主數據應用除了服務實時的在線業(yè)務系統(tǒng)外，還有很多場景可以應用。例如 基于主數據做 數據資產的審計與監(jiān)控分析， 將主數據作為重要的數據資產，對其建設、使用等情況進行全面的監(jiān)控，同時對于主數據的更新、變化趨勢，乃至關聯數據進行分析，可以一定程度上改善決策支撐，以及發(fā)現業(yè)務操作上的問題，進行實時審計，促進管理體系的不斷完善和業(yè)務發(fā)展不斷提升。又例如基于主數據承接業(yè)務畫像建設工作，通過主數據本身的數據高實效與正確性的保障，加上主數據比較完善的模型設計， 可以極大的節(jié)省業(yè)務畫像建設的成本。

3.2如何提升團隊的主數據工程能力?

主數據(MDM系統(tǒng))的建設是打造數據思維能力的基礎工作，是一個需要不斷完善進步的過程, 建設過程中涉及所有部門、每一方業(yè)務系統(tǒng)設計者的協同與配合。以下也整理了一下相關的總結，希望可以幫助大家提升主數據的思維能力：

1. 加強大家對主數據的學習與認識，最好在機制上進行對齊。建議有強制要求各業(yè)務方參與建設。

2. 構建單獨的主數據建設團隊，以中立的視角來承接，保障建設的合理性，規(guī)范化與專業(yè)化。

3. 加強模型設計與架構設計的評審工作，確保執(zhí)行過程的效果，同時加強總結，幫助大家的學習，提升能力。

• 深入剖析全鏈路灰度技術內幕

• 愛奇藝基礎數據平臺演進

• Go語言重新開始，Go Modules的前世今生與基本使用

• 大數據平臺架構設計探究

• 冪等設計詳解

技術原創(chuàng)及架構實踐文章，歡迎通過公眾號菜單「聯系我們」進行投稿。

高可用架構

改變互聯網的構建方式