一、面臨的問題

自16年成立以來，網(wǎng)易嚴(yán)選已經(jīng)發(fā)展了7個年頭。數(shù)據(jù)一直是網(wǎng)易嚴(yán)選的核心資產(chǎn)，支撐著我們的業(yè)務(wù)發(fā)展，大數(shù)據(jù)平臺也在嚴(yán)選成立不久之后就開始建設(shè)了。

我們的大數(shù)據(jù)基礎(chǔ)組建主要包括HDFS存儲系統(tǒng)、Kafka/Pulsar等消息中間件，還有用于實時計算的Flink、批處理的Hive、Spark計算引擎、AI訓(xùn)練的temsoflow，在這些基礎(chǔ)設(shè)施之上我們也開發(fā)了很多數(shù)據(jù)產(chǎn)品，如數(shù)據(jù)集成工具datahub，任務(wù)開發(fā)平臺等。

嚴(yán)選的數(shù)據(jù)來源主要包括線上業(yè)務(wù)數(shù)據(jù)庫的數(shù)據(jù)、埋點日志數(shù)據(jù)，這些數(shù)據(jù)經(jīng)過數(shù)據(jù)集成工具收集至大數(shù)據(jù)平臺，經(jīng)過數(shù)據(jù)開發(fā)工程師、算法工程師的ETL處理來構(gòu)建數(shù)據(jù)倉庫、提取特征進(jìn)行算法模型訓(xùn)練，處理好的數(shù)據(jù)最終被數(shù)據(jù)產(chǎn)品/算法/BI等服務(wù)使用。數(shù)據(jù)從集成到最終被使用的鏈路非常長，而且中間依賴包括計算/存儲/調(diào)度等很多服務(wù)和組件。

隨著業(yè)務(wù)的發(fā)展，任務(wù)越來越多，參與開發(fā)的人員也越來越多，很多問題就逐漸暴露了出來，主要包括如下幾點：

1、首當(dāng)其沖的是數(shù)據(jù)成本，數(shù)據(jù)日積月累、存儲量與日俱增、計算量也隨之增大，但是又不能快速準(zhǔn)確地對數(shù)據(jù)進(jìn)行分類，數(shù)據(jù)是否有用全然不知，數(shù)據(jù)也不敢輕易刪除；

2、其次是數(shù)據(jù)使用效率低，越來越多的表缺乏管理，在頻繁變更的需求面前無法快速知道想要的數(shù)據(jù)是否已經(jīng)存在，存在的又不知道具體在哪，較多的時間花費在溝通確認(rèn)上；

3、數(shù)據(jù)穩(wěn)定性差，調(diào)度任務(wù)越來越多，用戶的資源參數(shù)隨意設(shè)置，集群計算資源不足導(dǎo)致任務(wù)經(jīng)常失敗無法及時產(chǎn)出數(shù)據(jù)。在大促時期，更是無法保證數(shù)據(jù)產(chǎn)出的穩(wěn)定性；

4、數(shù)據(jù)開發(fā)缺乏規(guī)范，數(shù)倉分層混亂，模型隨意設(shè)計不通用，導(dǎo)致sql代碼隨意編寫、任務(wù)重復(fù)開發(fā)等問題，降低數(shù)據(jù)開發(fā)效率。

為了解決這些問題，我們成立了治理專項小組，并開發(fā)了全鏈路數(shù)據(jù)治理平臺，目標(biāo)是來提升大數(shù)據(jù)平臺整體的服務(wù)效率，對整個數(shù)據(jù)體系流程進(jìn)行系統(tǒng)性的治理。

二、全鏈路數(shù)據(jù)治理平臺

整個治理平臺的設(shè)計主要包括三大治理服務(wù) + 6個治理模型 + 3個治理應(yīng)用。

• 治理服務(wù)：包括統(tǒng)一元數(shù)據(jù)服務(wù)、全鏈路血緣服務(wù)、全鏈路監(jiān)控服務(wù)；

• 治理模型：基于治理服務(wù)提供的基本信息，來對數(shù)據(jù)進(jìn)行有效評估，給出治理策略，并由治理應(yīng)用來實際執(zhí)行。

主要包括：表生命周期模型、任務(wù)健康模型、任務(wù)優(yōu)先級模型、任務(wù)資源模型、數(shù)據(jù)產(chǎn)出模型、任務(wù)調(diào)度模型；

• 治理應(yīng)用：表治理、任務(wù)治理、系統(tǒng)治理。

