系統都是為應用而生的，數據中臺也不例外。要構建一套數據中臺服務于企業內部和外部運營，需要有成熟的建設方法論作為指導。數據中臺建設方法論可分為高階規劃、系統設計、開發實施、試運行和持續運營 5 個階段。

1、高階規劃

數據中臺規劃階段可細分為業務架構師主導的業務規劃和數據架構師主導的數據規劃。由業務規劃進行業務輸入，由技術規劃判斷業務規劃藍圖的可行性，最終形成可行的藍圖規劃設計。

1. 業務規劃

業務規劃分為三個步驟：業務調研、藍圖設計和應用設計。

（1）業務調研

業務調研主要包括以下兩方面。

第一，戰略與組織解讀。企業戰略決定了數據中臺的上限，也決定了企業對數據中臺的期望與目標。因此，通過明確企業戰略對企業運營提升的要求，可以明確企業數字化優化的目標與范圍。。

第二，調研訪談。調研訪談是通過問卷或針對性訪談的形式，對業務專家進行調研。在調研的過程中可以通過收集報表、報告、系統建設材料等信息輔助理解業務。

（2）藍圖設計

通過業務調研了解企業，結合數據現狀與業務痛點，將企業不同實體的數據進行提煉、抽象，形成數據域，將數據資產按照一定的體系進行規整，再結合業務訴求對數據分析場景進行提煉，最終形成一張囊括企業數據現狀與未來的藍圖。

（3）應用設計

銜接藍圖設計，結合數據調研的成果判斷數據可行性后，將數據分析場景、智能應用進行系統落地的可視化設計，形成 PRD 文檔和原型進行產品設計與說明。

2. 技術調研

技術調研是對企業的 IT 整體現狀進行摸查，調研內容包含企業主要業務及核心業務系統、信息安全相關要求等。

對企業主要業務和核心業務系統的調研包括業務和技術兩個方向。業務上梳理企業的主要業務及核心業務流程，技術上則梳理各業務系統及它們之間的數據流轉關系。

通過信息安全相關的調研了解企業內與信息安全相關的組織部門、規章制度等信息和要求，為后續制定數據處理和使用的流程規范提供依據。

3. 系統和數據調研

系統與數據調研的目的是厘清企業數據資源的種類、分布、存儲及管理現狀。系統與數據調研是按業務系統進行盤點的。

業務流程及動作的調研，需要從使用者的角度出發，確認業務系統每個原子操作產生了哪些數據，數據存儲在哪些數據表中。

數據源盤點需關注數據源種類，如結構化、半結構化和非結構化數據，以及鏈接地址、賬號、密碼、可抽取數據的時間段等；數據表級別關注是否為核心表、時間戳字段、數據更新標識、表的總數據量、日增數據量等信息。

系統與數據調研完后，需輸出相應的產出物，并與業務系統的相關人員就輸出物中的產出項進行溝通和確認。

4.總體規劃輸出

規劃階段包含業務側和技術側的調研，可以并行開展。在業務側完成調研及需求規劃后，技術側需要結合業務側的產出進行相關的數據探查事項，主要目的是確認調研產出是否足夠支撐業務規劃的數據應用建設。

總體規劃在最終定稿后，業務側需輸出指標、標簽清單、數據應用規劃文檔等，而技術側需輸出技術和系統調研的相關輸出物，以及系統調研階段的總結性報告。

2. 系統設計

系統設計包含總體設計、數據設計及平臺設計。

1.總體設計（數據架構、平臺架構和研發規范）

第一階段的規劃工作完成后，進入總體的架構設計階段。由阿里巴巴提出的 OneData 的核心思想是統一數據主體、統一數據建模、統一數據服務以及一系列的數據管理體系。在設計階段，可以參考這幾個方面進行考慮與架構。如下圖所示。

（1）數據架構

數據中臺的數據架構設計是基于需求調研階段的業務需求、數據情況，完成數據中臺概要設計工作。數據架構設計主要包含 OneModel 、OneID 和 OneService 。

1. OneData

數據中臺就是要在整個企業中形成一個公共數據層，實現數據的復用，所以強調數據只加工一次，不會因為不同的應用場景造成數據重復加工。

如何實現：

數據劃分主題進行管理：表的命名，字段的命名等規范統一，做到見名知義

