1 數據治理的背景

在數據建設過程中，業務人員和數據開發人員在日常使用數據的過程中還是能感受到一些痛點的，主要的表現：

第一，數據資產缺乏盤點。當前核心系統的主要數據已經采集到數據倉庫，但是在日常的業務分析中經常需要向業務系統了解需要用到的數據在哪里。總得來看對數據資產還是缺乏整體盤點，公司主要有哪些數據，都分布在哪些系統中，哪些數據已經采集到數倉，哪些還沒有入庫，還有待進一步梳理。

第二，數據標準化建設不足。數據標準會貫穿數據管理的全流程，雖然我們制定了一系列規范文檔、制度文檔、流程文檔等，但有了標準并不代表數據標準化已經落實了，像指標數據的標準化、主數據的標準化等方面還需要進一步的提升。

第三，數據質量問題。數據質量是數據的生命線，差的數據質量嚴重影響數據分析的結論，有的可能對決策產生誤導，如臟數據、維度數據缺失或變更等一系列問題，都需要進行治理，比如掃描信息缺失，導致運單路由軌跡不準確；數據維度值變化，統計某個渠道業務量陡增或驟降。

第四，數據模型待完善。目前已經建設了一批公共寬表，但是隨著業務發展，有些時候業務方需求比較急，開發直接從基礎明細表取數，導致寬表復用度降低；為了追求開發效率，團隊內部也存在煙囪式開發現象，導致一些 ST 層共有邏輯沒有下沉。

第五，數據安全問題。公司還會積累大量客戶的地址、姓名、電話等信息，這些信息都需要進行有效的安全管理。此外，國家也出臺了《數據安全法》、《個人信息保護法》等法律法規，需要我們做好數據分級分類和對數據合規安全的訪問，同時保障數據保密性、完整性和可用性。

而數據開發人員如何解決以上問題成為關鍵，也是數據治理工作的核心。

2 數據治理期望實現的目標

數據治理的范圍非常廣，貫穿數倉的整個生命周期，從數據產生->數據接入->數據存儲->數據處理->數據輸出->數據展示，每個階段都需要質量治理，評價維度包括完整性、規范性、一致性、準確性、唯一性、關聯性等。

最終，數據治理工作最主要期望能夠實現的目標是：

1. 提升數據質量

2. 解決數據孤島問題，實現數據匯聚聯接

3. 掌握數據資產現狀

4. 保障數據安全合規

5. 逐漸釋放業務價值，如在降本增效、提升客戶滿意度等方面發揮作用

3 數據治理體系

數據治理體系包括數據模型治理（規范治理、復用度治理）、架構治理（數據分層治理、數據流向治理）、元數據治理、數據安全治理、數據生命周期治理、數據質量管理以及數據體系治理等內容。

3.1 數據模型治理

大部分行業的數據都具備如下特征：

l 數據生命周期比較長

核心業務過程生命周期短則 1 天，長則 3-5 天，異常過程可能會更長。財務類周期結算長，涉及政策財經類數據計算回刷時間 1～3 個月；

l 業務流程復雜

核心業務過程從業務流程起始點到業務流程終點，流程較為復雜；

l 對象多數據大

數據由不同業務對象等多角色產生，且非常依賴他們操作的規范性；

l 數據精細化運營

當前各大行業競爭都非常激烈，在此背景下更需要精細化運營，因此對數據依賴非常強。公司通過數據化運營進行成本管控，運單時效管控，服務質量管控，已成為公司日常運營常態，因此對數據準確性，時效性要求很高。

同時，隨著業務持續發展，項目也在快速迭代。數據建設不規范等方面的原因導致了復用性不高、時效不穩定等，自然而然也會引起資源危機等問題。

為此可以制定了一整套的方案，主要包括三方面

第一，制定規范。制定諸如開發規范、分層使用規范，并嚴格要求各類數據開發和使用團隊遵守；

第二，過程管控。以需求為驅動，將設計、開發、上線等數據建設各個階段進行過程管控；

第三，模型分級。根據應用的重要程度來反推、梳理哪些是重要的模型和應用，將重要性高的模型和應用納入重點治理范圍，重點關注他們的復用性、實效性。

3.1.1 規范治理

規范是數倉建設的保障。為了避免出現指標重復建設和數據質量差的情況，統一按照最詳細、可落地的方法進行規范建設。

