我花10個小時，寫出了小白也能看懂的阿里數據中臺分析
數據中臺被譽為大數據的下一站，由阿里興起，核心思想是數據共享，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億條數據，這一切都建立在阿里強大的數據處理技術底座之上。
如果實時數據足夠多，場景足夠豐富，建立實時數據中臺的必要性還是非常高的。
隨著大數據內外運營的深入，我們發現這種需求越來越多，你會驚奇的發現，很多時候需求是隨著你技術能力的加強而增加的，很多時候，技術就是第一生產力。我們很多負責變現的產品、運營經理應是深有體會的。
從那個時候起，我就在想我們能否建立一個真正的實時數據中臺，能夠快速高效的創建海量的實時應用，從而將大數據的管理和應用水平提升到一個新的階段，終于我們現在走到了這條路上。
