我花10個小時,寫出了小白也能看懂的阿里資料中臺分析!

架構文摘發表於2019-12-12

作者:資料分析不是個事兒
www.jianshu.com/p/05a8db84e…

資料中臺被譽為大資料的下一站,由阿里興起,核心思想是資料共享,2015年阿里提出“大中臺,小前臺”的策略。2018 年因為“騰訊資料中臺論”,中臺再度成為了人們談論的焦點。

2019年,似乎人人都在提資料中臺,但卻不是所有人都清楚資料中臺到底意味著什麼。資料中臺是隻有大廠才需要考慮的高大上的概念嗎?普通企業該不該做資料中臺?資料中臺的出現會給現有資料從業者們帶來顛覆式的挑戰嗎?

資料中臺不是大資料平臺!

首先它不是一個平臺,也不是一個系統,如果有廠商說他們有個資料中臺賣給你,對不起,它是個騙子。

要回答資料中臺是什麼,首先要探討一下中臺到底是什麼。雖然沒有明確的定義,但是作為理工直男,我們可以先把中臺看作是一種中間層。既然是一種中間層,那麼中臺確實是一種十足技術用語,我們可以完全從技術角度來探討了。

我們可以應用 Gartner 的 Pace Layer 來理解為什麼要有中間層,這樣可以更好地理解中臺的定位和價值。Pace Layer 裡提到,可以按照事物變化的速度來分層,這樣可以逐層分析並設計合理的邊界與服務。

我花10個小時,寫出了小白也能看懂的阿里資料中臺分析!

在資料開發中,核心資料模型的變化是相對緩慢的,同時,對資料進行維護的工作量也非常大;但業務創新的速度、對資料提出的需求的變化,是非常快速的。

資料中臺的出現,就是為了彌補資料開發和應用開發之間,由於開發速度不匹配,出現的響應力跟不上的問題。

效率:為什麼應用開發增加一個報表,就要十幾天時間?為什麼不能實時獲得使用者推薦清單?當業務人員對資料產生一點疑問的時候,需要花費很長的時間,結果發現是資料來源的資料變了,最終影響上線時間。

協作問題:當業務應用開發的時候,雖然和別的專案需求大致差不多,但因為是別的專案組維護的,所以資料還是要自己再開發一遍。

能力問題:資料的處理和維護是一個相對獨立的技術,需要相當專業的人來完成,但是很多時候,我們有一大把的應用開發人員,而資料開發人員很少。

這三類問題都會導致應用開發團隊變慢。這就是中臺的關鍵——讓前臺開發團隊的開發速度不受後臺資料開發的影響。

資料中臺是聚合和治理跨域資料,將資料抽象封裝成服務,提供給前臺以業務價值的邏輯概念。

如下圖所示:

我花10個小時,寫出了小白也能看懂的阿里資料中臺分析!

DData API 是資料中臺的核心,它是連線前臺和後臺的橋樑,通過 API 的方式提供資料服務,而不是直接把資料庫給前臺、讓前臺開發自行使用資料。至於產生 DataAPI 的過程,怎麼樣讓 DataAPI 產生得更快,怎麼樣讓 DATA API 更加清晰,怎麼樣讓 DATA API 的資料質量更好,這些是要圍繞資料中臺去構建的能力。

其實這些概念說多了是很虛的,那我們就結合阿里的例子來講解。

阿里資料中臺詳解

阿里資料中臺賦能業務全景圖

我花10個小時,寫出了小白也能看懂的阿里資料中臺分析!

在架構圖中,看到最下面的內容主要是資料採集和接入,按照業態接入資料(比如淘寶、天貓、盒馬等),把這些資料抽取到計算平臺;通過OneData體系,以“業務板塊+分析維度”為架構去構建“公共資料中心”。

基於公共資料中心在上層根據業務需求進行建設:消費者資料體系、企業資料體系、內容資料體系等。

經過深度加工後,資料就可以發揮其價值被產品、業務所用;最後通過統一的資料服務中介軟體“OneService”提供統一資料服務。

