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