1、統(tǒng)一元數(shù)據(jù)服務(wù)

我們通過統(tǒng)一元數(shù)據(jù)服務(wù)來統(tǒng)一對元數(shù)據(jù)進(jìn)行管理，以解決元數(shù)據(jù)分散的問題，這些元數(shù)據(jù)可以清晰地描述數(shù)據(jù)在大數(shù)據(jù)體系中的運轉(zhuǎn)狀態(tài)和內(nèi)部組織結(jié)構(gòu)，我們的元數(shù)據(jù)主要來源于數(shù)據(jù)源、數(shù)據(jù)表、任務(wù)和數(shù)據(jù)服務(wù)。

像數(shù)據(jù)表元信息中我們詳細(xì)記錄了其表名、表結(jié)構(gòu)，還記錄了其訪問情況、存儲位置等，任務(wù)元信息中記錄了任務(wù)類型、資源配置、調(diào)度周期、歷史運行情況。

這些元數(shù)據(jù)都有相應(yīng)的agent自動采集，當(dāng)元數(shù)據(jù)發(fā)生變更時，如表結(jié)構(gòu)的變更會及時上報。

2、全鏈路血緣服務(wù)

元數(shù)據(jù)只是定義了一個個數(shù)據(jù)實體，如何讓這些孤立的實體建立聯(lián)系，就是血緣服務(wù)的主要職責(zé)。

對于不同的數(shù)據(jù)服務(wù)和組件，我們也有相應(yīng)的Agent來采集血緣，比如我們有Hive hook、spark listener來實時采集計算引擎的動態(tài)血緣，也有sql靜態(tài)血緣解析器來采集sql任務(wù)中的血緣，當(dāng)任務(wù)編輯上線時立即可以感知血緣的變更并更新。

每個agent將采集的局部血緣通過RPC請求方式傳輸給Linage Core模塊，Lineage Core負(fù)責(zé)將這些局部血緣構(gòu)建成完整的血緣圖譜和持久化存儲，并對外提供相應(yīng)的血緣查詢服務(wù)。

由于后續(xù)的所有治理措施是構(gòu)建在血緣之上的，錯誤的血緣關(guān)系將導(dǎo)致錯誤的治理決策，所以血緣數(shù)據(jù)的準(zhǔn)確性就尤其重要，我們有血緣校驗?zāi)K來對建立的血緣進(jìn)行稽核校驗，以確保我們構(gòu)建血緣的準(zhǔn)確率。當(dāng)前我們的血緣已經(jīng)有99%覆蓋率，已接入的血緣準(zhǔn)確率達(dá)到100%。

3、全鏈路監(jiān)控服務(wù)

最后一個關(guān)鍵的服務(wù)是全鏈路監(jiān)控服務(wù)，負(fù)責(zé)監(jiān)控數(shù)據(jù)鏈路中的任務(wù)、服務(wù)的運行情況，并收集相應(yīng)的metrics，比如任務(wù)的資源使用情況，實時任務(wù)的消息延遲、批任務(wù)的執(zhí)行時長、HDFS的整體存儲水位、Yarn集群的資源使用情況等。

4、數(shù)據(jù)治理模型

當(dāng)有了完整的數(shù)據(jù)元信息、血緣關(guān)系信息、監(jiān)控信息之后，我們就可以基于這些信息，來構(gòu)建一些治理模型，以輔助我們做出治理決策，并采取相應(yīng)的治理措施。

比如，我們使用任務(wù)健康模型從任務(wù)的配置、資源使用、運行時長、產(chǎn)出數(shù)據(jù)使用率等多個維度來評估任務(wù)的健康程度，每一個任務(wù)都有一份體檢報告，異常項一目了然。

使用表生命周期模型來根據(jù)表的訪問頻次、優(yōu)先級、存儲格式來對數(shù)據(jù)表進(jìn)行分類。

數(shù)據(jù)處理模型主要是針對離線數(shù)據(jù)的調(diào)度，對離線調(diào)度任務(wù)進(jìn)行路徑分析，識別生產(chǎn)鏈路中的關(guān)鍵節(jié)點、判斷是否出現(xiàn)資源瓶頸。

根據(jù)這些治理模型，可以讓我們俯瞰整個大數(shù)據(jù)平臺的運作情況，在此基礎(chǔ)之上我們就可以快速地構(gòu)建治理服務(wù)。

5、數(shù)據(jù)成本治理

