6000 字長文，終於將數據中臺架構體系講明白了

當前，大部分企業不再建設從源數據採集到分析應用的煙囪式系統，更傾向於數據集中採集、存儲，並應用分層建設。這種方式一方面有利於應用系統的快速部署，另一方面也保證了數據的集中管理與運營，體現數據的資產、資源屬性。

數據中臺的出現彌補了數據開發和應用開發之間由於開發速度不匹配而出現的響應力不足等缺陷問題。

數據中臺是國內學者提出的概念，起始於阿里的 “大中臺、小前臺” 概念。阿里的中臺是從管理的角度出發，以中臺事業部集中數據搜索，技術及產品，數據共享等多個部門的功能。其他組織或企業建設數據中臺不一定需要成立中臺事業部，但是數據集中治理與提升數據價值轉換效率的思路是一致的。

— 01 —

數據中臺通用體系架構

不同的企業對數據有不同的需求。企業數據應用不斷更新迭代，企業的中臺系統也需要不斷變化。

從數據處理與數據治理兩個維度出發，可以設計一個解耦的數據中臺體系架構。該數據中臺體系架構具有一定的柔性，可按照企業應用需求進行組合，或者對單個模塊進行擴充，能滿足大多數企業數據中臺建設的需求。

數據中臺體系架構示例

數據中臺的通用體系架構如圖 2 所示。該中臺體系架構以減少功能冗餘和提高功能複用爲原則，把數據中臺解耦爲 6 個可以分別獨立建設、演進的功能子系統。

數據結構與數據處理子系統是數據中臺體系架構的核心，數據治理是提升數據價值的重要手段。該數據中臺體系架構的通用性表現在以下幾點。

1、數據存儲框架

數據中臺的核心是數據，數據通過採集系統獲取，然後數據經過處理框架加工，並接受數據治理框架的管理，同時也要接受數據安全管理框架的管理，最後開放的價值數據將通過數據運營框架對外提供數據服務。

數據中臺的數據架構應該獨立規劃，並採用合理的技術架構對不同類型的數據進行存儲。

數據存儲框架中，無論數據採用對象存儲、塊存儲還是數據庫存儲技術，各種中臺數據可按照上圖所示分類管理。

源數據主要由採集框架進行管理，數據治理框架按照數據特徵把數據簡單分爲結構化和非結構化數據兩大類，而規範化分域數據則是數據治理框架對全量數據的規範化分域整理。寬表數據是數據關聯的結果，利用寬表數據可以對人、事、地、物、組等對象進行完整的數據畫像，同時寬表數據也可以作爲上層模型數據的中間層數據。

元數據和標籤數據都是對數據的描述，其中元數據用來對數據的客觀屬性進行表示，標籤數據更傾向於管理者對數據的主觀表述及等級劃分，比如質量等級標籤、安全標籤、屬性標籤等。主數據需要在各系統間頻繁更新、交換，且需要獨立的存儲空間進行維護管理。

2、數據採集框架

數據中臺的採集框架應對納入數據中臺的各種源數據進行統一採集管理。數據採集框架中應提供多種數據採集方式，如文件傳輸協議採集、數據庫採集、接口應用程序接入採集、流式採集及網絡爬蟲採集。

同時採集框架應按照數據採集規範對源數據進行預處理，從而去除明顯不需要的數據及多餘數據，並對採集過程進行管理。雖然數據中臺的體系架構沒有統一模板，但各企業數據採集框架基本一致。

3、數據處理框架

數據處理是每個數據應用的基本環節之一，經典的數據抽取、轉換和加載（ETL）處理流程在數據採集預處理、數據整合、數據建模等多個地方均要使用。單獨建設數據處理框架有利於數據處理工具組件的集中開發與管理，也有利於數據中臺數據處理任務的協調與調度。

