數(shù)據(jù)治理

• 元數(shù)據(jù)管理
• 數(shù)據(jù)質(zhì)量
• 數(shù)據(jù)模型
• 安全管理
• 主數(shù)據(jù)管理
• 數(shù)據(jù)生命周期

數(shù)據(jù)治理(Data Governance)，是一套持續(xù)改善管理機制，通常包括了數(shù)據(jù)架構(gòu)組織、數(shù)據(jù)模型、政策及體系制定、技術(shù)工具、數(shù)據(jù)標(biāo)準(zhǔn)、數(shù)據(jù)質(zhì)量、影響度分析、作業(yè)流程、監(jiān)督及考核流程等內(nèi)容。

統(tǒng)一流程參考模型

為什么要治理

• 不論是金融行業(yè)、通訊行業(yè)、地產(chǎn)行業(yè)、傳統(tǒng)制造業(yè)以及農(nóng)業(yè)，其信息化的發(fā)展基本都遵循了“諾蘭模型”。筆者認(rèn)為企業(yè)信息化大致經(jīng)歷了初期的煙囪式系統(tǒng)建設(shè)、中期的集成式系統(tǒng)建設(shè)和后期的數(shù)據(jù)管理式系統(tǒng)建設(shè)三個大的階段，可以說是一個先建設(shè)后治理的過程。

數(shù)據(jù)質(zhì)量層次不齊

“數(shù)據(jù)資產(chǎn)化”的概念已經(jīng)被大多數(shù)人理解和接受。不論是企業(yè)、政府還是其他組織機構(gòu)，對于的數(shù)據(jù)資產(chǎn)的管理越來越重視。然而，數(shù)據(jù)并不等于資產(chǎn)，也就是說不是所有數(shù)據(jù)都是數(shù)據(jù)資產(chǎn)，數(shù)據(jù)中也有垃圾數(shù)據(jù)。我們需要治理的是能夠為企業(yè)創(chuàng)造價值的數(shù)據(jù)資產(chǎn)，而不是全部數(shù)據(jù)。

數(shù)據(jù)交換和共享困難

• 企業(yè)信息化建設(shè)初期缺乏整體的信息化規(guī)劃，系統(tǒng)建設(shè)大多都是以業(yè)務(wù)部門驅(qū)動的單體架構(gòu)系統(tǒng)或套裝軟件，數(shù)據(jù)分散在這些架構(gòu)不統(tǒng)一、開發(fā)語言不一致、數(shù)據(jù)庫多樣化的系統(tǒng)中，甚至還有大量的數(shù)據(jù)存放在員工的個人電腦中，導(dǎo)致在企業(yè)內(nèi)部形成了一個個的“信息孤島”。
• 這些“孤島”之間缺乏有效的連接通道，數(shù)據(jù)不能互聯(lián)互通，不能按照用戶的指令進行有意義的交流，數(shù)據(jù)的價值不能充分發(fā)揮。只有聯(lián)通數(shù)據(jù)，消除這些“信息孤島”，才能實現(xiàn)數(shù)據(jù)驅(qū)動業(yè)務(wù)、數(shù)據(jù)驅(qū)動管理，才能真正釋放數(shù)據(jù)價值。

打通各個業(yè)務(wù)線之間的數(shù)據(jù)建設(shè)，很多公司都是統(tǒng)一建設(shè)

缺乏有效的管理機制

• 許多企業(yè)都認(rèn)識到了數(shù)據(jù)的重要性，并嘗試通過生產(chǎn)系統(tǒng)的業(yè)務(wù)流來控制數(shù)據(jù)流，但由于缺乏有效的管理機制和某些人為的因素，在數(shù)據(jù)流轉(zhuǎn)過程中，存在數(shù)據(jù)維護錯誤、數(shù)據(jù)重復(fù)、數(shù)據(jù)不一致、數(shù)據(jù)不完整的情況，導(dǎo)致了產(chǎn)生了大量的垃圾數(shù)據(jù)。數(shù)據(jù)產(chǎn)權(quán)不明確，管理職責(zé)混亂，管理和使用流程不清晰，是造成數(shù)據(jù)質(zhì)量問題的重要因素。

存在數(shù)據(jù)安全隱患