數據格式和字段命名和定義規范化：具體參考離線數倉項目講解的表和字段命名規范：數倉分層-業務主題域-業務過程-基礎信息-分區規則

指標一致：提供全局數據字典確保意義一致。

數據模型復用：推薦采用分層的設計方式，通常包括：ODS，DWD，DWS，ADS / DM，DIM。

數據完善：數據中臺盡可能的覆蓋到所有業務過程，用戶和系統的一切行為都被記錄下來永久保存OneData 體系的目標是構建統一的數據規范標準，讓數據成為一種資產，而不是成本。

OneModel 可分為以下四部分。

業務板塊：根據業務的特點和需求將相對獨立的業務劃分成不同的業務板塊，不同業務板塊之間的指標或業務重疊度較低。數據域是指面向業務分析，將業務過程或者維度進行抽象的集合。數據域劃分上，需要從三個方面進行考慮。

1）全局性：站在企業高度上，保障良好的擴展性和穩定性。

2）數量適中：根據業務情況，劃分的粒度要粗細合適，通常在 5～15 個。

3）可理解：站在業務的角度上，確保劃分便于理解，不產生歧義。

在劃分數據域時，既要涵蓋當前所有業務的需求，也要考慮有新業務的彈性擴展。

總線矩陣：在進行了充分的業務調研和需求調研后，就要構建總線矩陣了。總線矩陣由業務處理過程和維度組成一個二維表格。在行為不同的業務處理過程與維度的交叉點上打上標記，表示該業務處理過程與該維度相關。

數據分層：數據模型以維度建模理論為基礎，建設數據中臺的公共數據層。一般將數據模型劃分為操作數據層（ODS）、通用數據模型層（CDM）和應用數據層（ADS）。

OneID 功能包含以下四部分。

OneID 配置：主要根據具體的業務需求，完成數據源表、ID 映射表、歧義規則表的設置工作。

OneID 數據處理：主要通過數據源表和 ID 映射表等配置表單完成原始數據的數據拉取和清洗等操作，生成基礎數據。

OneID 規則計算：主要利用圖計算框架完成關鍵連接點的搜索和歧義數據的圖連通工作，并根據配置的規則對圖數據進行切割，從而唯一確定一個實體的身份信息，生成 OneID。

OneID 數據存儲和展示：主要完成 OneID 圖數據存儲和展示，以及最后生成的 OneID 清單數據存儲等。

OneService 統一數據服務

OneService 包括以下功能模塊：服務單元設計、API 設計、API 審核和 API 運營。服務單元設計是指將單個或多個物理表配置成一個視圖。基于配置好的服務單元，通過簡單可視化界面或 SQL 腳本，設計 API 的請求參數和返回參數。API 設計好后，將其發布至服務市場供使用者調用。API 在被使用前，需要經過申請審批。被使用的 API 需要運維及監控，包括平均響應時長、調用次數、錯誤率等指標的監控，還可以配置 API 的告警及限流措施等。

（2）平臺架構

結合前期調研的業務需求和數據現狀，從宏觀層面規劃出數據中臺的各個模塊、各個功能部件所用到的技術總體架構圖。

采集架構：數據采集打通各種數據來源，為數據中臺提供待分析和處理的數據，主要分為實時和離線數據采集。

存儲架構：整個存儲架構包含原始數據源存儲技術、數據源接入技術、數據中臺數據存儲與計算技術、數據服務及數據應用技術。

數據流：從業務數據進入數據采集通道，到進入數據中臺在各個加工任務中流轉，再到數據對外服務的這個過程，需要進行哪些存儲、哪些技術處理等，這些步驟需要在設計時就以數據流向用流程圖的形式畫出。

網絡架構：數據中臺涉及與多方的源系統進行數據交互，而網絡設計對于后續數據同步、接口調用等有較大影響。

部署架構：這部分設計主要涉及數據中臺的研發平臺與應用軟件。需包含整體的部署方案。

安全架構：主要包含研發平臺的用戶角色權限控制方案、開發與生產環境隔離方案、數據安全方案。

（3）數據模型設計規范與標準

良好的數據模型可方便、有效地組織數據中臺中存儲的企業數據資產，所以數據模型的設計工作有必要遵循一定的規范和約束。

2. 數據設計 （數據集成、模型設計和服務詳設）

