(網(wǎng)經(jīng)社訊)一、概述
究竟什么是中臺, 業(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ù)報表需求, 運營側數(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)化.
總結下來, 做好數(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ù)的加工/轉換,既數(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ù)倉中同樣適用, 本文不展開
三. 總結&展望
有贊數(shù)據(jù)中臺并不是一蹴而就, 而是面臨著業(yè)務和技術上的挑戰(zhàn)逐漸成長到現(xiàn)在, 當然還有很多待完善的地方, 比如指標庫,統(tǒng)一數(shù)據(jù)服務還處于剛剛起步階段. 后面有贊數(shù)據(jù)中臺的建設將主要集中在成本,數(shù)據(jù)資產(chǎn)管理&復用,實時數(shù)倉等方面發(fā)力, 幫助我們的商家和業(yè)務方挖掘更多數(shù)據(jù)價值.
