01?數據中臺定義

對于一個企業，數據中臺核心使命，沉淀有價值數據，形成企業數據共享，數據服務或應用于企業各部門、各領域的工作。從技術視角，數據中臺是一種數據管理體系，最重要的目標是支持各部門業務數據和提供計算服務。數據中臺的本質就是“數據倉庫+數據服務中間件”。從業務視角，數據中臺是指通過完成企業內外部多源異構的數據采集、治理、建模、分析、應用，打通數據孤島實現數據集中管理應用,成為企業數據資產管理中樞。數據中臺數據模型的分層，業界比較通用的分層方式是將數據模型分為5層：

①ODS（Operate Data Store，操作數據層）

②DIM（Dictionary Data Layer ，維度數據層）

③DWD（Data Warehouse Detail ，明細數據層）

④DWS（Data Warehouse Service，匯總數據層）

⑤ADS（Application Data Store，數據應用層）

02? 數據中臺發展歷程數據中臺為行業熟知，由阿里興起并推廣，2015年阿里提出“大中臺，小前臺”的策略，方法論講“OneData（統一數據）、OneEntity（統一實體）、OneService（統一服務）”，OneData致力干統一數據標準，讓數據成為資產而非成本；OneEntity致力于統一實體，讓數據融通而以非孤島存在；OneService致力于統一數據服務，讓數據復用而非復制。隨著金融行業數字化轉型加快，數據中臺在金融領域被重視，數據中臺甚至寫進了各大銀行、保險等機構的發展戰略。例如，2019年12月，招商銀行宣布設置數據資產與平臺研發中心，其定位就是“數據中臺”；2020年，中國農業銀行制定了“六大中臺”戰略，打造數據、信貸、開放銀行、零售營銷、對公營銷和運營六大中臺；中國太保集團攜手阿里云首次打造集團級數據中臺，全面向數據智能要紅利。

03 數據中臺建設中的“通用+標準+敏捷”

1、“通用化+標準化+敏捷性”的重要性大型企業在數據中臺建設過程中通常以IT條線人員作為產品經理主導，雖然能夠做到技術架構的先進性，圍繞“ODS、DWD、DWS”大規模存儲及計算性能展開投入，但業務參與度太弱，導致系統對業務響應的敏捷度較差，業務通用性低。往往企業新上一個業務，在業務看來很簡單的“接入數據、生成標簽、報表統計、提取數據”業務需求，在數據中臺從需求分析到上線支持以月為周期。2020年底，傳出阿里掌門逍遙子要拆掉親自搭建的大中臺，核心原因對業務一線響應效率較差。既然中臺是鏈接業務，驅動業務，支持業務，那么衡量數據中臺（包含業務中臺）價值應該交給業務一線，那么從業務視角，“通用+標準+敏捷”三個維度評價中臺是否成功關鍵。

2、“通用化+標準化+敏捷性”的說明關于通用性，數據中臺的核心價值就是共享，因此數據中臺的數據標準、數據接口、數據規則是否具備通用性衡量了數據中臺的成功與否的標準，如果每一個新接入的數據源需要重新設計接口，設計數據處理流程、更新寬表、開發新的標簽，那么數據中臺不過是把數據煙囪平移到新的平臺而已。關于標準化，數據中臺具有沉淀數據的價值使命，數據通用性、可用性主要依賴于“數據的標準化”，如對“地址“的現行大多企業標準化做到了“省市區鎮”的結構化、參數化，但實際省市區鎮的由于國家城鎮改革，區劃參數在不斷變化中，每一次行政區劃變動涉及企業歷史地址數據更新，若能夠標準化到“經緯度”，那么大幅減少歷史數據的更新工作量（僅需通過地址經緯度翻譯出最新省市區鎮即可）。關于敏捷性，數據中臺強調復用，復用最大的效果之一響應業務需求“快速敏捷”；如果一個數據需求中臺響應時效不如過去的數據集市，那么中臺難以滿足日益提速的業務節奏。

