資料中台被譽為大資料的下一站，由阿裡興起，核心思想是資料共享，2015年阿裡提出“大中台，小前台”的政策。2018 年因為“騰訊資料中台論”，中台再度成為了人們談論的焦點。
2019年，似乎人人都在提資料中台，但卻不是所有人都清楚資料中台到底意味着什麼。資料中台是隻有大廠才需要考慮的高大上的概念嗎？普通企業該不該做資料中台？資料中台的出現會給現有資料從業者們帶來颠覆式的挑戰嗎？
資料中台不是大資料平台！
首先它不是一個平台，也不是一個系統，如果有廠商說他們有個資料中台賣給你，對不起，它是個騙子。
要回答資料中台是什麼，首先要探讨一下中台到底是什麼。雖然沒有明确的定義，但是作為理工直男，我們可以先把中台看作是一種中間層。既然是一種中間層，那麼中台确實是一種十足技術用語，我們可以完全從技術角度來探讨了。
我們可以應用 Gartner 的 Pace Layer 來了解為什麼要有中間層，這樣可以更好地了解中台的定位和價值。Pace Layer 裡提到，可以按照事物變化的速度來分層，這樣可以逐層分析并設計合理的邊界與服務。
在資料開發中，核心資料模型的變化是相對緩慢的，同時，對資料進行維護的工作量也非常大；但業務創新的速度、對資料提出的需求的變化，是非常快速的。
資料中台的出現，就是為了彌補資料開發和應用開發之間，由于開發速度不比對，出現的響應力跟不上的問題。
資料中台解決的問題可以總結為如下三點：
效率：為什麼應用開發增加一個報表，就要十幾天時間？為什麼不能實時獲得使用者推薦清單？當業務人員對資料産生一點疑問的時候，需要花費很長的時間，結果發現是資料源的資料變了，最終影響上線時間。
協作問題：當業務應用開發的時候，雖然和别的項目需求大緻差不多，但因為是别的項目組維護的，是以資料還是要自己再開發一遍。
能力問題：資料的處理和維護是一個相對獨立的技術，需要相當專業的人來完成，但是很多時候，我們有一大把的應用開發人員，而資料開發人員很少。
這三類問題都會導緻應用開發團隊變慢。這就是中台的關鍵——讓前台開發團隊的開發速度不受背景資料開發的影響。
資料中台是聚合和治理跨域資料，将資料抽象封裝成服務，提供給前台以業務價值的邏輯概念。
如下圖所示：
DData API 是資料中台的核心，它是連接配接前台和背景的橋梁，通過 API 的方式提供資料服務，而不是直接把資料庫給前台、讓前台開發自行使用資料。至于産生 DataAPI 的過程，怎麼樣讓 DataAPI 産生得更快，怎麼樣讓 DATA API 更加清晰，怎麼樣讓 DATA API 的資料品質更好，這些是要圍繞資料中台去建構的能力。
其實這些概念說多了是很虛的，那我們就結合阿裡的例子來講解。
阿裡資料中台詳解
1、阿裡資料中台賦能業務全景圖
在架構圖中，看到最下面的内容主要是資料采集和接入，按照業态接入資料（比如淘寶、天貓、盒馬等），把這些資料抽取到計算平台；通過OneData體系，以“業務闆塊+分析次元”為架構去建構“公共資料中心”。
基于公共資料中心在上層根據業務需求進行建設：消費者資料體系、企業資料體系、内容資料體系等。
經過深度加工後，資料就可以發揮其價值被産品、業務所用；最後通過統一的資料服務中間件“OneService”提供統一資料服務。
2、阿裡資料中台三大體系
經過多年實戰，沉澱出了阿裡雲上資料中台核心能力架構體系：産品+技術+方法論。
曆經阿裡生态内各種實戰曆練後，雲上資料中台從業務視角而非純技術視角出發，智能化建構資料、管理資料資産，并提供數椐調用、資料監控、資料分析與資料展現等多種服務。
承技術啟業務，是建設智能資料和催生資料智能的引擎。在OneData、OneEntity、OneService三大體系，特别是其方法論的指導下，雲上資料中台本身的核心能力在不斷積累和沉澱。在阿裡巴巴，幾乎所有人都知道雲上資料中台的三大體系，如上圖所示。
OneData緻力幹統一資料标準，讓資料成為資産而非成本；OneEntity緻力于統一實體，讓資料融通而以非孤島存在；OneService緻力于統一資料服務，讓資料複用而非複制。
這三大體系不僅有方法論，還有深刻的技術沉澱和不斷優化的産品沉澱，進而形成了阿裡巴巴雲上資料中台核心能力架構體系。
3、阿裡資料中台及賦能業務模式支撐
阿裡資料中台，經曆了所有阿裡生态内業務的考驗，包括新零售、金融、物流、營銷、旅遊、健康、大文娛、社交等領域。
資料中台除了建立起自已的核心能力之外，向上賦能業務前台，向下與統一計算背景連接配接，融為一體。
4、資料中台六大資料技術領域
前文提到，在建設阿裡資料公共層之初，規劃了六大資料技術領域，即資料模型領域、存儲治理領域、資料品質領域、安全權限領域、平台運維領域、研發工程領域。
而在阿裡資料公共層建設項目第二階段完成存儲治理領域，已經被擴大到資源治理領域，進而更新到資料資産管理領域，安全權限領域，更新到資料信任領域，因為很多工作已經在産品中實作，平台運維領域不再作為一個資料技術領域被推進，資料模型領域與資料品質領域還在持續推進中，不過增加了許多新的内涵，智能黑盒領域則是新起之秀。
由此可見，資料技術領域不是一成不變的，而是随着業務的發展和技術的突破不斷擴大、 升華的。
那麼，實時的資料中台怎麼做？
下面是實作實時資料中台的一種邏輯架構，友善你去了解，其實最關鍵的是實時模型那一層。
1、實時接入：
不同類型的資料需要不同的接入方式，flume+kafka現在是标配，其他還有檔案、資料庫的DSG等等技術。比如營運商就有B域的訂購、通話，O域的位置、上網等各類實時資料。
2、計算架構：
這裡隻列出一種，基于Kappa架構實作實時/離線一體化業務開發能力，相對于傳統Lambda架構，開發人員隻需面對一個架構，開發、測試和運維的難度都相對較小，且能充分發揮Flink流式計算架構一點執行、高吞吐、毫秒級響應、批流融合的特點。
比如将流計算元件劃分實時資料切片，批處理元件提供離線資料模型（駐留記憶體），兩類資料在處理過程中實作批流關聯。
3、實時模型：
跟資料倉庫模型一樣，實時模型肯定首先是面向業務的，比如營運商有流量營運、服務提醒、競争應對、放好拉新、廳店引流、語音消費、營運評估、實時關懷、實時預警、實時洞察、實時推薦等一系列的實時場景，你總是要基于你的實時業務提煉出具備共性的資料模型要素。
比如放号拉新中的外來務工實時營銷，其中可能的觸發場景是針對漫入到某個交通樞紐并駐留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億條資料，這一切都建立在阿裡強大的資料處理技術底座之上。
如果實時資料足夠多，場景足夠豐富，建立實時資料中台的必要性還是非常高的。
随着大資料内外營運的深入，我們發現這種需求越來越多，你會驚奇的發現，很多時候需求是随着你技術能力的加強而增加的，很多時候，技術就是第一生産力。我們很多負責變現的産品、營運經理應是深有體會的。
從那個時候起，我就在想我們能否建立一個真正的實時資料中台，能夠快速高效的建立海量的實時應用，進而将大資料的管理和應用水準提升到一個新的階段，終于我們現在走到了這條路上。