1、背景

任何一個系統，為了保證其良好地運行下去，一定是需要持續的維護和治理，數倉也不例外。本文主要分享下今年嚴選數倉團隊從規范、計存、質量、安全幾塊入手對現有數據資產進行的一些治理的思路和方案。

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

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

基礎能力上來說，已經沉淀的能力有：

• 數據地圖：由數據開發治理平臺的數據地圖及嚴選數據資產中心提供，大部分數據沉淀在產品，未入倉；
• 全鏈路血緣：由嚴選數據資產中心提供，數據沉淀在產品，未入倉；
• 數據探查能力：由數據開發治理平臺的測試中心提供；
• 影響評估能力：主要由嚴選數據資產中心提供，結合血緣和數據分級能力得出影響程度。

整體資產全景見下圖：

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

2、思路

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

（1）規范制定

數據建模規范，即數據開發在設計模型階段需要遵循的規范，比如dwd不能加工指標等。

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

（2）能力建設

即我們數據治理過程中需要用到的系統能力補全，包含元數據建設，數據平臺的迭代及治理工具的開發。

（3）治理實施

從治理目標上來說，我們圍繞降本、提效、質量3個點去規劃治理方案；

從實施方案上來說，主要落實在規范、計算存儲、數據質量、數據安全4個方面。

（4）結果衡量

治理結果目標制定；

治理過程指標衡量。

3、實施

3.1 規范治理

嚴選數倉建模規范主要基于Kimball維度建模理論，結合嚴選業務實際情況制定，大致架構如下圖：

有了規范定義，那我們首先需要的就是看下當前數倉的規范程度，這里我們基于元數據ETL加工得到我們的監測指標，并基于有數BI進行的可視化呈現。

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

（1）跨層依賴——巡檢及待辦分發

• DWS依賴ODS
• DM依賴ODS

（2）反向依賴——巡檢及待辦分發

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

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

• 一張DWD只依賴一張ODS

3.2 指標治理

嚴選的指標管理基于自研的指標管理系統，該系統會對指標的口徑進行管理，并強制綁定到數據網關，實現從數據網關輸出的數據，都附帶明確的口徑定義。但該系統存在一個問題，那就是定義和研發分離。指標口徑基于該系統定義，但是指標的開發和該系統并沒關聯，那么在開發過程中，口徑定義和實際開發的口徑可能就會出現偏差，并且在dws和ads的加工上，建模設計完全由數據開發把關，也就可能出現模型設計質量參差不齊的情況。

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

3.3 計算存儲治理

計算存儲資源的消耗直接關系數據的生產成本以及數據產出的穩定性和及時性，所以這塊也是比較重要的。

（1）計算治理

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

觸發條件：

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

防治：

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

優化方法：謂詞下推/小文件合并/join優化/data skew優化/提高任務并行度/Spark AQE 參數調整

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

（2）存儲治理

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

觸發條件：

• 強推薦：30天打開次數+近30天引用次數+近30天訪問次數+近30天寫入次數 = 0
• 弱推薦 ：近30天打開次數+近30天引用次數+近30天訪問次數 = 0
• 不存在于調度任務

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

防治：

• 全局：整體情況及占比變化效果群消息
• 個人：單獨push需要治理的表
• 數據開發治理平臺的數據資產存儲模塊操作
• API獲取處理結果統計

3.4 數據安全治理

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

分級打標的依據是集團下發的《網易數據分類分級管理制度》，根據這個文件，我們手工把數倉的各項涉敏數據項給盤點出來，整理成結構化的數據。再用一個Spark Job的形式去批量對所有數倉表進行采樣和字段打標。大致實現如下:↓

目前這個系統做了基本的實現，后續需要繼續擴展識別項覆蓋率和準確率，具體技術細節我們就不在這里討論了，后面單開一篇文章分享。

得到分級結果后，我們就可以拿這份數據去重新盤點和治理我們的數據加密和權限管理情況了。

3.5 數據質量治理

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

（1）事前

事前我們主要是規范數據需求流程，明確各個參與方職責，進行風險評估和保障定義：

業務：需求提出

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

數據開發：需求評審

• 數據系分評審、鏈路評估
• 驗證方案、回滾方案
• 鏈路風險巡檢/治理
• SLA 定義、保障方式定義

QA：測試評審

• 測試測分及評審
• 自測標準、驗收標準
• 測試報告、驗收反饋
• 事故報告、事故復盤

（2）事中

事中我們遵循數據開發->研發自測->QA自測->數據發布->產品發布->用戶驗收的流程，保證研發過程的質量合格。

（3）事后

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

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

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

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

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

3.6 橫向巡檢機制

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

4、效果

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

具體關鍵成果如下：

（1）規范

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

（2）計存

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

（3）質量

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