數據設計包括數據集成、模型設計和服務詳設，如下圖所示。

（1）數據集成

數據集成需要解決不同源系統數據異構性問題。

結構化數據一般以二維形式存儲在關系型數據庫中，對于這種數據類型，數據集成有 3 種方式。

直連同步：通過規范的 API（如 JDBC）直接連接業務庫。但是業務庫直連的方式對源系統的性能影響較大，當執行大批量數據同步時會降低甚至拖垮業務系統的性能，此種抽取方式性能較差，不太建議使用。

數據文件同步：通過約定好的文件編碼、大小、格式等，直接從源系統生成數據的文件，由專門的文件服務器加載到數據中臺。但由于要保證數據文件的完整性，通常除數據文件外，還需要上傳校驗文件，供下游系統做數據校驗。

數據庫日志解析同步：這種方式實現了實時與準實時同步，延遲可以控制在毫秒級別，并且對業務系統的性能影響比較小，目前應用較為廣泛。

除了數據讀取的方式，還可按數據量來分解數據集成策略。

小數據量同步：數據記錄小于 10 萬條的源表建議每日全量更新，寫入全量分區表。全量分區表可按天創建。可根據業務需要設置數據的生命周期，并定時清理。

大數據量同步：數據記錄大于 10 萬條的源表通過時間戳抽取增量數據到增量分區表。增量分區表可設置長周期，根據需要設置冷、溫、熱數據區。

非結構化數據一般沒有固定的結構，各種文檔、圖片、視頻、音頻等都屬于非結構化數據。對于這類數據，數據集成策略通常是直接整體存儲，而且一般存儲為二進制的數據格式。

除了結構化數據和非結構化數據，還有半結構化數據，常見的數據格式有 JSON 和 XML。對于半結構化數據，數據集成策略同樣可以是直接整體存儲。但隨著數據技術的發展，NoSQL 數據庫已經可以很好地支持半結構化數據的存儲。NoSQL 主要有 4 種模型。

鍵值模型：鍵值模型在表現形式上比較單一，但卻有很強的擴展性。

列式模型：由于每列可以動態擴展，列式模型相比鍵值模型能夠支持的數據更為復雜。

文檔模型：文檔模型對于復雜數據的支持和在擴展性上都有很大優勢。

圖模型：使用場景通常基于圖數據結構，如社交網絡、推薦等。

（2）模型設計

數據模型可以分為主題域模型、標簽模型和算法模型。主題域模型是基礎，是對數據標準化、規范化的過程。標簽模型基于主題域模型將對象的各種標識打通歸一，將跨業務板塊、跨數據域的對象組織起來。算法模型基于主題域模型，將各對象的歷史行為、屬性等數據作為輸入，利用算法能力分析和預測對象的行為。

主題域模型設計。主題域模型也就是大家常說的數倉模型，最權威的數倉模型設計是 Kimball 的維度建模。阿里巴巴基于維度建模，沉淀了 OneModel 方法論。

主題域模型可分為以下三層。

操作數據層（Operational Data Store，ODS）：主要將業務系統、日志等結構化和半結構化數據引入數據中臺，保留業務系統原始數據。ODS 分為緩沖區和數據服務區。緩沖區保證 ODS 能原樣引入所接入的源數據，不進行任何類型轉換。數據服務區是對緩沖區數據進行類型轉換或增量合并處理后得到的，為通用數據模型層和應用數據層提供數據服務。引入緩沖區是考慮到數據引入后可能會有一些特殊的處理需求，比如JSON 格式數據，需要在解析后再引入。

通用數據模型層（Common Data Model，CDM）：包含整個數據中臺的大部分數據，是數據中臺的基礎，因此保證該層數據的健壯性是重中之重。主要完成公共數據加工與整合，建立一致性的維度，構建可復用、面向分析和統計的明細事實表及匯總事實表。

應用數據層（Application Data Service，ADS）：提供直接面向業務或應用的數據，主要對個性化指標數據進行加工處理；同時為方便滿足數據應用、數據消費的訴求，進行面向應用邏輯的數據組裝，比如大寬表集市、橫表轉縱表、趨勢指標串等。

