概述
究竟什么是中臺, 業(yè)界并沒有一個標準答案, 各個廠商都有自己的定義. 筆者比較認可的一個定義是 ThoughtWorks 提出的"企業(yè)級能力復用平臺". 各個領域涌現(xiàn)出很多中臺產(chǎn)品, 如業(yè)務中臺, 搜索中臺, 數(shù)據(jù)中臺等. 其中數(shù)據(jù)中臺這個詞匯越來越多的出現(xiàn)在視野中, 從百度指數(shù)中可以看到這一趨勢.

本文,介紹有贊的數(shù)據(jù)中臺產(chǎn)生的背景和建設思路. 簡單來說, 有贊的數(shù)據(jù)中臺解決的是"有贊的數(shù)據(jù)資產(chǎn)的加工和復用", 這里提到了數(shù)據(jù)中臺的兩個重要功能: 數(shù)據(jù)加工和數(shù)據(jù)復用, 分別由數(shù)據(jù)技術中臺和數(shù)據(jù)資產(chǎn)中臺解決. 數(shù)據(jù)技術中臺主要解決數(shù)據(jù)的加工問題, 在眾多大數(shù)據(jù)組件中,幫助數(shù)據(jù)開發(fā)者簡化開發(fā)過程,提高開發(fā)效率. 數(shù)據(jù)資產(chǎn)中臺主要是解決數(shù)據(jù)復用的問題, 要做到數(shù)據(jù)復用, 數(shù)據(jù)口徑的統(tǒng)一是重中之重. 雙管齊下, 提高對前臺業(yè)務的支撐效率.

二. 數(shù)據(jù)團隊面臨的挑戰(zhàn)數(shù)據(jù)團隊面臨的挑戰(zhàn)主要有兩方面:

業(yè)務挑戰(zhàn)
技術挑戰(zhàn)

2.1 業(yè)務挑戰(zhàn)
有贊是一家服務商家的 SaaS 公司, 服務數(shù)百萬各行各業(yè)的商家, 提供電商解決方案. 有贊數(shù)據(jù)團隊的服務對象主要是各個前臺業(yè)務線, 所以一切故事的開始來源于業(yè)務團隊. 因為業(yè)務特點決定, 目前有贊的數(shù)據(jù)需求有以下特點:

垂直業(yè)務線眾多: 有贊微商城, 有贊零售, 有贊美業(yè), 有贊教育等
業(yè)務域眾多: 商品, 店鋪, 會員, 交易, 支付等
數(shù)據(jù)需求多樣: 商家后臺數(shù)據(jù)報表需求, 運營側(cè)數(shù)據(jù)分析需求, 大促看板需求, 實時報表需求等
業(yè)務需求迅速迭代: 業(yè)務模型的迭代演進, SaaS領域?qū)σ延泄δ鼙容^高的兼容要求等
...

2.2 技術挑戰(zhàn)業(yè)務線各種各樣的數(shù)據(jù)需求, 給數(shù)據(jù)團隊提出了很多挑戰(zhàn), 主要體現(xiàn)在兩方面:

組件多, 維護成本高
開發(fā)門檻高

組件多, 維護成本高軟件行業(yè)"沒有銀彈"在大數(shù)據(jù)領域顯現(xiàn)的淋漓盡致. 在有贊的大數(shù)據(jù)技術棧中, 針對不同的場景, 分別維護著眾多的大數(shù)據(jù)組件. 如數(shù)據(jù)基礎組件的 HDFS, YARN 組件;離線計算元數(shù)據(jù)組件 HIVE META, 離線計算引擎 HIVE, Spark SQL, Presto;實時計算框架 Storm, Spark Streaming, Flink 等. 這些還只是組件本身并不包括組件配套的鑒權, 安全, 脫敏, 質(zhì)量相關的服務.

開發(fā)門檻高比如，針對最普通的實時計算場景，任務的開發(fā)者通常考慮以下幾個方面問題:

數(shù)據(jù)Source流在哪兒, 如何接入
數(shù)據(jù)處理后的Sink是流還是其他存儲,如果是其他存儲系統(tǒng),可用性是怎樣的,單機房可用還是多機房,擴展性怎么樣, 寫入是否有熱點,是否可以配合實時鏈路的并行度調(diào)整做水平擴展
實時任務本身的高可用部署，監(jiān)控及報警
消息的一致性語義是什么(at least once, exactly once 還是 at most once), 每種語義對上下游服務的要求是怎么樣的
實時計算任務的計算資源如何配置, 水位如何,大促期間如何擴容
公司內(nèi)部各種各樣非大數(shù)據(jù)的技術組件,如何做適配
...