數據處理框架專門負責數據處理相關的任務，包括批處理、流處理、人工智能分析、數據清洗、數據交換及查詢，此外數據處理的相關工具組件可在處理框架中配置。任務調度模塊在數據處理框架中處於居中指揮的作用，並對運行的數據處理任務進行監控及異常處理等操作。

4、數據治理框架

廣義的數據治理不僅包含提升數據價值的內容，如數據管理、數據目錄、數據質量等，也包含數據安全管理及數據共享服務。

數據安全管理與數據價值提升是一個矛盾體，如果由一個廠商或開發團隊進行數據安全管理及數據價值提升相關軟件的開發，則開發者的操作難免有所偏向，而且矛盾不容易公開，少了衝突也就少了優質的解決方案。

另外，數據共享與數據治理的其他內容也存在相同的問題。因此，本文建議數據中臺的數據治理框架中不包含數據安全與共享的相關內容。

數據治理框架包含數據目錄、數據管理、模型管理和數據質量 4 個模塊：

5、數據安全框架

數據已經成爲數據資產，數據安全框架是數據中臺必不可少的組成部分。數據安全疊加在數據中臺其他功能框架之上，數據採集、處理、交換、共享等每個環節均必須實施安全控制策略。安全框架可以分爲日誌管理、用戶認證、權限管理及加解密等幾個功能模塊。

此外，安全全門戶也可以對外提供安全能力封裝，展示數據中臺的安全態勢及安全視圖。

6、數據運營框架

數據中臺的核心功能是綜合衆多數據應用的數據處理及數據治理功能，集中建設、集中管理、減少冗餘、增加複用。數據中臺的最終目的還是爲其他應用或開發者提供數據服務，而對外數據服務功能將直接面向不確定的外部對象。

因此單獨建設數據運營，一方面有利於針對外部用戶提供針對性功能；另一方面，數據運營模塊作爲用戶與數據中臺核心數據服務之間的中間層，可以有效隔離外部用戶直接控制、接觸核心數據及應用，可保護數據中臺的安全性及內部功能的穩定性。

綜合以上因素，數據運營應配置運營門戶、能力開放、數據開放及運營監控等功能：

_— 02 —_

數據中臺典型架構

數據中臺的目標是讓數據持續用起來，通過數據中臺提供的工具、方法和運行機制，把數據變爲一種服務能力，讓數據更方便地被業務所使用。下圖所示爲數據中臺總體架構圖，數據中臺是在底層存儲計算平臺與上層的數據應用之間的一整套體系。

數據中臺總體架構圖

數據中臺屏蔽掉底層存儲平臺的計算技術複雜性，降低對技術人才的需求，讓數據的使用成本更低。通過數據中臺的數據匯聚、數據開發模塊建立企業數據資產。通過資產管理與治理、數據服務把數據資產變爲數據服務能力，服務於企業業務。數據安全體系、數據運營體系保障數據中臺可以長期健康、持續運轉。

1. 數據匯聚

數據匯聚是數據中臺數據接入的入口。數據中臺本身幾乎不產生數據，所有數據來自於業務系統、日誌、文件、網絡等，這些數據分散在不同的網絡環境和存儲平臺中，難以利用，很難產生業務價值。

數據匯聚是數據中臺必須提供的核心工具，把各種異構網絡、異構數據源的數據能夠方便地採集到數據中臺進行集中存儲，爲後續的加工建模做準備。數據匯聚方式一般有數據庫同步、埋點、網絡爬蟲、消息隊列等；從匯聚的時效性來分，有離線批量匯聚和實時採集。

2. 數據開發

通過數據匯聚模塊匯聚到中臺的數據，沒有經過什麼處理，基本是按照數據的原始狀態堆砌在一起的，這樣業務還是很難使用。數據開發是一整套數據加工以及加工過程管控的工具，有經驗的數據開發、算法建模人員利用數據加工模塊提供的功能，可以快速把數據加工成對業務有價值的形式，提供給業務使用。

