1、背景

任何一個系統(tǒng)，為了保證其良好地運行下去，一定是需要持續(xù)的維護和治理，數(shù)倉也不例外。本文主要分享下今年嚴(yán)選數(shù)倉團隊從規(guī)范、計存、質(zhì)量、安全幾塊入手對現(xiàn)有數(shù)據(jù)資產(chǎn)進行的一些治理的思路和方案。

網(wǎng)易嚴(yán)選是個自營品牌電商，這意味著嚴(yán)選的業(yè)務(wù)會覆蓋C端的用戶營銷，商品到B端的供應(yīng)鏈以及財務(wù)業(yè)務(wù)。業(yè)務(wù)和數(shù)據(jù)的整體復(fù)雜度會相對較高，各個不同業(yè)務(wù)域也呈現(xiàn)出不同的特點和問題。所以我們需要結(jié)合現(xiàn)有的資產(chǎn)特點去設(shè)計治理方法論和效果評估方法，然后圍繞著治理方法論去建設(shè)我們的治理工具。

治理開始前，先盤一下我們可用的資源，設(shè)計下整體的方向。從人力上來說，項目整體設(shè)計與推動大概可投入1.5人力，治理實施可以拉上資產(chǎn)對應(yīng)的數(shù)據(jù)開發(fā)配合，這個人力方案決定了我們肯定是不會去設(shè)計開發(fā)個整體的治理系統(tǒng)來做這個事情，而是應(yīng)該把重點放在規(guī)范和治理方案設(shè)計上，依托現(xiàn)有基礎(chǔ)能力，以最低程度的開發(fā)資源投入來推動這個事情。

基礎(chǔ)能力上來說，已經(jīng)沉淀的能力有：

• 數(shù)據(jù)地圖：由數(shù)據(jù)開發(fā)治理平臺的數(shù)據(jù)地圖及嚴(yán)選數(shù)據(jù)資產(chǎn)中心提供，大部分?jǐn)?shù)據(jù)沉淀在產(chǎn)品，未入倉；
• 全鏈路血緣：由嚴(yán)選數(shù)據(jù)資產(chǎn)中心提供，數(shù)據(jù)沉淀在產(chǎn)品，未入倉；
• 數(shù)據(jù)探查能力：由數(shù)據(jù)開發(fā)治理平臺的測試中心提供；
• 影響評估能力：主要由嚴(yán)選數(shù)據(jù)資產(chǎn)中心提供，結(jié)合血緣和數(shù)據(jù)分級能力得出影響程度。

整體資產(chǎn)全景見下圖：

歷史我們也做過不少數(shù)據(jù)治理相關(guān)投入，但存在一些問題，比如缺乏體系化設(shè)計，導(dǎo)致多個項目/團隊交叉治理，重復(fù)治理等問題，同時，治理效果也缺乏持續(xù)的追蹤和效果衡量。這些是本次治理項目需要解決的問題。

2、思路

整體思路上我們分4步走。

（1）規(guī)范制定

數(shù)據(jù)建模規(guī)范，即數(shù)據(jù)開發(fā)在設(shè)計模型階段需要遵循的規(guī)范，比如dwd不能加工指標(biāo)等。

數(shù)據(jù)開發(fā)SOP，為了系統(tǒng)能幫我們自動做一些規(guī)范校驗和補全，我們可能制定一些流程上的規(guī)范，比如建表必須走模型設(shè)計中心，dw層全部先評審后開發(fā)等。

（2）能力建設(shè)

即我們數(shù)據(jù)治理過程中需要用到的系統(tǒng)能力補全，包含元數(shù)據(jù)建設(shè)，數(shù)據(jù)平臺的迭代及治理工具的開發(fā)。

（3）治理實施

從治理目標(biāo)上來說，我們圍繞降本、提效、質(zhì)量3個點去規(guī)劃治理方案；

從實施方案上來說，主要落實在規(guī)范、計算存儲、數(shù)據(jù)質(zhì)量、數(shù)據(jù)安全4個方面。

（4）結(jié)果衡量

治理結(jié)果目標(biāo)制定；

治理過程指標(biāo)衡量。

3、實施

3.1 規(guī)范治理