對于沒有相關經(jīng)驗的同學, 需要查閱多種組件的文檔, 勢必會有開發(fā)成本高的困擾.

三. 數(shù)據(jù)中臺按照產(chǎn)生順序, 數(shù)據(jù)中臺主要包括:

數(shù)據(jù)技術中臺
數(shù)據(jù)資產(chǎn)中臺

3.1 數(shù)據(jù)技術中臺構建所以, 技術上的復雜性, 帶來了開發(fā)成本高的問題. 所以易用性的本質(zhì)是為了提效, 數(shù)據(jù)技術中臺由一些列工具型平臺構成, 最主要的幾部分如下:

基礎組件運維管控
數(shù)據(jù)開發(fā)平臺
數(shù)據(jù)資產(chǎn)管理平臺
數(shù)據(jù)指標管理
統(tǒng)一數(shù)據(jù)服務

基礎組件運維管控上文也有提到, 大數(shù)據(jù)基礎組件種類繁多, 概括下來可以分為三類:

離線計算組件 (HDFS,YARN, HIVE, Spark)
分布式在線存儲組件(HBase, Kafka, Druid)
實時計算組件(Storm, Spark Streaming, Flink)

每類組件的管控需求都不盡相同, 比如在線存儲組件對 rt, 可用性要求較高; 實時計算組件對延遲, 積壓問題比較在意; 離線計算組件對數(shù)據(jù)吞吐能力要求較高, 但是因為是分布式計算,所以對慢盤, 慢任務需要有特別關注, 否則很容易一個節(jié)點拖慢整個集群.

運維管理好大數(shù)據(jù)組件, 做好動物管理員, 本身就是一件類似數(shù)據(jù)運營的工作, 找到系統(tǒng)的北極星指標, 關注它, 使用它來幫助做系統(tǒng)的優(yōu)化.

總結(jié)下來, 做好數(shù)據(jù)組件的管理需要解決以下問題:

確定核心指標. 需要 case by case 的確認每個子系統(tǒng)的最核心的指標, 比如對 HDFS 系統(tǒng)來說, 文件數(shù)目, 文件操作 tps, 文件操作的 rt, 99% rt, 是否有丟塊等,就是核心指標, 需要特別關注.
監(jiān)控. 采集核心指標, 展現(xiàn)到監(jiān)控上, 便于觀察趨勢, 幫助問題排查和擴容等操作的判斷依據(jù).
報警. 根據(jù)核心指標, 確定安全水位, 配置報警, 縮短故障發(fā)現(xiàn)時間.
具備一定的定制開發(fā)能力. 對使用組件不要求有核心 feature 的開發(fā)改造能力(這不符合 ROI), 但是在權限/安全方面, 社區(qū)版本很難滿足定制需求, 這就需要對基礎組件做一定的改造; 另外需要關注社區(qū),對于重大隱患的 bug, 需要打回的公司的版本.
軟件發(fā)布/配置發(fā)布規(guī)范. 多人協(xié)作, 多組件協(xié)作, 需要一個完整的開發(fā)/測試/發(fā)布流程, 不止對軟件, 對配置的發(fā)布也一定要規(guī)范. 這方面曾經(jīng)踩過不少的坑.
故障演練, 要定期的主動對技術組件做故障演練, 有些組件雖然支持某類功能,但是隨著數(shù)據(jù)量, 負載的不同, 這類功能實際效果具體是怎樣的需要通過實踐來確認. 比如 HBase 支持單機宕機自動恢復, 但是宕機恢復時間究竟是多少, 跟集群負載, 各方面的配置都是相關的, 需要通過故障演練來組件優(yōu)化系統(tǒng).
性能摸底. 需要對組件做標準的 Benchmark, 一來掌握系統(tǒng)極限,二來在業(yè)務接入時能夠提供準確的性能指標, 幫助業(yè)務方做選型判斷.
...

數(shù)據(jù)開發(fā)平臺數(shù)據(jù)開發(fā)平臺關注的是數(shù)據(jù)的加工, 是數(shù)據(jù)開發(fā)用戶(數(shù)據(jù)產(chǎn)品開發(fā)同學, 數(shù)倉開發(fā)同學, 業(yè)務線數(shù)據(jù)開發(fā)同學)最頻繁接觸到的產(chǎn)品, 數(shù)據(jù)開發(fā)平臺主要包括兩個平臺型產(chǎn)品, 分別解決離線和實時場景的數(shù)據(jù)加工需求.