數據開發模塊主要是面向開發、分析人員，提供離線、實時、算法開發工具以及任務的管理、代碼發佈、運維、監控、告警等一些列集成工具，方便使用，提升效率。

3. 數據資產體系

有了數據匯聚、數據開發模塊，中臺已經具備傳統數倉平臺的基本能力，可以做數據的匯聚以及各種數據開發，就可以建立企業的數據資產體系。之前說數據資產體系是中臺的血肉，開發、管理、使用的都是數據。大數據時代，數據量大，增長快，業務對數據的依賴也會越來越高，必須考慮數據的一致性和可複用性，垂直煙囪式的數據和數據服務的建設方式註定不能長久存在。

不同的企業因業務不同導致數據不同，數據建設的內容也是不同的，但是建設方法可以相似，數據要統一建設，筆者建議數據按照貼源數據、統一數倉、標籤數據、應用數據的標準統一建設。

4. 數據資產管理

通過數據資產體系建立起來的數據資產還是一套偏技術的數據體系，業務人員比較難理解。資產管理是以企業全員更好理解的方式，把企業的數據資產展現給企業全員（當然要考慮權限和安全管控），數據資產管理包括對數據資產目錄、元數據、數據質量、數據血緣、數據生命週期等進行管理和展示，以一種更直觀的方式展現企業的數據資產，提升企業的數據意識。

5. 數據服務體系

前面利用數據匯聚、數據開發建設企業數據資產，利用數據管理展現企業的數據資產，但是並沒有發揮數據的價值。數據服務體系就是把數據變爲一種服務能力，通過數據服務讓數據參與到業務，激活整個數據中臺，數據服務體系是數據中臺存在的價值所在。

企業的數據服務是千變萬化的，中臺產品可以帶有一些標準服務，但是很難滿足企業的服務訴求，大部分服務還是需要通過中臺的能力快速定製。數據中臺的服務模塊並沒有自帶很多服務，而是提供快速的服務生成能力以及服務的管控、鑑權、計量等功能。

6. 運營體系和安全體系

通過前面的數據匯聚、數據開發、數據資產、資產管理、數據服務，已經完成了整個數據中臺的搭建和建設，也已經在業務中發揮一定的價值。

運營體系和安全體系是數據中臺得以健康、持續運轉的基礎，如果沒有它們，數據中臺很可能像個一般項目一樣，一期搭建起平臺、建設部分數據、嘗試一兩個應用場景之後而止步，無法正常地持續運營，不能持續發揮數據應用價值。這也就完全達不到建設數據中臺的目標。

— 03 —

12 張企業數據中臺架構圖

一、技術中臺架構圖

中臺概念出現之前，在信息化模式上，前端爲支撐業務的應用端，後端爲各個應用系統，爲前端用戶，如：客戶、供應商、夥伴、社會，提供服務，但隨着市場、用戶需求、業務的多變性，底層僵硬的應用無法及時提供支撐。

企業需要一個強大的中間層爲高頻多變的業務提供支撐，爲不同的受衆用戶提供多端訪問渠道，基於此類需求 “中臺” 概念出現，接着開始對企業客戶、中間件廠商、數據平臺廠商、甚至傳統應用軟件廠商都有較大的概念衝擊。

恰逢此時，微服務技術和架構、容器化的生態、Devops 概念和工具處於大發展的階段，最後基於 “大中臺、小前臺” 的信息化建設模式開始流行。

二、銀行數據架構體系

數據架構層面通過數據分類、分層部署等手段，從非功能性視角將數據合理佈局。通過整體架構管控和設計，支持業務操作類和管理分析類應用（系統），滿足業務發展及 IT 轉型對數據的需求，架構的擴展性和適應性能夠提升數據分析應用的及時性、靈活性和準確性。

那實際情況下各個銀行的數據架構體系會有所不同，根據各行的業務發展、客戶數據量、交易數據量、功能需求等會有不同的演變路徑以及發展方向。