• 近年來，隨著大數(shù)據(jù)的發(fā)展，諸如此類的數(shù)據(jù)安全事件多不勝數(shù)。數(shù)據(jù)資產(chǎn)管理上，正在由傳統(tǒng)分散式的人工管理向計算機集中化管理方向發(fā)展，數(shù)據(jù)的安全問題愈來愈受到人們的關(guān)注。

發(fā)現(xiàn)問題嚴(yán)重滯后

影響不清晰

• 數(shù)據(jù)變更對下游的影響不清晰，無法確認(rèn)影響范圍

DMBOK的數(shù)據(jù)治理框架

• DMBOK是由數(shù)據(jù)管理協(xié)會(DAMA)編撰的關(guān)于數(shù)據(jù)管理的專業(yè)書籍，一本DAMA 數(shù)據(jù)管理辭典。對于企業(yè)數(shù)據(jù)治理體系的建設(shè)有一定的指導(dǎo)性

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

數(shù)據(jù)控制：在數(shù)據(jù)管理和使用層面之上進行規(guī)劃、監(jiān)督和控制。

數(shù)據(jù)架構(gòu)管理：定義數(shù)據(jù)資產(chǎn)管理藍(lán)圖。

數(shù)據(jù)開發(fā)：數(shù)據(jù)的分析、設(shè)計、實施、測試、部署、維護等工作。

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

數(shù)據(jù)安全管理：確保隱私、保密性和適當(dāng)?shù)脑L問權(quán)限等。

數(shù)據(jù)質(zhì)量管理：定義、監(jiān)測和提高數(shù)據(jù)質(zhì)量。

參考數(shù)據(jù)和主數(shù)據(jù)管理：管理數(shù)據(jù)的黃金版本和副本。

數(shù)據(jù)倉庫和商務(wù)智能管理：實現(xiàn)報告和分析。

文件和內(nèi)容管理：管理數(shù)據(jù)庫以外的數(shù)據(jù)

元數(shù)據(jù)管理：元數(shù)據(jù)的整合、控制以及提供元數(shù)據(jù)。

數(shù)倉治理

• 節(jié)約機器資源(存在很多廢棄的邏輯和表，占用了大量的存儲資源和計算資源)
• 節(jié)約人力資源(降低了開發(fā)和維護的成本)
• 數(shù)據(jù)資產(chǎn)沉淀

這個是一個長期的工作，類似于代碼重構(gòu)

治理的分類

粗治理

• 臨時表的處理
• 無訪問信息的表(統(tǒng)一管理元數(shù)據(jù)和adhoc 以及調(diào)度)
• 無下游依賴的表(得有調(diào)度系統(tǒng))

細(xì)治理

專項性質(zhì)的治理方案，主要針對有人負(fù)責(zé)的項目

• 運行時間長的任務(wù)
• 存儲空間空間過大的表

數(shù)據(jù)源治理

據(jù)源，顧名思義就是數(shù)據(jù)的來源，互聯(lián)網(wǎng)公司的數(shù)據(jù)來源隨著公司的規(guī)模擴張而呈遞增趨勢，同時自不同的業(yè)務(wù)源，比如埋點采集，客戶上報等。

數(shù)據(jù)源管理

• 配置了大量的重復(fù)數(shù)據(jù)源

數(shù)據(jù)源監(jiān)控

• 可以監(jiān)控數(shù)據(jù)量和數(shù)據(jù)質(zhì)量

數(shù)據(jù)同步

• 數(shù)據(jù)同步是指不同數(shù)據(jù)存儲系統(tǒng)之間要進行數(shù)據(jù)遷移，比如在hdfs上，大多業(yè)務(wù)和應(yīng)用因為效率的原因不可以直接從HDFS上獲取數(shù)據(jù)，因此需要將hdfs上匯總后的數(shù)據(jù)同步至其他的存儲系統(tǒng)，比如mysql
• sqoop可以做到這一點，但是Sqoop太過繁重，而且不管數(shù)據(jù)量大小，都需要啟動MapReduce來執(zhí)行，而且需要Hadoop集群的每臺機器都能訪問業(yè)務(wù)數(shù)據(jù)庫;阿里開源的dataX是一個很好的解決方案。

數(shù)倉模型治理

數(shù)據(jù)劃分及命名空間約定

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