3、中臺“通用化+標準化+敏捷性”的實現案例數據接入的“通用化+標準化+敏捷性”：實現接口的通用化，對實時接口、批量接口、文件上傳接口中字段的定義配置化與模塊化，如90%事件數據可以進行通用化定義:事件來源（枚舉值/文本）、事件對象（枚舉值/文本）、事件開始時間（日期）、結束時間（日期）、事件內容（枚舉值/文件/數值）、事件特殊標記（枚舉值/文件/數值/日期）。通用化、標準化的接口可以節約數據接入需求分析及接口重復設計工作量，僅需維護數據源的定義表。同時考慮對于非分析數據應用場景，允許數據應用層可以跨層調用接入的數據（避免ODS層、DWD層處理流程消耗的時效），根據需要設置接入數據臨時表（只存儲一定周期接入原始數據），直接供應用層調用（實際業務中很多事件數據無需DWS或DWD層進行加工），可大幅提高響應業務時效。如在壽險保險領域，客戶的投保、保全、理賠、咨訴事件數據都可以納入通用化接口：事件類型設置3個數值字段（如應用到咨訴-投訴-銷售投訴）、事件名稱設置2個文本字段（XX活動）、事件對象設置6個文本字段（客戶號、手機號、保單號）、事件開始與結束時間各設置兩個日期字段（客戶投訴時間、投訴事件發生時間、實際結案時間、客戶要求結案時間）、事件內容設置三個文本字段（投訴內容、客服備注內容），特殊標記設置2個數值、2個文本、2個日期（如投訴是否升級等），實踐證明通用化接口兼容80%以上保險領域事件數據，減少需求分析及接口設計工作。考慮到壽險實際業務中“作業報表、觸點推送”兩類應用中很多數據無需在DWS或DWD層匯總加工。因此增加設置接入數據臨時表，供中臺的報表、觸點兩兩大應用模塊取用進行快速增量更新，實現與數據寫入ODS層流程解耦，有效解決排期不一致各種問題。應用層的“通用化+標準化+敏捷性”，此處主要探討從數據接入到完成業務部署的通用化流程。首先最為常見的標簽，實際傳統金融行業50%的標簽可直接來源于ODS數據，且具有階段性需求特征，無需進行加工計算。如客戶是否購買、是否理賠、是否參加活動、活動類型等，這類型標簽完全可以在應用層配置化，通用化，無需DWD、DWS層重新設計開發。具體案例如在壽險客戶標簽應用層，通過在ADS層預設“數值、枚舉值、文本、日期”四個類型的萬能標簽。當業務階需要新增的標簽為臨時事件類標簽，無需“匯總、排序”等計算，完全可以借用在ADS層預設的標簽，繞開DWD、DWS層，直接通過ODS接入數據按照通用的“證件號、手機號、保單號”比對邏輯在原有的ADS層的客戶數據、保單數據上完成即時標簽生成，并在界面自定義標簽名稱，標簽部署時效縮短至“分鐘”。中臺另一個報表領域，傳統行業中業務生產數據報表80%的指標計算規則是可復用的，可實現計算規則封裝。同時傳統作業管理報表使用源數據即可快速完成計算，無需“ODS層、DWD層、DWS層、ADS層”層層加工。因此基于數據中臺構建的報表可以在數據接入模塊化的基礎上實現配置化。如壽險領域保全作業管理數據報表主要為“不同客群、產品下的保全事件數、客戶數、成功率、對應業務人員數等固化指標”，可以基于實時接入的保全事件數據，結合已經構建好的ADS層的保單數據、客戶數據，在界面快速配置數據源、調用封裝好指標計算規則，快速生成指定的報表，由于跨過了龐大的“DWD層、DWS層”數據計算，報表更新頻率可提升至分鐘。規則參數的“通用化+標準化+敏捷性”，在中臺構建數據領域的規則引擎，統一前中后端規則。如對于“省市區、渠道、職業”等參數枚舉值統一由業務部門在規則引擎界面維護管理，實現規則透明化，前中后系統規則統一，可大幅減少數據清洗系統工作量。

如對地址的省市區的結構化，中臺不僅統一枚舉值，同時可轉化出地址對應的“經緯度”，即便后續國家行政區劃參數發生變動，中臺可通過“經緯度”翻譯出最新的“省市區”，避免歷史數據治理與清洗。

寫在最后的話希望通過上述具象案例說明“數據中臺”建設需符合企業實際，中臺構建應以業務為導向。當前傳統企業“IT與業務”分屬不同的部門，中臺建設多以支持者角色出現，難以滿足“中臺數據業務化+業務數據化”的管理組織要求，傳統企業的數字化轉型可嘗試構建“業務+IT+管理”融合型團隊，培養“業務+數據，業務+技術”復合型團隊。