資料中臺建設中的“通用化+標準化+敏捷性”

對於一個企業，資料中臺核心使命，沉澱有價值資料，形成企業資料共享，資料服務或應用於企業各部門、各領域的工作。

從技術視角，資料中臺是一種資料管理體系，最重要的目標是支援各部門業務資料和提供計算服務。資料中臺的本質就是“資料倉儲+資料服務中介軟體”。

從業務視角，資料中臺是指透過完成企業內外部多源異構的資料採集、治理、建模、分析、應用，打通資料孤島實現資料集中管理應用,成為企業資料資產管理中樞。

資料中臺資料模型的分層，業界比較通用的分層方式是將資料模型分為5層：

①ODS(Operate Data Store，運算元據層)

②DIM(Dictionary Data Layer ，維度資料層)

③DWD(Data Warehouse Detail ，明細資料層)

④DWS(Data Warehouse Service，彙總資料層)

⑤ADS(Application Data Store，資料應用層)

資料中臺發展歷程

資料中臺為行業熟知，由阿里興起並推廣，2015年阿里提出“大中臺，小前臺”的策略，方法論講“OneData(統一資料)、OneEntity(統一實體)、OneService(統一服務)”，OneData致力幹統一資料標準，讓資料成為資產而非成本;OneEntity致力於統一實體，讓資料融通而以非孤島存在;OneService致力於統一資料服務，讓資料複用而非複製。

隨著金融行業數字化轉型加快，資料中臺在金融領域被重視，資料中臺甚至寫進了各大銀行、保險等機構的發展戰略。例如，2019年12月，招商銀行宣佈設定資料資產與平臺研發中心，其定位就是“資料中臺”;2020年，中國農業銀行制定了“六大中臺”戰略，打造資料、信貸、開放銀行、零售營銷、對公營銷和運營六大中臺;中國太保集團攜手阿里雲首次打造集團級資料中臺，全面向資料智慧要紅利。

資料中臺建設中的“通用+標準+敏捷”

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+管理”融合型團隊，培養“業務+資料，業務+技術”複合型團隊。