數據中臺設計方法論
數據中臺建設方針：橫向規劃，各個擊破。
橫向規劃即在數據中臺規劃初期，需要打通企業各個業務系，打破數據孤島現象。其實就是我們建設數據倉庫的階段。比如電信業務，我們要把客戶、賬務、客服、營銷等業務板塊打通數據，全盤考慮，融通數據形成數據資產。
數據中臺建設過程中涉及到大數據平臺建設、數據倉庫建設、模型算法、數據治理、數據服務等一系列工程，不可能一蹴而就，我們需要梳理業務場景，看他們需要什麼樣的服務先找一個業務場景，搭建起數據中臺的服務能力，然後依次迭代，各個擊破。
一、總體規劃
數據集成
首先我們需要確認平臺接入哪些數據，確認數據接入的方式是實時接入還是離線抽取。離線抽取的話是全量抽取還是增量抽取。抽取頻次數每天抽取還是每小時抽取。
實時接入可以使用kafka實時寫入數據到HDFS集羣上。
離線數據可以使用Sqoop抽取關係型數據庫到HDFS。
模型建設
模型建設是數據中臺的重要部分，可以說數據中臺的成敗在於模型建設的好壞。模型分爲我們常指的數據倉庫的分析模型和我們的一些通用算法模型。
分析模型
數據接入到數據倉庫中，我們需要對數據進行加工，按照我們規劃的業務域，對各個業務的數據彙總聚合，形成我們的數據模型。
這其中涉及到數據倉庫建設，在這簡單說下。
這是一個簡單的數據分層結構。原始數據ODS，經過清洗成爲數倉中的明細數據DWS和維度數據DIM，各個業務的明細數據按照業務域和維度數據關聯形成我們的數據模型DW，不同的DW經過聚合形成各個業務指標數據APP層。
在數倉的建設中我們聲明業務粒度，粒度能夠精確的表明業務含義。同時還要確定維度，是用戶維度還是商品維度等，最終形成我們的主數據，也就是模型數據的基礎。
算法模型
我們在業務開發過程中會形成一些通用的算法，可以是封裝好的隨機森林、迴歸等通用算法，也可以是我們業務算法，比如用戶商品推薦算法等。通過把這些算法總結，形成我們的算法模型，供各個業務直接調用。
ETL平臺
在開發數據模型時，我們必須有一個統一的平臺，能夠像流水線一樣，把數據一步步加工成數據模型。這其中涉及到數據萃取、數據聚合、作業調度等。
與業務研發不同，數據研發一般很少寫詳細的需求涉及文檔，通常就是和業務人員簡單的溝通，但是慢慢的你會發現開發完的任務會一改再改。爲了避免此種現象，我們可以根據自己的實際業務整理一份需求模板。其中包括數據來源字段，數據口徑，任務調度週期，字段mapping。
數據資產
通俗的來說，我們在數倉中開發的模型就是數據資產，數據資產需要規範的管控和治理。
資產管理最基礎的工作是做好元數據的管理，元數據包含了數據的口徑，數據模型的釋義，模型之間的血緣等等，詳細的可以看之前的元數據文章《數據倉庫元數據》。將元數據和數據模型統一有序的管理起來形成企業的數據資產。
數據資產治理不是在事後管控的，在我們建設模型的過程中需要形成一套自己的數倉開發規範進行管理。
數據服務
俗話說，酒香也怕巷子深。我們做好數據資產後，要推銷我們的資產，爲更多部門使用，這也是數據中臺建設的初衷。因此提供一套數據服務能力，對外統一對接是一件很重要的工作。
數據服務標準：數據結構標準化、在線查詢實時化、數據開發可視化。
數據結構標準化
針對數據交互，我們需要提供統一的接口視圖，可進行數據的查詢、權限管控。
在線查詢實時化
針對各業務的調用，我們需要提供指標級數據口徑統一的實時數據結果。
數據開發可視化
提供數據接口的可視化統一管理頁面，開發人員通過通過可視化管理API，降低接口理解的難度，易於維護。
討論
關於數據中臺的建設，最初是阿里提出來的，但是這之前，很多企業其實已經有了類似的想法，也實施了部分。對於大型集團企業，中臺方法論很實用。打破了集團各版塊的數據孤島，形成了統一的數據服務能力。但是慢慢的很多人提出了，對於中小企業，中臺方法論是不是太繁瑣了，對於他們來說是負擔，中小企業需要的也許是更快捷的迭代形式的數據服務。
那麼關於中臺建設，你怎麼看呢？你的企業會選擇中臺嗎？