阿里資料中臺三大體系

我花10個小時,寫出了小白也能看懂的阿里資料中臺分析!

經過多年實戰,沉澱出了阿里雲上資料中臺核心能力框架體系:產品+技術+方法論*。

歷經阿里生態內各種實戰歷練後,雲上資料中臺從業務視角而非純技術視角出發,智慧化構建資料、管理資料資產,並提供數椐呼叫、資料監控、資料分析與資料展現等多種服務。

承技術啟業務,是建設智慧資料和催生資料智慧的引擎。在OneData、OneEntity、OneService三大體系,特別是其方法論的指導下,雲上資料中臺本身的核心能力在不斷積累和沉澱。在阿里巴巴,幾乎所有人都知道雲上資料中臺的三大體系,如上圖所示。

OneData致力幹統一資料標準,讓資料成為資產而非成本;OneEntity致力於統一實體,讓資料融通而以非孤島存在;OneService致力於統一資料服務,讓資料複用而非複製。

這三大體系不僅有方法論,還有深刻的技術沉澱和不斷優化的產品沉澱,從而形成了阿里巴巴雲上資料中臺核心能力框架體系。

阿里資料中臺及賦能業務模式支撐

我花10個小時,寫出了小白也能看懂的阿里資料中臺分析!

阿里資料中臺,經歷了所有阿里生態內業務的考驗,包括新零售、金融、物流、營銷、旅遊、健康、大文娛、社交等領域。

資料中臺除了建立起自已的核心能力之外,向上賦能業務前臺,向下與統一計算後臺連線,融為一體。

資料中臺六大資料技術領域

我花10個小時,寫出了小白也能看懂的阿里資料中臺分析!

前文提到,在建設阿里資料公共層之初,規劃了六大資料技術領域,即資料模型領域、儲存治理領域、資料質量領域、安全許可權領域、平臺運維領域、研發工程領域。

而在阿里資料公共層建設專案第二階段完成儲存治理領域,已經被擴大到資源治理領域,進而升級到資料資產管理領域,安全許可權領域,升級到資料信任領域,因為很多工作已經在產品中實現,平臺運維領域不再作為一個資料技術領域被推進,資料模型領域與資料質量領域還在持續推進中,不過增加了許多新的內涵,智慧黑盒領域則是新起之秀。

由此可見,資料技術領域不是一成不變的,而是隨著業務的發展和技術的突破不斷擴大、 昇華的。

那麼,實時的資料中臺怎麼做?

下面是實現實時資料中臺的一種邏輯架構,方便你去理解,其實最關鍵的是實時模型那一層。

我花10個小時,寫出了小白也能看懂的阿里資料中臺分析!

1、實時接入

不同型別的資料需要不同的接入方式,flume+kafka現在是標配,其他還有檔案、資料庫的DSG等等技術。比如運營商就有B域的訂購、通話,O域的位置、上網等各類實時資料。

2、計算框架

這裡只列出一種,基於Kappa架構實現實時/離線一體化業務開發能力,相對於傳統Lambda架構,開發人員只需面對一個框架,開發、測試和運維的難度都相對較小,且能充分發揮Flink流式計算框架一點執行、高吞吐、毫秒級響應、批流融合的特點。

比如將流計算元件劃分實時資料切片,批處理元件提供離線資料模型(駐留記憶體),兩類資料在處理過程中實現批流關聯。

3、實時模型

跟資料倉儲模型一樣,實時模型肯定首先是面向業務的,比如運營商有流量運營、服務提醒、競爭應對、放好拉新、廳店引流、語音消費、運營評估、實時關懷、實時預警、實時洞察、實時推薦等一系列的實時場景,你總是要基於你的實時業務提煉出具備共性的資料模型要素。

比如放號拉新中的外來務工實時營銷,其中可能的觸發場景是針對漫入到某個交通樞紐並駐留10分鐘以上的使用者進行營銷投放,“在某個位置的駐留時長”這個公共要素可能就是一種可複用的實時模型。

