(網(wǎng)經(jīng)社訊)一、概述
究竟什么是中臺, 業(yè)界并沒有一個標準答案, 各個廠商都有自己的定義. 筆者比較認可的一個定義是 ThoughtWorks 提出的'企業(yè)級能力復(fù)用平臺'. 各個領(lǐng)域涌現(xiàn)出很多中臺產(chǎn)品, 如業(yè)務(wù)中臺, 搜索中臺, 數(shù)據(jù)中臺等. 其中數(shù)據(jù)中臺這個詞匯越來越多的出現(xiàn)在視野中, 從百度指數(shù)中可以看到這一趨勢.
本文, 介紹有贊的數(shù)據(jù)中臺產(chǎn)生的背景和建設(shè)思路. 簡單來說, 有贊的數(shù)據(jù)中臺解決的是'有贊的數(shù)據(jù)資產(chǎn)的加工和復(fù)用', 這里提到了數(shù)據(jù)中臺的兩個重要功能: 數(shù)據(jù)加工和數(shù)據(jù)復(fù)用, 分別由數(shù)據(jù)技術(shù)中臺和數(shù)據(jù)資產(chǎn)中臺解決. 數(shù)據(jù)技術(shù)中臺主要解決數(shù)據(jù)的加工問題, 在眾多大數(shù)據(jù)組件中,幫助數(shù)據(jù)開發(fā)者簡化開發(fā)過程,提高開發(fā)效率. 數(shù)據(jù)資產(chǎn)中臺主要是解決數(shù)據(jù)復(fù)用的問題, 要做到數(shù)據(jù)復(fù)用, 數(shù)據(jù)口徑的統(tǒng)一是重中之重. 雙管齊下, 提高對前臺業(yè)務(wù)的支撐效率.
二. 數(shù)據(jù)團隊面臨的挑戰(zhàn)
數(shù)據(jù)團隊面臨的挑戰(zhàn)主要有兩方面:
業(yè)務(wù)挑戰(zhàn)
技術(shù)挑戰(zhàn)
2.1 業(yè)務(wù)挑戰(zhàn)
有贊是一家服務(wù)商家的 SaaS 公司, 服務(wù)數(shù)百萬各行各業(yè)的商家, 提供電商解決方案. 有贊數(shù)據(jù)團隊的服務(wù)對象主要是各個前臺業(yè)務(wù)線, 所以一切故事的開始來源于業(yè)務(wù)團隊. 因為業(yè)務(wù)特點決定, 目前有贊的數(shù)據(jù)需求有以下特點:
垂直業(yè)務(wù)線眾多: 有贊微商城, 有贊零售, 有贊美業(yè), 有贊教育等
業(yè)務(wù)域眾多: 商品, 店鋪, 會員, 交易, 支付等
數(shù)據(jù)需求多樣: 商家后臺數(shù)據(jù)報表需求, 運營側(cè)數(shù)據(jù)分析需求, 大促看板需求, 實時報表需求等
業(yè)務(wù)需求迅速迭代: 業(yè)務(wù)模型的迭代演進, SaaS領(lǐng)域?qū)σ延泄δ鼙容^高的兼容要求等
...
2.2 技術(shù)挑戰(zhàn)
業(yè)務(wù)線各種各樣的數(shù)據(jù)需求, 給數(shù)據(jù)團隊提出了很多挑戰(zhàn), 主要體現(xiàn)在兩方面:
組件多, 維護成本高
開發(fā)門檻高
組件多, 維護成本高
軟件行業(yè)'沒有銀彈'在大數(shù)據(jù)領(lǐng)域顯現(xiàn)的淋漓盡致. 在有贊的大數(shù)據(jù)技術(shù)棧中, 針對不同的場景, 分別維護著眾多的大數(shù)據(jù)組件. 如數(shù)據(jù)基礎(chǔ)組件的 HDFS, YARN 組件;離線計算元數(shù)據(jù)組件 HIVE META, 離線計算引擎 HIVE, Spark SQL, Presto;實時計算框架 Storm, Spark Streaming, Flink 等. 這些還只是組件本身并不包括組件配套的鑒權(quán), 安全, 脫敏, 質(zhì)量相關(guān)的服務(wù).
開發(fā)門檻高
比如，針對最普通的實時計算場景，任務(wù)的開發(fā)者通?？紤]以下幾個方面問題:
數(shù)據(jù)Source流在哪兒, 如何接入
數(shù)據(jù)處理后的Sink是流還是其他存儲,如果是其他存儲系統(tǒng),可用性是怎樣的,單機房可用還是多機房,擴展性怎么樣, 寫入是否有熱點,是否可以配合實時鏈路的并行度調(diào)整做水平擴展
實時任務(wù)本身的高可用部署，監(jiān)控及報警
消息的一致性語義是什么(at least once, exactly once 還是 at most once), 每種語義對上下游服務(wù)的要求是怎么樣的
實時計算任務(wù)的計算資源如何配置, 水位如何,大促期間如何擴容
公司內(nèi)部各種各樣非大數(shù)據(jù)的技術(shù)組件,如何做適配
...
對于沒有相關(guān)經(jīng)驗的同學(xué), 需要查閱多種組件的文檔, 勢必會有開發(fā)成本高的困擾.
三. 數(shù)據(jù)中臺
按照產(chǎn)生順序, 數(shù)據(jù)中臺主要包括:
數(shù)據(jù)技術(shù)中臺
數(shù)據(jù)資產(chǎn)中臺
3.1 數(shù)據(jù)技術(shù)中臺構(gòu)建
所以, 技術(shù)上的復(fù)雜性, 帶來了開發(fā)成本高的問題. 所以易用性的本質(zhì)是為了提效, 數(shù)據(jù)技術(shù)中臺由一些列工具型平臺構(gòu)成, 最主要的幾部分如下:
基礎(chǔ)組件運維管控
數(shù)據(jù)開發(fā)平臺
數(shù)據(jù)資產(chǎn)管理平臺
數(shù)據(jù)指標管理
統(tǒng)一數(shù)據(jù)服務(wù)
基礎(chǔ)組件運維管控
上文也有提到, 大數(shù)據(jù)基礎(chǔ)組件種類繁多, 概括下來可以分為三類:
離線計算組件 (HDFS,YARN, HIVE, Spark)
分布式在線存儲組件(HBase, Kafka, Druid)
實時計算組件(Storm, Spark Streaming, Flink)
每類組件的管控需求都不盡相同, 比如在線存儲組件對 rt, 可用性要求較高; 實時計算組件對延遲, 積壓問題比較在意; 離線計算組件對數(shù)據(jù)吞吐能力要求較高, 但是因為是分布式計算,所以對慢盤, 慢任務(wù)需要有特別關(guān)注, 否則很容易一個節(jié)點拖慢整個集群.
運維管理好大數(shù)據(jù)組件, 做好動物管理員, 本身就是一件類似數(shù)據(jù)運營的工作, 找到系統(tǒng)的北極星指標, 關(guān)注它, 使用它來幫助做系統(tǒng)的優(yōu)化.
總結(jié)下來, 做好數(shù)據(jù)組件的管理需要解決以下問題:
確定核心指標. 需要 case by case 的確認每個子系統(tǒng)的最核心的指標, 比如對 HDFS 系統(tǒng)來說, 文件數(shù)目, 文件操作 tps, 文件操作的 rt, 99% rt, 是否有丟塊等,就是核心指標, 需要特別關(guān)注.
監(jiān)控. 采集核心指標, 展現(xiàn)到監(jiān)控上, 便于觀察趨勢, 幫助問題排查和擴容等操作的判斷依據(jù).
報警. 根據(jù)核心指標, 確定安全水位, 配置報警, 縮短故障發(fā)現(xiàn)時間.
具備一定的定制開發(fā)能力. 對使用組件不要求有核心 feature 的開發(fā)改造能力(這不符合 ROI), 但是在權(quán)限/安全方面, 社區(qū)版本很難滿足定制需求, 這就需要對基礎(chǔ)組件做一定的改造; 另外需要關(guān)注社區(qū),對于重大隱患的 bug, 需要打回的公司的版本.
軟件發(fā)布/配置發(fā)布規(guī)范. 多人協(xié)作, 多組件協(xié)作, 需要一個完整的開發(fā)/測試/發(fā)布流程, 不止對軟件, 對配置的發(fā)布也一定要規(guī)范. 這方面曾經(jīng)踩過不少的坑.
故障演練, 要定期的主動對技術(shù)組件做故障演練, 有些組件雖然支持某類功能,但是隨著數(shù)據(jù)量, 負載的不同, 這類功能實際效果具體是怎樣的需要通過實踐來確認. 比如 HBase 支持單機宕機自動恢復(fù), 但是宕機恢復(fù)時間究竟是多少, 跟集群負載, 各方面的配置都是相關(guān)的, 需要通過故障演練來組件優(yōu)化系統(tǒng).
性能摸底. 需要對組件做標準的 Benchmark, 一來掌握系統(tǒng)極限,二來在業(yè)務(wù)接入時能夠提供準確的性能指標, 幫助業(yè)務(wù)方做選型判斷.
...
數(shù)據(jù)開發(fā)平臺
數(shù)據(jù)開發(fā)平臺關(guān)注的是數(shù)據(jù)的加工, 是數(shù)據(jù)開發(fā)用戶(數(shù)據(jù)產(chǎn)品開發(fā)同學(xué), 數(shù)倉開發(fā)同學(xué), 業(yè)務(wù)線數(shù)據(jù)開發(fā)同學(xué))最頻繁接觸到的產(chǎn)品, 數(shù)據(jù)開發(fā)平臺主要包括兩個平臺型產(chǎn)品, 分別解決離線和實時場景的數(shù)據(jù)加工需求.
離線開發(fā)平臺, 主要負責(zé)離線數(shù)據(jù)的加工, 任務(wù)調(diào)度, 數(shù)據(jù) ETL, 臨時查詢, 監(jiān)控報警等
實時計算平臺, 主要負責(zé)實時計算任務(wù)的管理, 監(jiān)控報警等
關(guā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)管理服務(wù), 來統(tǒng)籌大數(shù)據(jù)資源的管理.
總體說來, 數(shù)據(jù)資產(chǎn)管理平臺關(guān)注的是數(shù)據(jù)的靜態(tài)狀態(tài), 比如 Hive 的庫表/字段, HBase 的表, Kafka的 Topic. 提供以下幾方面的工具:
數(shù)據(jù)地圖(方便用戶查找,定位已有的數(shù)據(jù)自產(chǎn)并復(fù)用)
數(shù)據(jù)質(zhì)量(對數(shù)據(jù)資源,根據(jù)預(yù)設(shè)的規(guī)則做質(zhì)量檢查,提前發(fā)現(xiàn)潛在問題,比如每日數(shù)據(jù)量,是否有字段缺失等,并且在數(shù)據(jù)不合格的狀況下能夠及時通知出來)
成本核算(統(tǒng)計各個團隊,組件的成本占用,利于做成本降低之類的優(yōu)化,當(dāng)數(shù)據(jù)體量達到一定規(guī)模的時候, 成本問題會變的越來越重要)
數(shù)據(jù)血緣管理(管理所有的數(shù)據(jù)資源的依賴關(guān)系, 主要用在兩個場景: a. 數(shù)據(jù)問題評估, 當(dāng)上游數(shù)據(jù)變更或者質(zhì)量問題的時候, 能夠快速確定影響面和修復(fù)方案. b. 數(shù)據(jù)生命周期管理, 當(dāng)下游應(yīng)用下線,不再使用某個數(shù)據(jù)的時候,能夠找到不被引用的數(shù)據(jù), 及時下線,避免不必要的計算)
...
數(shù)據(jù)指標管理
如果說數(shù)據(jù)平臺關(guān)注的是數(shù)據(jù)的加工/轉(zhuǎn)換,既數(shù)據(jù)任務(wù)的管理; 數(shù)據(jù)資產(chǎn)管理平臺關(guān)注的是具體的數(shù)據(jù)表和字段的質(zhì)量和血緣; 那么指標庫管理的就是數(shù)據(jù)指標的口徑統(tǒng)一和復(fù)用. 在有贊, 我們通過指標庫系統(tǒng)來管理數(shù)據(jù)指標的口徑.
概括來說,數(shù)據(jù)指標被分為原子指標和派生指標. 原子指標為不可再分割的基礎(chǔ)指標, 由數(shù)倉團隊統(tǒng)一開發(fā)和管理, 原子指標數(shù)據(jù)一般落在數(shù)倉的 DW 層. 但是往往業(yè)務(wù)方需要的指標, 原子指標并不能滿足, 所以業(yè)務(wù)方需要在原子指標的基礎(chǔ)上再次加工成派生指標. 比如 交易數(shù)據(jù)中 gmv 是原子指標, 微商城業(yè)務(wù)最近 30 天的gmv 指標就是派生指標 wsc30dgmv.關(guān)于指標庫, 后面會有單獨的文章介紹.
統(tǒng)一數(shù)據(jù)服務(wù)
數(shù)據(jù)開發(fā)平臺,資產(chǎn)治理平臺,指標庫只是解決了數(shù)據(jù)的加工和口徑的統(tǒng)一的問題. 產(chǎn)出的數(shù)據(jù)并不是真正對外可用的. 絕大多數(shù)場景, 都需要數(shù)據(jù)開發(fā)的同學(xué), 將加工后的數(shù)據(jù), 通過數(shù)據(jù)交換組件, 導(dǎo)出到線存儲服務(wù)中, 然后再開發(fā)數(shù)據(jù)接口, 供前臺業(yè)務(wù)同學(xué)調(diào)用. 這里在線存儲服務(wù)到接口這一層, 傳統(tǒng)的業(yè)務(wù)支撐方式中存在大量的重復(fù)開發(fā). 針對這個問題, 我們設(shè)計統(tǒng)一數(shù)據(jù)服務(wù), 用戶通過配置模板的方式, 生成數(shù)據(jù) API 服務(wù), 簡化開發(fā)流程. 有贊的統(tǒng)一數(shù)據(jù)服務(wù)目前剛剛上線, 已經(jīng)支持 10 業(yè)務(wù)場景, 后面會有單獨的文章介紹.
3.2 數(shù)據(jù)資產(chǎn)中臺構(gòu)建
3.1 節(jié)中介紹了偏技術(shù)視角的中臺, 涵蓋了大數(shù)據(jù)的技術(shù)架構(gòu). 但是數(shù)據(jù)中臺遠不止技術(shù)設(shè)施,更主要的是數(shù)據(jù)資產(chǎn)的建設(shè)和組織, 因為對業(yè)務(wù)方而言,業(yè)務(wù)方更關(guān)注的是有哪兒些數(shù)據(jù)自產(chǎn)可以使用,而不是通過什么底層技術(shù)實現(xiàn).
大數(shù)據(jù)團隊提供的數(shù)據(jù)資產(chǎn)主要有以下幾類:
離線數(shù)據(jù)資產(chǎn)(離線數(shù)倉)
數(shù)據(jù)智能服務(wù)
實時數(shù)據(jù)資產(chǎn)(實時數(shù)倉)
在用戶數(shù)目上, 目前離線數(shù)倉承接了大多數(shù)的數(shù)據(jù)需求, 這里僅僅對離線數(shù)倉展開介紹. 離線數(shù)倉中數(shù)據(jù)的開發(fā)主要發(fā)生在數(shù)據(jù)開發(fā)平臺上, 包括數(shù)據(jù) etl 導(dǎo)入任務(wù), 數(shù)據(jù)開發(fā)任務(wù), 數(shù)據(jù) etl 導(dǎo)出任務(wù),任務(wù)流的管理和調(diào)度. 借助于指標庫和數(shù)倉開發(fā)規(guī)范做數(shù)據(jù)的加工. 整個開發(fā)過程中, 數(shù)據(jù)開發(fā)平臺,數(shù)據(jù)質(zhì)量管理,指標庫平臺會通過對命名, 指標的查重等手段來強制一些開發(fā)規(guī)范的執(zhí)行, 從根本上解決數(shù)據(jù)指標口徑一致和數(shù)據(jù)復(fù)用等問題.
有贊離線數(shù)據(jù)資產(chǎn)如上圖中藍色部分, 從底向上分為三層:
公共數(shù)據(jù)層
公共數(shù)據(jù)層主要承載數(shù)倉建模中的 ODS 層和 DW 層, 數(shù)據(jù)的開發(fā)和口徑管理由數(shù)據(jù)倉庫團隊負責(zé). 數(shù)據(jù)的開發(fā)和口徑管理嚴格按照數(shù)倉開發(fā)規(guī)范和指標管理規(guī)范,提供公共的原子指標的開發(fā).
垂直業(yè)務(wù)域數(shù)據(jù)層
垂直業(yè)務(wù)域數(shù)據(jù)層, 樹妖曾在數(shù)倉建模中的 DM 層, 數(shù)據(jù)的開發(fā)和口徑管理由業(yè)務(wù)方的數(shù)據(jù)開發(fā)同學(xué)負責(zé). 業(yè)務(wù)方同樣根據(jù)數(shù)倉開發(fā)規(guī)范和指標管理規(guī)范, 完成派生指標的開發(fā).
數(shù)據(jù)服務(wù)層
數(shù)據(jù)在離線數(shù)倉中開發(fā)完畢后, 通過數(shù)據(jù)開發(fā)平臺的 ETL 導(dǎo)出任務(wù)導(dǎo)出到在線存儲層, 然后自行封裝或者通過統(tǒng)一數(shù)據(jù)服務(wù),提供在線數(shù)據(jù)接口.
這一分層在實時數(shù)倉中同樣適用, 本文不展開
三. 總結(jié)&展望
有贊數(shù)據(jù)中臺并不是一蹴而就, 而是面臨著業(yè)務(wù)和技術(shù)上的挑戰(zhàn)逐漸成長到現(xiàn)在, 當(dāng)然還有很多待完善的地方, 比如指標庫,統(tǒng)一數(shù)據(jù)服務(wù)還處于剛剛起步階段. 后面有贊數(shù)據(jù)中臺的建設(shè)將主要集中在成本,數(shù)據(jù)資產(chǎn)管理&復(fù)用,實時數(shù)倉等方面發(fā)力, 幫助我們的商家和業(yè)務(wù)方挖掘更多數(shù)據(jù)價值.
