我猜各位數倉同學可能會經常收到下遊抱怨，例如：資料表難用、想要的名額都不知道存放在哪個資料表、資料表命名缺少規範不易讀等，由于設計資料表是一個“經驗活”（包括業務了解、設計中的經驗沉澱等），是以對于數倉同學來說有時候想做好一個完美的資料表其實頗有挑戰，也從另外角度證明線上資料表大多數來說都不夠合規，需要持續治理。
本期語興從資料表治理角度出發，探讨資料表合規治理的最佳實踐及相關挑戰。
01資料表合規治理的背景
随着業務的快速疊代，同時數倉也在擴張期高速支援，産生的資料量越來越大，劃分的資料域也愈來越多，但很多數倉在初步搭建時都沒有确定好資料标準、模型設計規範、沒有一套完整資料的生命周期管理體系、同時組内成員技術/業務水準品質參差不齊導緻，進而導緻煙囪資料表大量産生，無規範/無中繼資料維護的資料表讓人無法看懂，資料表很難發揮出資料的價值（這裡特指複用性），為了快速支援業務導緻分層混亂（這裡不代表非要做完資料表再去支援業務、而是在支援業務後能否沉澱資産）。
從語興自身去說，目前所在的業務線資料表也混亂，有時候想查一個名額甚至發現線上有5個以上資料表出現重複加工（存在之前名額中心未建設導緻情況），曆史字段名/表命名起的也很随意沒有規範，線上資料鍊路較長錯綜複雜依賴導緻産出資料也晚，同時有23%的ODS穿透率（ODS穿透率：代表ODS跨層引用率，常見為ODS層到ADS層引用，口徑為：被跨層依賴的ODS表數量/ODS層表數量）。
02資料表合規治理前的思考
由于資料表之間互相依賴過多、鍊路過長且繁雜，是以直接上手可能會造成線上事故，需要與團隊多次頭腦風暴後對目前治理優先級進行排期，語興這邊為大家提供一個思路，可以先從簡單的資料标準重制定->無用/臨時資料表下線->應用名額公共下沉複用->解決ODS穿透問題->煙囪資料表重構及下線->中繼資料非合規資料表（包括中繼資料字段資訊）修改。
同時在初期我們需要完成各類中繼資料接入，搭建治理看闆，開發團隊治理産出統計資料表，保障治理進度以及人力資源協調。
這裡我們可以借助網易的easy data和資料治理360平台完成模型品質的評估幫助大家更快找到治理方向。
（網易easy data-模型設計中心Demo圖）
（網易easy data-資料治理360 Demo圖）
03資料表合規治理的過程
1.資料标準重制定
對目前資料域/主題域按照業務流程及應用重新劃分，重新制定中繼資料規範（表名、字段命名、字段資料格式等）用于新資料表建設中規範内容。
（1）資料域與主題域差別及如何劃分
主題域：從業務視角自上而下分析，從整體業務環節中升華出來大的專項分析子產品，結合對接的業務範圍和行業形态從更高的視角去洞察整個業務流程；
資料域：從資料視角自下而上搭建，對每個業務環節進行切割劃分，形成不同環節的資料集，組裝為完整的業務流程；
可能大家看到這還是有點懵，那在這裡舉個例子：假如現在的業務是金融産品（例如貸款、賒購等），按照金融産品業務生命周期拆解，可以分為貸前（準入、授信等）、貸中（支用、還款等）、貸後（催回等），那這裡貸前中的環節内容就是資料域，假如我們想從更高角度（風控、營銷活動分析）去看整個業務流程并從中得到一些專題分析内容，那這裡升華的部分就叫主題域。
（2）中繼資料規範（具體内容在附錄）
除了已知的詞根/命名等内容，還需要保證中繼資料的清洗包括資料表使用說明、存儲标準、資料表負責人注明、字段類型統一等。
2.無用/臨時資料表下線
根據資料血緣及任務依賴（這裡建議在數倉側開發血緣資料表，可不到字段血緣，如有條件可将範圍擴大到可視化側）對線上長期無用表、下遊無血緣且空跑資料表、臨時表進行掃描及下線，降低無用存儲及計算損耗。
中繼資料資訊采集：可使用雲端資料平台自帶功能如下圖，如使用開源元件同學可使用三方工具Apache Ambari、Apache Atlas、等對Hive中繼資料資訊收集，并後續存儲在資料表中存放，并可以根據資料表進行重要等級打标，給予表檢索及使用熱度，這裡建議使用DataHub開源資料中心，DataHub提供了可擴充的中繼資料管理平台，可以滿足資料發現，資料可觀察與治理。這也極大的解決了資料複雜性的問題，位址：datahubproject.io。
（網易easy data-資料治理360 推薦表下線治理Demo圖）
3. 應用名額公共下沉複用
由于在數倉擴張期切沒有名額中心前提下大量開發應用側資料表導緻名額複用性較差問題，首先我們檢視應用層名額是否口徑一緻，如不一緻需要與下遊再次溝通後修改，其次我們對應用層模型名額按照資料域、周期（1D（1天）、30D（最近30天）、60D（最近60天）、90D（最近90天）、MTD（月初至今）、TD（曆史至今））拆解并将不同顆粒度下的名額放入對應資料表驗證後複用，并切換線上資料表直接引用名額。
4. 解決ODS穿透問題
依靠我們在下線無用/臨時資料表時的資料血緣找到跨層引用資料表，并對這些資料表按照模型5要素（資料域、顆粒度、度量、次元、事實表類型）建構CDM(DWD與DWS)層，并驗證ADS/DWS标簽/名額引用新DWD資料表的品質情況，最後完成DWD/DWS資料表上線,及DWS/ADS的引用資料表切換。
（網易easy data-資料資産地圖資料血緣Demo圖）
5.煙囪資料表重構/下線
對于線上曆史多次重複開發煙囪資料表進行重構/下線，可複用公共名額以及整合其他相似場景下資料表字段内容到一個或多個資料表中，提升資料表易用性，使資料表清晰明了，由于對煙囪資料表重構/下線，進而也避免由内容不足而導緻的互相依賴和任務鍊路延長問題發生。
6. 中繼資料非合規資料表重構/修改
對原來非合規資料表中繼資料進行内容按照新定的标準重構，切記在建設同時需要修改下遊表名依賴及代碼中字段引用資訊，避免線上故障發生，可以先重構ODS、DWD、DWS資料表的中繼資料資訊，保障資料準确性後上線，後續可按照主題域分工，讓組内每位同學加入進來切換ADS資料表，但在切換前需要與下遊知會溝通，并拉會對切換工作計劃排期，溝通後并與下遊一起調整。
7. 資料表合規後續維護
可以從資料表價值（被引用次數、查詢次數、被收藏次數等）、資料表中繼資料規範（按照新資料标準去檢測打分）設定資料表合規評判分，并設立紅黑榜，以及對應獎懲措施，後續可通過Python等開發不合規資料表資訊提示（可日推、周推提醒），可通過郵件或者群資訊方式，指定負責人定時治理不規範的資料表，維護好資料表的品質，同時還需要建設資料表設計中心，強制資料表上線前稽核，以及按照強管控方式強行限定資料表名、詞根内容、字段名等達到易讀有保障效果。
（網易easy-data模型設計中心主題域建設Demo圖）
（網易easy-data模型設計中心資料表内容建設Demo圖）
04資料表合規治理的結果
（1）下線各層無用/臨時資料表總計80+，釋放存儲資源3.7T；
（2）完成30+個應用層煙囪資料表整合，及370+公共名額下沉；
（3）ODS穿透率由原來23%下降至4%；
（4）推出治理紅黑榜的，維持整體的資産健康分在80分以上；
（5）資料産出平均時間由原來每日最晚8:30産出降低至7:10（任務鍊路縮短）；
（6）與團隊配合完成網易某業務線數倉資料表命名、字段命名、字段類型、資料表标注規範、資料表分區生命周期等6個方向規範制定；
05資料表合規治理中遇到的難點
由于在治理中後期涉及煙囪資料表重構問題，與下遊多次對接無果（包含資料表遷移時需要下遊配合報表改動，但隻會徒增下遊工作量），導緻治理難推動，并且在想出合理方案時，也會因為下遊各類情況導緻治理進展不斷Delay，後續經過多次磨合才實作資料表的更換，互相之間協調都較困難。
06資料表合規治理思考
對于資料表合規治理是持續性的工作，數倉側無法保障每個資料表就一定是合規的、易用的，要把資料表治理常态化，強制規範化進而減少問題發生。
對于本次遇到治理困難為部門之間協調配合問題，其實在事後自己也有一個複盤思考，我覺得治理工作配合要從3個點出發：
（1）讓下遊配合其實最重要的是調動他們積極性，因為資料表治理對于下遊來說可有可無 ，沒有你資料表治理線上任務依舊在跑着，數倉隻是修改了資料表内容，保障了易用性，可能對于下遊來說毫無感覺，是以可以從下遊使用資料中的痛點去溝通，在優先業務支援的同時給予時間設計資料表内容，共同維護好資料标準。
（2）除了這些還可以加一些獎懲措施活動，讓下遊覺得配合是有價值的，例如通過紅黑榜定期也給他們發送郵件或者資訊，并開展簡單的教育訓練，讓下遊具備治理的意識，同時在他們自助治理後提供激勵。
（3）如果治理在周邊部門起到了效果，可以做更大的推進作用，比如我們在和下遊一起做治理并取到了效果，可以發治送理效果月報/周報 發送全部門，讓其他人也有感覺，并定期分享自己治理心得與其他部門資料部溝通，提升資料部在公司的影響力。
07資料标準（附錄）
1.資料表命名規範
-
ODS層（接入層）：
ods__{業務資料庫名}_{業務資料表名}（可以在結尾補充增量或全量情況，或者在中繼資料側補充）
-
DWD層（明細層）：
dwd_{一級資料域}_{二級資料域}_{三級資料域}_{業務過程（不清楚或沒有寫detail）}_存儲政策（df/di，df為全量資料，di為增量資料)）
-
DWS層（彙總層）：
dws_{一級資料域}_{二級資料域}_{三級資料域}_{顆粒度}（例如員工/部門）_{業務過程}_{周期粒度}（例如近30天寫30d、90天寫3m）
-
ADS層（應用層）：
ads_{應用主題/應用場景}_{顆粒度}（例如買家/賣家）_{業務過程}_{排程周期}（例如1天排程一次寫1d）
-
DIM表（次元表）：
dim_{次元定義}_{更新周期（可不添加）}（例如日期寫date）
-
TMP表（臨時表）：
tmp_{表名}_{臨時表編号}
-
VIEW（視圖）：
{表名}_view
-
備份表：
{表名}_bak
2.資料表命名詞根
（1）存儲政策
- df：日全量
- di：日增量
- hf：小時全量
- hi：小時增量
- mf：月全量
- mi：月增量
- wf：周全量
- wi：周增量
（2）顆粒度
- buyer：買家
- seller：賣家
- user：使用者
- emp：員工
- order：訂單
（3）統計周期
- 1d：近一天名額統計
- 1m：近一月名額統計
- 1y：近一年名額統計
- 3m：近三個月名額統計
- 6m：近六個月名額統計
- nd：近n天名額統計（無法确定具體天可用nd替代）
- td：曆史累計
（4）排程周期
- 1d：天排程
- 1m：月排程
- 1y：小時排程
3.字段命名規範
- 是否某某類型使用者，字段命名規範：is_{内容}
- 枚舉值類型字段命名規範：xxx_type
- 時間戳類型字段命名規範：xxx_date,xxx_time
- 周期名額命名：{内容}_{時間描述}（如最近一次lst1，最近兩次lst2，曆史his，最近第二次last2nd_date）
- 百分比命名：{内容}_rate
- 數值類型（整型）命名：{内容}_cnt_{周期}（周期看情況添加）
- 數值類型（小數）金額命名：{内容}_amt_{周期}（周期看情況添加）
4.字段類型規範
- 文本：String
- 日期：String
- 整數：Bigint
- 小數：高精度用Decimal、正常使用Double
- 枚舉值：單枚舉-'Y'/'N'用String、多枚舉用String
- 各類：IDString
5.資料表中其他中繼資料規範
- 資料表負責人（Owner）；
- 資料表中文名及使用說明；
- 每個開發字段中文名（中文名需要包含該字段内容，例如是否為某某類型使用者，需要寫出包含内容(Y/N)）；
- 資料表的顆粒度；
- 資料表的主鍵或聯合主鍵；
6.資料表中存儲周期規範
- ODS層1年
- DWD層3-5年
- DWS層10年（部分可永久）
- ADS層10年（部分可永久）
- DIM層3-5年（部分可永久）
資料表分區建議最多2級分區，超過2級分區會造成資料長周期存儲問題，1級分區為業務日期，2級根據業務場景設定。
作者簡介
語興，網易資料開發工程師。