據(jù)數(shù)據(jù)治理核心要素：元數(shù)據(jù)、數(shù)據(jù)質(zhì)量與權(quán)限管控落地指南)
做數(shù)據(jù)治理這行最怕聽到一句話我們數(shù)倉已經(jīng)建好了就差治理了。每次聽到我都忍不住想把人拉回現(xiàn)實——數(shù)據(jù)治理從來不是某個系統(tǒng)上線后的補丁而是從數(shù)據(jù)進(jìn)大門那一刻就要貫穿始終的骨架。這幾年我見過太多項目花大價錢上了Hadoop、Hive、Spark結(jié)果BI報表還是沒人敢信業(yè)務(wù)還是拿著Excel自己算。原因很簡單數(shù)據(jù)沒人管、口徑不一致、質(zhì)量沒人負(fù)責(zé)數(shù)倉搭得再漂亮也是空中樓閣。今天這篇就不繞彎子把大數(shù)據(jù)領(lǐng)域數(shù)據(jù)治理的核心要素一次講透。從元數(shù)據(jù)、數(shù)據(jù)標(biāo)準(zhǔn)到數(shù)據(jù)質(zhì)量從行列級權(quán)限到完整的治理平臺功能再到戰(zhàn)略的交付成果落地。如果你正準(zhǔn)備做數(shù)據(jù)治理項目、要搭數(shù)據(jù)中臺或者剛接手一個爛數(shù)倉想從頭梳理這篇都值得你泡杯茶慢慢看我會盡量用真實項目的口吻把該避的坑也一起說出來。1. 先想清楚數(shù)據(jù)治理到底在治理什么很多團(tuán)隊把數(shù)據(jù)治理理解成給數(shù)倉做保潔這是最大的誤區(qū)。數(shù)據(jù)治理不是清洗幾次數(shù)據(jù)、建幾個規(guī)范就完事了它是一套由人、流程、工具共同構(gòu)成的管理體系。動手之前必須先把治理的對象和邊界劃清楚。1.1 數(shù)據(jù)混亂的三張典型面孔先說我在項目里反復(fù)見到的三種亂象基本能覆蓋九成以上企業(yè)的數(shù)據(jù)痛點。第一種是同名不同義、同義不同名。營銷部門的訂單金額是不含運費的實付金額財務(wù)部門的訂單金額是含稅含運費的應(yīng)收金額兩邊報表一對比數(shù)字永遠(yuǎn)對不上。反過來有人叫user_id有人叫userid還有叫member_id的ETL腳本里光是字段映射就寫到手抽筋。第二種是數(shù)據(jù)血緣缺失。表A里的某個字段到底是從哪張表、經(jīng)過什么邏輯加工來的中間為什么被過濾掉了一部分?jǐn)?shù)據(jù)一問三不知。一旦上游接口調(diào)整了字段下游報表數(shù)據(jù)悄悄變了沒人知道是哪一步出了問題。第三種是權(quán)限失控。數(shù)據(jù)開發(fā)賬號能直接掃全表敏感字段沒有脫敏下游業(yè)務(wù)用戶也能看到不該看的客戶手機號。這不是技術(shù)問題是管理問題但技術(shù)上往往也根本沒做管控。這三張面孔不是獨立存在的它們環(huán)環(huán)相扣口徑不一致是因為沒有數(shù)據(jù)標(biāo)準(zhǔn)找不到問題是因為沒有血緣數(shù)據(jù)裸奔是因為沒有權(quán)限管控。所以數(shù)據(jù)治理的核心要素從來都是體系化的一整套東西。1.2 六要素拆解從找數(shù)據(jù)到用數(shù)據(jù)做過幾個項目之后我習(xí)慣把數(shù)據(jù)治理的核心要素拆成六塊每塊解決一個具體問題核心要素解決什么問題關(guān)鍵功能典型輸出元數(shù)據(jù)管理數(shù)據(jù)在哪里、是什么、怎么加工元數(shù)據(jù)中心、血緣解析、數(shù)據(jù)字典數(shù)據(jù)地圖、血緣關(guān)系圖數(shù)據(jù)標(biāo)準(zhǔn)口徑統(tǒng)一說話同一種語言字段標(biāo)準(zhǔn)、碼表、命名規(guī)范數(shù)據(jù)標(biāo)準(zhǔn)文檔、標(biāo)準(zhǔn)代碼庫數(shù)據(jù)質(zhì)量數(shù)據(jù)是否可信、能用質(zhì)量規(guī)則引擎、異常預(yù)警、質(zhì)量報告質(zhì)量評分、整改工單數(shù)據(jù)安全與權(quán)限數(shù)據(jù)可控敏感數(shù)據(jù)不泄漏行列權(quán)限、脫敏、審計權(quán)限矩陣、審計日志數(shù)據(jù)資產(chǎn)目錄數(shù)據(jù)可見、可搜索、可理解資產(chǎn)目錄、檢索、訂閱數(shù)據(jù)資產(chǎn)門戶數(shù)據(jù)服務(wù)數(shù)據(jù)可消費、可集成API服務(wù)、訂閱推送、數(shù)據(jù)大屏統(tǒng)一數(shù)據(jù)服務(wù)層這六個要素不是順序關(guān)系而是互相咬合的。元數(shù)據(jù)是基礎(chǔ)標(biāo)準(zhǔn)是規(guī)則質(zhì)量是結(jié)果安全是紅線目錄是窗口服務(wù)是出口。缺了任何一個數(shù)據(jù)治理都會跛腳。1.3 治理的邊界別和數(shù)倉建設(shè)混為一談還有一點必須拎清楚數(shù)據(jù)治理不是數(shù)據(jù)開發(fā)。ETL工程師負(fù)責(zé)把數(shù)據(jù)從A搬到B治理團(tuán)隊負(fù)責(zé)定義A到B該怎么搬、搬完怎么驗收、不合格怎么辦。如果治理團(tuán)隊陷到寫SQL、調(diào)性能、做模型設(shè)計里面去那這個項目離爛尾不遠(yuǎn)了。我見過最典型的反面案例是治理團(tuán)隊為了體現(xiàn)價值去幫業(yè)務(wù)部門做了一堆報表。結(jié)果報表倒是出了不少核心的數(shù)據(jù)標(biāo)準(zhǔn)沒人定質(zhì)量問題沒人管半年后報表口徑又亂成一鍋粥。治理的職責(zé)是制定規(guī)則、監(jiān)督執(zhí)行、推動整改不是替代業(yè)務(wù)開發(fā)。守住這個邊界后面所有事情才有得談。2. 元數(shù)據(jù)與數(shù)據(jù)標(biāo)準(zhǔn)讓數(shù)據(jù)從能用到好用如果說數(shù)倉里的數(shù)據(jù)是貨架上的商品那元數(shù)據(jù)就是商品的標(biāo)簽和擺放圖數(shù)據(jù)標(biāo)準(zhǔn)就是商品的統(tǒng)一規(guī)格。沒有這兩樣數(shù)據(jù)再多也相當(dāng)于一個沒有索引的倉庫找東西全靠翻。2.1 技術(shù)元數(shù)據(jù)與業(yè)務(wù)元數(shù)據(jù)一個都不能少技術(shù)元數(shù)據(jù)相對好做它描述的是庫表字段、存儲類型、分區(qū)信息、數(shù)據(jù)量、更新頻率這些客觀屬性。只要你有Hive、Spark、Kafka這些組件的訪問權(quán)限靠著元數(shù)據(jù)采集工具就能自動抓個七八成。真正難的是業(yè)務(wù)元數(shù)據(jù)。同一個用戶活躍數(shù)分母到底是去重后的用戶還是包含測試賬號這個口徑寫在哪哪個業(yè)務(wù)負(fù)責(zé)人對指標(biāo)負(fù)責(zé)這些信息只存在于業(yè)務(wù)人員的腦子里。我在項目里常用的做法是在做數(shù)據(jù)字典評審時強制要求每個核心指標(biāo)指定一個業(yè)務(wù)Owner并且由他簽字確認(rèn)口徑描述。只有技術(shù)元數(shù)據(jù)沒有業(yè)務(wù)元數(shù)據(jù)數(shù)據(jù)字典就是個空殼。2.2 血緣追蹤的落地姿勢血緣關(guān)系是元數(shù)據(jù)管理里最有價值、也最容易做淺的部分。很多團(tuán)隊說自己有數(shù)據(jù)血緣打開一找全是表級血緣字段級完全空白。這種血緣對排查指標(biāo)口徑問題幾乎沒有幫助。落地血緣通常有三條路解析SQL用Hive/Spark SQL解析器從代碼里提取輸入表、輸出表、字段映射關(guān)系。工具層面可以用Apache Atlas能自動抓到表級和一部分字段級血緣。ETL埋點在編寫數(shù)據(jù)加工任務(wù)時顯式聲明source、target以及字段級轉(zhuǎn)換邏輯。這種方式準(zhǔn)確率最高但對開發(fā)規(guī)范要求嚴(yán)需要團(tuán)隊配合。混合模式先靠解析SQL把血緣關(guān)系打通到表級再對核心鏈路做人工整理和字段級補充。我的建議是不要一上來就追求完美字段級血緣。先做到核心鏈路、核心指標(biāo)相關(guān)的表級血緣完整跑通上游變更影響分析這個場景你就能嘗到甜頭。比如上游訂單表要新增一個枚舉值你在血緣圖上立刻能看到下游哪些指標(biāo)會受影響而不是等業(yè)務(wù)投訴了再去翻幾十個腳本。2.3 數(shù)據(jù)標(biāo)準(zhǔn)先行Excel模板導(dǎo)入背后的字段規(guī)范熱搜詞里提到以Excel模板數(shù)據(jù)導(dǎo)入的數(shù)據(jù)治理項目這個點非常實際。很多傳統(tǒng)企業(yè)做治理第一步往往不是建平臺而是先規(guī)范Excel導(dǎo)入。大家不要覺得Excel導(dǎo)入很簡單它其實就是數(shù)據(jù)標(biāo)準(zhǔn)落地的最佳切入點。比如業(yè)務(wù)部門要上報渠道數(shù)據(jù)如果沒有標(biāo)準(zhǔn)今天填線上明天填網(wǎng)銷后天填A(yù)PP后端做匯總時頭都大了。所以我在設(shè)計模板導(dǎo)入功能時會把字段名、數(shù)據(jù)類型、長度、枚舉值、是否必填、是否唯一全部定義在標(biāo)準(zhǔn)庫里。用戶下載到的模板本身就是一份強制版的數(shù)據(jù)標(biāo)準(zhǔn)。Excel模板的作用不只是收集數(shù)據(jù)它還是隱形的校驗器手機號必須滿足正則表達(dá)式、渠道字段只能選標(biāo)準(zhǔn)碼表里的值、導(dǎo)入文件里不能有重復(fù)的主鍵。這些規(guī)則不是寫死在頁面上的而是從數(shù)據(jù)標(biāo)準(zhǔn)配置里動態(tài)生成的。這樣當(dāng)標(biāo)準(zhǔn)更新時模板和校驗規(guī)則就能同步升級不會出現(xiàn)Excel模板和數(shù)倉口徑對不上的尷尬。3. 數(shù)據(jù)質(zhì)量最能直接體現(xiàn)治理成效的硬指標(biāo)做數(shù)據(jù)治理項目業(yè)務(wù)方和國際供應(yīng)商最不看虛的就是數(shù)據(jù)質(zhì)量有沒有提升。所以數(shù)據(jù)質(zhì)量一定是整個治理體系里最先見效、也最容易出彩的部分。3.1 數(shù)據(jù)質(zhì)量六個維度別只盯著準(zhǔn)確性很多非專業(yè)人員一說數(shù)據(jù)質(zhì)量就認(rèn)為是數(shù)據(jù)準(zhǔn)不準(zhǔn)。但真實項目里準(zhǔn)確性往往是最難定義、最難驗證的。所以目前業(yè)內(nèi)普遍會把數(shù)據(jù)質(zhì)量拆成六個可操作的維度維度定義常見異常例子完整性數(shù)據(jù)是否缺失訂單表中的用戶ID為空唯一性是否有重復(fù)同一訂單號出現(xiàn)兩次準(zhǔn)確性數(shù)據(jù)是否真實反映業(yè)務(wù)完成時間早于下單時間一致性跨表口徑是否統(tǒng)一不同表同一用戶性別標(biāo)注不同及時性數(shù)據(jù)是否按時到位每日分區(qū)數(shù)據(jù)延遲4小時有效性數(shù)據(jù)是否符合規(guī)則手機號只有11位數(shù)字卻出現(xiàn)字母在六維度的基礎(chǔ)上我建議再補一個可理解性也就是每個字段有沒有清晰易懂的業(yè)務(wù)解釋否則下游用戶根本不知道字段應(yīng)該怎么用準(zhǔn)確性問題就會以另一種形式出現(xiàn)。3.2 規(guī)則配置與異常預(yù)警讓系統(tǒng)代替人工盯數(shù)質(zhì)量規(guī)則才是這part真正動手的地方。規(guī)則要配置在數(shù)據(jù)接入、加工、出數(shù)整個鏈路的關(guān)鍵節(jié)點上。比如對訂單明細(xì)表每天檢查主鍵唯一率重復(fù)率超過0.1%就告警對手機號字段用正則表達(dá)式校驗格式有效比率低于90%觸發(fā)阻斷對每日分區(qū)數(shù)據(jù)設(shè)置產(chǎn)出時間SLA超過約定時間未生成分區(qū)就通知調(diào)度負(fù)責(zé)人對金額字段設(shè)置非負(fù)數(shù)校驗發(fā)現(xiàn)負(fù)數(shù)自動標(biāo)記為可疑數(shù)據(jù)并轉(zhuǎn)入暫存區(qū)。質(zhì)量檢查任務(wù)要跟著調(diào)度跑數(shù)據(jù)加工完成之后立刻觸發(fā)質(zhì)量檢查結(jié)果自動匯總成質(zhì)量報告。這里有個關(guān)鍵設(shè)計——質(zhì)量規(guī)則要有負(fù)責(zé)人。沒有負(fù)責(zé)人的規(guī)則就是一堆報警垃圾。每條規(guī)則生效前至少要指定一個接收告警的人并對規(guī)則閾值進(jìn)行評審否則寧可先不配置。3.3 從事后清洗轉(zhuǎn)向事前攔截傳統(tǒng)數(shù)倉的做法是數(shù)據(jù)已經(jīng)進(jìn)來了跑個腳本發(fā)現(xiàn)臟數(shù)據(jù)再清洗。這種方式成本高而且容易導(dǎo)致清洗邏輯不一致——今天清這個明天漏那個。我更推薦事前攔截的思路把質(zhì)量檢查前移到數(shù)據(jù)接入環(huán)節(jié)。以Excel模板導(dǎo)入為例用戶上傳數(shù)據(jù)后后端先做逐行校驗?zāi)囊恍小⒛囊涣谐隽藛栴}直接返回詳細(xì)的錯誤提示給上傳人讓他改完再傳。合格數(shù)據(jù)才能進(jìn)入正式表不合格數(shù)據(jù)進(jìn)暫存區(qū)并通知數(shù)據(jù)Owner處理。這樣做的好處是源頭臟數(shù)據(jù)根本進(jìn)不了數(shù)倉下游模型和報表就不用再做一遍防御性清洗。前期開發(fā)工作量會大一些但長期看收益非常高。我做過一個渠道數(shù)據(jù)上報項目用事前攔截之后數(shù)倉里核心表的臟數(shù)據(jù)比例從4%降到了0.3%而且這個成績是持續(xù)保持的不是靠突擊清洗。3.4 一個Hive案例網(wǎng)約車訂單明細(xì)的臟數(shù)據(jù)如何暴露問題拿一個常見的網(wǎng)約車大數(shù)據(jù)綜合項目場景來舉個例子。假設(shè)有一張訂單明細(xì)表從業(yè)務(wù)庫同步到Hive每天一個分區(qū)。一開始我們只看總訂單量這個指標(biāo)沒發(fā)現(xiàn)任何異常。但某天把指標(biāo)細(xì)化到城市維度時發(fā)現(xiàn)訂單量排名第一的城市居然顯示為未知因為訂單表和城市表關(guān)聯(lián)不上外鍵關(guān)系被破壞了。繼續(xù)排查又發(fā)現(xiàn)兩個問題一部分訂單的完成時間比下單時間還早明顯是設(shè)備時間異常導(dǎo)致還有個別訂單金額為負(fù)其實是退款記錄被錯當(dāng)成了新訂單。如果不做治理這三類數(shù)據(jù)會直接污染營收、完單率、客單價等多個核心指標(biāo)。有了質(zhì)量平臺之后我在這張表上配置了三條規(guī)則完成時間必須晚于下單時間、city_id必須在城市表里存在、訂單金額非負(fù)數(shù)。每天跑批后先檢查這三條有異常自動阻斷并通知數(shù)據(jù)開發(fā)。之后再跑渠道分析報表業(yè)務(wù)看到未知城市終于消失這種直觀的改善比任何匯報PPT都有說服力。4. 數(shù)據(jù)安全與權(quán)限管控行級、列級權(quán)限的設(shè)計方案數(shù)據(jù)治理做到一定階段安全權(quán)限就會浮出水面而且通常是業(yè)務(wù)方主動提需求——因為不合規(guī)或者出過事故。4.1 大數(shù)據(jù)平臺上權(quán)限為什么難做傳統(tǒng)關(guān)系型數(shù)據(jù)庫有成熟的GRANT權(quán)限體系但大數(shù)據(jù)平臺上的數(shù)據(jù)往往躺在HDFS上算的時候用Hive、Spark、Presto查詢的時候又可能走統(tǒng)一SQL入口。只要有一個入口沒接入權(quán)限校驗等于整個權(quán)限體系白做。另外數(shù)倉里的表動輒幾百張字段幾十上百個用戶角色又雜。如果每張表、每個字段都手工授權(quán)管理員會瘋掉。所以設(shè)計權(quán)限模型前先要梳理清楚誰是數(shù)據(jù)Owner、哪些角色需要什么粒度的數(shù)據(jù)訪問權(quán)、審批流怎么走。4.2 開源方案怎么選Ranger、Atlas、自研模型先給結(jié)論如果你用的是標(biāo)準(zhǔn)Hadoop生態(tài)最早可以嘗試定級Apache Ranger加Apache Atlas的組合如果你有統(tǒng)一查詢?nèi)肟诨蛘邫?quán)限邏輯很特殊再考慮自研權(quán)限網(wǎng)關(guān)。方案管控粒度優(yōu)點局限適用場景Apache RangerHive/HDFS/Kafka表級、列級、行過濾社區(qū)成熟、支持多組件統(tǒng)一授權(quán)、審計日志齊全規(guī)則多了配置復(fù)雜需要專人維護(hù)標(biāo)準(zhǔn)Hadoop技術(shù)棧企業(yè)Apache Atlas元數(shù)據(jù)、標(biāo)簽、血緣可以和Ranger聯(lián)動做標(biāo)簽權(quán)限本身不是權(quán)限引擎已建Atlas元數(shù)據(jù)中心的企業(yè)自研權(quán)限網(wǎng)關(guān)任意粒度靈活可按用戶動態(tài)改寫SQL開發(fā)量大、要維護(hù)語法解析有統(tǒng)一查詢?nèi)肟凇?quán)限邏輯復(fù)雜Ranger的列級權(quán)限做的是脫敏策略比如身份證號非授權(quán)用戶查出來只能看到前三位和后四位行級權(quán)限做的是row filter比如不同區(qū)域的銷售只能看到本區(qū)域訂單。Atlas是一個元數(shù)據(jù)管理平臺它可以給表打上敏感內(nèi)部公開等標(biāo)簽再讓Ranger基于標(biāo)簽來授權(quán)。4.3 行級和列級權(quán)限的建模思路列級權(quán)限的核心是識別敏感字段然后按角色配置策略。真實的策略通常分三種禁止訪問、明文訪問、脫敏訪問。脫敏又分為保留前幾位、哈希替換、置空等。行級權(quán)限的通用做法是謂詞注入。比如你要讓華東區(qū)的銷售只能看area_codeHD的數(shù)據(jù)底層邏輯就是在查詢SQL后面自動追加where area_code HD。如果使用Ranger可以寫類似current_user in (select ... from user_area ...)之類的行過濾條件。但行級權(quán)限要小心性能。給大表加行過濾尤其是動態(tài)子查詢時可能會導(dǎo)致查詢效率斷崖式下跌。我在一個項目里就踩過這個坑給一個10億行的事實表加了按部門過濾條件里面用了子查詢結(jié)果原來十幾秒的查詢跑了好幾分鐘。后來做成預(yù)計算的用戶-to-部門映射表再用join代替子查詢性能才恢復(fù)正常。4.4 審計與合規(guī)權(quán)限不是配完就完了做安全權(quán)限最忌諱的是配完就忘。Ranger自帶的審計日志至少要保持6個月且需要能回答一個問題某個用戶在某個時間到底訪問了哪些表、查了哪些數(shù)據(jù)、有沒有導(dǎo)出行為。尤其是通過Excel模板導(dǎo)入導(dǎo)出數(shù)據(jù)的場景要防止數(shù)據(jù)泄露和惡意數(shù)據(jù)導(dǎo)出。我在治理平臺里會要求用戶申請權(quán)限時填寫數(shù)據(jù)用途、有效期導(dǎo)出接口要有敏感字段水印核心表的全量導(dǎo)出必須走審批流程。結(jié)合審計日志出了問題能查、能追、能舉證這是安全治理的底線。5. 一個完整數(shù)據(jù)治理項目該有的功能全家桶前面講的是治理核心要素落到系統(tǒng)層面一個真正能用的治理平臺到底該有哪些功能我按照做項目的經(jīng)驗把高頻需求整理成一張功能清單大家可以照著檢視自己的平臺。5.1 Excel模板導(dǎo)入它不是上傳Excel那么簡單很多公司做數(shù)據(jù)治理系統(tǒng)第一個模塊就是模板數(shù)據(jù)導(dǎo)入。這個模塊看似簡單但最容易翻車。我拆一下該有的功能模板管理支持多套模板每個模板對應(yīng)一個數(shù)據(jù)標(biāo)準(zhǔn)能動態(tài)生成模板文件并控制版本模板下載與上傳用戶下載標(biāo)準(zhǔn)模板填報后上傳系統(tǒng)后臺做異步解析逐行校驗解析后按標(biāo)準(zhǔn)庫校驗字段長度、格式、枚舉值、必填項、唯一性錯誤回顯第幾行第幾列出錯錯誤原因?qū)懨靼妆热绲?023行手機號格式錯誤支持在線修正后重新上傳暫存區(qū)校驗通過但未發(fā)布的數(shù)據(jù)先進(jìn)暫存區(qū)由數(shù)據(jù)Owner審核后寫入正式表增量導(dǎo)入與任務(wù)調(diào)度支持定時增量導(dǎo)入并與數(shù)據(jù)質(zhì)量檢查和血緣采集聯(lián)動。我在做這種模塊時有一個心得模板即標(biāo)準(zhǔn)。模板的每個列頭都要能從標(biāo)準(zhǔn)庫里找到對應(yīng)的字段定義這樣用戶填報的過程就是按標(biāo)準(zhǔn)填數(shù)的過程。另外上傳大Excel文件一定要做成異步隊列前端先返回解析中等有結(jié)果再通知千萬不能同步阻塞。5.2 數(shù)據(jù)資產(chǎn)目錄讓業(yè)務(wù)自己找到數(shù)據(jù)數(shù)據(jù)治理的成果如果只給IT看價值發(fā)揮不出來。所以必須做一個數(shù)據(jù)資產(chǎn)目錄讓業(yè)務(wù)用戶能像逛分類網(wǎng)站一樣找數(shù)據(jù)。目錄里至少要包含數(shù)據(jù)表名稱、所屬業(yè)務(wù)域、業(yè)務(wù)負(fù)責(zé)人、統(tǒng)計口徑說明、更新頻率、數(shù)據(jù)量、質(zhì)量評分、最近一周訪問熱度。再配合關(guān)鍵字搜索、收藏、訂閱業(yè)務(wù)就能主動找到核心指標(biāo)數(shù)據(jù)而不是天天找數(shù)倉工程師要表。這個目錄的數(shù)據(jù)來源就是元數(shù)據(jù)中心和質(zhì)量管理模塊所以如果前面元數(shù)據(jù)沒做扎實資產(chǎn)目錄就會是個空架子。反過來說資產(chǎn)目錄也是檢驗元數(shù)據(jù)質(zhì)量最好的窗口——業(yè)務(wù)搜不到的東西背后往往就是元數(shù)據(jù)沒補齊。5.3 數(shù)據(jù)服務(wù)與數(shù)據(jù)大屏的聯(lián)動治理好數(shù)據(jù)最終要變成服務(wù)尤其是現(xiàn)在很多項目要通過數(shù)據(jù)大屏來展示成果。大屏只是消費端本質(zhì)上它需要穩(wěn)定、高質(zhì)量的數(shù)據(jù)服務(wù)。我建議治理平臺把數(shù)據(jù)服務(wù)能力單獨做成一層數(shù)據(jù)源做治理檢查 - 生成指標(biāo)寬表 - 注冊API服務(wù) - 大屏調(diào)用API渲染這里有兩個容易被忽視的細(xì)節(jié)一是數(shù)據(jù)服務(wù)要配置緩存策略和超時熔斷避免大屏高并發(fā)把底層數(shù)倉打崩二是要監(jiān)控API的數(shù)據(jù)量和響應(yīng)時間某一天指標(biāo)值突變時能回溯是數(shù)據(jù)質(zhì)量告警還是上游任務(wù)延遲。數(shù)據(jù)大屏好看與否八成在數(shù)據(jù)服務(wù)層不在前端可視化。5.4 任務(wù)調(diào)度與治理自動化治理平臺本身就是一套系統(tǒng)也離不開調(diào)度。質(zhì)量檢查、血緣采集、報表生成、權(quán)限策略同步全部要有自動調(diào)度能力。調(diào)度設(shè)計上注意幾個點一是要有依賴管理先等數(shù)倉加工完再跑質(zhì)量檢查避免誤報二是支持按分區(qū)、按表優(yōu)先級調(diào)度核心表優(yōu)先三是失敗重跑要冪等避免重復(fù)生成數(shù)據(jù)。更進(jìn)一步可以把治理流程做進(jìn)自動化閉環(huán)質(zhì)量規(guī)則觸發(fā)告警 - 自動生成工單 - 推送給負(fù)責(zé)人 - 整改后復(fù)測 - 關(guān)閉工單。這一步做好了治理就從人盯人變成了系統(tǒng)盯系統(tǒng)。6. 治理戰(zhàn)略落地交付成果與真實踩坑經(jīng)驗最后一個環(huán)節(jié)也是最容易被忽視的數(shù)據(jù)治理項目最終交付的是什么如果只有系統(tǒng)沒有機制上線即失效。6.1 數(shù)據(jù)治理戰(zhàn)略的常見交付成果實例做項目一定要有可見的交付物不然管理層沒法驗收。結(jié)合我見到的實戰(zhàn)核心交付成果通常包括數(shù)據(jù)治理平臺包含元數(shù)據(jù)管理、數(shù)據(jù)標(biāo)準(zhǔn)、質(zhì)量規(guī)則、權(quán)限管控、資產(chǎn)目錄、數(shù)據(jù)服務(wù)等模塊數(shù)據(jù)標(biāo)準(zhǔn)體系文檔命名規(guī)范、字段標(biāo)準(zhǔn)、碼表、指標(biāo)口徑說明數(shù)據(jù)字典與血緣圖譜覆蓋核心業(yè)務(wù)域的字段級字典和核心鏈路血緣數(shù)據(jù)質(zhì)量報告周報/月報包含質(zhì)量評分、問題清單、整改率權(quán)限矩陣與審計報告核心表的訪問權(quán)限總表以及操作審計日志數(shù)據(jù)資產(chǎn)門戶及API服務(wù)業(yè)務(wù)自助取數(shù)、大屏數(shù)據(jù)服務(wù)。以網(wǎng)約車數(shù)據(jù)分析這類綜合項目為例交付的不只是幾張Hive寬表更重要的是把訂單明細(xì)怎么定義、訂單金額口徑是什么、哪些字段需要權(quán)限管控梳理成文檔和規(guī)則這樣項目換人也能接得住。6.2 組織與流程沒有Owner的治理一定爛尾技術(shù)只是工具治理真正落地靠的是分工和流程。至少要有三層角色數(shù)據(jù)治理委員會定制度、定標(biāo)準(zhǔn)、排優(yōu)先級數(shù)據(jù)Owner每個核心數(shù)據(jù)域要有業(yè)務(wù)負(fù)責(zé)人對數(shù)據(jù)口徑和質(zhì)量管理負(fù)責(zé)數(shù)據(jù)管家/治理工程師日常維護(hù)元數(shù)據(jù)、配置規(guī)則、跟蹤整改。我在項目里一個深刻的感受是如果質(zhì)量報告發(fā)出去了卻沒有一個責(zé)任人去認(rèn)領(lǐng)和推動那報告就只是一張廢紙。所以在治理平臺上線之前先要把組織責(zé)任矩陣做出來。誰認(rèn)領(lǐng)、誰整改、誰驗收這些在流程里寫死了系統(tǒng)才有抓手。6.3 分階段實施節(jié)奏先止血再造血治理項目最忌諱一上來就鋪大攤子。我見過一個企業(yè)想一步到位做全量元數(shù)據(jù)結(jié)果元數(shù)據(jù)團(tuán)隊累得半死業(yè)務(wù)卻不怎么買賬。更務(wù)實的做法是三步走第一階段止血。先梳理核心業(yè)務(wù)域的1-2條關(guān)鍵鏈路把表、字段、口徑、Owner摸清基礎(chǔ)元數(shù)據(jù)補齊核心質(zhì)量規(guī)則上線讓業(yè)務(wù)看到報表數(shù)據(jù)終于能對齊了。第二階段造血。建設(shè)數(shù)據(jù)資產(chǎn)目錄開放自助檢索讓業(yè)務(wù)自己找到想要的數(shù)據(jù)。同時把行/列權(quán)限覆蓋到敏感數(shù)據(jù)上。第三階段擴(kuò)張。數(shù)據(jù)服務(wù)下沉治理能力產(chǎn)品化支持更多業(yè)務(wù)域接入。根據(jù)前兩個階段的反饋迭代標(biāo)準(zhǔn)體系和自動化流程。過程中要有一個業(yè)務(wù)痛點驅(qū)動的心態(tài)。哪個指標(biāo)的投訴最多哪個數(shù)據(jù)出了問題后果最嚴(yán)重就先治理哪塊。治理不要追求全面開花先把痛點變成亮點后面才有支持者。6.4 我踩過的幾個坑希望你能繞過最后分享幾個我真實踩過的坑算是給同行提個醒。第一個坑是標(biāo)準(zhǔn)定義過度理想化。一上來搞了上百個標(biāo)準(zhǔn)字段結(jié)果業(yè)務(wù)根本填不齊。后來學(xué)乖了標(biāo)準(zhǔn)只覆蓋真正共享和統(tǒng)計的必要字段其他字段暫時放行但不入標(biāo)準(zhǔn)庫。第二個坑是質(zhì)量規(guī)則報警沒人認(rèn)領(lǐng)。規(guī)則配置得很全每天報警幾十條但都是發(fā)給數(shù)倉開發(fā)沒有同步給業(yè)務(wù)Owner。結(jié)果就是報警淪為狼來了大家默認(rèn)忽略。后來改成每條規(guī)則都有明確的負(fù)責(zé)人和處置時限無效規(guī)則定期下架質(zhì)量治理才真正轉(zhuǎn)動起來。第三個坑是權(quán)限模型做得過于復(fù)雜。行級權(quán)限精確到每個用戶字段級脫敏策略疊了十幾層結(jié)果數(shù)據(jù)分析師查數(shù)時頻繁被攔截體驗極差。后來調(diào)整成角色屬性審批的粗粒度結(jié)構(gòu)按團(tuán)隊授權(quán)、用屬性動態(tài)過濾、關(guān)鍵操作留審計既安全又不擋路。第四個坑是忽略Excel導(dǎo)入的模板版本管理。舊模板還在被業(yè)務(wù)使用標(biāo)準(zhǔn)庫卻更新了導(dǎo)致上傳數(shù)據(jù)校驗失敗。后來把模板和標(biāo)準(zhǔn)庫做了版本綁定同一時期允許多個模板版本并存用戶下載哪個版本就按哪個版本校驗問題就消失了。這些坑有一個共同點都是技術(shù)到位治理機制沒跟上造成的。數(shù)據(jù)治理的本質(zhì)是把數(shù)據(jù)當(dāng)作資產(chǎn)來管而資產(chǎn)管理的核心從來都不是軟件而是人和規(guī)則。把這三個要素理順了大數(shù)據(jù)治理自然就落地了。 大數(shù)據(jù)數(shù)據(jù)治理核心要素：元數(shù)據(jù)、數(shù)據(jù)質(zhì)量與權(quán)限管控落地指南
做數(shù)據(jù)治理這行最怕聽到一句話我們數(shù)倉已經(jīng)建好了就差治理了。每次聽到我都忍不住想把人拉回現(xiàn)實——數(shù)據(jù)治理從來不是某個系統(tǒng)上線后的補丁而是從數(shù)據(jù)進(jìn)大門那一刻就要貫穿始終的骨架。這幾年我見過太多項目花大價錢上了Hadoop、Hive、Spark結(jié)果BI報表還是沒人敢信業(yè)務(wù)還是拿著Excel自己算。原因很簡單數(shù)據(jù)沒人管、口徑不一致、質(zhì)量沒人負(fù)責(zé)數(shù)倉搭得再漂亮也是空中樓閣。今天這篇就不繞彎子把大數(shù)據(jù)領(lǐng)域數(shù)據(jù)治理的核心要素一次講透。從元數(shù)據(jù)、數(shù)據(jù)標(biāo)準(zhǔn)到數(shù)據(jù)質(zhì)量從行列級權(quán)限到完整的治理平臺功能再到戰(zhàn)略的交付成果落地。如果你正準(zhǔn)備做數(shù)據(jù)治理項目、要搭數(shù)據(jù)中臺或者剛接手一個爛數(shù)倉想從頭梳理這篇都值得你泡杯茶慢慢看我會盡量用真實項目的口吻把該避的坑也一起說出來。1. 先想清楚數(shù)據(jù)治理到底在治理什么很多團(tuán)隊把數(shù)據(jù)治理理解成給數(shù)倉做保潔這是最大的誤區(qū)。數(shù)據(jù)治理不是清洗幾次數(shù)據(jù)、建幾個規(guī)范就完事了它是一套由人、流程、工具共同構(gòu)成的管理體系。動手之前必須先把治理的對象和邊界劃清楚。1.1 數(shù)據(jù)混亂的三張典型面孔先說我在項目里反復(fù)見到的三種亂象基本能覆蓋九成以上企業(yè)的數(shù)據(jù)痛點。第一種是同名不同義、同義不同名。營銷部門的訂單金額是不含運費的實付金額財務(wù)部門的訂單金額是含稅含運費的應(yīng)收金額兩邊報表一對比數(shù)字永遠(yuǎn)對不上。反過來有人叫user_id有人叫userid還有叫member_id的ETL腳本里光是字段映射就寫到手抽筋。第二種是數(shù)據(jù)血緣缺失。表A里的某個字段到底是從哪張表、經(jīng)過什么邏輯加工來的中間為什么被過濾掉了一部分?jǐn)?shù)據(jù)一問三不知。一旦上游接口調(diào)整了字段下游報表數(shù)據(jù)悄悄變了沒人知道是哪一步出了問題。第三種是權(quán)限失控。數(shù)據(jù)開發(fā)賬號能直接掃全表敏感字段沒有脫敏下游業(yè)務(wù)用戶也能看到不該看的客戶手機號。這不是技術(shù)問題是管理問題但技術(shù)上往往也根本沒做管控。這三張面孔不是獨立存在的它們環(huán)環(huán)相扣口徑不一致是因為沒有數(shù)據(jù)標(biāo)準(zhǔn)找不到問題是因為沒有血緣數(shù)據(jù)裸奔是因為沒有權(quán)限管控。所以數(shù)據(jù)治理的核心要素從來都是體系化的一整套東西。1.2 六要素拆解從找數(shù)據(jù)到用數(shù)據(jù)做過幾個項目之后我習(xí)慣把數(shù)據(jù)治理的核心要素拆成六塊每塊解決一個具體問題核心要素解決什么問題關(guān)鍵功能典型輸出元數(shù)據(jù)管理數(shù)據(jù)在哪里、是什么、怎么加工元數(shù)據(jù)中心、血緣解析、數(shù)據(jù)字典數(shù)據(jù)地圖、血緣關(guān)系圖數(shù)據(jù)標(biāo)準(zhǔn)口徑統(tǒng)一說話同一種語言字段標(biāo)準(zhǔn)、碼表、命名規(guī)范數(shù)據(jù)標(biāo)準(zhǔn)文檔、標(biāo)準(zhǔn)代碼庫數(shù)據(jù)質(zhì)量數(shù)據(jù)是否可信、能用質(zhì)量規(guī)則引擎、異常預(yù)警、質(zhì)量報告質(zhì)量評分、整改工單數(shù)據(jù)安全與權(quán)限數(shù)據(jù)可控敏感數(shù)據(jù)不泄漏行列權(quán)限、脫敏、審計權(quán)限矩陣、審計日志數(shù)據(jù)資產(chǎn)目錄數(shù)據(jù)可見、可搜索、可理解資產(chǎn)目錄、檢索、訂閱數(shù)據(jù)資產(chǎn)門戶數(shù)據(jù)服務(wù)數(shù)據(jù)可消費、可集成API服務(wù)、訂閱推送、數(shù)據(jù)大屏統(tǒng)一數(shù)據(jù)服務(wù)層這六個要素不是順序關(guān)系而是互相咬合的。元數(shù)據(jù)是基礎(chǔ)標(biāo)準(zhǔn)是規(guī)則質(zhì)量是結(jié)果安全是紅線目錄是窗口服務(wù)是出口。缺了任何一個數(shù)據(jù)治理都會跛腳。1.3 治理的邊界別和數(shù)倉建設(shè)混為一談還有一點必須拎清楚數(shù)據(jù)治理不是數(shù)據(jù)開發(fā)。ETL工程師負(fù)責(zé)把數(shù)據(jù)從A搬到B治理團(tuán)隊負(fù)責(zé)定義A到B該怎么搬、搬完怎么驗收、不合格怎么辦。如果治理團(tuán)隊陷到寫SQL、調(diào)性能、做模型設(shè)計里面去那這個項目離爛尾不遠(yuǎn)了。我見過最典型的反面案例是治理團(tuán)隊為了體現(xiàn)價值去幫業(yè)務(wù)部門做了一堆報表。結(jié)果報表倒是出了不少核心的數(shù)據(jù)標(biāo)準(zhǔn)沒人定質(zhì)量問題沒人管半年后報表口徑又亂成一鍋粥。治理的職責(zé)是制定規(guī)則、監(jiān)督執(zhí)行、推動整改不是替代業(yè)務(wù)開發(fā)。守住這個邊界后面所有事情才有得談。2. 元數(shù)據(jù)與數(shù)據(jù)標(biāo)準(zhǔn)讓數(shù)據(jù)從能用到好用如果說數(shù)倉里的數(shù)據(jù)是貨架上的商品那元數(shù)據(jù)就是商品的標(biāo)簽和擺放圖數(shù)據(jù)標(biāo)準(zhǔn)就是商品的統(tǒng)一規(guī)格。沒有這兩樣數(shù)據(jù)再多也相當(dāng)于一個沒有索引的倉庫找東西全靠翻。2.1 技術(shù)元數(shù)據(jù)與業(yè)務(wù)元數(shù)據(jù)一個都不能少技術(shù)元數(shù)據(jù)相對好做它描述的是庫表字段、存儲類型、分區(qū)信息、數(shù)據(jù)量、更新頻率這些客觀屬性。只要你有Hive、Spark、Kafka這些組件的訪問權(quán)限靠著元數(shù)據(jù)采集工具就能自動抓個七八成。真正難的是業(yè)務(wù)元數(shù)據(jù)。同一個用戶活躍數(shù)分母到底是去重后的用戶還是包含測試賬號這個口徑寫在哪哪個業(yè)務(wù)負(fù)責(zé)人對指標(biāo)負(fù)責(zé)這些信息只存在于業(yè)務(wù)人員的腦子里。我在項目里常用的做法是在做數(shù)據(jù)字典評審時強制要求每個核心指標(biāo)指定一個業(yè)務(wù)Owner并且由他簽字確認(rèn)口徑描述。只有技術(shù)元數(shù)據(jù)沒有業(yè)務(wù)元數(shù)據(jù)數(shù)據(jù)字典就是個空殼。2.2 血緣追蹤的落地姿勢血緣關(guān)系是元數(shù)據(jù)管理里最有價值、也最容易做淺的部分。很多團(tuán)隊說自己有數(shù)據(jù)血緣打開一找全是表級血緣字段級完全空白。這種血緣對排查指標(biāo)口徑問題幾乎沒有幫助。落地血緣通常有三條路解析SQL用Hive/Spark SQL解析器從代碼里提取輸入表、輸出表、字段映射關(guān)系。工具層面可以用Apache Atlas能自動抓到表級和一部分字段級血緣。ETL埋點在編寫數(shù)據(jù)加工任務(wù)時顯式聲明source、target以及字段級轉(zhuǎn)換邏輯。這種方式準(zhǔn)確率最高但對開發(fā)規(guī)范要求嚴(yán)需要團(tuán)隊配合。混合模式先靠解析SQL把血緣關(guān)系打通到表級再對核心鏈路做人工整理和字段級補充。我的建議是不要一上來就追求完美字段級血緣。先做到核心鏈路、核心指標(biāo)相關(guān)的表級血緣完整跑通上游變更影響分析這個場景你就能嘗到甜頭。比如上游訂單表要新增一個枚舉值你在血緣圖上立刻能看到下游哪些指標(biāo)會受影響而不是等業(yè)務(wù)投訴了再去翻幾十個腳本。2.3 數(shù)據(jù)標(biāo)準(zhǔn)先行Excel模板導(dǎo)入背后的字段規(guī)范熱搜詞里提到以Excel模板數(shù)據(jù)導(dǎo)入的數(shù)據(jù)治理項目這個點非常實際。很多傳統(tǒng)企業(yè)做治理第一步往往不是建平臺而是先規(guī)范Excel導(dǎo)入。大家不要覺得Excel導(dǎo)入很簡單它其實就是數(shù)據(jù)標(biāo)準(zhǔn)落地的最佳切入點。比如業(yè)務(wù)部門要上報渠道數(shù)據(jù)如果沒有標(biāo)準(zhǔn)今天填線上明天填網(wǎng)銷后天填A(yù)PP后端做匯總時頭都大了。所以我在設(shè)計模板導(dǎo)入功能時會把字段名、數(shù)據(jù)類型、長度、枚舉值、是否必填、是否唯一全部定義在標(biāo)準(zhǔn)庫里。用戶下載到的模板本身就是一份強制版的數(shù)據(jù)標(biāo)準(zhǔn)。Excel模板的作用不只是收集數(shù)據(jù)它還是隱形的校驗器手機號必須滿足正則表達(dá)式、渠道字段只能選標(biāo)準(zhǔn)碼表里的值、導(dǎo)入文件里不能有重復(fù)的主鍵。這些規(guī)則不是寫死在頁面上的而是從數(shù)據(jù)標(biāo)準(zhǔn)配置里動態(tài)生成的。這樣當(dāng)標(biāo)準(zhǔn)更新時模板和校驗規(guī)則就能同步升級不會出現(xiàn)Excel模板和數(shù)倉口徑對不上的尷尬。3. 數(shù)據(jù)質(zhì)量最能直接體現(xiàn)治理成效的硬指標(biāo)做數(shù)據(jù)治理項目業(yè)務(wù)方和國際供應(yīng)商最不看虛的就是數(shù)據(jù)質(zhì)量有沒有提升。所以數(shù)據(jù)質(zhì)量一定是整個治理體系里最先見效、也最容易出彩的部分。3.1 數(shù)據(jù)質(zhì)量六個維度別只盯著準(zhǔn)確性很多非專業(yè)人員一說數(shù)據(jù)質(zhì)量就認(rèn)為是數(shù)據(jù)準(zhǔn)不準(zhǔn)。但真實項目里準(zhǔn)確性往往是最難定義、最難驗證的。所以目前業(yè)內(nèi)普遍會把數(shù)據(jù)質(zhì)量拆成六個可操作的維度維度定義常見異常例子完整性數(shù)據(jù)是否缺失訂單表中的用戶ID為空唯一性是否有重復(fù)同一訂單號出現(xiàn)兩次準(zhǔn)確性數(shù)據(jù)是否真實反映業(yè)務(wù)完成時間早于下單時間一致性跨表口徑是否統(tǒng)一不同表同一用戶性別標(biāo)注不同及時性數(shù)據(jù)是否按時到位每日分區(qū)數(shù)據(jù)延遲4小時有效性數(shù)據(jù)是否符合規(guī)則手機號只有11位數(shù)字卻出現(xiàn)字母在六維度的基礎(chǔ)上我建議再補一個可理解性也就是每個字段有沒有清晰易懂的業(yè)務(wù)解釋否則下游用戶根本不知道字段應(yīng)該怎么用準(zhǔn)確性問題就會以另一種形式出現(xiàn)。3.2 規(guī)則配置與異常預(yù)警讓系統(tǒng)代替人工盯數(shù)質(zhì)量規(guī)則才是這part真正動手的地方。規(guī)則要配置在數(shù)據(jù)接入、加工、出數(shù)整個鏈路的關(guān)鍵節(jié)點上。比如對訂單明細(xì)表每天檢查主鍵唯一率重復(fù)率超過0.1%就告警對手機號字段用正則表達(dá)式校驗格式有效比率低于90%觸發(fā)阻斷對每日分區(qū)數(shù)據(jù)設(shè)置產(chǎn)出時間SLA超過約定時間未生成分區(qū)就通知調(diào)度負(fù)責(zé)人對金額字段設(shè)置非負(fù)數(shù)校驗發(fā)現(xiàn)負(fù)數(shù)自動標(biāo)記為可疑數(shù)據(jù)并轉(zhuǎn)入暫存區(qū)。質(zhì)量檢查任務(wù)要跟著調(diào)度跑數(shù)據(jù)加工完成之后立刻觸發(fā)質(zhì)量檢查結(jié)果自動匯總成質(zhì)量報告。這里有個關(guān)鍵設(shè)計——質(zhì)量規(guī)則要有負(fù)責(zé)人。沒有負(fù)責(zé)人的規(guī)則就是一堆報警垃圾。每條規(guī)則生效前至少要指定一個接收告警的人并對規(guī)則閾值進(jìn)行評審否則寧可先不配置。3.3 從事后清洗轉(zhuǎn)向事前攔截傳統(tǒng)數(shù)倉的做法是數(shù)據(jù)已經(jīng)進(jìn)來了跑個腳本發(fā)現(xiàn)臟數(shù)據(jù)再清洗。這種方式成本高而且容易導(dǎo)致清洗邏輯不一致——今天清這個明天漏那個。我更推薦事前攔截的思路把質(zhì)量檢查前移到數(shù)據(jù)接入環(huán)節(jié)。以Excel模板導(dǎo)入為例用戶上傳數(shù)據(jù)后后端先做逐行校驗?zāi)囊恍小⒛囊涣谐隽藛栴}直接返回詳細(xì)的錯誤提示給上傳人讓他改完再傳。合格數(shù)據(jù)才能進(jìn)入正式表不合格數(shù)據(jù)進(jìn)暫存區(qū)并通知數(shù)據(jù)Owner處理。這樣做的好處是源頭臟數(shù)據(jù)根本進(jìn)不了數(shù)倉下游模型和報表就不用再做一遍防御性清洗。前期開發(fā)工作量會大一些但長期看收益非常高。我做過一個渠道數(shù)據(jù)上報項目用事前攔截之后數(shù)倉里核心表的臟數(shù)據(jù)比例從4%降到了0.3%而且這個成績是持續(xù)保持的不是靠突擊清洗。3.4 一個Hive案例網(wǎng)約車訂單明細(xì)的臟數(shù)據(jù)如何暴露問題拿一個常見的網(wǎng)約車大數(shù)據(jù)綜合項目場景來舉個例子。假設(shè)有一張訂單明細(xì)表從業(yè)務(wù)庫同步到Hive每天一個分區(qū)。一開始我們只看總訂單量這個指標(biāo)沒發(fā)現(xiàn)任何異常。但某天把指標(biāo)細(xì)化到城市維度時發(fā)現(xiàn)訂單量排名第一的城市居然顯示為未知因為訂單表和城市表關(guān)聯(lián)不上外鍵關(guān)系被破壞了。繼續(xù)排查又發(fā)現(xiàn)兩個問題一部分訂單的完成時間比下單時間還早明顯是設(shè)備時間異常導(dǎo)致還有個別訂單金額為負(fù)其實是退款記錄被錯當(dāng)成了新訂單。如果不做治理這三類數(shù)據(jù)會直接污染營收、完單率、客單價等多個核心指標(biāo)。有了質(zhì)量平臺之后我在這張表上配置了三條規(guī)則完成時間必須晚于下單時間、city_id必須在城市表里存在、訂單金額非負(fù)數(shù)。每天跑批后先檢查這三條有異常自動阻斷并通知數(shù)據(jù)開發(fā)。之后再跑渠道分析報表業(yè)務(wù)看到未知城市終于消失這種直觀的改善比任何匯報PPT都有說服力。4. 數(shù)據(jù)安全與權(quán)限管控行級、列級權(quán)限的設(shè)計方案數(shù)據(jù)治理做到一定階段安全權(quán)限就會浮出水面而且通常是業(yè)務(wù)方主動提需求——因為不合規(guī)或者出過事故。4.1 大數(shù)據(jù)平臺上權(quán)限為什么難做傳統(tǒng)關(guān)系型數(shù)據(jù)庫有成熟的GRANT權(quán)限體系但大數(shù)據(jù)平臺上的數(shù)據(jù)往往躺在HDFS上算的時候用Hive、Spark、Presto查詢的時候又可能走統(tǒng)一SQL入口。只要有一個入口沒接入權(quán)限校驗等于整個權(quán)限體系白做。另外數(shù)倉里的表動輒幾百張字段幾十上百個用戶角色又雜。如果每張表、每個字段都手工授權(quán)管理員會瘋掉。所以設(shè)計權(quán)限模型前先要梳理清楚誰是數(shù)據(jù)Owner、哪些角色需要什么粒度的數(shù)據(jù)訪問權(quán)、審批流怎么走。4.2 開源方案怎么選Ranger、Atlas、自研模型先給結(jié)論如果你用的是標(biāo)準(zhǔn)Hadoop生態(tài)最早可以嘗試定級Apache Ranger加Apache Atlas的組合如果你有統(tǒng)一查詢?nèi)肟诨蛘邫?quán)限邏輯很特殊再考慮自研權(quán)限網(wǎng)關(guān)。方案管控粒度優(yōu)點局限適用場景Apache RangerHive/HDFS/Kafka表級、列級、行過濾社區(qū)成熟、支持多組件統(tǒng)一授權(quán)、審計日志齊全規(guī)則多了配置復(fù)雜需要專人維護(hù)標(biāo)準(zhǔn)Hadoop技術(shù)棧企業(yè)Apache Atlas元數(shù)據(jù)、標(biāo)簽、血緣可以和Ranger聯(lián)動做標(biāo)簽權(quán)限本身不是權(quán)限引擎已建Atlas元數(shù)據(jù)中心的企業(yè)自研權(quán)限網(wǎng)關(guān)任意粒度靈活可按用戶動態(tài)改寫SQL開發(fā)量大、要維護(hù)語法解析有統(tǒng)一查詢?nèi)肟凇?quán)限邏輯復(fù)雜Ranger的列級權(quán)限做的是脫敏策略比如身份證號非授權(quán)用戶查出來只能看到前三位和后四位行級權(quán)限做的是row filter比如不同區(qū)域的銷售只能看到本區(qū)域訂單。Atlas是一個元數(shù)據(jù)管理平臺它可以給表打上敏感內(nèi)部公開等標(biāo)簽再讓Ranger基于標(biāo)簽來授權(quán)。4.3 行級和列級權(quán)限的建模思路列級權(quán)限的核心是識別敏感字段然后按角色配置策略。真實的策略通常分三種禁止訪問、明文訪問、脫敏訪問。脫敏又分為保留前幾位、哈希替換、置空等。行級權(quán)限的通用做法是謂詞注入。比如你要讓華東區(qū)的銷售只能看area_codeHD的數(shù)據(jù)底層邏輯就是在查詢SQL后面自動追加where area_code HD。如果使用Ranger可以寫類似current_user in (select ... from user_area ...)之類的行過濾條件。但行級權(quán)限要小心性能。給大表加行過濾尤其是動態(tài)子查詢時可能會導(dǎo)致查詢效率斷崖式下跌。我在一個項目里就踩過這個坑給一個10億行的事實表加了按部門過濾條件里面用了子查詢結(jié)果原來十幾秒的查詢跑了好幾分鐘。后來做成預(yù)計算的用戶-to-部門映射表再用join代替子查詢性能才恢復(fù)正常。4.4 審計與合規(guī)權(quán)限不是配完就完了做安全權(quán)限最忌諱的是配完就忘。Ranger自帶的審計日志至少要保持6個月且需要能回答一個問題某個用戶在某個時間到底訪問了哪些表、查了哪些數(shù)據(jù)、有沒有導(dǎo)出行為。尤其是通過Excel模板導(dǎo)入導(dǎo)出數(shù)據(jù)的場景要防止數(shù)據(jù)泄露和惡意數(shù)據(jù)導(dǎo)出。我在治理平臺里會要求用戶申請權(quán)限時填寫數(shù)據(jù)用途、有效期導(dǎo)出接口要有敏感字段水印核心表的全量導(dǎo)出必須走審批流程。結(jié)合審計日志出了問題能查、能追、能舉證這是安全治理的底線。5. 一個完整數(shù)據(jù)治理項目該有的功能全家桶前面講的是治理核心要素落到系統(tǒng)層面一個真正能用的治理平臺到底該有哪些功能我按照做項目的經(jīng)驗把高頻需求整理成一張功能清單大家可以照著檢視自己的平臺。5.1 Excel模板導(dǎo)入它不是上傳Excel那么簡單很多公司做數(shù)據(jù)治理系統(tǒng)第一個模塊就是模板數(shù)據(jù)導(dǎo)入。這個模塊看似簡單但最容易翻車。我拆一下該有的功能模板管理支持多套模板每個模板對應(yīng)一個數(shù)據(jù)標(biāo)準(zhǔn)能動態(tài)生成模板文件并控制版本模板下載與上傳用戶下載標(biāo)準(zhǔn)模板填報后上傳系統(tǒng)后臺做異步解析逐行校驗解析后按標(biāo)準(zhǔn)庫校驗字段長度、格式、枚舉值、必填項、唯一性錯誤回顯第幾行第幾列出錯錯誤原因?qū)懨靼妆热绲?023行手機號格式錯誤支持在線修正后重新上傳暫存區(qū)校驗通過但未發(fā)布的數(shù)據(jù)先進(jìn)暫存區(qū)由數(shù)據(jù)Owner審核后寫入正式表增量導(dǎo)入與任務(wù)調(diào)度支持定時增量導(dǎo)入并與數(shù)據(jù)質(zhì)量檢查和血緣采集聯(lián)動。我在做這種模塊時有一個心得模板即標(biāo)準(zhǔn)。模板的每個列頭都要能從標(biāo)準(zhǔn)庫里找到對應(yīng)的字段定義這樣用戶填報的過程就是按標(biāo)準(zhǔn)填數(shù)的過程。另外上傳大Excel文件一定要做成異步隊列前端先返回解析中等有結(jié)果再通知千萬不能同步阻塞。5.2 數(shù)據(jù)資產(chǎn)目錄讓業(yè)務(wù)自己找到數(shù)據(jù)數(shù)據(jù)治理的成果如果只給IT看價值發(fā)揮不出來。所以必須做一個數(shù)據(jù)資產(chǎn)目錄讓業(yè)務(wù)用戶能像逛分類網(wǎng)站一樣找數(shù)據(jù)。目錄里至少要包含數(shù)據(jù)表名稱、所屬業(yè)務(wù)域、業(yè)務(wù)負(fù)責(zé)人、統(tǒng)計口徑說明、更新頻率、數(shù)據(jù)量、質(zhì)量評分、最近一周訪問熱度。再配合關(guān)鍵字搜索、收藏、訂閱業(yè)務(wù)就能主動找到核心指標(biāo)數(shù)據(jù)而不是天天找數(shù)倉工程師要表。這個目錄的數(shù)據(jù)來源就是元數(shù)據(jù)中心和質(zhì)量管理模塊所以如果前面元數(shù)據(jù)沒做扎實資產(chǎn)目錄就會是個空架子。反過來說資產(chǎn)目錄也是檢驗元數(shù)據(jù)質(zhì)量最好的窗口——業(yè)務(wù)搜不到的東西背后往往就是元數(shù)據(jù)沒補齊。5.3 數(shù)據(jù)服務(wù)與數(shù)據(jù)大屏的聯(lián)動治理好數(shù)據(jù)最終要變成服務(wù)尤其是現(xiàn)在很多項目要通過數(shù)據(jù)大屏來展示成果。大屏只是消費端本質(zhì)上它需要穩(wěn)定、高質(zhì)量的數(shù)據(jù)服務(wù)。我建議治理平臺把數(shù)據(jù)服務(wù)能力單獨做成一層數(shù)據(jù)源做治理檢查 - 生成指標(biāo)寬表 - 注冊API服務(wù) - 大屏調(diào)用API渲染這里有兩個容易被忽視的細(xì)節(jié)一是數(shù)據(jù)服務(wù)要配置緩存策略和超時熔斷避免大屏高并發(fā)把底層數(shù)倉打崩二是要監(jiān)控API的數(shù)據(jù)量和響應(yīng)時間某一天指標(biāo)值突變時能回溯是數(shù)據(jù)質(zhì)量告警還是上游任務(wù)延遲。數(shù)據(jù)大屏好看與否八成在數(shù)據(jù)服務(wù)層不在前端可視化。5.4 任務(wù)調(diào)度與治理自動化治理平臺本身就是一套系統(tǒng)也離不開調(diào)度。質(zhì)量檢查、血緣采集、報表生成、權(quán)限策略同步全部要有自動調(diào)度能力。調(diào)度設(shè)計上注意幾個點一是要有依賴管理先等數(shù)倉加工完再跑質(zhì)量檢查避免誤報二是支持按分區(qū)、按表優(yōu)先級調(diào)度核心表優(yōu)先三是失敗重跑要冪等避免重復(fù)生成數(shù)據(jù)。更進(jìn)一步可以把治理流程做進(jìn)自動化閉環(huán)質(zhì)量規(guī)則觸發(fā)告警 - 自動生成工單 - 推送給負(fù)責(zé)人 - 整改后復(fù)測 - 關(guān)閉工單。這一步做好了治理就從人盯人變成了系統(tǒng)盯系統(tǒng)。6. 治理戰(zhàn)略落地交付成果與真實踩坑經(jīng)驗最后一個環(huán)節(jié)也是最容易被忽視的數(shù)據(jù)治理項目最終交付的是什么如果只有系統(tǒng)沒有機制上線即失效。6.1 數(shù)據(jù)治理戰(zhàn)略的常見交付成果實例做項目一定要有可見的交付物不然管理層沒法驗收。結(jié)合我見到的實戰(zhàn)核心交付成果通常包括數(shù)據(jù)治理平臺包含元數(shù)據(jù)管理、數(shù)據(jù)標(biāo)準(zhǔn)、質(zhì)量規(guī)則、權(quán)限管控、資產(chǎn)目錄、數(shù)據(jù)服務(wù)等模塊數(shù)據(jù)標(biāo)準(zhǔn)體系文檔命名規(guī)范、字段標(biāo)準(zhǔn)、碼表、指標(biāo)口徑說明數(shù)據(jù)字典與血緣圖譜覆蓋核心業(yè)務(wù)域的字段級字典和核心鏈路血緣數(shù)據(jù)質(zhì)量報告周報/月報包含質(zhì)量評分、問題清單、整改率權(quán)限矩陣與審計報告核心表的訪問權(quán)限總表以及操作審計日志數(shù)據(jù)資產(chǎn)門戶及API服務(wù)業(yè)務(wù)自助取數(shù)、大屏數(shù)據(jù)服務(wù)。以網(wǎng)約車數(shù)據(jù)分析這類綜合項目為例交付的不只是幾張Hive寬表更重要的是把訂單明細(xì)怎么定義、訂單金額口徑是什么、哪些字段需要權(quán)限管控梳理成文檔和規(guī)則這樣項目換人也能接得住。6.2 組織與流程沒有Owner的治理一定爛尾技術(shù)只是工具治理真正落地靠的是分工和流程。至少要有三層角色數(shù)據(jù)治理委員會定制度、定標(biāo)準(zhǔn)、排優(yōu)先級數(shù)據(jù)Owner每個核心數(shù)據(jù)域要有業(yè)務(wù)負(fù)責(zé)人對數(shù)據(jù)口徑和質(zhì)量管理負(fù)責(zé)數(shù)據(jù)管家/治理工程師日常維護(hù)元數(shù)據(jù)、配置規(guī)則、跟蹤整改。我在項目里一個深刻的感受是如果質(zhì)量報告發(fā)出去了卻沒有一個責(zé)任人去認(rèn)領(lǐng)和推動那報告就只是一張廢紙。所以在治理平臺上線之前先要把組織責(zé)任矩陣做出來。誰認(rèn)領(lǐng)、誰整改、誰驗收這些在流程里寫死了系統(tǒng)才有抓手。6.3 分階段實施節(jié)奏先止血再造血治理項目最忌諱一上來就鋪大攤子。我見過一個企業(yè)想一步到位做全量元數(shù)據(jù)結(jié)果元數(shù)據(jù)團(tuán)隊累得半死業(yè)務(wù)卻不怎么買賬。更務(wù)實的做法是三步走第一階段止血。先梳理核心業(yè)務(wù)域的1-2條關(guān)鍵鏈路把表、字段、口徑、Owner摸清基礎(chǔ)元數(shù)據(jù)補齊核心質(zhì)量規(guī)則上線讓業(yè)務(wù)看到報表數(shù)據(jù)終于能對齊了。第二階段造血。建設(shè)數(shù)據(jù)資產(chǎn)目錄開放自助檢索讓業(yè)務(wù)自己找到想要的數(shù)據(jù)。同時把行/列權(quán)限覆蓋到敏感數(shù)據(jù)上。第三階段擴(kuò)張。數(shù)據(jù)服務(wù)下沉治理能力產(chǎn)品化支持更多業(yè)務(wù)域接入。根據(jù)前兩個階段的反饋迭代標(biāo)準(zhǔn)體系和自動化流程。過程中要有一個業(yè)務(wù)痛點驅(qū)動的心態(tài)。哪個指標(biāo)的投訴最多哪個數(shù)據(jù)出了問題后果最嚴(yán)重就先治理哪塊。治理不要追求全面開花先把痛點變成亮點后面才有支持者。6.4 我踩過的幾個坑希望你能繞過最后分享幾個我真實踩過的坑算是給同行提個醒。第一個坑是標(biāo)準(zhǔn)定義過度理想化。一上來搞了上百個標(biāo)準(zhǔn)字段結(jié)果業(yè)務(wù)根本填不齊。后來學(xué)乖了標(biāo)準(zhǔn)只覆蓋真正共享和統(tǒng)計的必要字段其他字段暫時放行但不入標(biāo)準(zhǔn)庫。第二個坑是質(zhì)量規(guī)則報警沒人認(rèn)領(lǐng)。規(guī)則配置得很全每天報警幾十條但都是發(fā)給數(shù)倉開發(fā)沒有同步給業(yè)務(wù)Owner。結(jié)果就是報警淪為狼來了大家默認(rèn)忽略。后來改成每條規(guī)則都有明確的負(fù)責(zé)人和處置時限無效規(guī)則定期下架質(zhì)量治理才真正轉(zhuǎn)動起來。第三個坑是權(quán)限模型做得過于復(fù)雜。行級權(quán)限精確到每個用戶字段級脫敏策略疊了十幾層結(jié)果數(shù)據(jù)分析師查數(shù)時頻繁被攔截體驗極差。后來調(diào)整成角色屬性審批的粗粒度結(jié)構(gòu)按團(tuán)隊授權(quán)、用屬性動態(tài)過濾、關(guān)鍵操作留審計既安全又不擋路。第四個坑是忽略Excel導(dǎo)入的模板版本管理。舊模板還在被業(yè)務(wù)使用標(biāo)準(zhǔn)庫卻更新了導(dǎo)致上傳數(shù)據(jù)校驗失敗。后來把模板和標(biāo)準(zhǔn)庫做了版本綁定同一時期允許多個模板版本并存用戶下載哪個版本就按哪個版本校驗問題就消失了。這些坑有一個共同點都是技術(shù)到位治理機制沒跟上造成的。數(shù)據(jù)治理的本質(zhì)是把數(shù)據(jù)當(dāng)作資產(chǎn)來管而資產(chǎn)管理的核心從來都不是軟件而是人和規(guī)則。把這三個要素理順了大數(shù)據(jù)治理自然就落地了。