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