本文目錄

數據治理

統一流程參考模型

為什么要治理

DMBOK的數據治理框架

數倉治理

治理的分類

數據源治理

數倉模型治理

數據服務治理

上下游約定

數倉評價(如何評價一個數據倉庫的好壞)

數據準確性

時效性

覆蓋性

建構層次清晰

數據準確一致

性能指標

成本指標

易用性指標

需求響速度

穩定性

總結

知識星球

數據治理

元數據管理 數據質量 數據模型 安全管理 主數據管理 數據生命周期

數據治理（Data Governance），是一套持續改善管理機制，通常包括了數據架構組織、數據模型、政策及體系制定、技術工具、數據標準、數據質量、影響度分析、作業流程、監督及考核流程等內容。

統一流程參考模型 image-20201205183104040為什么要治理 image-20201205183119801不論是金融行業、通訊行業、地產行業、傳統制造業以及農業，其信息化的發展基本都遵循了“諾蘭模型”。筆者認為企業信息化大致經歷了初期的煙囪式系統建設、中期的集成式系統建設和后期的數據管理式系統建設三個大的階段，可以說是一個先建設后治理的過程。 數據質量層次不齊 “數據資產化”的概念已經被大多數人理解和接受。不論是企業、政府還是其他組織機構，對于的數據資產的管理越來越重視。然而，數據并不等于資產，也就是說不是所有數據都是數據資產，數據中也有垃圾數據。我們需要治理的是能夠為企業創造價值的數據資產，而不是全部數據。 數據交換和共享困難 企業信息化建設初期缺乏整體的信息化規劃，系統建設大多都是以業務部門驅動的單體架構系統或套裝軟件，數據分散在這些架構不統一、開發語言不一致、數據庫多樣化的系統中，甚至還有大量的數據存放在員工的個人電腦中，導致在企業內部形成了一個個的“信息孤島”。 這些“孤島”之間缺乏有效的連接通道，數據不能互聯互通，不能按照用戶的指令進行有意義的交流，數據的價值不能充分發揮。只有聯通數據，消除這些“信息孤島”，才能實現數據驅動業務、數據驅動管理，才能真正釋放數據價值。

打通各個業務線之間的數據建設，很多公司都是統一建設

缺乏有效的管理機制 許多企業都認識到了數據的重要性，并嘗試通過生產系統的業務流來控制數據流，但由于缺乏有效的管理機制和某些人為的因素，在數據流轉過程中，存在數據維護錯誤、數據重復、數據不一致、數據不完整的情況，導致了產生了大量的垃圾數據。數據產權不明確，管理職責混亂，管理和使用流程不清晰，是造成數據質量問題的重要因素。 存在數據安全隱患 近年來，隨著大數據的發展，諸如此類的數據安全事件多不勝數。數據資產管理上，正在由傳統分散式的人工管理向計算機集中化管理方向發展，數據的安全問題愈來愈受到人們的關注。 發現問題嚴重滯后 影響不清晰 數據變更對下游的影響不清晰，無法確認影響范圍 DMBOK的數據治理框架 DMBOK是由數據管理協會（DAMA）編撰的關于數據管理的專業書籍，一本DAMA 數據管理辭典。對于企業數據治理體系的建設有一定的指導性

注：DAMA 是數據管理協會的簡稱，是一個全球性數據管理和業務專業志愿人士組成的非營利協會，致力于數據管理的研究和實踐。

image-20201205183235954

數據控制：在數據管理和使用層面之上進行規劃、監督和控制。

數據架構管理：定義數據資產管理藍圖。

數據開發：數據的分析、設計、實施、測試、部署、維護等工作。

數據操作管理：提供從數據獲取到清除的技術支持。

數據安全管理：確保隱私、保密性和適當的訪問權限等。

數據質量管理：定義、監測和提高數據質量。

參考數據和主數據管理：管理數據的黃金版本和副本。

數據倉庫和商務智能管理：實現報告和分析。

文件和內容管理：管理數據庫以外的數據

元數據管理：元數據的整合、控制以及提供元數據。

數倉治理 節約機器資源(存在很多廢棄的邏輯和表，占用了大量的存儲資源和計算資源) 節約人力資源(降低了開發和維護的成本) 數據資產沉淀

這個是一個長期的工作，類似于代碼重構

治理的分類 粗治理 臨時表的處理 無訪問信息的表(統一管理元數據和adhoc 以及調度) 無下游依賴的表(得有調度系統) 細治理

專項性質的治理方案，主要針對有人負責的項目