首先分享表治理、任務(wù)治理兩個數(shù)據(jù)成本治理的案例：

1）表治理

通過表生命周期模型，我們可以將表數(shù)據(jù)劃分為幾類：頻繁訪問的熱表、訪問頻次不是那么高的溫數(shù)據(jù)、幾乎不訪問的冷表。

對于熱數(shù)據(jù)，我們可以在其產(chǎn)出后，進(jìn)行緩存預(yù)熱，來提高查詢效率；對于冷數(shù)據(jù)，我們可以進(jìn)行冷備、過期數(shù)據(jù)進(jìn)行刪除操作來節(jié)省存儲。

還有一個就是小文件合并。眾所周知，小文件在HDFS這種針對離線大文件而設(shè)計的存儲系統(tǒng)是非常不友好的，存儲效率低，過多的小文件對namenode帶來的壓力巨大。因此，我們可以給予表的存儲信息，自動識別出有小文件的表，并通過小文件合并工具自動合并。

由于Hive是不支持事物的，同時對同一張表進(jìn)行讀寫是有問題的，因此我們根據(jù)血緣和任務(wù)調(diào)度信息來進(jìn)行錯峰執(zhí)行，避免同時對表的同一個分區(qū)進(jìn)行操作，并且做了數(shù)據(jù)比對、備份、失敗快速恢復(fù)回滾處理，保證合并過程數(shù)據(jù)的準(zhǔn)確性。

2）任務(wù)治理

任務(wù)治理可以根據(jù)任務(wù)健康模型來識別健康分低的任務(wù)，并自動做出治理優(yōu)化，如對產(chǎn)出冷表的任務(wù)進(jìn)行下線處理，來節(jié)省存儲計算資源；對任務(wù)進(jìn)行計算引擎的自動升級，來提升其運行效率。

我們的任務(wù)離線調(diào)度是基于Azkaban的，任務(wù)之間的依賴需要用戶手動配置，任務(wù)治理服務(wù)會自動對任務(wù)進(jìn)行配置項優(yōu)化，去掉無效的任務(wù)依賴、補全缺失的依賴，在配置的時候給出依賴建議，減少人工操作。

有些任務(wù)執(zhí)行耗時耗資源，對于這些低效任務(wù)，我們采取報警的手段是通知到人，進(jìn)行人工調(diào)優(yōu)。

表和任務(wù)的治理主要是關(guān)注在局部和個體，而更為全局的治理，則由我們的系統(tǒng)治理來完成，接下來介紹一下我們的系統(tǒng)性治理項之一——數(shù)倉基線穩(wěn)定性治理。

6、數(shù)倉基線穩(wěn)定性治理

在數(shù)據(jù)生產(chǎn)鏈路中，會對核心數(shù)據(jù)產(chǎn)出任務(wù)配置不同的基線，比如掛在凌晨3點基線上的任務(wù)，需要在3點之前完成，晚于3點就造成了破線，從而導(dǎo)致數(shù)據(jù)產(chǎn)出延遲。

在數(shù)據(jù)開發(fā)過程中，任務(wù)的調(diào)度時間是通過人工設(shè)置的，而人工很難有一個全局的視角.來判斷任務(wù)具體哪一個時間點調(diào)度是最佳時間，實際上往往是估摸著大概設(shè)置一個調(diào)度時間。

所以我們分析發(fā)現(xiàn)，有很多任務(wù)的調(diào)度時間設(shè)置是不合理的，導(dǎo)致系統(tǒng)在某一些時間段有任務(wù)堆積、資源不足的情況，從而導(dǎo)致基線破線頻發(fā)，值班起夜頻繁。

為了保障數(shù)據(jù)及時產(chǎn)出，我們針對全鏈路數(shù)倉任務(wù)進(jìn)行智能調(diào)度，首先我們根據(jù)血緣信息對任務(wù)進(jìn)行自動分級打標(biāo)，然后根據(jù)任務(wù)的優(yōu)先級、任務(wù)的歷史運行情況和平臺的整體計算資源，來自動計算出每個任務(wù)最合理的調(diào)度時間、資源配置。

由于這些任務(wù)都是T+1任務(wù)，調(diào)整后的效果提升是否明顯，需要等到第二天凌晨才能知曉，而且頻繁調(diào)整線上任務(wù)也存在較大的風(fēng)險，因此我們開發(fā)一個調(diào)度模擬器來模擬任務(wù)調(diào)度，這樣我們可以快速地驗證我們的治理策略的效果，給我們提供是否實施該治理策略的依據(jù)，當(dāng)效果符合預(yù)期時，才實際去調(diào)整，從而可以減少頻繁調(diào)整線上任務(wù)規(guī)避風(fēng)險。

