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