運行時間長的任務 存儲空間空間過大的表 數據源治理 據源，顧名思義就是數據的來源，互聯網公司的數據來源隨著公司的規模擴張而呈遞增趨勢，同時自不同的業務源，比如埋點采集，客戶上報等。 數據源管理 配置了大量的重復數據源 數據源監控 可以監控數據量和數據質量 數據同步 數據同步是指不同數據存儲系統之間要進行數據遷移，比如在hdfs上，大多業務和應用因為效率的原因不可以直接從HDFS上獲取數據，因此需要將hdfs上匯總后的數據同步至其他的存儲系統，比如mysql sqoop可以做到這一點，但是Sqoop太過繁重，而且不管數據量大小，都需要啟動MapReduce來執行，而且需要Hadoop集群的每臺機器都能訪問業務數據庫；阿里開源的dataX是一個很好的解決方案。 數倉模型治理 數據劃分及命名空間約定

表的命名就涉及到數據域的劃分，因為表的命名需要將數據域囊括進去

根據業務劃分數據并約定命名，建議針對業務名稱結合數據層次約定相關命名的英文縮寫，這樣可以給后續數據開發過程中，對項目空間、表、字段等命名做為重要參照。 按業務劃分：命名時按主要的業務劃分，以指導物理模型的劃分原則、命名原則及使用的ODS project。例如，按業務定義英文縮寫，阿里的“淘寶”英文縮寫可以定義為“tb”。 按數據域劃分：命名時按照CDM層的數據進行數據域劃分，以便有效地對數據進行管理，以及指導數據表的命名。例如，“交易”數據的英文縮寫可定義為“trd”。-** 按業務過程劃分**：當一個數據域由多個業務過程組成時，命名時可以按業務流程劃分。業務過程是從數據分析角度看客觀存在的或者抽象的業務行為動作。例如，交易數據域中的“退款”這個業務過程的英文縮寫可約定命名為“rfd_ent”。 表命名規范需清晰、一致，表命名需易于下游的理解和使用 下線表的統一命名 常規表的命名 分層前綴[dwd|dws|ads|bi]_業務域_主題域_XXX_粒度 業務域、主題域我們都可以用詞根的方式枚舉清楚，不斷完善，粒度也是同樣的，主要的是時間粒度、日、月、年、周等，使用詞根定義好簡稱。 中間表 中間表一般出現在Job中，是Job中臨時存儲的中間數據的表，中間表的作用域只限于當前Job執行過程中，Job一旦執行完成，該中間表的使命就完成了，是可以刪除的（按照自己公司的場景自由選擇，以前公司會保留幾天的中間表數據，用來排查問題）。 統一指標和字段命名 相同的字段在不同表中的字段名必須相同。 核心指標要進行邏輯收口以及在元數據上進行維護 公共處理邏輯下沉及單一 底層公用的處理邏輯應該在數據調度依賴的底層進行封裝與實現，不要讓公用的處理邏輯暴露給應用層實現，不要讓公共邏輯在多處同時存在。 核心模型與擴展模型分離 建立核心模型與擴展模型體系，核心模型包括的字段支持常用核心的業務，擴展模型包括的字段支持個性化或是少量應用的需要。在必須讓核心模型與擴展模型做關聯時，不能讓擴展字段過度侵入核心模型，以免破壞了核心模型的架構簡潔性與可維護性。 層次調用約定 應用層應優先調用公共層數據，必須存在中間層數據，不允許應用層跨過中間層從ODS層重復加工數據。 一方面，中間層團隊應該積極了解應用層數據的建設需求，將公用的數據沉淀到公共層，為其他團隊提供數據服務 另一方面，應用層團隊也應積極配合中間層團隊進行持續的數據公共建設的改造。必須避免出現過度的引用ODS層、不合理的數據復制以及子集合冗余。

垃圾的數倉就會出現大量的跨層調用，所以可以通過跨層調用ods 表率來衡量數倉的建設

組合原則 將維度所描述業務相關性強的字段在一個物理維表實現。

相關性強是指經常需要一起查詢或進行報表展現、兩個維度屬性間是否存在天然的關系等。例如，商品基本屬性和所屬品牌。

數據拆分 對于維度屬性過多，涉及源較多的維度表（例如會員表），可以做適當拆分

數據的水平和垂直拆分是按照訪問熱度分布和數據表非空數據值、零數據值在行列二維空間上分布情況進行劃分的。