下圖是我們對數(shù)倉3點基線的一個治理效果，按照智能調(diào)度給出的治理策略，調(diào)整了線上任務(wù)的調(diào)度時間，效果還是非常顯著，基線完成時間提前40小時。

前面介紹的成本治理和穩(wěn)定性治理都是在事后介入治理，也就是先污染后治理，如果一直以這些策略的話是治標(biāo)不治本。

我們不知道是小文件、任務(wù)配置不合理的問題，還是開發(fā)人員在開發(fā)階段造成的問題。當(dāng)我們深入了解數(shù)倉開發(fā)的全流程后，我們發(fā)現(xiàn)數(shù)倉建設(shè)過程中是存在很多問題，如數(shù)倉架構(gòu)不合理、計算口徑不統(tǒng)一、指標(biāo)缺乏管理構(gòu)建混亂，模型設(shè)計不規(guī)范開發(fā)效率低等。

三、數(shù)據(jù)開發(fā)治理

為了治理這類開發(fā)不規(guī)范的問題，我們構(gòu)建了一套指標(biāo)管理系統(tǒng)Polaris，提供指標(biāo)、模型的開發(fā)管理能力，讓數(shù)據(jù)開發(fā)流程更為規(guī)范，并提供自動生成任務(wù)的能力，以達(dá)到事前治理的目的，從源頭避免了污染。

以前數(shù)據(jù)開發(fā)對指標(biāo)的管理非?；靵y（記錄在文檔中、指標(biāo)起名隨意、計算口徑可能寫在物理表注釋中），指標(biāo)管理平臺可以提供更加標(biāo)準(zhǔn)的指標(biāo)定義流程，在平臺根據(jù)業(yè)務(wù)域來劃分，進(jìn)行業(yè)務(wù)過程、原子指標(biāo)、派生指標(biāo)的設(shè)計和計算口徑的定義。

在模型構(gòu)建流程上也更加規(guī)范，完全規(guī)避了數(shù)倉跨層依賴、反向依賴、相同指標(biāo)重復(fù)計算的問題，并且平臺提供了模型代碼自動構(gòu)建的能力，用戶只需要在平臺上設(shè)計好指標(biāo)和模型即可，任務(wù)代碼由平臺根據(jù)模型自動生成，并自動完成任務(wù)的發(fā)布與調(diào)度，像之前提及的任務(wù)調(diào)度時間設(shè)置、資源設(shè)置、表存儲格式設(shè)置都無需用戶介入，僅需專注于模型的設(shè)計工作即可。

數(shù)據(jù)開發(fā)工程師就可以在平臺上完成數(shù)據(jù)域定義、業(yè)務(wù)過程定義、指標(biāo)定義、模型定義，并使用平臺提供的一鍵發(fā)布功能，完成模型的開發(fā)與上線，極大地提高了模型開發(fā)的效率，也確保了整個流程上的規(guī)范性。

當(dāng)前Polaris平臺已經(jīng)有300多個指標(biāo)、200+個模型在指標(biāo)平臺上構(gòu)建，自動化構(gòu)建的100+個模型，大大提升了數(shù)據(jù)開發(fā)的效率，指標(biāo)開發(fā)的交付周期由周縮短至天。

經(jīng)歷過這些數(shù)據(jù)治理的場景和需求之后，從最開始的事后治理，到指標(biāo)平臺建設(shè)開展事前治理，嚴(yán)選數(shù)據(jù)體系不斷地進(jìn)行演進(jìn)，整個過程也在趨于完善。

四、總結(jié)&未來規(guī)劃

數(shù)據(jù)治理是一個持續(xù)的過程。

在未來的工作中，我們希望數(shù)據(jù)治理更加的自動化、智能化。如元數(shù)據(jù)的能實現(xiàn)自動發(fā)現(xiàn)與采集，治理流程更加自動化，來提高數(shù)據(jù)治理的效率；實現(xiàn)任務(wù)調(diào)度的智能化，提高計算資源的利用率，提高數(shù)倉基線的完成率。

本文根據(jù)祝佳俊老師在〖2023 中國數(shù)據(jù)智能管理峰會-上海站〗現(xiàn)場演講內(nèi)容整理而成。