標簽模型設計。企業的重要數據資產，如客戶、商品、門店、供應商、員工等實體的標簽模型都是數據中臺加工的重點。比如，先獲取商品的生產、采購、定價、銷售、退貨等歷史行為數據，然后按照業務場景需要來制定商品所涉及的商品標簽，形成商品標簽模型。

算法模型設計。數據中臺整合全域的數據，需要通過 AI 算法將寶貴的數據形成有價值的數據資產。算法模型是最能將企業的數據資產發揮出幾何倍數價值的模型。例如，憑借商品個性化推薦模型，淘寶的“千人千面”場景幫助用戶極大提升了體驗感。

（3）服務詳設

數據服務按數據內容可分為主題分析類數據服務、標簽類數據服務和算法類數據服務。

主題分析類數據服務可通過整合數據分析場景，分專題設計通用的數據匯總寬表，通過數據寬表拼寫不同的 SQL，支撐相應的數據報表，避免數據的冗余建設。

標簽類數據服務的設計卻有所不同，切忌按照標簽使用場景逐個進行數據服務設計。因為運營可能會隨時增加標簽，迫使在設計標簽服務時考慮通用性和擴展性。一般建議以底層的標簽寬表為出發點，設計標簽通用的增加、修改和查詢功能。

與業務聯動緊密的算法類數據服務則需要注意可能直接面對低延遲、高并發的調用場景，比如推薦場景，包括搜索推薦、猜你喜歡、加購推薦等，一定要做好服務接口的性能壓測，以滿足業務實時交易級的性能要求。

除了考慮服務的通用性和性能，還需要考慮服務開放的數據安全性。

3. 平臺設計（資源規劃、技術選型、部署方案）

平臺設計指的是大數據運行平臺在資源規劃、技術選型、部署方案等方面的設計。臺設計階段將以客戶現有數據體量及可預測的業務增長情況作為考量因素，對平臺建設所需的資源進行預估和規劃，產出平臺及數據應用部署所需的資源清單、部署方案及相關人員在平臺上的賬號和權限的設計等。

1、資源規劃：需要對支撐大數據平臺所需的資源進行估算。一般可考慮未來 3 年企業的數據量。

數據中臺架構應該具備的能力

1、基礎設施/基礎平臺、存儲引擎、計算引擎、輔助服務

2、數據集成

3、數據開發

4、工作流調度

5、數據治理：數據質量、元數據管理、數據安全

6、數據可視化

7、DevOps

6、其他數據服務

2、技術選型：

大數據技術選型的原則是考慮當前及未來一段時間可能使用的場景，根據場景來推導技術的選擇。

3. 開發實施

開發實施階段可分為環境搭建、數據集成、代碼研發三個層面。

1. 環境搭建

平臺層面的環境搭建，包括大數據集群、數據研發平臺、智能數據應用產品等相關工具的部署。平臺的搭建按設計階段輸出的資源規劃和平臺部署方案實施即可。部署后，需要對平臺環境進行測試，同時在產品工具層面，需要對企業進行相關產品的使用培訓。

2. 數據集成

數據集成方案從宏觀上設計和規范了數據源級別的數據集成流程和同步策略。在當前階段，需要對各數據源制定表級別的集成策略，形成數據同步清單，包括上云數據存量、日增量、數據更新頻率等相關信息，供具體實施時使用。實施后，還需要逐一對數據源表進行數據監控及驗證。

3. 代碼研發

代碼研發階段包括數據研發與驗證、應用研發與測試、性能測試三部分。數據研發與驗證主要包括數據模型的業務代碼開發、數據監控代碼開發、數據準確性驗證。研發與測試主要包括數據應用層面的開發和測試工作，如數據服務、數據應用前端開發。性能測試包括數據產出時間、數據接口服務性能等方面的測試。

4. 試運行

數據中臺上線之后，分析專題的指標口徑、數據應用效果等多方面的數據準確性都需要通過真實的運行數據去驗證。通常需要進行一段時間的試運行。

1.中臺試運行

為保障生產環境數據的準確性，需要先在測試環境基于企業全量的數據進行一段時間的試運行，主要包含以下步驟。

1）數據遷移：增量模型涉及的存量數據需進行一次全量的數據遷移，以保證數據的完整性，全量模型則直接按頻度進行抽取即可。