• 根據(jù)業(yè)務(wù)劃分?jǐn)?shù)據(jù)并約定命名，建議針對業(yè)務(wù)名稱結(jié)合數(shù)據(jù)層次約定相關(guān)命名的英文縮寫，這樣可以給后續(xù)數(shù)據(jù)開發(fā)過程中，對項目空間、表、字段等命名做為重要參照。
• 按業(yè)務(wù)劃分：命名時按主要的業(yè)務(wù)劃分，以指導(dǎo)物理模型的劃分原則、命名原則及使用的ODS project。例如，按業(yè)務(wù)定義英文縮寫，阿里的“淘寶”英文縮寫可以定義為“tb”。
• 按數(shù)據(jù)域劃分：命名時按照CDM層的數(shù)據(jù)進行數(shù)據(jù)域劃分，以便有效地對數(shù)據(jù)進行管理，以及指導(dǎo)數(shù)據(jù)表的命名。例如，“交易”數(shù)據(jù)的英文縮寫可定義為“trd”。-** 按業(yè)務(wù)過程劃分**：當(dāng)一個數(shù)據(jù)域由多個業(yè)務(wù)過程組成時，命名時可以按業(yè)務(wù)流程劃分。業(yè)務(wù)過程是從數(shù)據(jù)分析角度看客觀存在的或者抽象的業(yè)務(wù)行為動作。例如，交易數(shù)據(jù)域中的“退款”這個業(yè)務(wù)過程的英文縮寫可約定命名為“rfd_ent”。
• 表命名規(guī)范需清晰、一致，表命名需易于下游的理解和使用
• 下線表的統(tǒng)一命名

常規(guī)表的命名

分層前綴[dwd|dws|ads|bi]_業(yè)務(wù)域_主題域_XXX_粒度

業(yè)務(wù)域、主題域我們都可以用詞根的方式枚舉清楚，不斷完善，粒度也是同樣的，主要的是時間粒度、日、月、年、周等，使用詞根定義好簡稱。

中間表

• 中間表一般出現(xiàn)在Job中，是Job中臨時存儲的中間數(shù)據(jù)的表，中間表的作用域只限于當(dāng)前Job執(zhí)行過程中，Job一旦執(zhí)行完成，該中間表的使命就完成了，是可以刪除的(按照自己公司的場景自由選擇，以前公司會保留幾天的中間表數(shù)據(jù)，用來排查問題)。

統(tǒng)一指標(biāo)和字段命名

• 相同的字段在不同表中的字段名必須相同。
• 核心指標(biāo)要進行邏輯收口以及在元數(shù)據(jù)上進行維護

公共處理邏輯下沉及單一

• 底層公用的處理邏輯應(yīng)該在數(shù)據(jù)調(diào)度依賴的底層進行封裝與實現(xiàn)，不要讓公用的處理邏輯暴露給應(yīng)用層實現(xiàn)，不要讓公共邏輯在多處同時存在。

核心模型與擴展模型分離

• 建立核心模型與擴展模型體系，核心模型包括的字段支持常用核心的業(yè)務(wù)，擴展模型包括的字段支持個性化或是少量應(yīng)用的需要。在必須讓核心模型與擴展模型做關(guān)聯(lián)時，不能讓擴展字段過度侵入核心模型，以免破壞了核心模型的架構(gòu)簡潔性與可維護性。

層次調(diào)用約定

• 應(yīng)用層應(yīng)優(yōu)先調(diào)用公共層數(shù)據(jù)，必須存在中間層數(shù)據(jù)，不允許應(yīng)用層跨過中間層從ODS層重復(fù)加工數(shù)據(jù)。
• 一方面，中間層團隊?wèi)?yīng)該積極了解應(yīng)用層數(shù)據(jù)的建設(shè)需求，將公用的數(shù)據(jù)沉淀到公共層，為其他團隊提供數(shù)據(jù)服務(wù)
• 另一方面，應(yīng)用層團隊也應(yīng)積極配合中間層團隊進行持續(xù)的數(shù)據(jù)公共建設(shè)的改造。必須避免出現(xiàn)過度的引用ODS層、不合理的數(shù)據(jù)復(fù)制以及子集合冗余。

垃圾的數(shù)倉就會出現(xiàn)大量的跨層調(diào)用，所以可以通過跨層調(diào)用ods 表率來衡量數(shù)倉的建設(shè)