3.1.1.1詞根規范

詞根是維度和指標管理的基礎，劃分為普通詞根與專有詞根，提高詞根的易用性和關聯性。

普通詞根：描述事物的最小單元體，如：交易-trade。

專有詞根：具備約定成俗或行業專屬的描述體，如：美元-USD。

3.1.1.2表命名規范

通用規范

l 表名、字段名采用一個下劃線分隔詞根（示例：clienttype->client_type）。

l 每部分使用小寫英文單詞，屬于通用字段的必須滿足通用字段信息的定義。

l 表名、字段名需以字母為開頭。

l 表名、字段名最長不超過64個英文字符。

l 優先使用詞根中已有關鍵字（數倉標準配置中的詞根管理），定期Review新增命名的不合理性。

l 在表名自定義部分禁止采用非標準的縮寫。

l 表命名規則:表名稱 類型 + 業務主題 + 子主題 + 表含義 + 存儲格式 + 更新頻率 +結尾，如下圖所示：

統一的表命名規范

3.1.1.3指標命名規范

結合指標的特性以及詞根管理規范，將指標進行結構化處理。

l 基礎指標詞根，即所有指標必須包含以下基礎詞根：

l 業務修飾詞，用于描述業務場景的詞匯，例如trade-交易。

l 日期修飾詞，用于修飾業務發生的時間區間。

l 聚合修飾詞，對結果進行聚集操作。

l 基礎指標，單一的業務修飾詞+基礎指標詞根構建基礎指標 ，例如：交易金額-trade_amt。

l 派生指標，多修飾詞+基礎指標詞根構建派生指標。派生指標繼承基礎指標的特性，例如：安裝門店數量-install_poi_cnt。

l 普通指標命名規范，與字段命名規范一致，由詞匯轉換即可以。

3.1.2 復用度治理

復用度治理方面，主要包括三塊：

第一，流程規范的制定。我們會制定相關規范來要求數據參與者都遵守。通過制定規范，應用開發團隊和數倉團隊進行分工，且在業務需求評審環節要求數倉團隊介入，可以更早地評估是否需要設計相關模型來支持應用團隊的數據開發；

第二，過程線上管控。在數據使用、模型設計、任務上線等環節都進行線上管控，由leader審批把關；

第三，核心數據識別。最主要是識別出四類核心數據，最主要關注核心模型和核心應用，并對這類數據我們重點關注、重點保障，優先保障其核心鏈路上數據的準確性和及時性。

在數據復用度治理方面還需要關注時效、引用度、需求響應及時性之間的平衡問題。我們不能為了提高模型的復用度就任意的增加維度、指標，否則可能會導致下游應用產出障礙的問題。也不能說某個指標下游引用不多就增加到寬表中來，一定要考慮平衡性的問題。

除此之外，我們還需要考慮響應的及時性。在流程上我們希望盡量做到規范，希望應用層都引用模型、寬表的數據。在實際工作中，有時為了保證“業務需求第一”的原則，有可能允許應用層先從明細層取數進行開發，模型同步進行迭代優化，后續再讓應用層把需求切換回來。

3.2 架構治理

3.2.1 數據分層

優秀可靠的數倉體系，往往需要清晰的數據分層結構，即要保證數據層的穩定又要屏蔽對下游的影響，并且要避免鏈路過長，一般的分層架構如下：

但是在對數倉分層架構做治理的過程中，同時也要結合公司業務場景和組織架構合理涉及數倉分層架構，才能保證數倉分層架構能夠匹配公司業務發展，更好地賦能業務。

3.2.2 數據流向

穩定業務按照標準的數據流向進行開發，即ODS-->DWD-->DWA-->APP。非穩定業務或探索性需求，可以遵循ODS->DWD->APP或者ODS->DWD->DWT->APP兩個模型數據流。在保障了數據鏈路的合理性之后，又在此基礎上確認了模型分層引用原則：

正常流向：ODS>DWD->DWT->DWA->APP，當出現ODS >DWD->DWA->APP這種關系時，說明主題域未覆蓋全。應將DWD數據落到DWT中，對于使用頻度非常低的表允許DWD->DWA。盡量避免出現DWA寬表中使用DWD又使用（該DWD所歸屬主題域）DWT的表。同一主題域內對于DWT生成DWT的表，原則上要盡量避免，否則會影響ETL的效率。DWT、DWA和APP中禁止直接使用ODS的表， ODS的表只能被DWD引用。禁止出現反向依賴，例如DWT的表依賴DWA的表。

