【推薦】五分鐘搞懂

資料治理

資料治理是一個通過一系列資訊相關的過程來實作決策權和職責分工的系統，這些過程按照達成共識的模型來執行，該模型描述了誰（Who）能根據什麼資訊，在什麼時間（When）和情況（Where）下，用什麼方法（How），采取什麼行動（What）。

資料治理的最終目标

提升資料的價值，資料治理非常必要，是企業實作數字戰略的基礎，它是一個管理體系，包括組織、制度、流程、工具。

資料治理的本質

解決組織、制度、流程關于資料的問題，解決資料認責，資料可信，資料一緻的問題，提供平台、工具、方法

資料治理範圍的确定

1. 資料治理的藍圖規劃及其目标
2. 确定主題域及主題域邊界（此處需要業務調研）
3. 成立相應的組織、制度、流程
4. 對資料平台進行調研選型

❝六大領域（資料架構、資料标準、資料品質、資料安全、主資料、中繼資料）四大保障（管理組織、管理制度、管理流程、管理文化）一大平台❞

資料成熟度評估、資料品質報告

輸出物：藍圖以及目标，政策（資料模型管理政策、資料品質管理政策、中繼資料管理正常、主資料管理政策、資料服務管理政策）、流程（資料标準管控流程、是資料品質管理流程、資料需求流程、資料資産下架流程、主資料管控流程）、資料 owner 的釋出，組織以及流程制度的成立與釋出；

資料資産的盤點

1. 明确資料資産盤點的粒度

主題域分組、主題域、業務對象、邏輯 s 實體、屬性

1. 業務調研、系統調研

調研企業所有系統情況，收集所有系統名稱，建設目标，系統類型劃分，使用者，使用者來源和規模。

1. 業務流程的梳理

梳理業務與業務之間的流程關系，業務流程涉及的關鍵主體與動作，輸入輸出情況；

1. 業務流程的分解

識别各業務環節涉及的人、事、物， 輸入、輸出、元件和資料；輸出業務流程圖；根據梳理好的業務流程圖，轉換成對應的資料流圖；

5.資料标準的梳理

對于資料按照主資料、參考資料、交易資料、分析資料進行分類，并梳理出資料的技術标準和業務标準；補充和整理完整的資料字典；

• 落地範圍：哪些标準需要落地 涉及到哪些 IT 系統
• 差異分析：與現有資料的差異 差異有多大
• 影響分析：對哪些系統産生影響 産生什麼樣的影響 影響是否可控
• 落地方案：組織架構 人員分工 考核制度 監管方案
• 落地執行：釋出标準 标準映射 常态化
• 效果評估：跟蹤評估落地的效果 哪些事做對了 哪些事需要改進

1. 資料的分級分類 資料分類分級，根據行業标準和特點對于資料資産進行分類，将資料資産劃分為公開、内部、敏感等不同的敏感等級；

• 輸出物：資料資産目錄，資料 CRUD 矩陣，資料标準，資料治理政策

資料治理實施方法論

資料治理的目的：一般是為了提高資料品質，以便于資料可以更好地服務于業務，對業務進行賦能 資料品質常見的問題：完整性、一緻性、準确性、及時性、有效性 資料品質的根源：業務系統的變更、開發運維人員的參差不齊、手工錄入。

資料治理的方法論

1. 主資料治理：

指企業内一緻并共享的業務主體。特點：準确性、一緻性、內建性、共享性/可重用性和高價值。主資料治理一般會作為單獨的項目來做，MDM 系統。一般是從源端進行管控治理

• 主資料的主要問題：

關鍵資訊孤島，資料分布在多個孤島，不能跨組織傳播 組織内不能就一個主資料源達成一緻 資料品質問題引發的業務流程和交易的失敗 不正确或丢失資料造成合規性和績效管理的問題 決策者做出基于錯誤資料的錯誤決定

• 主資料解決方案：

• 資料轉換映射
• 由應用系統承擔主資料管理功能
• 集中管控

1. 交易資料治理

交易資料一般可以先在資料平台先行治理，之後再在源端進行管控治理

1. 參考資料治理

參考資料一般可以先在資料平台先行治理，之後再在源端進行管控治理

1. 分析資料治理

分析資料一般可以在資料平台進行治理

1. 資料模型、資料标準的治理

資料模型、資料标準一般可以先在資料平台先行治理，之後再在源端進行管控治理

1. 中繼資料治理

是企業資料資産管理的基礎，是關于“資料的資料”，例如資料類型、資料定義、資料關系等，相當于資料表格中的表頭資訊，是一個相對客觀的概念。中繼資料一般可以先在資料中台先行治理，之後再在源端進行管控治理

1. 資料資産成本的治理

• 資産上線容易下線難
• 低價值的資料資産
• 資産的煙囪式開發
• 資料的傾斜
• 資産的生命周期
• 排程周期的合理性
• 任務參數的合理性

「如何優化」

• 資料資産的全鍊路血緣
• 針對未使用的資産，進行下架處理
• 針對低價值，使用頻率低的資産，按照應用粒度評估應用是否還有存在的必要，可進行下架政策，以及優化模型
• 針對高價值的，評估計算資源與存儲資源，以及優化模型

1. 資料資産安全合規

• 資料資産進行分級分類
• 資料資産進行加密
• 資料資産進行權限管控
• 資料使用進行流程申請
• 對關鍵資料制定跟蹤制度

• 遵從相關法律法規

  輸出物：資料平台的搭建；資料門戶的建立；

「一般來說第一階段不建議全面落标，強調按需建設，"以用促治，以用促建"」

群裡前幾天也有關于資料治理的讨論，我感覺說的非常好，現摘錄出來，與君共勉。在這裡特别感謝蘇奕嘉，南知唔知，李奇峰，幻楓~~~