離線開發(fā)平臺, 主要負責離線數(shù)據(jù)的加工, 任務調(diào)度, 數(shù)據(jù) ETL, 臨時查詢, 監(jiān)控報警等
實時計算平臺, 主要負責實時計算任務的管理, 監(jiān)控報警等

關于這兩個平臺, 有更具體的文章介紹(見參考文章),這里不在贅述.
數(shù)據(jù)資產(chǎn)管理平臺數(shù)據(jù)資產(chǎn)管理平臺主要解決數(shù)據(jù)資源的管理, 數(shù)據(jù)資產(chǎn)遍布在各個大數(shù)據(jù)組件中, 有 hive 的表, 有 hbase 的表, 有 druid 的 datasource, 有 kafka 中的流, 各個組件的管控系統(tǒng)很難互相打通, 所以需要一個統(tǒng)一的數(shù)據(jù)資產(chǎn)管理服務, 來統(tǒng)籌大數(shù)據(jù)資源的管理.

總體說來, 數(shù)據(jù)資產(chǎn)管理平臺關注的是數(shù)據(jù)的靜態(tài)狀態(tài), 比如 Hive 的庫表/字段, HBase 的表, Kafka的 Topic. 提供以下幾方面的工具:

數(shù)據(jù)地圖(方便用戶查找,定位已有的數(shù)據(jù)自產(chǎn)并復用)
數(shù)據(jù)質(zhì)量(對數(shù)據(jù)資源,根據(jù)預設的規(guī)則做質(zhì)量檢查,提前發(fā)現(xiàn)潛在問題,比如每日數(shù)據(jù)量,是否有字段缺失等,并且在數(shù)據(jù)不合格的狀況下能夠及時通知出來)
成本核算(統(tǒng)計各個團隊,組件的成本占用,利于做成本降低之類的優(yōu)化,當數(shù)據(jù)體量達到一定規(guī)模的時候, 成本問題會變的越來越重要)
數(shù)據(jù)血緣管理(管理所有的數(shù)據(jù)資源的依賴關系, 主要用在兩個場景: a. 數(shù)據(jù)問題評估, 當上游數(shù)據(jù)變更或者質(zhì)量問題的時候, 能夠快速確定影響面和修復方案. b. 數(shù)據(jù)生命周期管理, 當下游應用下線,不再使用某個數(shù)據(jù)的時候,能夠找到不被引用的數(shù)據(jù), 及時下線,避免不必要的計算)
...

數(shù)據(jù)指標管理如果說數(shù)據(jù)平臺關注的是數(shù)據(jù)的加工/轉(zhuǎn)換,既數(shù)據(jù)任務的管理; 數(shù)據(jù)資產(chǎn)管理平臺關注的是具體的數(shù)據(jù)表和字段的質(zhì)量和血緣; 那么指標庫管理的就是數(shù)據(jù)指標的口徑統(tǒng)一和復用. 在有贊, 我們通過指標庫系統(tǒng)來管理數(shù)據(jù)指標的口徑.

概括來說,數(shù)據(jù)指標被分為原子指標和派生指標. 原子指標為不可再分割的基礎指標, 由數(shù)倉團隊統(tǒng)一開發(fā)和管理, 原子指標數(shù)據(jù)一般落在數(shù)倉的 DW 層. 但是往往業(yè)務方需要的指標, 原子指標并不能滿足, 所以業(yè)務方需要在原子指標的基礎上再次加工成派生指標. 比如 交易數(shù)據(jù)中 gmv 是原子指標, 微商城業(yè)務最近 30 天的gmv 指標就是派生指標 wsc30dgmv.關于指標庫, 后面會有單獨的文章介紹.

統(tǒng)一數(shù)據(jù)服務數(shù)據(jù)開發(fā)平臺,資產(chǎn)治理平臺,指標庫只是解決了數(shù)據(jù)的加工和口徑的統(tǒng)一的問題. 產(chǎn)出的數(shù)據(jù)并不是真正對外可用的. 絕大多數(shù)場景, 都需要數(shù)據(jù)開發(fā)的同學, 將加工后的數(shù)據(jù), 通過數(shù)據(jù)交換組件, 導出到線存儲服務中, 然后再開發(fā)數(shù)據(jù)接口, 供前臺業(yè)務同學調(diào)用. 這里在線存儲服務到接口這一層, 傳統(tǒng)的業(yè)務支撐方式中存在大量的重復開發(fā). 針對這個問題, 我們設計統(tǒng)一數(shù)據(jù)服務, 用戶通過配置模板的方式, 生成數(shù)據(jù) API 服務, 簡化開發(fā)流程. 有贊的統(tǒng)一數(shù)據(jù)服務目前剛剛上線, 已經(jīng)支持 10+業(yè)務場景, 后面會有單獨的文章介紹.