組合原則

• 將維度所描述業(yè)務(wù)相關(guān)性強的字段在一個物理維表實現(xiàn)。

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

數(shù)據(jù)拆分

• 對于維度屬性過多，涉及源較多的維度表(例如會員表)，可以做適當(dāng)拆分

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

核心表

• 拆分為核心表和擴展表。核心表相對字段較少，刷新產(chǎn)出時間較早，優(yōu)先使用。擴展表字段較多，且可以冗余核心表部分字段，刷新產(chǎn)出時間較晚，適合數(shù)據(jù)分析人員使用。

數(shù)據(jù)冗余

• 數(shù)據(jù)記錄數(shù)較大的維度表(例如商品表)，可以適當(dāng)冗余一些子集合，以減少下游掃描數(shù)據(jù)量

sql 規(guī)范

任務(wù)注釋

• name: 任務(wù)名和表名保持一致
• description：任務(wù)描述，該任務(wù)的主要內(nèi)容
• target：目標(biāo)表名，一般一個任務(wù)只輸出一個目標(biāo)表
• author：創(chuàng)建者，和創(chuàng)建日期，
• modify：內(nèi)容變更記錄，變更人，變更日期，變更原因 ，這個從版本控制中也可以找到，但是這些這里更直觀一些。

sql 模板

• sql 的寫法，sql 結(jié)構(gòu)

數(shù)據(jù)服務(wù)治理

報表治理

接口治理

上下游約定

• 由于數(shù)倉的特性和定位，它就需要強依賴上游的業(yè)務(wù)系統(tǒng)，當(dāng)然也會有一些下游系統(tǒng)，所以定好上下游的規(guī)范，變更的通知機制是非常有必要的。

上游約定

• 對于數(shù)倉來說，最重要的就是數(shù)據(jù)了，數(shù)倉中的數(shù)據(jù)，主要來源是業(yè)務(wù)系統(tǒng)，就是公司各種業(yè)務(wù)數(shù)據(jù)，所以數(shù)倉需要不斷的將業(yè)務(wù)系統(tǒng)數(shù)據(jù)同步到自身平臺來，所以一旦上游業(yè)務(wù)系統(tǒng)發(fā)生變化，數(shù)倉也要同步變化，不然，這種同步操作很可能失敗。

表結(jié)構(gòu)變更

• 上游的表結(jié)構(gòu)經(jīng)常會發(fā)生變化，新增字段、修改字段、刪除字段(除非真的不用這個字段了，通常會選擇標(biāo)識為棄用)。
• 表結(jié)構(gòu)最好要維護清楚，表名、字段名、字段類型、字段描述，都整理清楚，不使用的字段要么刪除，要么備注好，當(dāng)業(yè)務(wù)頻繁發(fā)生變化或者迭代優(yōu)化的時候，很容易出現(xiàn)，我寫了半天的代碼，最后發(fā)現(xiàn)表用的不對，字段用的不對，這就尷尬了。
• 對于這種變化，人工處理的話，就是手動在數(shù)倉對應(yīng)的表中增加、修改字段，然后修改同步任務(wù);這個最好可以搞成自動化的，比如，自動監(jiān)控上游表結(jié)構(gòu)的變更，變化后，自動去修改數(shù)倉中的表結(jié)構(gòu)，自動修改同步任務(wù)。

枚舉值

• 業(yè)務(wù)系統(tǒng)中會有很多的常量，用來標(biāo)識一些狀態(tài)或者類型，這種值經(jīng)常會新增，數(shù)倉中會對這些值做些處理，比如轉(zhuǎn)換成維度，會翻譯成對應(yīng)的中文，而實際上這種映射關(guān)系，我們是不知道的，只有業(yè)務(wù)開發(fā)才知道，所以最好可以讓他們維護一張枚舉值表，我們?nèi)ネ竭@張表。

create_time & update_time

• 正常來說，create_time，當(dāng)這條記錄插入后，就不會再變了，但是某種情況下，哈哈，開發(fā)同學(xué)會去更新它;update_time，當(dāng)這條記錄變化后，這個時間也要變，有的開發(fā)同學(xué)不去更新它
• 所以在做增量操作的時候，一定和開發(fā)說好這兩個字段的定義和使用場景。