3.3 元數據治理

我們的數倉中有上萬張表，無論是對數據開發者還是業務使用方，都會面臨無從下手的情況。他們在日常使用過程中的痛點最主要可以歸納為有什么、在哪里、怎么用三類。

比如一個運單，有收件人、發件人、運載軌跡、費用等各種信息，但具體有哪些表就不是很清楚了。在實際的工作中，分析師也經常會問有沒有哪塊的數據，在哪里之類等等。哪怕是找到表之后，也會疑惑數據是如何加工的，如果要用的話有哪些限制條件等等問題。

基于對現狀的梳理及現階段要對元數據信息管理的目標。

元數據可分為技術元數據和業務元數據：

技術元數據為開發和管理數據倉庫的IT 人員使用，它描述了與數據倉庫開發、管理和維護相關的數據，包括數據源信息、數據轉換描述、數據倉庫模型、數據清洗與更新規則、數據映射和訪問權限等。

常見的技術元數據有：

存儲元數據：如表、字段、分區等信息。

運行元數據：如大數據平臺上所有作業運行等信息：類似于 Hive Job 日志，包括作業類型、實例名稱、輸入輸出、 SQL 、運行參數、執行時間，執行引擎等。

數據開發平臺中數據同步、計算任務、任務調度等信息：包括數據同步的輸入輸出表和字段，以及同步任務本身的節點信息：計算任務主要有輸入輸出、任務本身的節點信息 任務調度主要有任務的依賴類型、依賴關系等，以及不同類型調度任務的運行日志等。

數據質量和運維相關元數據：如任務監控、運維報警、數據質量、故障等信息，包括任務監控運行日志、告警配置及運行日志、故障信息等。

業務元數據為管理層和業務分析人員服務，從業務角度描述數據，包括商務術語、數據倉庫中有什么數據、數據的位置和數據的可用性等，幫助業務人員更好地理解數據倉庫中哪些數據是可用的以及如何使用。

常見的業務元數據有維度及屬性(包括維度編碼，字段類型，創建人，創建時間，狀態等)、業務過程、指標(包含指標名稱,指標編碼，業務口徑，指標類型，責任人，創建時間，狀態，sql等)，安全等級，計算邏輯等的規范化定義，用于更好地管理和使用數據。數據應用元數據，如數據報表、數據產品等的配置和運行元數據。

元數據不僅定義了數據倉庫中數據的模式、來源、抽取和轉換規則等，而且是整個數據倉庫系統運行的基礎，元數據把數據倉庫系統中各個松散的組件聯系起來，組成了一個有機的整體。

元數據治理主要解決三個問題：

通過建立相應的組織、流程和工具，推動業務標準的落地實施，實現指標的規范定義，消除指標認知的歧義；

基于業務現狀和未來的演進方式，對業務模型進行抽象，制定清晰的主題、業務過程和分析方向，構建完備的技術元數據，對物理模型進行準確完善的描述，并打通技術元數據與業務元數據的關系，對物理模型進行完備的刻畫；

通過元數據建設，為使用數據提效，解決“找數、理解數、評估”難題以及“取數、數據可視化”等難題。

3.4 數據安全治理

數據安全是企業數據建設必不可少的一環，我們的數據都存儲在大大小小的磁盤中，對外提供不同程度的查詢和計算服務。

需要定時對數據進行核查、敏感字段加密、訪問權限控制，確保數據能夠被安全地使用。

圍繞數據安全標準，首先要有數據的分級、分類標準，確保數據在上線前有著準確的密級。第二，針對數據使用方，要有明確的角色授權標準，通過分級分類和角色授權，來保障重要數據拿不走。第三，針對敏感數據，要有隱私管理標準，保障敏感數據的安全存儲，即使未授權用戶繞過權限管理拿到敏感數據，也要確保其看不懂。第四，通過制定審計標準，為后續的審計提供審計依據，確保數據走不脫。

3.5 數據生命周期治理