嚴(yán)選數(shù)倉建模規(guī)范主要基于Kimball維度建模理論，結(jié)合嚴(yán)選業(yè)務(wù)實際情況制定，大致架構(gòu)如下圖：

有了規(guī)范定義，那我們首先需要的就是看下當(dāng)前數(shù)倉的規(guī)范程度，這里我們基于元數(shù)據(jù)ETL加工得到我們的監(jiān)測指標(biāo)，并基于有數(shù)BI進行的可視化呈現(xiàn)。

然后基于當(dāng)前數(shù)倉規(guī)范的達成情況，我們制定了今年主要要解決的問題及規(guī)范治理的目標(biāo)，并同樣對治理目標(biāo)做了可視化。主要問題及解決方式如下：

（1）跨層依賴——巡檢及待辦分發(fā)

• DWS依賴ODS
• DM依賴ODS

（2）反向依賴——巡檢及待辦分發(fā)

• DWD依賴DM
• DWD依賴DWS
• DWS依賴DM

（3）單一事實建模——運動式治理

• 一張DWD只依賴一張ODS

3.2 指標(biāo)治理

嚴(yán)選的指標(biāo)管理基于自研的指標(biāo)管理系統(tǒng)，該系統(tǒng)會對指標(biāo)的口徑進行管理，并強制綁定到數(shù)據(jù)網(wǎng)關(guān)，實現(xiàn)從數(shù)據(jù)網(wǎng)關(guān)輸出的數(shù)據(jù)，都附帶明確的口徑定義。但該系統(tǒng)存在一個問題，那就是定義和研發(fā)分離。指標(biāo)口徑基于該系統(tǒng)定義，但是指標(biāo)的開發(fā)和該系統(tǒng)并沒關(guān)聯(lián)，那么在開發(fā)過程中，口徑定義和實際開發(fā)的口徑可能就會出現(xiàn)偏差，并且在dws和ads的加工上，建模設(shè)計完全由數(shù)據(jù)開發(fā)把關(guān)，也就可能出現(xiàn)模型設(shè)計質(zhì)量參差不齊的情況。

對于以上問題，我們的解法是新設(shè)計一套指標(biāo)管理系統(tǒng)，將指標(biāo)定義和開發(fā)工作耦合起來，實現(xiàn)定義即研發(fā)的效果。目前該系統(tǒng)已經(jīng)在部分場景實現(xiàn)了落地，系統(tǒng)詳細設(shè)計這里就不展開了，感興趣的同學(xué)可以線下交流。

3.3 計算存儲治理

計算存儲資源的消耗直接關(guān)系數(shù)據(jù)的生產(chǎn)成本以及數(shù)據(jù)產(chǎn)出的穩(wěn)定性和及時性，所以這塊也是比較重要的。

（1）計算治理

計算資源可優(yōu)化的點主要在于因代碼或參數(shù)的不合理導(dǎo)致的低效任務(wù)上，主要思路是識別出這部分任務(wù)，然后通過by任務(wù)的優(yōu)化去提高資源利用率。治理方法如下：

觸發(fā)條件：

• 數(shù)據(jù)開發(fā)治理平臺openAPI獲取yarn資源消耗明細
• 內(nèi)存空閑時間分布聚類取前20%閾值
• RAM實際申請大于1TB
• 利用率小于10%

防治：

• 全局：整體消耗資源(RMB/RAM/CPU/TIME)分布監(jiān)控
• 個人：觸發(fā)條件發(fā)飛書push任務(wù)治理通知
• 過程記錄(已治理/待治理)效果統(tǒng)計

優(yōu)化方法：謂詞下推/小文件合并/join優(yōu)化/data skew優(yōu)化/提高任務(wù)并行度/Spark AQE 參數(shù)調(diào)整

首先我們起個數(shù)據(jù)開發(fā)治理平臺的任務(wù)，按照觸發(fā)條件去巡檢，篩選出待治理列表。然后發(fā)現(xiàn)這部分任務(wù)有著明顯的長尾分布特性，極少數(shù)任務(wù)占用了大部分資源。所以我們針對top100的任務(wù)由專人挨個進行的by case的優(yōu)化，剩余的任務(wù)則通過待辦分發(fā)的形式推送給任務(wù)的負責(zé)人進行優(yōu)化跟進。同時，我們做了全局的和個人的計算資源監(jiān)控大盤，通過消息通知的形式，每天進行監(jiān)控和公示。