3.2 數(shù)據(jù)資產(chǎn)中臺構建
3.1 節(jié)中介紹了偏技術視角的中臺, 涵蓋了大數(shù)據(jù)的技術架構. 但是數(shù)據(jù)中臺遠不止技術設施,更主要的是數(shù)據(jù)資產(chǎn)的建設和組織, 因為對業(yè)務方而言,業(yè)務方更關注的是有哪兒些數(shù)據(jù)自產(chǎn)可以使用,而不是通過什么底層技術實現(xiàn).

大數(shù)據(jù)團隊提供的數(shù)據(jù)資產(chǎn)主要有以下幾類:

離線數(shù)據(jù)資產(chǎn)(離線數(shù)倉)
數(shù)據(jù)智能服務
實時數(shù)據(jù)資產(chǎn)(實時數(shù)倉)

在用戶數(shù)目上, 目前離線數(shù)倉承接了大多數(shù)的數(shù)據(jù)需求, 這里僅僅對離線數(shù)倉展開介紹. 離線數(shù)倉中數(shù)據(jù)的開發(fā)主要發(fā)生在數(shù)據(jù)開發(fā)平臺上, 包括數(shù)據(jù) etl 導入任務, 數(shù)據(jù)開發(fā)任務, 數(shù)據(jù) etl 導出任務,任務流的管理和調(diào)度. 借助于指標庫和數(shù)倉開發(fā)規(guī)范做數(shù)據(jù)的加工. 整個開發(fā)過程中, 數(shù)據(jù)開發(fā)平臺,數(shù)據(jù)質(zhì)量管理,指標庫平臺會通過對命名, 指標的查重等手段來強制一些開發(fā)規(guī)范的執(zhí)行, 從根本上解決數(shù)據(jù)指標口徑一致和數(shù)據(jù)復用等問題.

有贊離線數(shù)據(jù)資產(chǎn)如上圖中藍色部分, 從底向上分為三層:

公共數(shù)據(jù)層公共數(shù)據(jù)層主要承載數(shù)倉建模中的 ODS 層和 DW 層, 數(shù)據(jù)的開發(fā)和口徑管理由數(shù)據(jù)倉庫團隊負責. 數(shù)據(jù)的開發(fā)和口徑管理嚴格按照數(shù)倉開發(fā)規(guī)范和指標管理規(guī)范,提供公共的原子指標的開發(fā).

垂直業(yè)務域數(shù)據(jù)層垂直業(yè)務域數(shù)據(jù)層, 樹妖曾在數(shù)倉建模中的 DM 層, 數(shù)據(jù)的開發(fā)和口徑管理由業(yè)務方的數(shù)據(jù)開發(fā)同學負責. 業(yè)務方同樣根據(jù)數(shù)倉開發(fā)規(guī)范和指標管理規(guī)范, 完成派生指標的開發(fā).

數(shù)據(jù)服務層數(shù)據(jù)在離線數(shù)倉中開發(fā)完畢后, 通過數(shù)據(jù)開發(fā)平臺的 ETL 導出任務導出到在線存儲層, 然后自行封裝或者通過統(tǒng)一數(shù)據(jù)服務,提供在線數(shù)據(jù)接口.這一分層在實時數(shù)倉中同樣適用, 本文不展開

三. 總結(jié)&展望有贊數(shù)據(jù)中臺并不是一蹴而就, 而是面臨著業(yè)務和技術上的挑戰(zhàn)逐漸成長到現(xiàn)在, 當然還有很多待完善的地方, 比如指標庫,統(tǒng)一數(shù)據(jù)服務還處于剛剛起步階段. 后面有贊數(shù)據(jù)中臺的建設將主要集中在成本,數(shù)據(jù)資產(chǎn)管理&復用,實時數(shù)倉等方面發(fā)力, 幫助我們的商家和業(yè)務方挖掘更多數(shù)據(jù)價值.

總結(jié)

以上是生活随笔為你收集整理的有赞数据中台建设实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。