❝

從以下三個角度出發,xdm 先思考思考：

資料治理分為哪些方面？資料治理上下遊關系和界限如何明确？資料治理的具體技術落地方向？假如上遊未遵守治理規則，下遊要做哪些防範措施和技術手段以盡可能保證自己資料治理？❞

「技術層面-李奇峰總結」

1. 資料分類：首先是針對各資料進行歸類，根據業務需求劃分成不同的類别，然後将資料表依次歸類。
2. 時間字段治理：在所有資料中添加統一名稱的時間字段，依次記錄資料發生時間、最後更新時間、插入時間等。
3. 資料過濾：在入庫時如果碰到無法解析的錯誤資料，或者關鍵字段缺失的資料，則直接丢棄。
4. 資料去重：如果在入庫時發現庫中存在相同的資料，則會将新資料直接覆寫舊資料。
5. 資料抽取與合并：将各個類别的資料的指定字段抽取到一個正式庫中，統一格式，去除多樣字段，标注來源資訊。同時在抽取過程中，将屬于同一事件的多個日志進行合并，儲存至合并庫中。
6. 資料關聯：資料入庫後，各個資料之間關聯性較弱，在開發過程中需要重複調用資料接口進行資料擷取。于是在資料入庫時或入庫後，根據主外鍵 ID、相同含義字段進行關聯，将關聯字段更新至源資料中。

「業務層面-蘇奕嘉總結」

我覺得從架構而言，我個人認為需要幾部分：

1. 字段規則治理：主要是和業務方對齊原子名額的含義，如有多條線，需要一起對齊口徑，隻有業務方都承認和了解接受了原子名額口徑，數倉才好進一步處理，舉例：淨收益到底是【營銷額-成本（包含各種費用）】還是【營銷額-成本（隻包含成品本身的成本）】，不同的業務線可能有不同的定義，如供應鍊和營銷鍊注重的就不一樣
2. 資料源治理：資料源即上遊資料，上遊資料多而繁雜，可細分為不同資料類型進行劃域治理，類似主題模組化和資料域的概念，比如訂單、客戶、供應鍊、财務等等，不同的域有不同的強規則體系，這個體系可形成一套完備的探查系統，比如資料源探查體系：訂單{null 值:是否有 null 值,長度:訂單号是否滿足規則,金額:是否有營銷額無淨銷額……}，客戶{OneID:是否辨別,手機号:是否為空,收貨位址:是否滿足規則……}。不同的資料域有着不同的字段定義标準和探查規則标準，如果沒有探查階段，那麼資料治理就是睜眼瞎
3. 資料品質回報體系：很多時候，上遊資料有了問題，下遊溝通其實是一個很難的事情，比如上遊為了滿足自己業務需求，私自改了數值/字段名/表名等等，下遊會發生依賴錯誤/資料值錯誤等情況，如果要求上遊怎樣做，其實很不靠譜，别人不太會聽你的，那麼就需要從更高一個次元解決，一是成立 PMO 組織，由更進階别的 Leader 組織，内部有資料部門，業務部門和測試部門，資料部門發現問題，交由測試部門進行總結回報，定期給出品質報告，由測試部門監督業務部門完成整改，可用作計入績效考核等方式進行管控，沒有裁判的賽道是虛假的、不完整的。
4. 資料災備規則和系統：沒有人管控的了别人的做法和想法，那麼就要做好資料部門本身的災備規則和系統，比如從小處講，ODS 接入後在 DW 清洗時要注意 NULL 值處理，不管這個字段以前有沒有 NULL 值，從大處講，就是完善資料部門自己的代碼書寫規範，每次發版需要嚴格 CodeReview，如果從系統角度出發，比如第三方，就做一個第三方統一接入系統，從源頭規範化資料格式，比如業務線，就采取業務中台模式，資料所有資料統一處理統一管理，當然，這些扯開都是很大的話題，以後再講

「業務層面-幻楓總結」

1. 名額體系的建立，加上緯度屬性的內建，構成資料字典，
2. 資料源有公約規則限制的情況下建立明細資料的的資料監控，資料遠沒有公約規則的，按照基礎的資料标準和業務過程進行資料探查，然後按照資料展現情況進行資料監控，
3. 就是資料治理的組織架構，要由上層牽頭下遊處理，且要有管理體系，比如限制規範更改要有特定的流程，
4. 就是數倉内部根據下遊的需求，制定清晰轉換規則，要有相應的操作留檔

「思想層面-南知總結」

資料權限（安全），中繼資料管理（技術 or 業務，資産），資料品質（上下遊延遲，故障快速感覺和修複） 治理是很大的概念，從我經曆過或做過的，可以下手的點就是品質、安全、資産數倉是數倉，治理是治理。要明确的分開，凡涉及到口徑、資料源、ETL processing 的，應該算數倉方法論或數倉規範或落地平台化的方式方法

資料治理與其說是一個技術活，其實更是一個業務活，建議不要 it 部門主導，最好是營銷或者财務部門主導，it 部門提供技術支援和解決方案，這裡幾點原因，供君參考

優勢一、首先不要讓别人有什麼資料問題都是 it 的事（這點很重要），

優勢二、資料有問題，财務核算會很難，他會是直接受益者，或者說是痛點機關

優勢三、資料治理，會牽扯到很多業務的改造，it 話語權一般不足

優勢四、财務負責 更容易展現價值 而不是 it 閉門造車

問題與思考

1. 資料治理屬于一個資料基礎性工作，但是又需要業務部門的深度參與，如何展現對業務部門的價值？
2. 資料治理需要業務的深度參與，業務部門具體需要做哪些工作？
3. 資料治理本質上是對業務源頭進行一個限制，那資料認責這塊，是如何進行劃分的？