（2）存儲治理

歷史對于冷表冷任務(wù)這塊我們沒有系統(tǒng)關(guān)注和清理過，所以隨著業(yè)務(wù)的不斷發(fā)展積累的大量的冷表冷任務(wù)。對于這塊兒的治理主要借助數(shù)據(jù)開發(fā)治理平臺的數(shù)據(jù)資產(chǎn)中心的存儲優(yōu)化功能。但因為數(shù)據(jù)資產(chǎn)中心對于特殊存儲比如kudu、iceberg，以及倉外血緣沒有做邏輯判斷。所以拿到數(shù)據(jù)資產(chǎn)中心的推薦下線數(shù)據(jù)后，我們結(jié)合嚴(yán)選維護的全鏈路血緣做了交叉校驗，得到最終的待下線任務(wù)集。任務(wù)集的判斷條件如下：

觸發(fā)條件：

• 強推薦：30天打開次數(shù)+近30天引用次數(shù)+近30天訪問次數(shù)+近30天寫入次數(shù) = 0
• 弱推薦 ：近30天打開次數(shù)+近30天引用次數(shù)+近30天訪問次數(shù) = 0
• 不存在于調(diào)度任務(wù)

得到任務(wù)集后，先大致分析了下待下線表的分布，發(fā)現(xiàn)有幾個占比較大且風(fēng)險較低的庫，比如kylin cube build的臨時數(shù)據(jù)，庫存中心的流水日志等，我們判斷風(fēng)險較小，且數(shù)量較大，就讓數(shù)據(jù)開發(fā)治理平臺的同學(xué)幫忙批量下線掉。對于是dw，dm等db的表，因為誰也沒辦法保證血緣100%的準(zhǔn)確性，且攤分到每個人頭上后量不算大，所以就采取待辦分發(fā)的形式push表負責(zé)人去進行治理。然后我們再通過open API去監(jiān)控集群整體，和每個數(shù)據(jù)開發(fā)的冷表治理情況，針對需要改進的點再單獨push。

防治：

• 全局：整體情況及占比變化效果群消息
• 個人：單獨push需要治理的表
• 數(shù)據(jù)開發(fā)治理平臺的數(shù)據(jù)資產(chǎn)存儲模塊操作
• API獲取處理結(jié)果統(tǒng)計

3.4 數(shù)據(jù)安全治理

這個事情大的背景是目前數(shù)倉關(guān)于數(shù)據(jù)加密脫敏，數(shù)據(jù)權(quán)限管理等工作基本靠共識，比如大家都知道用戶手機號是敏感數(shù)據(jù)，有人要這份數(shù)據(jù)時也會多走個流程審批一下。但是到底哪些表里面有存用戶手機號，這些手機號有沒有被妥善地加密或脫敏，表授權(quán)時有沒有去判斷里面是否有敏感數(shù)據(jù)，這些我們都是不知道的。所以我們考慮基于實體識別的方法，把數(shù)據(jù)資產(chǎn)的敏感程度給分級打標(biāo)出來。

分級打標(biāo)的依據(jù)是集團下發(fā)的《網(wǎng)易數(shù)據(jù)分類分級管理制度》，根據(jù)這個文件，我們手工把數(shù)倉的各項涉敏數(shù)據(jù)項給盤點出來，整理成結(jié)構(gòu)化的數(shù)據(jù)。再用一個Spark Job的形式去批量對所有數(shù)倉表進行采樣和字段打標(biāo)。大致實現(xiàn)如下:↓

目前這個系統(tǒng)做了基本的實現(xiàn)，后續(xù)需要繼續(xù)擴展識別項覆蓋率和準(zhǔn)確率，具體技術(shù)細節(jié)我們就不在這里討論了，后面單開一篇文章分享。

得到分級結(jié)果后，我們就可以拿這份數(shù)據(jù)去重新盤點和治理我們的數(shù)據(jù)加密和權(quán)限管理情況了。

3.5 數(shù)據(jù)質(zhì)量治理

質(zhì)量這塊兒我們分事前、事中、事后三塊去實施。

（1）事前