任何事物都具有一定的生命周期，數據也不例外。從數據的產生、加工、使用乃至消亡都應該有一個科學的管理辦法，將極少或者不再使用的數據從系統中剝離出來，并通過核實的存儲設備進行保留，不僅能夠提高系統的運行效率，更好的服務客戶，還能大幅度減少因為數據長期保存帶來的儲存成本。數據生命周期一般包含在線階段、歸檔階段（有時還會進一步劃分為在線歸檔階段和離線歸檔階段）、銷毀階段三大階段，管理內容包括建立合理的數據類別，針對不同類別的數據制定各個階段的保留時間、存儲介質、清理規則和方式、注意事項等。

從上圖數據生命周期中各參數間的關系中我們可以了解到，數據生命周期管理可以使得高價值數據的查詢效率大幅提升，而且高價格的存儲介質的采購量也可以減少很多；但是隨著數據的使用程度的下降，數據被逐漸歸檔，查詢時間也慢慢的變長；最后隨著數據的使用頻率和價值基本沒有了之后，就可以逐漸銷毀了。

3.6 數據質量治理

對于數據質量的監控，主要包括三個環節：

第一，結合數據質量衡量的六個維度及日常工作中發現的數據質量問題，配置相關規則。

第二，在數據加工的各個環節設置檢查點，比如從 ODS 到 DW，從 DW 到 DM 等環節。如在 ODS 的檢查點設置中，可能會包括數據源抽取記錄的檢查；在基礎層會有空值、編碼值、一致性、重復性等問題的檢查 。

第三，輸出異常結果，進行告警處理。

看一個具體的監控案例。當用數據質量監控平臺對一張表進行監控時，我們可以選擇配置相關規則，可以直接采用預置的規則模版，也可以自定義規則。也可以設置檢查規則的屬性，比如是強規則還是弱規則，此外對告警的屬性也可以進行設置。規則配置完成以后在實際檢測過程中，如果某個檢測規則違反了強規則，則其會阻斷下游任務的執行。

告警升級機制方面，強規則一般會提供電話告警。如果說由于疏忽或其他情況導致任務負責人未及時處理，那么會升級到leader來推進問題的解決。

告警信息是點對點，我們對告警信息會進行聚合，形成質量全貌信息。比如每天早上來上班，我就可以打開質量全貌信息，看一下當天執行了多少檢查規則，有多少是有問題的。如果有問題可以繼續分辨哪些是真有問題，哪些是沒問題，有問題的是否已經解決。如果檢查規則設置不合理，我們會進行優化，逐漸使得告警規則更準確，形成質量監控全面、準確的閉環。

第一，結合數據質量衡量的六個維度及日常工作中發現的數據質量問題，配置相關規則。

第二，在數據加工的各個環節設置檢查點，比如從 ODS 到 DW，從 DW 到 DM 等環節。如在 ODS 的檢查點設置中，可能會包括數據源抽取記錄的檢查；在基礎層會有空值、編碼值、一致性、重復性等問題的檢查 。

第三，輸出異常結果，進行告警處理。

看一個具體的監控案例。當用數據質量監控平臺對一張表進行監控時，我們可以選擇配置相關規則，可以直接采用預置的規則模版，也可以自定義規則。也可以設置檢查規則的屬性，比如是強規則還是弱規則，此外對告警的屬性也可以進行設置。規則配置完成以后在實際檢測過程中，如果某個檢測規則違反了強規則，則其會阻斷下游任務的執行。

告警升級機制方面，強規則一般會提供電話告警。如果說由于疏忽或其他情況導致任務負責人未及時處理，那么會升級到leader來推進問題的解決。

告警信息是點對點，我們對告警信息會進行聚合，形成質量全貌信息。比如每天早上來上班，我就可以打開質量全貌信息，看一下當天執行了多少檢查規則，有多少是有問題的。如果有問題可以繼續分辨哪些是真有問題，哪些是沒問題，有問題的是否已經解決。如果檢查規則設置不合理，我們會進行優化，逐漸使得告警規則更準確，形成質量監控全面、準確的閉環。

還有一些深層次的數據質量問題可能通過我們常規的檢查手段并不一定能發現，這時就需要借助下游數據使用來解決，一般我們會結合業務專題分析推動數據治理。在專題分析過程中，可能會發現種種數據質量問題，比如數據未線上化、數據采集不完整等。

本文轉載自微信公眾號「

」，作者「滌生-宇哥」，可以通過以下二維碼關注。

轉載本文請聯系「滌生大數據」公眾號。