2）數據跑批：完整運行數據中臺的全流程任務，包括數據抽取、加工、服務提供及應用展現，分析各層級模型任務的運行耗時以及對應時間段的資源情況，并不斷優化和調整。

3）數據驗證：篩選核心關鍵指標、標簽，進行數據準確性的驗證，例如存量指標可與系統現有指標進行對比，增量指標則與模型設計內容逐層對比。

4）應用驗證：對于對外服務接口類應用，聯系應用方進行接口及數據的驗證，并完成應用全流程的拉通，優化調用的頻次及時間點。

2.歷史數據重跑和測試

在試運行過程中，數據中臺的指標或標簽可能會因為業務側的口徑變更而進行歷史數據的重刷動作。在這種情況下，要保證數據準確且可逆，需注意以下事項。

影響評估：評估業務變動涉及的模型。

數據備份：數據處理前，先備份當前狀態下的數據。

口徑調整：確認業務口徑調整涉及的技術口徑調整內容，并體現在模型設計文檔的版本控制中。

數據驗證：調整后，嚴格按照設計內容進行數據的驗證和測試，并與業務側達成一致，在測試環境中進行確認。

5. 持續運營

在數據中臺正式上線后，隨著企業業務的不斷拓展，會接入更越來越多的數據源。同時，某些數據應用會因為企業業務方向的調整而廢棄，就需要及時清理。作為數據中臺的建設者，不僅需要定期與數據使用者主動溝通，了解數據使用情況，還要通過系統查看指標、標簽等資產的調用情況，以此判斷是否需要優化。

1.正式上線

試運行穩定執行一段時間后，可按模塊和迭代申請生產環境的正式上線。正式上線時，分以下兩步進行。

1）割接方案。如果數據中臺存在替換現有其他系統的情況，就需要制定割接方案，以保障數據中臺能夠覆蓋舊系統的數據能力。

2）上線預演。在正式上線前，需進行割接或上線的演練操作，盡可能多地暴露數據、環境、資源等各方面的問題。

系統上線后，制定相關的檢查規則及告警機制，以保障數據中臺的正常運行。大致分為如下兩類。

數據規則：數據一致性，主鍵唯一性，數據完整性。

資源規則：服務器資源，如 CPU、I/O 等，以及存儲告警規則。

2.運營保障

系統上線以后，跟進系統的運行情況，綜合分析以提煉新的需求點。運營策略可從產品、應用、數據三方面進行。

產品側：收集直接使用方的產品體驗狀況，根據反饋內容進行優化，提高產品的易用性，增強使用方對產品的黏性。

應用側：分析應用對象的重點關注模塊，并階段性地形成分析報告。中臺建設者可根據報告內容，對接應用相關人員，持續挖掘新的需求內容。

數據側：通過數據鏈路跟蹤的結果，總結階段性重點關注的數據內容。結合自上而下和自下而上兩種途徑，分析整個系統數據層面的缺口，并制定匯聚及擴建計劃，提高中臺數據支撐的力度。

睿治數據治理平臺是由億信華辰完全自主研發的、開創性的、一站式綜合數據治理整體解決方案。睿治數據治理平臺融合數據集成、數據交換、實時計算存儲、元數據管理、數據標準管理、數據質量管理、主數據管理、數據資產管理、數據安全管理、數據生命周期管理十大功能模塊，打通數據治理各個環節。十大功能模塊可獨立或自由組合使用，快速滿足政府、企業各類不同的數據治理場景，助力數據標準落地，提升數據質量，實現數據資產化。

億信華辰還將成熟的數據治理產品與豐富的實戰經驗相結合，精心打磨面向數字化轉型不同階段的數據治理全域解決方案，8大方案覆蓋數據資產盤點、數據標準與質量管控、倉湖一體化、數據中心等多個領域，針對所有數據問題，對癥下藥，各個擊破，助力數據標準落地，提升數據質量，實現數據資產化，為客戶持續賦能。

如今，睿治數據治理平臺以平臺化、智能化、可視化的優勢，成功應用于政府、金融、能源、制造、教育等不同行業，擁有豐富的數字化實踐經驗，廣受客戶好評。未來，億信華辰將將繼續深耕行業，不斷加強企業技術實力和產品優勢，幫助客戶實現由“人管數”到“智能化管數”的質的飛躍，賦能我國數字化轉型和數字經濟高質量發展。