數據倉庫管控準則

數據倉庫管控準則我干數據倉庫相關的工作快十年了，見過太多企業一開始投入大量資源搭數據倉庫，想把分散的數據攢起來做分析、支撐業務決策，結果用個兩三年就變成了沒人敢用的“數據垃圾堆”：同一個指標三個部門出三個數，找一張表要問三四個老員工，冷數據占著高額存儲費舍不得刪，出了數據問題沒人認賬，甚至還出過敏感數據泄露的風險。其實絕大多數問題都不是技術能力不夠，而是從一開始就沒建立清晰的管控規則，大家隨心所欲用數據，最后自然亂成一團。這篇準則是我和身邊同行踩了無數坑總結出來的，不管是剛搭倉庫的新企業還是已經陷入混亂的老項目，照著做都能理順數據倉庫的秩序，讓數據真正變成可用的資產。1總則總則是整個管控體系的基礎，所有后續規則都要圍繞這個基礎展開，不能跑偏。1.1管控目的數據倉庫管控的核心目的不是給大家添堵、設門檻，而是四個核心目標：第一是保證數據可信，讓所有人用數據的時候都能確認這個數的口徑、來源是對的，不用反復扯皮核對；第二是提升使用效率，統一標準后找數據、用數據的時間能節省一半以上；第三是控制成本，避免冗余存儲、無效計算浪費企業資源；第四是守住安全合規底線，避免出現數據泄露、違規使用的風險。1.2適用范圍本準則適用于企業內部所有數據倉庫場景，不管是自建私有數據倉庫，還是依托云服務搭建的公共數據倉庫，覆蓋所有接入數據倉庫的數據集、所有訪問使用數據倉庫的人員，包括開發人員、數據分析人員、業務人員、管理層，所有人都要遵守。1.3核心管控原則整個管控體系要堅持三個不變的原則，所有規則調整都不能違背這三點：1.3.1誰產出誰負責原則任何接入數據倉庫的數據，都必須有明確的歸屬負責人，從口徑定義、質量維護到變更下線，全流程都由負責人牽頭負責，不能出現數據沒人管的情況。這真的是踩坑踩出來的經驗，我之前待過的一家公司，曾經出現過運營臨時傳了一張活動數據，用完就沒人管了，半年后財務做核算用了這張錯的數據，虧了幾十萬都找不到責任人，就是因為一開始沒定負責人。1.3.2統一標準原則所有數據的命名、口徑、分層都要走統一標準，不允許任何部門或個人自搞一套，同一個指標只能有一個官方口徑，避免出現“數出多門”的問題。1.3.3最小夠用原則不管是權限還是存儲，都只給滿足需求的最小范圍，不開放超額權限，不保留無用數據，從根源上降低風險和成本。明確了管控的基本方向和原則之后，接下來就要落實到數據從進入到退出的全生命周期每個環節，這是管控的核心抓手，每個環節都有明確的操作準則。2數據全生命周期管控準則數據從接入到下線，每個環節都要管控到位，不能有漏洞。2.1數據接入準入管控接入是第一道關口，把不好這關，后面再怎么整理都費勁。2.1.1接入申請審核任何數據要接入公共數據倉庫，都必須提前提交正式申請，申請里要寫清楚數據的來源、業務用途、更新頻率、敏感級別、負責人聯系方式，沒有申請或者申請信息不全的，一律不允許接入。很多人覺得這個流程麻煩，其實就是擋掉了很多無效的測試數據、臨時數據，避免這些垃圾數據占空間還誤導人。我就見過有人把本地調試的測試數據不小心上傳到公共倉庫，結果給高管做季度匯報的時候用錯了數，差點出大問題，要是有準入審核，這種事根本不會發生。2.1.2元數據規范對齊申請通過之后，接入之前必須按照統一規范整理元數據：命名必須符合“業務域_主題域_分層_表描述”的格式，禁止用無意義的數字編號、拼音簡寫或者模糊名稱，比如用戶業務域用戶主題的DWD層明細信息表，就得命名成uc_user_dwd_base_info，不能叫user123或者我的新表；每個字段都必須寫清楚清晰的中文注釋，說明這個字段代表什么業務含義、取值規則是什么，不允許留空注釋或者寫只有自己看得懂的注釋。2.1.3接入完成驗收數據接入完成后，負責人要自己先做驗收，再提交管控組抽檢，驗收要核對接入的數據量和源端是不是一致，核心字段的空值率、格式是不是符合要求，核心指標的計算結果是不是符合業務預期，驗收合格才能正式對外開放使用，不合格的打回重新調整。2.2數據存儲管控接入完成進入存儲階段，存儲管控做好了能省很多錢，也能提升查詢效率。2.2.1分層存儲規范必須嚴格按照數據倉庫的分層規則存數據，ODS層只能放原始接入的源數據，不允許做修改，保留原始數據可回溯；DWD層存放清洗脫敏后的明細數據，做統一的維度對齊；DWS層存放按照主題匯總的輕度聚合數據，供各個分析場景使用；應用層只存放面向特定應用的結果數據，不允許跨層亂存數據，更不允許把原始敏感數據直接放在應用層給業務人員隨意訪問。2.2.2冷熱數據分級存儲按照數據的使用頻率劃分冷熱，最近半年經常被訪問的熱數據存放在高性能存儲介質，半年到兩年內偶爾訪問的溫數據存放在中等成本存儲，超過兩年幾乎沒人訪問的冷數據，要做離線歸檔，挪到低成本存儲里，既不丟數據又能節省成本。我之前那家公司，三年前的老活動數據還占著高性能SSD存儲，每個月光存儲費就多花十幾萬，就是因為沒做冷熱分級，這個教訓真的記一輩子。2.2.3冗余數據清理同一個邏輯的數據只允許保留一份權威版本，不允許不同部門各自存儲相同邏輯的數據，要是發現重復冗余的數據，管控組要通知負責人統一合并下線，避免大家不知道該用哪個。2.3數據使用管控使用是大家接觸最多的環節，規則清晰能避免很多矛盾。2.3.1權限按流程申請所有訪問數據倉庫的權限都必須按流程申請，說明申請數據的用途，審批通過之后才能開通，不允許私自共享賬號、借用權限，也不允許超范圍申請權限。很多人覺得給全庫權限用著方便，我見過剛畢業的開發不小心跑了錯的語句，刪了半張公共表，全公司的報表都斷了，找都找不到原因，所以權限管控真不是形式主義。2.3.2口徑一致性要求所有對外發布、用于決策分析的數據，必須使用官方統一的口徑，不允許私自修改口徑計算數據之后對外發布，如果對現有口徑有異議，可以找口徑負責人提修改建議，討論通過更新官方口徑之后才能用新的，不能自己搞一套私下用。好多部門之間因為指標數對不上吵架，90%都是因為有人不用統一口徑自己算，這個規則定死了能省好多溝通成本。2.3.3敏感數據導出管控敏感數據導出必須提前申請，留下導出記錄，不允許私自把敏感數據導出到數據倉庫之外的地方，更不允許傳給企業外部的人員。2.4數據下線管控不用的數據要及時下線，別留著占地方，下線也要按規則來，不能坑了正在用的人。2.4.1下線提前通知要下線任何公共數據，都必須提前至少半個月發通知，通知到所有已經申請使用這個數據的用戶和相關部門，給大家留足時間遷移切換，不能說下就下，人家報表跑著一半突然斷了，耽誤正事。2.4.2下線前備份下線之前必須把數據完整備份到離線存儲里，保留足夠長的時間，萬一后續需要回溯還能找回來，確認沒問題了再正式刪除在線存儲的數據。2.4.3下線后標記更新數據下線之后，要立刻在元數據平臺標記清楚這個數據已經下線，說明下線時間和原因，避免新的用戶還過來找這個數據，浪費時間。全流程的操作規則定清楚了，還得明確誰來做這些事，權責分清楚了規則才能落地，不然就是一紙空文。3角色與權責管控準則所有參與數據倉庫的人員都要明確自己的權責，各負其責才能把管控做好。3.1數據倉庫管控組管控組是整個管控體系的組織者，主要負責三件事：第一是制定、更新管控準則，根據業務和技術的變化調整規則，解答大家關于管控的疑問；第二是審核各類接入、下線、權限申請，做日常的合規巡檢，發現違規使用及時糾正；第三是做好服務，定期收集大家的痛點，優化流程，給大家做培訓，我一直覺得管控組不是“抓人的”，是給大家服務的，幫大家少踩坑，少出問題，不能把自己變成流程的絆腳石。3.2數據負責人每一個公共數據集、每一個官方指標都必須有明確的數據負責人，一般由對應業務域或者開發團隊的人擔任，權責也很清晰：第一是負責定義數據口徑，更新維護元數據信息，解答其他用戶關于這個數據的疑問；第二是負責監控數據質量，數據出問題了要第一時間修復；第三是數據要變更或者下線的時候，負責提前通知所有使用者，對接遷移工作。3.3數據使用者所有用數據的人也有需要遵守的權責：第一是嚴格按照管控流程申請數據和權限，不違規使用數據；第二是使用過程中發現數據有問題，要及時反饋給數據負責人，不能自己改完湊合用也不說，坑了后面用的人；第三是保管好自己的賬號權限，不轉借，不共享，避免出現賬號亂用的問題。權責分清楚之后，還有一條不能碰的紅線，就是安全和合規，這是所有管控的底線。4安全與合規管控準則安全合規出問題，整個數據倉庫甚至企業都會受影響，所以必須嚴格遵守。4.1敏感數據分級管控所有數據按照敏感程度分成四個等級：公開級、內部級、敏感級、高度敏感級，不同級別對應不同的管控要求，公開級可以隨便訪問，內部級只能企業內部訪問，敏感級需要專門審批，高度敏感級比如用戶的隱私信息，除非有合規要求的特定場景，否則不允許存入公共數據倉庫，就算要存也必須做全加密處理，只開放必要的查詢權限，不允許導出明文。4.2堅持權限最小夠用原則給權限的時候永遠只給滿足工作需求的最小范圍，比如做運營活動分析的，只需要看到用戶的群體特征，不需要拿到具體的個人身份證號、手機號，那就絕對不給這些字段的權限，從根源上降低泄露風險。4.3全流程審計留痕所有對數據倉庫的訪問、修改、導出操作，都必須留下完整的審計日志，日志至少保留規定的時長，出了問題可以直接追溯到具體的操作人、操作時間，避免出了問題找不到責任人。4.4符合監管要求所有數據的收集、存儲、使用都必須符合國家的相關監管規定，不允許違規收集用戶數據，不允許超出約定范圍使用數據，更不允許私自把數據對外提供，現在監管要求越來越嚴，這個底線絕對不能碰，出了問題不管是企業還是個人都擔不起。管控不是一勞永逸的，定好規則就不管了肯定不行，得持續優化調整，適應業務的變化。5運維與持續優化管控準則數據倉庫是跟著業務成長的，管控規則也要跟著一起變。5.1日常運行監控管控組要做好日常的監控，每天檢查數據同步有沒有失敗，數據質量有沒有觸發告警，存儲和資源夠不夠用，出了問題要第一時間處理，不能等用戶找過來了才發現問題，最好是把問題解決在用戶發現之前。5.2定期數據盤點每隔半年要做一次全數據倉庫的盤點，梳理清楚哪些數據沒人用，哪些數據重復了，哪些數據質量問題很多，統一做清理優化，把沒用的數據下線，把重復的數據合并，把質量差的數據修復，一直保持數據倉庫的整潔。5.3管控規則迭代準則不是定下來就永遠不變的，每隔一年要收集一次所有用戶的意見，看看哪里流程太繁瑣，哪里有漏洞，哪里不符合現在的業務情況，及時調整優化。比如我之前待的公司，一開始接入申請要走三層審批，非敏感數據也要等兩三天，后來大家提了意見，改成非敏感數據只要數據負責人審批就行，效率一下子提上來了，規則就是要解決問題，不能抱著老規矩不變。5.4持續培訓賦能新員工入職要做管控規則的培訓，規則更新了也要給所有相關人員做培訓，讓大家都知道該怎么做，哪里找申請入口，找誰解決問題，不能大家都不知道規則，最后管控就成了只有管控組自己知道的擺設。總結總的來說，數據倉庫管控的核心，從來不是為了限制大家用數據，反而是為了讓大家能更放心、更高效的用好數據。我見