網易嚴選全鏈路數據治理的實踐與總結

作者：祝佳俊 2023-06-19 07:27:50

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

一、面臨的問題

自16年成立以來，網易嚴選已經發展了7個年頭。數據一直是網易嚴選的核心資產，支撐著我們的業務發展，大數據平臺也在嚴選成立不久之后就開始建設了。

嚴選的數據來源主要包括線上業務數據庫的數據、埋點日志數據，這些數據經過數據集成工具收集至大數據平臺，經過數據開發工程師、算法工程師的ETL處理來構建數據倉庫、提取特征進行算法模型訓練，處理好的數據最終被數據產品/算法/BI等服務使用。數據從集成到最終被使用的鏈路非常長，而且中間依賴包括計算/存儲/調度等很多服務和組件。

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

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

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

3、數據穩定性差，調度任務越來越多，用戶的資源參數隨意設置，集群計算資源不足導致任務經常失敗無法及時產出數據。在大促時期，更是無法保證數據產出的穩定性；

4、數據開發缺乏規范，數倉分層混亂，模型隨意設計不通用，導致sql代碼隨意編寫、任務重復開發等問題，降低數據開發效率。

為了解決這些問題，我們成立了治理專項小組，并開發了全鏈路數據治理平臺，目標是來提升大數據平臺整體的服務效率，對整個數據體系流程進行系統性的治理。

二、全鏈路數據治理平臺

整個治理平臺的設計主要包括三大治理服務 + 6個治理模型 + 3個治理應用。

治理服務：包括統一元數據服務、全鏈路血緣服務、全鏈路監控服務；

治理模型：基于治理服務提供的基本信息，來對數據進行有效評估，給出治理策略，并由治理應用來實際執行。

主要包括：表生命周期模型、任務健康模型、任務優先級模型、任務資源模型、數據產出模型、任務調度模型；

治理應用：表治理、任務治理、系統治理。

1、統一元數據服務

我們通過統一元數據服務來統一對元數據進行管理，以解決元數據分散的問題，這些元數據可以清晰地描述數據在大數據體系中的運轉狀態和內部組織結構，我們的元數據主要來源于數據源、數據表、任務和數據服務。

像數據表元信息中我們詳細記錄了其表名、表結構，還記錄了其訪問情況、存儲位置等，任務元信息中記錄了任務類型、資源配置、調度周期、歷史運行情況。

這些元數據都有相應的agent自動采集，當元數據發生變更時，如表結構的變更會及時上報。

2、全鏈路血緣服務

元數據只是定義了一個個數據實體，如何讓這些孤立的實體建立聯系，就是血緣服務的主要職責。

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

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

由于后續的所有治理措施是構建在血緣之上的，錯誤的血緣關系將導致錯誤的治理決策，所以血緣數據的準確性就尤其重要，我們有血緣校驗模塊來對建立的血緣進行稽核校驗，以確保我們構建血緣的準確率。當前我們的血緣已經有99%覆蓋率，已接入的血緣準確率達到100%。

3、全鏈路監控服務

最后一個關鍵的服務是全鏈路監控服務，負責監控數據鏈路中的任務、服務的運行情況，并收集相應的metrics，比如任務的資源使用情況，實時任務的消息延遲、批任務的執行時長、HDFS的整體存儲水位、Yarn集群的資源使用情況等。

4、數據治理模型

當有了完整的數據元信息、血緣關系信息、監控信息之后，我們就可以基于這些信息，來構建一些治理模型，以輔助我們做出治理決策，并采取相應的治理措施。

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

使用表生命周期模型來根據表的訪問頻次、優先級、存儲格式來對數據表進行分類。

數據處理模型主要是針對離線數據的調度，對離線調度任務進行路徑分析，識別生產鏈路中的關鍵節點、判斷是否出現資源瓶頸。

根據這些治理模型，可以讓我們俯瞰整個大數據平臺的運作情況，在此基礎之上我們就可以快速地構建治理服務。

5、數據成本治理

首先分享表治理、任務治理兩個數據成本治理的案例：

1）表治理

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

對于熱數據，我們可以在其產出后，進行緩存預熱，來提高查詢效率；對于冷數據，我們可以進行冷備、過期數據進行刪除操作來節省存儲。

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

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

2）任務治理

任務治理可以根據任務健康模型來識別健康分低的任務，并自動做出治理優化，如對產出冷表的任務進行下線處理，來節省存儲計算資源；對任務進行計算引擎的自動升級，來提升其運行效率。

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

有些任務執行耗時耗資源，對于這些低效任務，我們采取報警的手段是通知到人，進行人工調優。

表和任務的治理主要是關注在局部和個體，而更為全局的治理，則由我們的系統治理來完成，接下來介紹一下我們的系統性治理項之一——數倉基線穩定性治理。

6、數倉基線穩定性治理

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

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

所以我們分析發現，有很多任務的調度時間設置是不合理的，導致系統在某一些時間段有任務堆積、資源不足的情況，從而導致基線破線頻發，值班起夜頻繁。

為了保障數據及時產出，我們針對全鏈路數倉任務進行智能調度，首先我們根據血緣信息對任務進行自動分級打標，然后根據任務的優先級、任務的歷史運行情況和平臺的整體計算資源，來自動計算出每個任務最合理的調度時間、資源配置。

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

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

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

我們不知道是小文件、任務配置不合理的問題，還是開發人員在開發階段造成的問題。當我們深入了解數倉開發的全流程后，我們發現數倉建設過程中是存在很多問題，如數倉架構不合理、計算口徑不統一、指標缺乏管理構建混亂，模型設計不規范開發效率低等。

三、數據開發治理

為了治理這類開發不規范的問題，我們構建了一套指標管理系統Polaris，提供指標、模型的開發管理能力，讓數據開發流程更為規范，并提供自動生成任務的能力，以達到事前治理的目的，從源頭避免了污染。

以前數據開發對指標的管理非常混亂（記錄在文檔中、指標起名隨意、計算口徑可能寫在物理表注釋中），指標管理平臺可以提供更加標準的指標定義流程，在平臺根據業務域來劃分，進行業務過程、原子指標、派生指標的設計和計算口徑的定義。

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