万字长文精华之数据中台构建五步法
陳新宇?羅家鷹?江威?鄧通
讀完需要
24
分鐘速讀僅需 8 分鐘
陳新宇
云徙科技聯合創始人兼首席架構師，中國軟件行業協會應用軟件產品云服務分會“數字企業中臺應用專家顧問團”副主任專家，香港中文大學計算機科學與工程學博士，領導云徙科技數字中臺系統的規劃、建設并賦能企業落地實施。曾負責并參與大型企業管理軟件基礎架構和開發平臺的設計與研發。此外，還曾參與數據庫的自然語言交互、分布式系統、軟件可靠性等多項學術性研究項目。
羅家鷹
云徙科技副總裁，上海交通大學學士，中山大學 MBA。近四年來，一直致力于阿里中臺賦能數字商業的研究與布道。曾任金蝶軟件（中國）有限公司 IT 規劃首席顧問、用友網絡電子商務事業部總經理。擁有 20 年的企業咨詢及服務經驗，先后主導了數十家大型企業的數字化轉型咨詢方案。
江 威
云徙科技地產事業部總經理，領導中臺在地產方面的建設與落地，長期從事阿里中臺賦能地產行業的研究與布道，擁有豐富的地產項目實施經驗。曾任明源云、阿里云地產行業等業務總監，具備豐富的地產行業業務及產品經驗，先后主導過萬科、保利、新城、富力等多家大型地產的數字化項目。
鄧 通
云徙科技汽車事業部總經理，香港中文大學信息工程碩士，專注于汽車行業數字化營銷研究。曾多次創業，涉足社群電商、智能家居、互聯網＋農業 S2B2C 中臺項目，先后主導過長安汽車、一汽集團、長安福特等頭部車企以及博郡汽車、愛馳汽車等新能源車企基于汽車行業中臺的數字化營銷項目。
1
? ?
數據中臺構建五步法
系統都是為應用而生的，數據中臺也不例外。要構建一套數據中臺服務于企業內部和外部運營，需要有成熟的數據中臺建設方法論作為指導。企業建設數據中臺遵循的方法論就像菜譜，初學者根據菜譜按部就班就可以輕松完成一道道菜肴，高階玩家根據菜譜可以查漏補缺，使廚藝精進。數據中臺建設方法論可分為高階規劃、系統設計、開發實施、試運行和持續運營 5 個階段，如圖 4-6 所示。
圖 4-6 數據中臺建設五步法
1.1
? ?
高階規劃
萬丈高樓平地起，規劃階段之于數據中臺建設，就相當于構建一座水庫前的勘察和分析，了解建水庫目標、水源、蓄水、水庫下游，為設計圖紙提供基礎支持。同樣建設數據中臺也需要對企業的數據源、存儲數據的方式、數據服務訴求等信息進行摸查，構建未來的藍圖。對現狀和將來了解得越清楚，對數據中臺的輪廓就了解得越清楚，數據中臺的成功就越有保障。數據中臺規劃階段可細分為業務架構師主導的業務規劃和數據架構師主導的數據規劃。這兩部分內容是相輔相成的，由業務規劃進行業務輸入，由技術規劃對數據現狀進行探查，判斷業務規劃藍圖的可行性，最終形成可行的藍圖規劃與應用設計。
1.業務規劃
業務規劃分為三個步驟：業務調研、藍圖設計和應用設計。首先通過業務調研對企業進行了解。
（1）業務調研
業務調研主要包括以下兩方面。
第一，戰略與組織解讀。企業戰略決定了數據中臺的上限，也決定了企業對數據中臺的期望與目標。企業戰略不僅能折射出企業的數據訴求本質，也能體現出數據中臺對企業的價值。因此，通過明確企業戰略對企業運營提升的要求，可以抓住企業運營提升的關鍵環節，對公司管理現狀進行診斷，分析數字化能力給企業帶來的效率和效益提升，明確企業數字化優化的目標與范圍。同時，明確企業的組織架構，熟悉企業的業務模式，了解企業的業務板塊，梳理業務部門的業務流程。
第二，調研訪談。調研訪談是通過問卷或針對性訪談的形式，對業務專家進行調研的過程。在調研的過程中可以收集報表、匯報材料、報告、可視化看板、系統建設材料等信息輔助理解業務。調研訪談的目的是通過對業務專家的調研，了解企業與業務，了解業務訴求與痛點，為后續的藍圖設計和應用設計提供業務知識基礎和輸入。調研前需要對業務背景、行業知識、調研問卷分布做準備，以便達到期望的調研效果。可以將調研問卷提前分發給業務專家，以便業務專家更有針對性地準備問題答復，提高調研效率。調研后需要結合業務場景，對數據進行推導，得出指標需求。推導的過程是現狀訴求→需求推導→解決手段→場景推導→指標推導，詳見表 4-1。
表 4-1 數據推導過程
（2）藍圖設計
通過業務調研了解企業，結合數據現狀與業務痛點，將企業不同實體的數據進行提煉、抽象，形成數據域，將數據資產按照一定的體系進行規整，再結合業務訴求對數據分析場景進行提煉，最終形成一張囊括企業數據現狀與未來的藍圖，為后續數據中臺的建設提供宏觀與發展路線的指導。
藍圖設計可從以下幾個方面進行分析設計：數智化轉型的一些考慮和戰略、設計方法論、對客戶業務的整體解析、數據中臺價值化、分析鏈路梳理、數據域梳理和劃分等。數據中臺藍圖一般包括三部分：數據源、數據基礎能力及數據洞察與智能應用規劃。通過數據中臺藍圖可以快速了解企業數據中臺的范圍與價值。
（3）應用設計
銜接藍圖設計，結合數據調研的成果判斷數據可行性后，將數據分析場景、智能應用進行系統落地的可視化設計，形成 PRD 文檔和原型進行產品設計與說明，最終促成應用的實現。
2.技術調研
技術調研是對企業的 IT 整體現狀進行摸查，調研內容包含企業主要業務及核心業務系統、整體網絡拓撲現狀、信息安全相關要求等。
對企業主要業務和核心業務系統的調研包括業務和技術兩個方向。業務上梳理企業的主要業務及核心業務流程，技術上則梳理各業務系統及它們之間的數據流轉關系。兩者相互印證，輸出企業的信息系統現狀大圖，并基于此確定后續的業務系統調研范圍。
整體網絡拓撲現狀的梳理，有助于厘清企業業務數據的存儲分布位置、數據傳輸的帶寬限制等信息，為后續數據集成方案設計提供基礎信息輸入。
通過信息安全相關的調研了解企業內與信息安全相關的組織部門、規章制度等信息和要求，為后續制定數據處理和使用的流程規范提供依據。
3.系統和數據調研
系統與數據調研的目的是厘清企業數據資源的種類、分布、存儲及管理現狀。系統與數據調研是按業務系統進行盤點的。系統盤點的范圍來源于技術調研的輸出。盤點項包括業務流程、業務動作、數據源、數據表、數據字典。該調研工作一般由技術主導。
業務流程及動作的調研，需要從使用者的角度出發，確認業務系統每個原子操作產生了哪些數據，數據存儲在哪些數據表中。這部分的調研需要調研人員通過系統文檔資料梳理系統流程，并通過實際操作來驗證數據流程，最后結合數據字典將系統流程和數據表進行關聯。
數據源盤點需關注數據源種類，如結構化、半結構化和非結構化數據，以及鏈接地址、賬號、密碼、可抽取數據的時間段等；數據表級別關注是否為核心表、時間戳字段、數據更新標識、表的總數據量、日增數據量等信息。
系統與數據調研完后，需輸出相應的產出物，并與業務系統的相關人員就輸出物中的產出項進行溝通和確認。在實際實施中，不同企業的信息系統建設情況也不盡相同，輸出物中的內容項可能需要以迭代方式進行補充調研。
4.總體規劃輸出
規劃階段包含業務側和技術側的調研，兩邊的調研工作可以并行開展。在業務側完成調研及需求規劃后，技術側需要結合業務側的產出進行相關的數據探查事項，主要目的是確認調研產出是否足夠支撐業務規劃的數據應用建設。
總體規劃在最終定稿后，業務側需輸出指標、標簽清單、數據應用規劃文檔等，而技術側需輸出技術和系統調研的相關輸出物，以及系統調研階段的總結性報告。
1.2
? ?
系統設計
在盤點了企業當前的數據應用需求及數據資產情況，并根據實際情況規劃了數據中臺的建設路徑后，我們就可以進入非常重要的系統設計環節了。系統設計包含總體設計、數據設計及平臺設計。
1.總體設計
第一階段的規劃工作完成后，進入總體的架構設計階段。此階段需要回答以下問題：如何構建統一、規范、可共享的數據體系，如何避免數據的冗余和重復建設，如何規避數據煙囪和不一致性等。由阿里巴巴提出的 OneData 的核心思想是統一數據主體、統一數據建模、統一數據服務以及一系列的數據管理體系。在設計階段，可以從這幾個方面進行考慮與架構。這一階段由技術架構師與模型設計師主導，規劃設計出整體的數據架構、平臺架構和研發規范，如圖 4-7 所示。
圖 4-7 總體設計
（1）數據架構
數據中臺的數據架構設計是基于需求調研階段的業務需求、數據情況，完成數據中臺概要設計工作。數據架構設計主要包含 OneModel 數據架構設計、OneID 數據架構設計和 OneService 數據架構設計。
OneModel 可分為以下四部分。
業務板塊：根據業務的特點和需求將相對獨立的業務劃分成不同的業務板塊，不同業務板塊之間的指標或業務重疊度較低。數據域：數據域是指面向業務分析，將業務過程或者維度進行抽象的集合。劃分數據域前，需要基于數據調研與業務調研，熟悉各業務系統設計文檔、數據字典等。歸納與總結出跨源的主題域合并，梳理出整個企業的數據域。數據域劃分上，需要從三個方面進行考慮。
1）全局性：站在企業高度上，保障良好的擴展性和穩定性。
2）數量適中：根據業務情況，劃分的粒度要粗細合適，通常在 5～15 個。
3）可理解：站在業務的角度上，確保劃分便于理解，不產生歧義。
在劃分數據域時，既要涵蓋當前所有業務的需求，也要考慮有新業務時，能夠將其包含到已有的數據域中，或者能夠很容易地拓展新的數據域。
總線矩陣：在進行了充分的業務調研和需求調研后，就要構建總線矩陣了。總線矩陣由業務處理過程和維度組成一個二維表格。在行為不同的業務處理過程（事實）與維度的交叉點上打上標記，表示該業務處理過程與該維度相關。這就是構建一致性維度與一致性事實的過程。維度表和事實表的模型設計以構建出來的總線矩陣為依據。
數據分層：數據模型以維度建模理論為基礎，建設數據中臺的公共數據層。一般將數據模型劃分為操作數據層（Operational Data Store，ODS）、通用數據模型層（Common Data Model，CDM）和應用數據層（Application Data Service，ADS）。
OneID 功能包含以下四部分。
OneID 配置：主要根據具體的業務需求，完成數據源表、ID 映射表、歧義規則表的設置工作。
OneID 數據處理：主要通過數據源表和 ID 映射表等配置表單完成原始數據的數據拉取和清洗等操作，生成基礎數據。
OneID 規則計算：主要利用圖計算框架完成關鍵連接點的搜索和歧義數據的圖連通工作，并根據配置的規則對圖數據進行切割，從而唯一確定一個實體的身份信息，生成 OneID。
OneID 數據存儲和展示：主要完成 OneID 圖數據存儲和展示，以及最后生成的 OneID 清單數據存儲等。
統一數據服務 OneService 包括以下功能模塊：服務單元設計、API 設計、API 審核和 API 運營。服務單元設計是指將單個或多個物理表配置成一個視圖。基于配置好的服務單元，通過簡單可視化界面或 SQL 腳本，設計 API 的請求參數和返回參數，以及對應的 API 信息。API 設計好后，將其發布至服務市場供使用者調用。API 在被使用前，需要經過申請審批。被使用的 API 需要運維及監控，包括平均響應時長、調用次數、錯誤率、掉線百分比等指標的監控，還可以配置 API 的告警及限流措施等。
（2）平臺架構
結合前期調研的業務需求和數據現狀，從宏觀層面規劃出數據中臺的各個模塊、各個功能部件所用到的技術總體架構圖。總體架構由數據采集、數據存儲、數據流、網絡、部署、安全等組成。
采集架構：數據采集打通各種數據來源，為數據中臺提供待分析和處理的數據，主要分為實時和離線數據采集方案，具體可參見 4.2.2 節。
存儲架構：整個存儲架構包含原始數據源存儲技術、數據源接入技術、數據中臺數據存儲與計算技術、數據服務及數據應用技術。從數據采集、數據加工到最后的數據展現，設計出整個流程中不同數據來源到數據中臺的存儲。
數據流：從業務數據進入數據采集通道，到進入數據中臺在各個加工任務中流轉，再到數據對外服務的這個過程，需要進行哪些存儲、哪些技術處理等，這些步驟需要在設計時就以數據流向用流程圖的形式畫出。
網絡架構：數據中臺涉及與多方的源系統進行數據交互，而網絡設計對于后續數據同步、接口調用等有較大影響，因此需要綜合考慮各業務系統與搭建數據中臺環境的網絡情況。如果涉及上云，業務系統有可能在本地，而數據中臺的環境在云上，要考慮是否需要設計專線。同時根據每天要同步的數據量，設計出帶寬的容量。
部署架構：這部分設計主要涉及數據中臺的研發平臺與應用軟件。需包含整體的部署方案，如 Hadoop 生態圈中所采用各個組件的部署節點，每個角色的功能部署幾個節點，在機器資源上如何分布，還包括數據庫的主備方案、后端應用的部署等。
安全架構：主要包含研發平臺的用戶角色權限控制方案、開發與生產環境隔離方案、數據安全方案。考慮在數據抽取、數據加工處理和數據服務的整個數據加工鏈條中對企業的敏感信息進行加密處理。
（3）數據模型設計規范與標準
良好的數據模型可方便、有效地組織數據中臺中存儲的企業數據資產，所以數據模型的設計工作有必要遵循一定的規范和約束。團隊在明確定義模型設計的相關實施規范及要求后，需要向參加數據中臺建設的相關人員明確規范和要求，確保團隊內統一標準，以保障和提升數據開發與運維管理的效率，并方便后續的知識移交和數據管理工作。規范應清晰地闡述模型定義與代碼開發的相關約束。模型規范要明確數據架構中的分層、分層的命名，定義不同接入頻率、不同系統表命名方式。代碼研發規范層面應定義好各種不同用途、不同腳本類型的命名規范等。
2.數據設計
數據設計包括數據集成、模型設計和服務詳設，如圖 4-8 所示。
圖 4-8 數據設計
（1）數據集成數據集成需要解決不同源系統數據異構性問題。源業務系統的數據類型多種多樣，有來源于關系型數據庫的結構化數據，也有來源于非關系型數據庫的非結構化數據及半結構化數據。
結構化數據一般以二維形式存儲在關系型數據庫中，對于這種數據類型，數據集成有 3 種方式。直連同步：通過規范的 API（如 JDBC）直接連接業務庫。但是業務庫直連的方式對源系統的性能影響較大，當執行大批量數據同步時會降低甚至拖垮業務系統的性能。即使業務數據庫存在備庫，當數據量較大時，此種抽取方式性能也較差，不太建議使用。
數據文件同步：通過約定好的文件編碼、大小、格式等，直接從源系統生成數據的文件，由專門的文件服務器（如 FTP 服務器）作為中間文件交換，加載到數據中臺。但由于要保證數據文件的完整性，通常除數據文件外，還需要上傳校驗文件，供下游系統校驗數據同步的準確性。
數據庫日志解析同步：這種方式實現了實時與準實時同步，延遲可以控制在毫秒級別，并且對業務系統的性能影響比較小，目前廣泛應用于從業務系統到數據中臺系統的增量數據同步應用之中。除了數據讀取的方式，還可按數據量來分解數據集成策略。
小數據量同步：數據記錄小于 10 萬條的源表建議每日全量更新，寫入全量分區表。全量分區表可按天創建。可根據業務需要設置數據的生命周期，并定時清理。
大數據量同步：數據記錄大于 10 萬條的源表通過時間戳抽取增量數據到增量分區表。增量分區表可設置長周期，根據需要設置冷、溫、熱數據區。
非結構化數據一般沒有固定的結構，各種文檔、圖片、視頻、音頻等都屬于非結構化數據。對于這類數據，數據集成策略通常是直接整體存儲，而且一般存儲為二進制的數據格式。
除了結構化數據和非結構化數據，還有半結構化數據。半結構化數據的應用越來越廣泛。半結構化數據帶有用來分隔語義元素和數據記錄的標記，具有自描述特性，常見的數據格式有 JSON 和 XML。對于半結構化數據，數據集成策略同樣可以是直接整體存儲。但隨著數據技術的發展，NoSQL 數據庫已經可以很好地支持半結構化數據的存儲。NoSQL 在邏輯表現形式上相當靈活，主要有 4 種模型。
鍵值模型：鍵值模型在表現形式上比較單一，但卻有很強的擴展性。列式模型：由于每列可以動態擴展，列式模型相比鍵值模型能夠支持的數據更為復雜。文檔模型：文檔模型對于復雜數據的支持和在擴展性上都有很大優勢。圖模型：使用場景通常基于圖數據結構，如社交網絡、推薦等。
在半結構化數據集成方面，建議使用 NoSQL 數據庫。
（2）模型設計
數據模型可以分為主題域模型、標簽模型和算法模型。其中主題域模型是基礎，是對數據標準化、規范化的過程。標簽模型基于主題域模型將對象的各種標識打通歸一，將跨業務板塊、跨數據域的對象組織起來。算法模型基于主題域模型，將各對象的歷史行為、屬性等數據作為輸入，利用算法能力分析和預測對象的行為。下面來詳細介紹這三種數據模型的設計。
首先來看主題域模型設計。主題域模型也就是大家常說的數倉模型。數倉模型的設計方法論已經非常成熟，最權威的數倉模型設計是 Kimball 的維度建模。阿里巴巴在維度建模的基礎上進行了升華，沉淀了 OneModel 方法論，將數據從業務板塊到業務域、業務流程、指標和維度，一層層梳理，構建出企業的指標體系并形成數倉模型。OneModel 方法論強調從業務過程出發，站在數據應用與分析的角度，梳理出業務過程中涉及的維度及度量，并對業務過程中的度量進行規范化定義，統一指標口徑，消除指標二義性，形成統一的指標體系；同時，構建一致性維度及事實矩陣，并據此進行維度及事實模型設計。主題域模型可分為以下三層。
操作數據層（Operational Data Store，ODS）：主要將業務系統、日志等結構化和半結構化數據引入數據中臺，保留業務系統原始數據。ODS 分為緩沖區和數據服務區。緩沖區設計主要保持與數據源的一致性，保證 ODS 能原樣引入所接入的源數據，不進行任何類型轉換和數據加工處理。數據服務區包括全量明細數據，該數據是對緩沖區數據進行類型轉換或增量合并處理后得到的，數據服務區為通用數據模型層和應用數據層提供數據服務。引入緩沖區是考慮到數據引入后可能會有一些特殊的處理需求，比如埋點數據采集后一般為 JSON 格式數據，這類需要在解析后再引入；或者有一部分實時采集的數據需要與當前存量數據進行合并處理，以獲取當前最新狀態的數據。緩沖區能起到很好的追溯作用，方便后續追查與核對問題，為后續的數據分層建模提供良好的數據基礎。
通用數據模型層（Common Data Model，CDM）：包含整個數據中臺的大部分數據，是數據中臺的基礎，因此保證該層數據的健壯性是重中之重。CDM 主要完成公共數據加工與整合，建立一致性的維度，構建可復用、面向分析和統計的明細事實表及匯總事實表。
應用數據層（Application Data Service，ADS）：提供直接面向業務或應用的數據，主要對個性化指標數據進行加工處理；同時為方便滿足數據應用、數據消費的訴求，進行面向應用邏輯的數據組裝，比如大寬表集市、橫表轉縱表、趨勢指標串等。
其次介紹標簽模型設計。實體標簽模型是數據中臺建設中的另一類重要模型，這類模型對于企業數據治理、業務輸出都具有舉足輕重的作用。企業的重要數據資產，如客戶、商品、門店、供應商、員工等實體的標簽模型都是數據中臺加工的重點。比如，先獲取商品的生產、采購、定價、銷售、退貨等歷史行為數據，然后按照業務場景需要來制定商品所涉及的商品標簽，形成商品標簽模型。
最后來講解算法模型設計。數據中臺整合全域的數據，需要通過 AI 算法將寶貴的數據形成有價值的數據資產。算法模型是數據中臺中最難設計的模型，但又是最能將企業的數據資產發揮出幾何倍數價值的模型。例如，憑借商品個性化推薦模型，淘寶的“千人千面”場景幫助用戶極大提升了體驗感，縮短了用戶的交易鏈條，提升了用戶的轉化率。算法模型與上兩種模型的不同之處在于，在建模的過程中需要充分聚焦算法所服務的場景。比如對于商品推薦算法模型，建模時需要充分理解涉及商品推薦的相關場景。商品個性化推薦一般有首頁推薦商品列表、猜你喜歡專欄、購物車推薦專欄等場景。我們要充分梳理這些場景的需求點，然后制定實現推薦模型的場景，如圖 4-9 所示。在通過場景梳理編排出算法實現邏輯后再開始設計算法模型及實現邏輯。
圖 4-9 推薦場景
（3）服務詳設
數據服務按數據內容可分為主題分析類數據服務、標簽類數據服務和算法類數據服務。
主題分析類數據服務可通過整合數據分析場景，分專題設計通用的數據匯總寬表，通過數據寬表拼寫不同的 SQL，支撐相應的數據報表，避免數據的冗余建設。
標簽類數據服務的設計卻有所不同，切忌按照標簽使用場景逐個進行數據服務設計。因為運營可能會隨時增加標簽，迫使在設計標簽服務時考慮通用性和擴展性。一般建議以底層的標簽寬表為出發點，設計標簽通用的增加、修改和查詢功能。
與業務聯動緊密的算法類數據服務則需要注意可能直接面對低延遲、高并發的調用場景，比如推薦場景，包括搜索推薦、猜你喜歡、加購推薦等，一定要做好服務接口的性能壓測，以滿足業務實時交易級的性能要求。
除了考慮服務的通用性和性能，還需要考慮服務開放的數據安全性。
3.平臺設計
平臺設計指的是大數據運行平臺在資源規劃、技術選型、部署方案等方面的設計，是根據總體架構中的平臺架構展開的。平臺能力具有通用性、擴展性和前瞻性是數據中臺成功建設的基礎。平臺設計階段將以客戶現有數據體量及可預測的業務增長情況作為考量因素，對平臺建設所需的資源進行預估和規劃，產出平臺及數據應用部署所需的資源清單、部署方案及相關人員在平臺上的賬號和權限的設計等。
資源規劃：需要對支撐大數據平臺所需的資源進行估算。一般可考慮未來 3 年企業的數據量，可借鑒的存儲空間資源估算公式如下：
磁盤空間預估=當前企業數據存量（TB）×3 +數據日 增量（TB）×3（副本數）×365×3
技術選型：大數據技術選型的原則是考慮當前及未來一段時間可能使用的場景，根據場景來推導技術的選擇。一般會從數據的采集、存儲、計算、管理、運維等多方面考慮需要選擇的技術或成熟產品來搭建大數據平臺。比如，文件采集使用 Flume 到 HDFS，數據庫采集使用 DataX 到 HDFS，計算與加工基于 Hive 存儲、離線使用 Spark SQL 處理、實時采用 Flink 等。
1.3
? ?
開發實施
開發實施階段可分為環境搭建、數據集成、代碼研發三個層面。
1.環境搭建
平臺層面的環境搭建，包括大數據集群、數據研發平臺、智能數據應用產品等相關工具的部署。平臺的搭建按設計階段輸出的資源規劃和平臺部署方案實施即可。在平臺環境、工具組件部署后，需要對平臺環境進行測試，同時在產品工具層面，需要對企業進行相關產品的使用培訓，并通過企業的驗收。
2.數據集成
數據集成方案從宏觀上設計和規范了數據源級別的數據集成流程和同步策略。在當前階段，需要對各數據源制定表級別的集成策略，形成數據同步清單，包括上云數據存量、日增量、分區字段、數據更新頻率、存儲周期、上云時間等相關信息，供具體實施時使用。數據集成工作實施后，還需要逐一對數據源表進行數據監控及驗證，以確保集成的數據無問題。
3.代碼研發
代碼研發階段包括數據研發與驗證、應用研發與測試、性能測試三部分。數據研發與驗證主要包括數據模型的業務代碼開發、數據監控代碼開發、數據準確性驗證。從模型數據開發、數據監控開發到數據驗證，再到模型上線，需要一整套開發流程來保障數據的產出。應用研發與測試主要包括數據應用層面的開發和測試工作，如數據服務、數據應用前端開發。性能測試包括數據產出時間、數據接口服務性能、數據應用訪問性能等方面的測試。
1.4
? ?
試運行
數據中臺上線之后，分析專題的指標口徑、數據應用效果等多方面的數據準確性都需要通過真實的運行數據去驗證。在這個時間段還不太適合全面對外發布，也不宜對外開放數據能力。通常我們需要進行一段時間的試運行。
1.中臺試運行
為保障生產環境數據的準確性，需要先在測試環境基于企業全量的數據進行一段時間的試運行，這主要包含以下幾步。
1）數據遷移：增量模型涉及的存量數據需進行一次全量的數據遷移，以保證數據的完整性，全量模型則直接按頻度進行抽取即可。遷移前，需制定詳細的遷移方案及步驟；遷移時，需記錄各個環節的關鍵數據，如遷移耗時、資源消耗情況等；遷移后，需總結并輸出遷移報告。
2）數據跑批：完整運行數據中臺的全流程任務，包括數據抽取、加工、服務提供及應用展現，分析各層級模型任務的運行耗時以及對應時間段的資源情況，并不斷優化、調整運行任務的啟動和依賴關系，以達到最佳的配置。
3）數據驗證：篩選核心關鍵指標、標簽，進行數據準確性的驗證，例如存量指標可與系統現有指標進行對比，增量指標則與模型設計內容逐層對比。
4）應用驗證：對于對外服務接口類應用，聯系應用方進行接口及數據的驗證，并完成應用全流程的拉通，優化調用的頻次及時間點；對于報表及專題分析類應用，驗證報表數據與數據中臺側數據的一致性，以及測試前端頁面、展現數據的性能。
2.歷史數據重跑和測試
在試運行過程中，數據中臺的指標或標簽可能會因為業務側的口徑變更而進行歷史數據的重刷動作。在這種情況下，要保證數據準確且可逆，有如下幾點注意事項。
影響評估：評估業務變動涉及的模型，并形成清單列表。
數據備份：數據處理前，先備份當前狀態下的數據。
口徑調整：確認業務口徑調整涉及的技術口徑調整內容，并體現在模型設計文檔的版本控制中。
數據驗證：調整后，嚴格按照設計內容進行數據的驗證和測試，并與業務側達成一致，在測試環境中進行確認。
1.5
? ?
持續運營
數據中臺不是一錘子買賣，是需要持續經營的。在數據中臺正式上線后，隨著企業業務的不斷拓展，會接入更越來越多的數據源，數據的分析也將越來越精細，數據應用場景會更加豐富多樣。同時，某些數據應用會因為企業業務方向的調整而廢棄，這些已經過時的應用就需要及時清理。作為數據中臺的建設者，不僅需要定期與數據使用者主動溝通，了解數據使用情況，了解這些數據到底帶來了什么價值，還要通過系統查看指標、標簽、專題、應用 API 這些資產的被調用情況，以此來判斷是否需要優化等。
1.正式上線試運行穩定執行一段時間后，可按模塊和迭代申請生產環境的正式上線動作，以交付階段性的工作成果。在正式上線時，分以下兩步進行。
1）割接方案。如果數據中臺存在替換現有其他系統的情況，就需要制定詳細的割接方案，以保障數據中臺能夠覆蓋舊系統的數據能力。2）上線預演。在正式上線前，需進行割接或上線的演練操作，盡可能多地暴露數據、環境、資源等各方面的問題，并逐步進行優化和調整。
系統上線后，制定相關的檢查規則及告警機制，以保障數據中臺的正常運行。檢查規則可大致分為如下兩類。
數據規則：數據一致性，主鍵唯一性，數據完整性。
資源規則：服務器資源，如 CPU、I/O 等；存儲告警規則。
檢查規則執行完成后，根據檢查結果制定告警策略，如異常告警阻斷、異常告警不阻斷。同時，通過短信、郵件等方式將檢查的結果進行告知，并制定告警升級機制。
2.運營保障
系統上線以后，跟進系統的運行、使用情況，綜合分析以提煉新的需求點，創造更大的價值點，持續運營。數據中臺的運營策略可從產品、應用、數據三方面進行。
產品側：收集直接使用方的產品體驗狀況，根據反饋內容進行優化，提高產品的易用性，增強使用方對產品的黏性。
應用側：分析應用對象的重點關注模塊，并階段性地形成分析報告。中臺建設者可根據報告內容，對接應用相關人員，持續挖掘新的需求內容，持續耕耘以創造更大的價值。
數據側：通過數據鏈路跟蹤的結果，總結階段性重點關注的數據內容。結合自上而下和自下而上兩種途徑，分析整個系統數據層面的缺口，并制定匯聚、擴建的計劃，提高中臺數據支撐的力度。
以上內容摘自《中臺實踐：數字化轉型方法論與解決方案》一書，經出版方授權發布
中臺暢銷書《中臺戰略》姊妹篇！領先的中臺服務提供商云徙科技官方出品，近百家龍頭企業數字化轉型經驗總結；業務中臺、數據中臺、技術平臺 3 大平臺建設方法論，地產、汽車、直銷、零售、渠道 5 大行業和領域數字化轉型解決方案
- EOF -
想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信
申請備注（姓名+公司+技術方向）才能通過哦！
好文推薦
為什么說IT科技公司應該留住35歲員工？
混沌工程：蘇寧系統穩定性之道
貝殼找房技術總監肖鵬：高速成長下的技術團隊怎么帶？
阿里技術專家楚衡：架構制圖的工具與方法論
螞蟻集團技術專家山丘：性能優化常見壓測模型及優缺點
京東平臺研發朱志國：領域驅動設計（DDD）理論啟示
架構專家高磊：緩存為王——無線緩存架構優化
三湘銀行中臺總助黎慧劍：銀行業務中臺建設實戰
? ?END ? ?? #架構師必備#點分享點點贊點在看
點擊“閱讀原文”了解更多數字化轉型好書原文鏈接
新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！總結
以上是生活随笔為你收集整理的万字长文精华之数据中台构建五步法的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： LeetCode 121. 买卖股票的最
- 下一篇： Spring Cloud 入门 之 Co