實時模型縱向可以劃分為DWD和DW兩層,DWD模型做的其實是針對各類實時資料做命名的標準化和過濾欄位的操作,方便進行資料的標準化管理,DW模型這裡分成了三大類:動態模型、事件模型和時序模型,每種模型適合不同的場景,同時需要採用與之適配的儲存格式。

動態模型:對實時的資料進行彙總統計,適合做實時的統計指標分析,比如實時的業務辦理量,一般可儲存於Kafka和Hbase。

事件模型:把實時的資料抽象成一系列業務事件,比如從位置日誌軌跡中記錄使用者的位置變更事件,從而可以觸發LBS的位置營銷,以下是典型的位置事件模型設計,一般可儲存於MQ和Redis:

我花10個小時,寫出了小白也能看懂的阿里資料中臺分析!

你也可以設計滑動視窗模型,比如儲存最新一小時的分鐘級的滑動視窗位置資訊:

我花10個小時,寫出了小白也能看懂的阿里資料中臺分析!

時序模型:主要儲存使用者的線上的時空位置等資訊,可以基於業務場景需要進行各種快速的計算,比如非常方便的計算駐留時長,儲存於Hbase或TSDB(時序資料庫):

我花10個小時,寫出了小白也能看懂的阿里資料中臺分析!

4、實時服務

有了實時模型還不夠,資料中臺還需要提供圖形化、流程化、可編排的資料開發工具,才能真正的降低實時資料開發成本。但由於離線和實時資料處理的技術手段不同,導致針對這兩種型別的資料開發和管理大多是在不同的平臺承載的。

比如以前我們的離線資料模型是通過DACP平臺管理的,但實時資料則遊離在DACP平臺之外,其往往屬於應用本身的一部分,應用需要通過編寫特定指令碼去消費和處理流處理引擎中的原生資料,這種處理的門檻不僅高,而且資源浪費也挺嚴重,每個實時應用其實都是流資料的孤島。

站在應用的角度看,業務其實需要的是一個統一的資料開發管理平臺,離線和實時資料應作為統一的物件進行管理,比如具備混合編排,混合關聯等能力,用簡單的類SQL定製化輸出應用所需的各類資料,從而高效的對外提供實時/離線資料服務。

我花10個小時,寫出了小白也能看懂的阿里資料中臺分析!

5、實時應用

資料中臺如果能支援實時資料的快速編排,根據我們的測算,其實時場景應用的資料開發、測試、部署週期會由0.5-1個月降低為1-2天,效益是很高的。

阿里處理的資料量已達EB級,相當於10億部高清電影的儲存量。在 2016年雙十一當天,實時計算處理的資料量達到9400萬條/秒。而從使用者產生資料來源頭採集、整合並構速資料、提供資料服務,到前臺展現完成僅需2.5秒。

"友盟+”是阿里把收購的幾家資料公司整合升級後,組成的一家資料公司。這裡僅以2017年“友盟+”對外公開的部分指標為例,其中的資料覆蓋14億部活躍裝置、685 萬家網站、135萬個應用程式,日均處理約280億條資料,這一切都建立在阿里強大的資料處理技術底座之上。

如果實時資料足夠多,場景足夠豐富,建立實時資料中臺的必要性還是非常高的。

隨著大資料內外運營的深入,我們發現這種需求越來越多,你會驚奇的發現,很多時候需求是隨著你技術能力的加強而增加的,很多時候,技術就是第一生產力。我們很多負責變現的產品、運營經理應是深有體會的。

從那個時候起,我就在想我們能否建立一個真正的實時資料中臺,能夠快速高效的建立海量的實時應用,從而將大資料的管理和應用水平提升到一個新的階段,終於我們現在走到了這條路上。


公眾號《架構文摘》每天一篇架構領域重磅好文,涉及一線網際網路公司應用架構(高可用、高效能、高穩定)、大資料、機器學習、Java架構等各個熱門領域。

我花10個小時,寫出了小白也能看懂的阿里資料中臺分析!

相關文章