1、背景

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

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

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

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

• 數(shù)據(jù)地圖：由數(shù)據(jù)開發(fā)治理平臺(tái)的數(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ā)治理平臺(tái)的測試中心提供；
• 影響評估能力：主要由嚴(yán)選數(shù)據(jù)資產(chǎn)中心提供，結(jié)合血緣和數(shù)據(jù)分級能力得出影響程度。

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

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

2、思路

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

（1）規(guī)范制定

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

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

（2）能力建設(shè)

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

（3）治理實(shí)施

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

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

（4）結(jié)果衡量

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

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

3、實(shí)施

3.1 規(guī)范治理

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

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

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

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

• DWS依賴ODS
• DM依賴ODS

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

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

（3）單一事實(shí)建?！\(yùn)動(dòng)式治理

• 一張DWD只依賴一張ODS

3.2 指標(biāo)治理

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

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

3.3 計(jì)算存儲(chǔ)治理

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

（1）計(jì)算治理

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

觸發(fā)條件：

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

防治：

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

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

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

（2）存儲(chǔ)治理

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

觸發(fā)條件：

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

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

防治：

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

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

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

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

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

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

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

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

（1）事前

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

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

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

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

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

QA：測試評審

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

（2）事中

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

（3）事后

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

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

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

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

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

3.6 橫向巡檢機(jī)制

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

4、效果

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

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

（1）規(guī)范

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

（2）計(jì)存

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

（3）質(zhì)量

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