數據中臺被譽爲大數據的下一站，由阿里興起，核心思想是數據共享，2015年阿里提出“大中臺，小前臺”的策略。2018 年因爲“騰訊數據中臺論”，中臺再度成爲了人們談論的焦點。
2019年，似乎人人都在提數據中臺，但卻不是所有人都清楚數據中臺到底意味着什麼。數據中臺是隻有大廠才需要考慮的高大上的概念嗎？普通企業該不該做數據中臺？數據中臺的出現會給現有數據從業者們帶來顛覆式的挑戰嗎？
數據中臺不是大數據平臺！
首先它不是一個平臺，也不是一個系統，如果有廠商說他們有個數據中臺賣給你，對不起，它是個騙子。
要回答數據中臺是什麼，首先要探討一下中臺到底是什麼。雖然沒有明確的定義，但是作爲理工直男，我們可以先把中臺看作是一種中間層。既然是一種中間層，那麼中臺確實是一種十足技術用語，我們可以完全從技術角度來探討了。
我們可以應用 Gartner 的 Pace Layer 來理解爲什麼要有中間層，這樣可以更好地理解中臺的定位和價值。Pace Layer 裏提到，可以按照事物變化的速度來分層，這樣可以逐層分析並設計合理的邊界與服務。
在數據開發中，核心數據模型的變化是相對緩慢的，同時，對數據進行維護的工作量也非常大；但業務創新的速度、對數據提出的需求的變化，是非常快速的。
數據中臺的出現，就是爲了彌補數據開發和應用開發之間，由於開發速度不匹配，出現的響應力跟不上的問題。
效率：爲什麼應用開發增加一個報表，就要十幾天時間？爲什麼不能實時獲得用戶推薦清單？當業務人員對數據產生一點疑問的時候，需要花費很長的時間，結果發現是數據源的數據變了，最終影響上線時間。
協作問題：當業務應用開發的時候，雖然和別的項目需求大致差不多，但因爲是別的項目組維護的，所以數據還是要自己再開發一遍。
能力問題：數據的處理和維護是一個相對獨立的技術，需要相當專業的人來完成，但是很多時候，我們有一大把的應用開發人員，而數據開發人員很少。
這三類問題都會導致應用開發團隊變慢。這就是中臺的關鍵——讓前臺開發團隊的開發速度不受後臺數據開發的影響。
數據中臺是聚合和治理跨域數據，將數據抽象封裝成服務，提供給前臺以業務價值的邏輯概念。
如下圖所示：
Data API 是數據中臺的核心，它是連接前臺和後臺的橋樑，通過 API 的方式提供數據服務，而不是直接把數據庫給前臺、讓前臺開發自行使用數據。至於產生 DataAPI 的過程，怎麼樣讓 DataAPI 產生得更快，怎麼樣讓 DATA API 更加清晰，怎麼樣讓 DATA API 的數據質量更好，這些是要圍繞數據中臺去構建的能力。
其實這些概念說多了是很虛的，那我們就結合阿里的例子來講解。
阿里數據中臺詳解
阿里數據中臺賦能業務全景圖
在架構圖中，看到最下面的內容主要是數據採集和接入，按照業態接入數據（比如淘寶、天貓、盒馬等），把這些數據抽取到計算平臺；通過OneData體系，以“業務板塊+分析維度”爲架構去構建“公共數據中心”。
基於公共數據中心在上層根據業務需求進行建設：消費者數據體系、企業數據體系、內容數據體系等。
經過深度加工後，數據就可以發揮其價值被產品、業務所用；最後通過統一的數據服務中間件“OneService”提供統一數據服務。
阿里數據中臺三大體系
經過多年實戰，沉澱出了阿里雲上數據中臺內核能力框架體系：產品+技術+方法論。
歷經阿里生態內各種實戰歷練後，雲上數據中臺從業務視角而非純技術視角出發，智能化構建數據、管理數據資產，並提供數椐調用、數據監控、數據分析與數據展現等多種服務。
承技術啓業務，是建設智能數據和催生數據智能的引擎。在OneData、OneEntity、OneService三大體系，特別是其方法論的指導下，雲上數據中臺本身的內核能力在不斷積累和沉澱。在阿里巴巴，幾乎所有人都知道雲上數據中臺的三大體系，如上圖所示。
OneData致力幹統一數據標準，讓數據成爲資產而非成本；OneEntity致力於統一實體，讓數據融通而以非孤島存在；OneService致力於統一數據服務，讓數據複用而非複製。
這三大體系不僅有方法論，還有深刻的技術沉澱和不斷優化的產品沉澱，從而形成了阿里巴巴雲上數據中臺內核能力框架體系。
阿里數據中臺及賦能業務模式支撐
阿里數據中臺，經歷了所有阿里生態內業務的考驗，包括新零售、金融、物流、營銷、旅遊、健康、大文娛、社交等領域。
數據中臺除了建立起自已的內核能力之外，向上賦能業務前臺，向下與統一計算後臺連接，融爲一體。
數據中臺六大數據技術領域
前文提到，在建設阿里數據公共層之初，規劃了六大數據技術領域，即數據模型領域、存儲治理領域、數據質量領域、安全權限領域、平臺運維領域、研發工程領域。
而在阿里數據公共層建設項目第二階段完成存儲治理領域，已經被擴大到資源治理領域，進而升級到數據資產管理領域，安全權限領域，升級到數據信任領域，因爲很多工作已經在產品中實現，平臺運維領域不再作爲一個數據技術領域被推進，數據模型領域與數據質量領域還在持續推進中，不過增加了許多新的內涵，智能黑盒領域則是新起之秀。
由此可見，數據技術領域不是一成不變的，而是隨着業務的發展和技術的突破不斷擴大、 昇華的。
那麼，實時的數據中臺怎麼做？
下面是實現實時數據中臺的一種邏輯架構，方便你去理解，其實最關鍵的是實時模型那一層。
1、實時接入
不同類型的數據需要不同的接入方式，flume+kafka現在是標配，其他還有文件、數據庫的DSG等等技術。比如運營商就有B域的訂購、通話，O域的位置、上網等各類實時數據。
計算框架
這裏只列出一種，基於Kappa架構實現實時/離線一體化業務開發能力，相對於傳統Lambda架構，開發人員只需面對一個框架，開發、測試和運維的難度都相對較小，且能充分發揮Flink流式計算框架一點執行、高吞吐、毫秒級響應、批流融合的特點。
比如將流計算組件劃分實時數據切片，批處理組件提供離線數據模型（駐留內存），兩類數據在處理過程中實現批流關聯。
實時模型
跟數據倉庫模型一樣，實時模型肯定首先是面向業務的，比如運營商有流量運營、服務提醒、競爭應對、放好拉新、廳店引流、語音消費、運營評估、實時關懷、實時預警、實時洞察、實時推薦等一系列的實時場景，你總是要基於你的實時業務提煉出具備共性的數據模型要素。
比如放號拉新中的外來務工實時營銷，其中可能的觸發場景是針對漫入到某個交通樞紐並駐留10分鐘以上的用戶進行營銷投放，“在某個位置的駐留時長”這個公共要素可能就是一種可複用的實時模型。
實時模型縱向可以劃分爲DWD和DW兩層，DWD模型做的其實是針對各類實時數據做命名的標準化和過濾字段的操作，方便進行數據的標準化管理，DW模型這裏分成了三大類：動態模型、事件模型和時序模型，每種模型適合不同的場景，同時需要採用與之適配的存儲格式。
動態模型：對實時的數據進行彙總統計，適合做實時的統計指標分析，比如實時的業務辦理量，一般可存儲於Kafka和Hbase。
事件模型：把實時的數據抽象成一系列業務事件，比如從位置日誌軌跡中記錄用戶的位置變更事件，從而可以觸發LBS的位置營銷，以下是典型的位置事件模型設計，一般可存儲於MQ和Redis：
你也可以設計滑動窗口模型，比如保存最新一小時的分鐘級的滑動窗口位置信息：
時序模型：主要保存用戶的在線的時空位置等信息，可以基於業務場景需要進行各種快速的計算，比如非常方便的計算駐留時長，存儲於Hbase或TSDB（時序數據庫）：
4、實時服務
有了實時模型還不夠，數據中臺還需要提供圖形化、流程化、可編排的數據開發工具，才能真正的降低實時數據開發成本。但由於離線和實時數據處理的技術手段不同，導致針對這兩種類型的數據開發和管理大多是在不同的平臺承載的。
比如以前我們的離線數據模型是通過DACP平臺管理的，但實時數據則遊離在DACP平臺之外，其往往屬於應用本身的一部分，應用需要通過編寫特定腳本去消費和處理流處理引擎中的原生數據，這種處理的門檻不僅高，而且資源浪費也挺嚴重，每個實時應用其實都是流數據的孤島。
站在應用的角度看，業務其實需要的是一個統一的數據開發管理平臺，離線和實時數據應作爲統一的對象進行管理，比如具備混合編排，混合關聯等能力，用簡單的類SQL定製化輸出應用所需的各類數據，從而高效的對外提供實時/離線數據服務。
5、實時應用
數據中臺如果能支持實時數據的快速編排，根據我們的測算，其實時場景應用的數據開發、測試、部署週期會由0.5-1個月降低爲1-2天，效益是很高的。
阿里處理的數據量已達EB級，相當於10億部高清電影的存儲量。在 2016年雙十一當天，實時計算處理的數據量達到9400萬條/秒。而從用戶產生數據源頭採集、整合並構速數據、提供數據服務，到前臺展現完成僅需2.5秒。
"友盟+”是阿里把收購的幾家數據公司整合升級後，組成的一家數據公司。這裏僅以2017年“友盟+”對外公開的部分指標爲例，其中的數據覆蓋14億部活躍設備、685 萬家網站、135萬個應用程序，日均處理約280億條數據，這一切都建立在阿里強大的數據處理技術底座之上。
如果實時數據足夠多，場景足夠豐富，建立實時數據中臺的必要性還是非常高的。
隨着大數據內外運營的深入，我們發現這種需求越來越多，你會驚奇的發現，很多時候需求是隨着你技術能力的加強而增加的，很多時候，技術就是第一生產力。我們很多負責變現的產品、運營經理應是深有體會的。
從那個時候起，我就在想我們能否建立一個真正的實時數據中臺，能夠快速高效的創建海量的實時應用，從而將大數據的管理和應用水平提升到一個新的階段，終於我們現在走到了這條路上。