一般國有銀行、股份制銀行等全國性的銀行業務較複雜，數據量也較多，數據架構也因此進化較快。常見的數據架構分區如下圖所示：

三、零售行業中臺架構

這是一張混合了技術和業務的中臺邏輯架構示意圖，前臺應用部分我們將零售和消費品行業需要對接消費者的若干應用系統一一列舉了出來，但是在中臺架構下它們已經和傳統的 “應用系統” 有了很大的差別，變得非常“輕量”。

四、業務中臺架構

前臺跟着界面走，天生就穩定不了，總是有五花八門的數據請求，這是必然的事情。

後臺應該主要負責數據存儲，把不同形式和規模的數據以合適的方式整理好，大數據倒騰起來動靜太大，要求有一定的穩定性。

如果前臺的請求都要求後臺直接做，那後臺管的事就太多了。

五、後臺架構

後臺是被許多前臺共享的，如果直接向前臺提供靈活數據服務，還可能導致各個前臺之間的耦合程度變高，維護成本立即陡增。

同樣的，把這些數據處理放在前臺也不合適，一方面不太安全，另一方面，前臺團隊也是忙着讓界面如何更好看使用更流暢，沒太多工夫琢磨數據的事情。這樣一個後臺架構就能夠相對平衡這一矛盾。

六、實時數據中臺

下面是實現實時數據中臺的一種邏輯架構，方便你去理解，其實最關鍵的是實時模型那一層

七、企業級中臺發展過程

我用下面這張圖來概括中臺發展的三個階段，最終我們發現，對於那些已經有 ERP 系統的企業來講，中臺的建設本質就是利用微服務架構構建開放業務平臺來替換閉源單體架構的 ERP 系統的過程。

八、阿里中臺架構

中臺是一種架構理念和方法。任何一種架構的方法，其本質不外乎，利用分、合、打散、重組等技術手段，對系統進行有序化重構，以達到減少系統 “熵” 的過程，使系統得以不斷進化。

九、阿里核心架構圖

通過阿里雲平臺將技術中臺進行部署，對集團內共享業務單元提供支撐，並最終對前臺各業務線提供服務化能力輸出。

十、全渠道零售中臺

如果僅僅是把所有的東西打包在一個 “大後臺” 並不能真正解決 IT 的痛點，因爲畢竟它是一個 IT 系統。IT 系統要考慮的東西除了業務功能，更重要和更有價值的地方在於：

十一、全渠道集成架構

2007~2012 年是 “集成模式” 概念被拋出率最高的年代，它有一個名字叫“SOA”，SOA 就是那個時代的“全渠道中臺”

十二、網易嚴選數據中臺體系

數據中臺的核心職責是高效地賦能數據前臺爲業務提供價值。要想理解數據中臺先要理解數據前臺，上文說到的搜索、推薦、BI 報表、數據大屏等都屬於數據前臺。

— 04 —

6 種行業數據中臺解決方案

▲地產行業解決方案

▲證券行業解決方案

▲零售行業解決方案

▲製造行業解決方案

▲傳媒行業解決方案

▲檢務行業解決方案

寫在最後的話

建設數據中臺，實現企業或機構數據資產的高效管理和數據價值最大化，爲機構帶來了數據平臺化的運營機制，有望解決應用開發與數據開發速度不匹配的問題。利用數據中臺，可以將機構的核心技術或團隊凝聚在一起，建設機構內強大的數據開發、運營等團隊，提升機構的團隊的硬實力和軟實力。

雖然一個良好的架構對一個信息系統的後期擴容及運維有重要作用，但總體架構設計只是數據中臺建設的第一步，每一個功能模塊還有很大的細化空間，如不同類型數據的存儲技術選型、數據安全合規審計技術、數據模型設計等。在具體項目中，數據共享與安全保護的平衡點、新技術的引用等，都需要進一步細化研究。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/IY7ktI9_ioaqUNWwB31HbQ

猜你喜歡