事前我們主要是規(guī)范數(shù)據(jù)需求流程，明確各個參與方職責(zé)，進行風(fēng)險評估和保障定義：

業(yè)務(wù)：需求提出

BI/PM：1、需求拆解 2、確定口徑

數(shù)據(jù)開發(fā)：需求評審

• 數(shù)據(jù)系分評審、鏈路評估
• 驗證方案、回滾方案
• 鏈路風(fēng)險巡檢/治理
• SLA 定義、保障方式定義

QA：測試評審

• 測試測分及評審
• 自測標(biāo)準(zhǔn)、驗收標(biāo)準(zhǔn)
• 測試報告、驗收反饋
• 事故報告、事故復(fù)盤

（2）事中

事中我們遵循數(shù)據(jù)開發(fā)->研發(fā)自測->QA自測->數(shù)據(jù)發(fā)布->產(chǎn)品發(fā)布->用戶驗收的流程，保證研發(fā)過程的質(zhì)量合格。

（3）事后

事后指的是需求交付后的運維保障及應(yīng)急恢復(fù)，這里的策略包括：基線值班、DQC、變更感知、大促時的壓測和發(fā)生故障后的復(fù)盤。

基線值班會有數(shù)據(jù)基線該怎么掛的問題，任務(wù)A到底要保障到7點產(chǎn)出還是9點產(chǎn)出，值班的資源是有限的，都保障就意味著保障力度都降低，同理DQC的配置也是。這里我們的做法是，先從數(shù)據(jù)的使用場景出發(fā)，看看線上服務(wù)和有數(shù)報表的重要性分級是什么樣的。再根據(jù)血緣往上追蹤，對整個上游鏈路的數(shù)據(jù)任務(wù)挨個打標(biāo)，高優(yōu)覆蓋低優(yōu)，以此來確認(rèn)任務(wù)的保障等級。

獲得任務(wù)分級后，我們把P0，P1的任務(wù)掛載到了7:30/9:30兩條基線，P2任務(wù)掛載到了10:00基線，由數(shù)據(jù)值班來保障他們的按時產(chǎn)出，并對破線及任務(wù)失敗進行記錄和復(fù)盤，便于確認(rèn)后續(xù)優(yōu)化方向。同時，P0、P1的任務(wù)也強制要求大家配上了基本的數(shù)據(jù)稽核。

然后是變更感知這塊兒，包含數(shù)據(jù)源變更感知和ETL變更感知。數(shù)倉不生產(chǎn)數(shù)據(jù)，我們在只是數(shù)據(jù)的搬運工，所以感知數(shù)據(jù)源的變更和“搬運程序”的變更對數(shù)據(jù)質(zhì)量的保障特別重要。

這里我們的做法是，收集數(shù)據(jù)源的變更工單日志以及數(shù)倉表和任務(wù)的修改記錄，通過一個周期調(diào)度的spark sql任務(wù)去識別出風(fēng)險變更以及影響范圍，并推送消息給到對應(yīng)的數(shù)據(jù)開發(fā)評估。

3.6 橫向巡檢機制

前面關(guān)于各個治理項目都有提到需要推送待辦任務(wù)給數(shù)據(jù)開發(fā)處理，所以我們需要一個通用的消息通知機制。再結(jié)合到我們大多數(shù)巡檢場景都可以基于元數(shù)據(jù)+SQL的形式識別，于是我們采用UDF的方法，對接消息中心的接口，實現(xiàn)了消息通知的SQL化。

4、效果

治理效果這塊兒，我們基于有數(shù)BI搭建了可視化看板，對整體的目標(biāo)達成率和每個人的目標(biāo)達成率進行了監(jiān)控和跟進。

具體關(guān)鍵成果如下：

（1）規(guī)范

• DWS跨層依賴率 21.2%->17.5%
• DWD反依賴率18.1%->11.5%

（2）計存

• 冷表下線10W+張，累計下降存儲2.8PB，凈下降1.9PB（8.49-6.59）
• 資源費用 12k/day->2k/day
• 內(nèi)存memory seconds 下降33%
• 高耗資源任務(wù)運行時間 下降90%
• 高耗資源任務(wù)成本消耗 下降69%

（3）質(zhì)量

• 基線破線率23.76%->0%
• DQC配置率10%->100%