導讀：

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

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

一、主數(shù)據(jù)概念

1.1 主數(shù)據(jù)概念介紹

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

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

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

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

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

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

Level 1 ：提供列表

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

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

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

Level 3 ：集中總線處理

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

1.2 為何需要主數(shù)據(jù)？

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

數(shù)據(jù)散亂且冗余浪費

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

數(shù)據(jù)不一致，校準難

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

業(yè)務協(xié)同低效

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

變化導致數(shù)據(jù)無法沉淀

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

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

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

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

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

2.1 業(yè)務背景分析

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

2.1.1 問題

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

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

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

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

2.1.2 挑戰(zhàn)

• 數(shù)據(jù)邊界劃分，哪些數(shù)據(jù)要納入主數(shù)據(jù)？

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

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

• 如何保證數(shù)據(jù)共享實時性，準確性？

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

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

2.2.1 分析階段

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

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

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

2.2.2 設計實現(xiàn)階段

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

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

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

基礎數(shù)據(jù)域：小程序類目、宿主等基礎數(shù)據(jù)模型

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

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

2.3 主數(shù)據(jù)架構設計目標

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

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

2.3.1 整體設計目標

• 消除數(shù)據(jù)冗余；保證數(shù)據(jù)一致性、安全性

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

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

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

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

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

2.3.3 關鍵技術點實現(xiàn)介紹

2.3.3.1 事務/補償

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

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

1. 事務大小要合理

2. 數(shù)據(jù)量可控

3. 接口耗時可控

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

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

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

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

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

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

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

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

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

2.3.3.3 可用性

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

2.3.3.4 流程機制

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

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

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

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

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

2.3.3.5 高時效性數(shù)據(jù)同步

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

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

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

3. 主數(shù)據(jù)延展思考

3.1 主數(shù)據(jù)是否還有更多可適用場景？

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

3.2如何提升團隊的主數(shù)據(jù)工程能力?

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

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

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

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

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

• 愛奇藝基礎數(shù)據(jù)平臺演進

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

• 大數(shù)據(jù)平臺架構設計探究

• 冪等設計詳解

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

高可用架構

改變互聯(lián)網的構建方式