簡介這份PDF白皮書面向企業(yè)數據管理者、數據平臺建設者與數字化轉型從業(yè)者圍繞“數據如何從資源變成資產”這一核心問題展開。內容從數據分類與數據資產定義講起梳理主數據、業(yè)務數據、分析數據的“樹干—枝葉—果實”關系進而說明數據治理解決的是找不到、看不懂、信不過、管不住四類現實困境并系統介紹網易數據治理2.0的開發(fā)治理一體化、數據中臺架構、湖內湖外統一治理、數據治理360、基于ROI的資產精細化管理、持續(xù)閉環(huán)與DataOps開發(fā)底座。資源共1個PDF文件約10.09MB目錄完整、層級清晰便于按章節(jié)檢索末章還給出證券、電信運營商、物流三個行業(yè)的落地實踐可幫助讀者對照自身場景理解治理框架的搭建順序與落地要點。目前已有721人學習適合需要建立數據治理整體認知或為內部立項尋找參考的讀者。1. 數據治理到底在治什么它管的不是數據是人和數據的關系“數據治理”這四個字第一次聽見的人多半會理解成“把數據洗干凈”或者“建一個大庫統一存起來”。真在企業(yè)里干過這活的人會告訴你清洗和建庫只是動作治理真正要對付的是兩件事人和數據之間怎么互相認識人和人之間怎么把同一份數據用到同一個口徑上。一份企業(yè)級的數據治理白皮書把這件事拆得很細先把企業(yè)數據分成主數據、業(yè)務數據和分析數據再看數據用不起來時到底卡在哪四個地方最后把治理動作塞回數據開發(fā)的流水線上。這條路子值得搞懂因為大多數公司踩的坑幾乎一模一樣——數據越攢越多能用的反而越來越少。2. 企業(yè)的數據到底長什么樣樹干、樹葉和果實的分類法企業(yè)里幾乎每個人每天都在和數據打交道管理者看報表基層員工填單據運營盯著轉化率?？捎貌缓脭祿脑蛲辉凇坝袥]有數據”而在“根本不知道手上這堆東西各是什么、各管什么用”。分類是所有后續(xù)動作的前提分不清類型就談不上治理更談不上把數據當資產來經營。2.1 主數據、業(yè)務數據、分析數據一棵樹就能記住主數據是有關業(yè)務實體的數據比如雇員、客戶、產品、地點。它回答的是“這個對象是誰”為業(yè)務交易和分析提供語境信息。一家公司如果客戶主數據沒管住同一個客戶在三個系統里就是三個人后續(xù)所有按客戶匯總的數字都會出問題。業(yè)務數據描述企業(yè)的經營活動產品出入庫、財務應收、采購、銷售都算。它回答的是“發(fā)生了什么”是分析數據的原料。業(yè)務數據的質量直接決定后面能不能算出可信的結果上游一筆單據錄錯下游十個報表跟著歪。分析數據來自業(yè)務數據的加工反映企業(yè)業(yè)績比如銷售收入增長、投資回報率。它回答的是“結果如何”是決策的依據也是數據價值真正體現出來的那一層。三類數據不是并列關系而是承載和供養(yǎng)關系。主數據是樹干業(yè)務數據是枝葉分析數據是枝頭的果實葉子離了樹干活不了果實靠葉子光合作用供養(yǎng)。脫離主數據談業(yè)務數據和分析數據就像拿著摘下來的葉子討論它還能不能結果。類型回答的問題典型例子類比缺失時會怎樣主數據這個對象是誰客戶、產品、地點、雇員樹干同一客戶在不同系統變成多條記錄業(yè)務數據發(fā)生了什么出入庫、應收、采購、銷售樹葉分析沒有原料只能拍腦袋分析數據結果如何收入增長、投資回報率果實決策失去依據價值無法兌現2.2 數據為什么不等于數據資產業(yè)內一份被廣泛引用的數據資產管理白皮書把數據資產定義為由組織合法擁有或控制的數據資源以電子或其他方式記錄例如文本、圖像、語音、視頻、網頁、數據庫、傳感信號等結構化或非結構化數據可進行計量或交易能直接或間接帶來經濟效益和社會效益。這個定義里有三根柱子。第一根是主體數據必須有歸屬歸屬于某個組織而不是飄在空中的字節(jié)。第二根是資源形態(tài)數據可以是結構化的表也可以是非結構化的語音和圖像判斷標準不是長什么樣而是能不能被記錄和被使用。第三根是價值能直接或間接帶來經濟效益和社會效益這一條才是“數據”和“資產”之間的分水嶺。關鍵在于這三根柱子不會自動立起來。數據的生成、匯聚、存儲、分析、共享每個環(huán)節(jié)都可能因為管理不當、治理手段缺失而產出低質量數據。低質量數據不但沒有價值還會制造錯誤決策它的破壞力和一條錯誤的財務報表是同一量級。用樹的比喻接著說不健康的樹干會影響葉子生長不健康的葉子無法提供足夠養(yǎng)分去孕育果實不健康的果實也吃不得。所以企業(yè)里數據量和資產量從來不是一回事只有對企業(yè)有價值的那部分數據才夠格叫資產。這個判斷聽起來簡單落到幾十萬張表上就變成一道實打實的篩選題。2.3 數據治理是那把鑰匙原料、加工線、成品如果把數據比作企業(yè)信息化的原料數據治理就是信息化的基石數據資產則是在治理過的數據上挖出來的價值。三者是一條流水線原料進廠、加工線運轉、成品出廠跳掉中間那段原料永遠只是原料。這條加工線處理的事情說白了是人與人、人與數據之間的關系。一份字段該叫什么名字、由誰定義、口徑變了通知誰、誰有權看、看完出問題找誰這些不是技術問題是責任和流程問題。也正因為如此數據治理常常被誤當成 IT 部門的私活。實際上它一端連著業(yè)務定義一端連著技術實現中間還夾著組織授權。只讓技術團隊做標準定得再漂亮也落不下去只讓業(yè)務團隊做討論三個月也產不出一張能用的表。搞清這一點后面的所有問題才有解釋的余地。3. 治理要解決的四個字找不到、看不懂、信不過、管不住很多公司都是在某一兩年突然集體喊起治理。原因往往不是領導忽然重視了而是業(yè)務規(guī)模擴張到某個臨界點原來靠人肉維持的小數倉撐不住了數據量漲上去問題密度也跟著漲某天一次事故直接把成本算清楚治理就被提上日程。把這些問題歸個類基本能收進四個詞找不到、看不懂、信不過、管不住。這四個詞對應的不是四個工具而是數據從被發(fā)現到被使用的完整鏈條。3.1 找不到幾萬張表里的大海撈針先看規(guī)模。某電商業(yè)務線約有 8 萬張表某內容業(yè)務線約有 4 萬張表。越靠近應用層大寬表越多一張表上百個字段非常正常。對一個分析師來說從幾萬張表里找到自己需要的那一張效率上跟大海撈針差不多。更值得琢磨的是數據地圖的使用數據90% 以上的使用者是 IT 人員本來作為目標用戶的業(yè)務人員幾乎不用。這不是工具做得不好而是索引對象錯了。地圖回答的是“表在哪兒”業(yè)務問的是“我要的那個數在哪兒”。業(yè)務人員腦子里想的是“上月新客復購率”地圖給他的是 dwd_trade_order_detail_v3中間那層翻譯工作沒人做。找不到的直接后果是重復開發(fā)。反正搜不到索性自己建一張建完又沒人知道下一波需求再建一張。表的數量于是繼續(xù)膨脹形成自我加速的循環(huán)。3.2 看不懂78% 的表存在元數據缺失即便業(yè)務人員找到了表也常?？床欢?。有統計顯示高達 78% 的表存在元數據缺失缺的主要是管理元數據和業(yè)務元數據而這兩類恰恰是業(yè)務人員判斷“這張表能不能用”的關鍵信息。元數據缺失有明顯的結構性原因。技術元數據完整度通常最高因為它能靠系統自動采集表結構、存儲位置、分區(qū)、任務依賴掃一遍就有。管理元數據和業(yè)務元數據與業(yè)務強相關必須由業(yè)務方配合補充誰負責、什么含義、口徑怎么算、什么密級這些系統猜不出來。凡是需要人手工補的缺失率一定高。字段名于是變成了黑匣子。一個叫 amt_pay 的字段可能是實付金額可能是應付金額也可能含稅不含稅光看名字誰也說不準。開發(fā)人員不敢改業(yè)務人員不敢用這張表就在那里躺著占著存儲等著某天被當成歷史包袱清理掉。提示元數據采集工具解決得了“有沒有”解決不了“準不準”。業(yè)務含義這部分只能靠責任到人靠工具替代不了。3.3 信不過一條上游邏輯改動幾十萬真金白銀質量是數據的生命線。沒有質量保障的數據不僅沒有價值還會產生錯誤決策這一點在涉及錢的場景里尤其刺眼。某次電商活動中開發(fā)修改了一個上游任務的計算邏輯影響了下游一張涉及資損的表紅包超發(fā)幾十萬的損失當場發(fā)生。這類教訓反復出現指向的其實是同一件事業(yè)務方對數據的信任是一次次事故磨掉的。再看日常。對內部工作群的反饋做過統計平均每周有 10 個數據質量問題被反饋“數據違反常識”是聽到最多的一句吐槽。更難受的是其中 90% 的問題由數據使用方先于開發(fā)方發(fā)現數據團隊非常被動經常是業(yè)務找上門才知道自己出了問題。根子在于質量規(guī)則沒有跟著開發(fā)走。實際開發(fā)過程中質量稽核規(guī)則的覆蓋率只有 10%相同數據項上有 70% 的情況稽核規(guī)則不一致閾值設置也不一致。同一張表在不同人手里守護它的規(guī)則完全不同甚至有些表根本沒規(guī)則守著。-- 訂單金額稽核金額為負或明顯超過 單價×數量都判為異常 -- 1.05 表示允許 5% 的優(yōu)惠浮動這個數值必須由業(yè)務口徑確認后寫進標準而不是讓開發(fā)各自拍板 SELECT order_id, pay_amount, unit_price * quantity AS expected_amount -- 理論金額用于人工復核時對照 FROM dwd_order_detail WHERE dt ${bizdate} -- 按天分區(qū)跑只稽核當天增量 AND (pay_amount 0 OR pay_amount unit_price * quantity * 1.05);這段 SQL 的邏輯很樸素把明顯不可能的值撈出來。真正的關鍵不在語句本身而在三個參數的來源。dt 決定稽核的時間范圍pay_amount 的字段類型、精度、是否允許為負應當來自數據標準而不是臨時約定1.05 這個閾值更典型一個人拍 1.05另一個人拍 1.2規(guī)則就打架了這正是前面那 70% 不一致的來源。規(guī)則一旦掛到數據元上閾值隨標準走才談得上統一。注意稽核規(guī)則如果由每個開發(fā)自行手寫同一張表在不同人手里會得到完全不同的判定結果覆蓋率低只是表象判定標準漂移才是根本問題。還有一組數字值得留意經由數據開發(fā)任務變更導致的生產環(huán)境數據問題占比達到 65%。也就是說大部分事故不是數據天生有問題而是改動引入的。傳統治理方式在開發(fā)完成之后才介入天然接不住這類事故。3.4 管不住成本黑洞和流于形式的權限數據成本是成本里最容易被忽略的一項因為它不像人力、采購那樣有明確賬單。但真去盤一遍庫存數字往往很扎眼某事業(yè)部 78.39% 的表只占了 21.63% 的存儲空間而這些表在 30 天內無人訪問。報表也一樣62% 的報表在 30 天內無人使用平均每張報表每個月還要花掉約 3 萬元的成本。資源的濫用還會直接帶來穩(wěn)定性問題。內部記錄顯示每個月都有 5 次以上事故與資源不合理使用有關比如一個五層嵌套的大 SQL 瞬間把集群壓垮殃及所有在同一集群上跑的任務。安全這一側的矛盾更微妙。企業(yè)既希望員工多用數據又要確保不同密級的數據只被對的人看到。權限分配不合理輕則數據誤刪重則數據泄密權限流程太復雜使用效率又掉下來。一個真實的場景是業(yè)務運營想用一張表得先找到表的負責人再聯系對方授權整個流程常常耗掉一天。而在授權方那頭負責人往往也不清楚該不該給最后權限流于形式只要能找到人就能拿到訪問權。四個問題擺在一起看會發(fā)現它們不共享同一個工具卻共享同一個根源治理動作發(fā)生在數據生產出來之后既沒有被量化也沒有形成閉環(huán)。這就是下一章要展開的部分。4. 治理為什么總在事后救火六處斷點與把治理前置的思路傳統數據治理的流程看起來相當完整定標準、落標準、查質量三步走完似乎就該見效?？烧媛涞刂笮Ч蛘凵踔脸霈F“治理項目做完第二年問題照舊”的尷尬局面。原因不復雜這套流程是圍繞存量數據設計的而企業(yè)的數據資產每天都在增量。4.1 三大件與定標、落標、稽核老流程是怎么轉的傳統數據治理包括三大件數據標準、元數據管理、數據質量。流程從制定數據標準開始簡稱定標接著通過元數據的采集、注冊、掃描、發(fā)布把數據標準與數據模型連接起來這個過程叫落標最后用數據標準關聯的質量稽核規(guī)則對數據模型進行稽查發(fā)現問題、形成質量報告、推動業(yè)務部門整改提升數據質量。這條鏈路本身是成立的問題是它的作用方向。它更強調對業(yè)務系統存量數據的治理對長效機制建設重視不夠于是企業(yè)只能靠一個又一個治理項目維持效果。項目一停新產生的數據繼續(xù)臟幾個月后又是一輪。更麻煩的是它的成本結構。傳統治理是一個反向治理的過程并不融入數據生產的整個過程與數據開發(fā)、建模、運維、安全等環(huán)節(jié)都存在脫節(jié)。要做治理就得改造現有系統和流程改造成本高到讓很多企業(yè)望而卻步。4.2 六處斷點治理為什么總在事后救火第一處斷點在質量與開發(fā)之間。質量稽核本是用來確認開發(fā)結果符合業(yè)務邏輯的但規(guī)則覆蓋率只有 10%規(guī)則設置還各不相同。開發(fā)人員對業(yè)務的理解深度參差很多人沒法從開發(fā)結果上判斷數據是否滿足業(yè)務要求問題只好留到使用方那里暴露。久而久之業(yè)務方對開發(fā)團隊的數據不再信任。第二處斷點在標準與建模之間。數據標準通常包括標準規(guī)劃、標準制定、標準發(fā)布、標準執(zhí)行、標準檢查五項內容企業(yè)也會結合行業(yè)情況制定自己的標準。但標準定完之后怎么讓開發(fā)人員貫徹是另一回事。標準與建模脫節(jié)結果就是表的命名不統一、字段命名各行其是數據的理解成本和管理成本一起上升。第三處斷點在元數據與開發(fā)之間。數據開發(fā)時任務之間是有依賴的下游要等上游實例產出?，F網環(huán)境中任務數量動輒上千甚至上萬靠手工配置依賴關系極其考驗熟練度也極易出錯。一旦漏配任務空跑下游數據就是錯的。要自動推薦上游任務靠的正是元數據里的血緣關系而元數據沒打通時這件事就只能靠人肉。第四處斷點在元數據與運維之間。大量任務同時異常時值班人員需要知道處理先后順序讓重要任務優(yōu)先恢復也需要知道故障源頭在哪因為很多故障是上游異常傳導下來的。這兩件事都離不開元數據脫節(jié)之后運維只能憑經驗猜。第五處斷點在標準與安全之間。數據權限怎么設、密級怎么定、哪些數據要脫敏、哪些人可以被賦權依據都來自數據標準。標準與安全脫節(jié)企業(yè)對數據安全的管理就失去了抓手變成盲目審批。第六處斷點更宏觀是治理與增量之間的斷點。前面五處都指向同一個現象治理動作發(fā)生在數據已經生產出來之后。數據生產是持續(xù)的治理是陣發(fā)的兩頭節(jié)奏對不上治理永遠在追趕。4.3 煙囪式開發(fā)與平臺割裂斷在架構上的那一半斷點不只在流程里也長在架構上。早期數倉建設多由各業(yè)務部門自行維護沒有上升到組織架構層面規(guī)劃各部門內部都有零散的數據開發(fā)和分析人員服務本團隊需求。結果就是一堆分裂的小數倉。這種煙囪式開發(fā)的典型癥狀有三個。一是指標口徑不一致缺少統一的規(guī)范建模標準各部門存在大量名稱相同但口徑不同的指標業(yè)務人員看數據像猜謎。二是重復開發(fā)超過 40% 的表沒有分層開發(fā)人員接到新需求時無法高效復用已有的表超過 50% 的任務直接讀取原始數據每次需求都從頭再來。三是資源浪費系統里沉淀了大量長期無人訪問的重復數據。平臺層面的割裂再補一刀。大型企業(yè)的 IT 架構里常有關系型數據庫、分析型數據庫、數據湖等多套系統各自從后端到前端相互獨立、緊耦合開發(fā)系統臃腫、建設效率低、響應業(yè)務慢。要建統一的大數據開發(fā)與治理平臺就得面對歷史數據和歷史任務的遷移成本還得承擔遷移過程中的數據遺失風險以及重新培訓人員的成本。這些顧慮堆在一起足以讓企業(yè)對平臺化望而卻步。4.4 把治理前置開發(fā)治理一體化的四個階段既然斷點都在“事后”解法就是把治理動作往前挪。開發(fā)治理一體化的核心思想是把數據治理的過程融入數據開發(fā)的全生命周期遵循“先設計、后開發(fā)先標準、后建?！钡脑瓌t追求“規(guī)范即設計、設計即開發(fā)、開發(fā)即治理”。整個流程分四個階段。需求階段先做業(yè)務調研和數據調研。表級調研包括表范圍、存儲位置、中英文名、來源系統、優(yōu)先級、更新方式、業(yè)務場景、數據條數和增量條數目的是據此制定接入計劃確認哪些數據要實時接入、哪些走離線。字段級調研包括表結構、字段類型格式、樣例數據、有值行、有值率、是否需要制定標準、是否已掛載標準、值域分布這些信息直接決定后續(xù)標準化的效率。同時把指標、模型分層、主題做初步梳理為設計鋪路。設計階段是最重的一塊包含標準設計和指標設計。標準規(guī)劃可以收集現行標準也可以結合自身業(yè)務梳理規(guī)劃時的優(yōu)先順序應圍繞業(yè)務協同、監(jiān)管合規(guī)、數據共享開放、數據分析應用來排非交互、非公開的數據標準化優(yōu)先級可以放低。標準制定的三件套是詞根、標準字典、數據元詞根是企業(yè)維護的標準詞庫確保含義相同的中文詞翻譯成相同的英文名制定過程是拆解、去重、定義最終確定中文全稱、英文全稱和英文簡稱標準字典維護枚舉字段的標準代碼集比如物料類型代碼中 5 代表采購物料、10 代表制造物料各業(yè)務系統枚舉范圍不同需要在中臺層統一數據元是用一組屬性描述定義、標識、表示和允許值的數據單元需要定義中文名稱、英文名稱、數據類型、數據格式、值域。三者制定完成后整包發(fā)布審核通過即可在全系統使用。指標設計要把業(yè)務指標拆成原子指標、派生指標和復合指標同時明確數據域、業(yè)務過程、修飾詞、時間周期。舉個具體例子“最近 1 天 PC 端支付金額”拆開就是業(yè)務過程為支付修飾詞為 PC 端時間周期為最近 1 天原子指標為支付金額指標域歸到訂單域。指標要經過新建、注冊、確權、治理、發(fā)布幾個環(huán)節(jié)使用中發(fā)現問題可提治理工單業(yè)務口徑問題派給業(yè)務部門技術口徑問題派給開發(fā)部門修完重新發(fā)布并生成新版本。模型設計階段定義維表、事實表和模型關系把標準落進去導入標準后系統自動填寫字段名稱、字段描述、數據元、數據字典建表時還能用標準化標簽把字段綁定到既定的維度和指標上保證指標和維度不會被各建各的。開發(fā)階段把設計好的模型做物理實現與技術元數據血緣、質量、調度任務信息和標準規(guī)范結合。字段類型這塊有個容易被忽略的細節(jié)不同行業(yè)對精度要求不同金融行業(yè)對小數點后保留位數和制造業(yè)的要求就不一樣因此需要一份可自定義的字段類型標準映射規(guī)范保證入湖后字段類型統一也減少開發(fā)手動調整類型帶來的失誤。安全也在這一層落地。數據標準里包含業(yè)務敏感數據的對象和屬性把敏感類型、安全等級、脫敏規(guī)則、脫敏算法以及脫敏配置同數據元關聯就能快速生成字段級的加密或脫敏規(guī)則。模型設計引用了某個數據元數據傳輸環(huán)節(jié)就按該數據元的規(guī)則做靜態(tài)脫敏離線開發(fā)環(huán)節(jié)按規(guī)則做動態(tài)脫敏還能針對不同用戶下發(fā)不同策略表本身也根據關聯數據元的密級獲得分類分級依據走對應的資源申請流程。交付階段把加工好的數據以可視化配置的方式開發(fā)成服務數據消費方在 API 集市查看調用說明并申請使用權權限、熔斷、限流這些機制在這里兜住交付質量與安全。平臺還會統計 API 調用情況結合治理模塊盤點 API 資產把閑置 API 和異常 API 挖出來通知負責人整頓。模型質量也需要可量化的標尺?？鐚右檬菬焽枋介_發(fā)的典型征兆直接繞過公共層去引用原始層短期省事長期把分層結構徹底沖垮。用跨層引用率這類指標盯著它才能知道治理是不是真的在生效。-- 跨層引用率統計直接引用 ods 層、跳過 dwd/dim 層的下游表數量 -- 數值越接近 0 說明分層建模執(zhí)行得越好持續(xù)上升說明又有人繞過公共層抄近道了 SELECT COUNT(DISTINCT downstream_table) AS cross_layer_table_cnt, -- p a hrefhttps://download.csdn.net/download/hedongsu/87740974 stylecolor:#ec7500;font-size:14px; 本文還有配套的精品資源點擊獲取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p