is_delete & is_valid

• 有些場景下，我們需要刪除某些數(shù)據(jù)，一般不會物理刪除，會通過一個字段來做邏輯刪除，請和開發(fā)同學(xué)溝通好，使用固定的一個字段，并確認(rèn)該字段雙方的理解是一致的，不然后面又很多坑

下游約定

對于數(shù)倉來說，一般的郵件、報表、可視化平臺都是下游，所以當(dāng)我們在數(shù)倉中進行某些重構(gòu)、優(yōu)化操作的時候，也需要通知他們。

主要就是對數(shù)倉模型做好維護，表的使用場景、字段描述等。對上游的要求，自己也要做好，因為自己也是上游。

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

其實對整個數(shù)倉而言，我們關(guān)注的就三個點，準(zhǔn)確性、時效性、穩(wěn)定性

面試官說這些都是一些原則，比較虛，有沒有可衡量的指標(biāo)?就是一個數(shù)據(jù)倉庫建好了，用這些指標(biāo)評價它好不好，有不好的要指出來，指導(dǎo)它改進。

指標(biāo)項

• 失敗的離線任務(wù)個數(shù)
• 沒有按時完成的任務(wù)個數(shù)
• ODS 同步超時的任務(wù)個數(shù)

數(shù)據(jù)準(zhǔn)確性

對外的報表提供反饋機制，對數(shù)據(jù)準(zhǔn)確性進行跟蹤

數(shù)檢平臺的整個平臺的數(shù)據(jù)準(zhǔn)確性進行監(jiān)控(到后期能不能利用機器學(xué)習(xí)去監(jiān)控，否則你要定制大量的規(guī)則)

時效性

• 針對數(shù)倉的對外提供的數(shù)據(jù)能否滿足失效性的需求
• 監(jiān)控數(shù)倉任務(wù)的運行時長進行優(yōu)化
• 能否快速響應(yīng)業(yè)務(wù)的數(shù)據(jù)需求

覆蓋性

我們主要指的是對數(shù)據(jù)域的覆蓋情況

建構(gòu)層次清晰

• 縱向的數(shù)據(jù)分層，橫向的主題劃分，業(yè)務(wù)過程劃分，讓整個層次結(jié)構(gòu)清晰易理解

數(shù)據(jù)準(zhǔn)確一致

• 定義一致性指標(biāo)、統(tǒng)一命名規(guī)范、統(tǒng)一業(yè)務(wù)含義、統(tǒng)一計算口徑，專業(yè)的建模團隊

性能指標(biāo)

• 通過統(tǒng)一的規(guī)劃設(shè)計，選用合理的數(shù)據(jù)模型，清晰統(tǒng)一的規(guī)范，并且考慮數(shù)據(jù)的使用場景，使得整體性能更好

需要持續(xù)不斷的業(yè)務(wù)邏輯重構(gòu)，是整體的sql 水平上升，提倡優(yōu)化精神

成本指標(biāo)

• 避免煙囪式的重復(fù)建設(shè)，節(jié)約計算、存儲、人力成本。

易用性指標(biāo)

• 復(fù)雜邏輯前置，降低業(yè)務(wù)方的使用門檻

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

需求響速度

數(shù)倉建設(shè)的好，底層設(shè)施完善，報表開發(fā)人員就可以快速響應(yīng)業(yè)務(wù)方的需求，跟上業(yè)務(wù)方快速試錯、快速嘗試的節(jié)奏

穩(wěn)定性

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

總結(jié)

數(shù)據(jù)治理和代碼重構(gòu)一樣，是一個慢活，但是它不能不做，因為數(shù)據(jù)治理可以提高整個數(shù)倉的管理效率，從而更好的服務(wù)業(yè)務(wù)

數(shù)據(jù)治理需要一些數(shù)據(jù)去指導(dǎo)，同理它的成果需要從數(shù)據(jù)方面去衡量，所以在整個過程中需要數(shù)據(jù)去證明它的價值與意義

數(shù)倉本身也需要自身的指標(biāo)去衡量，我們可以通過數(shù)據(jù)治理，使得數(shù)倉的指標(biāo)得到改善，這樣我們也可以證明數(shù)據(jù)治理的意義。