核心表 拆分為核心表和擴展表。核心表相對字段較少，刷新產出時間較早，優先使用。擴展表字段較多，且可以冗余核心表部分字段，刷新產出時間較晚，適合數據分析人員使用。 數據冗余 數據記錄數較大的維度表（例如商品表），可以適當冗余一些子集合，以減少下游掃描數據量 sql 規范 任務注釋 name: 任務名和表名保持一致 description：任務描述，該任務的主要內容 target：目標表名，一般一個任務只輸出一個目標表 author：創建者，和創建日期， modify：內容變更記錄，變更人，變更日期，變更原因 ，這個從版本控制中也可以找到，但是這些這里更直觀一些。 sql 模板 sql 的寫法，sql 結構 數據服務治理 報表治理 接口治理 上下游約定 由于數倉的特性和定位，它就需要強依賴上游的業務系統，當然也會有一些下游系統，所以定好上下游的規范，變更的通知機制是非常有必要的。 上游約定 對于數倉來說，最重要的就是數據了，數倉中的數據，主要來源是業務系統，就是公司各種業務數據，所以數倉需要不斷的將業務系統數據同步到自身平臺來，所以一旦上游業務系統發生變化，數倉也要同步變化，不然，這種同步操作很可能失敗。 表結構變更 上游的表結構經常會發生變化，新增字段、修改字段、刪除字段（除非真的不用這個字段了，通常會選擇標識為棄用）。 表結構最好要維護清楚，表名、字段名、字段類型、字段描述，都整理清楚，不使用的字段要么刪除，要么備注好，當業務頻繁發生變化或者迭代優化的時候，很容易出現，我寫了半天的代碼，最后發現表用的不對，字段用的不對，這就尷尬了。 對于這種變化，人工處理的話，就是手動在數倉對應的表中增加、修改字段，然后修改同步任務；這個最好可以搞成自動化的，比如，自動監控上游表結構的變更，變化后，自動去修改數倉中的表結構，自動修改同步任務。 枚舉值 業務系統中會有很多的常量，用來標識一些狀態或者類型，這種值經常會新增，數倉中會對這些值做些處理，比如轉換成維度，會翻譯成對應的中文，而實際上這種映射關系，我們是不知道的，只有業務開發才知道，所以最好可以讓他們維護一張枚舉值表，我們去同步這張表。 create_time & update_time 正常來說，create_time，當這條記錄插入后，就不會再變了，但是某種情況下，哈哈，開發同學會去更新它；update_time，當這條記錄變化后，這個時間也要變，有的開發同學不去更新它 所以在做增量操作的時候，一定和開發說好這兩個字段的定義和使用場景。 is_delete & is_valid 有些場景下，我們需要刪除某些數據，一般不會物理刪除，會通過一個字段來做邏輯刪除，請和開發同學溝通好，使用固定的一個字段，并確認該字段雙方的理解是一致的，不然后面又很多坑 下游約定 對于數倉來說，一般的郵件、報表、可視化平臺都是下游，所以當我們在數倉中進行某些重構、優化操作的時候，也需要通知他們。 主要就是對數倉模型做好維護，表的使用場景、字段描述等。對上游的要求，自己也要做好，因為自己也是上游。 數倉評價(如何評價一個數據倉庫的好壞) image-20210905100559380

其實對整個數倉而言，我們關注的就三個點，準確性、時效性、穩定性

面試官說這些都是一些原則，比較虛，有沒有可衡量的指標？就是一個數據倉庫建好了，用這些指標評價它好不好，有不好的要指出來，指導它改進。

指標項

失敗的離線任務個數 沒有按時完成的任務個數 ODS 同步超時的任務個數 數據準確性 對外的報表提供反饋機制，對數據準確性進行跟蹤 數檢平臺的整個平臺的數據準確性進行監控(到后期能不能利用機器學習去監控，否則你要定制大量的規則) 時效性 針對數倉的對外提供的數據能否滿足失效性的需求 監控數倉任務的運行時長進行優化 能否快速響應業務的數據需求 覆蓋性

我們主要指的是對數據域的覆蓋情況

建構層次清晰 縱向的數據分層，橫向的主題劃分，業務過程劃分，讓整個層次結構清晰易理解 數據準確一致 定義一致性指標、統一命名規范、統一業務含義、統一計算口徑，專業的建模團隊 性能指標 通過統一的規劃設計，選用合理的數據模型，清晰統一的規范，并且考慮數據的使用場景，使得整體性能更好

需要持續不斷的業務邏輯重構，是整體的sql 水平上升，提倡優化精神

成本指標 避免煙囪式的重復建設，節約計算、存儲、人力成本。 易用性指標 復雜邏輯前置，降低業務方的使用門檻

通過冗余維度和事實表，進行公共計算邏輯下沉，明細與匯總共存等為業務提供靈活性

需求響速度

數倉建設的好，底層設施完善，報表開發人員就可以快速響應業務方的需求，跟上業務方快速試錯、快速嘗試的節奏

穩定性

穩定性影響了時效性，也就是決定了我們的數據能不能按時產出，衡量穩定性的方式，我們可以使用三個9，或者四個9，甚至是用每天失敗的任務數除以總的任務數，我們的主要目標是得出一個相對合理的指標，從而不斷的去優化它。

總結 數據治理和代碼重構一樣，是一個慢活，但是它不能不做，因為數據治理可以提高整個數倉的管理效率，從而更好的服務業務 數據治理需要一些數據去指導，同理它的成果需要從數據方面去衡量，所以在整個過程中需要數據去證明它的價值與意義 數倉本身也需要自身的指標去衡量，我們可以通過數據治理，使得數倉的指標得到改善，這樣我們也可以證明數據治理的意義。