數據治理體系演進簡介
網易內部如嚴選、云音樂、傳媒等數據團隊對數據內容體系的治理思路都是將治理規范融入到開發過程中，將治理的動作提前，這其實就是“開發治理一體化”；事后依賴數據資產健康評估和治理工具進行數據的治理，建立事前加事后的數據治理體系。
隨著網易數帆商業化的發展，遇到很多金融及大型國企客戶，我們發現互聯網的這套數據治理的打法并不能全部適應傳統行業客戶的場景。我們開始向客戶和競爭對手學習，為此打磨出元數據管理，數據標準，數據資產目錄等子產品，沉淀出一套數據治理的產品體系。
本文主要內容包括以下四個方面：
- “先設計后開發”
- “先污染后治理”
- 基于元數據的數據治理體系
- 基于邏輯數據湖的數據治理介紹
1、“先設計后開發”
在軟件工程中良好的設計具有不可比擬的意義，它勝于需求、編碼、維護等環節，秉承設計優先的原則會讓軟件開發變得簡單高效，可以盡量避免掉因設計失誤而導致的缺陷，一個健壯的程序必然有良好的設計。
網易數帆有數數據中臺產品的特色之一“先設計后開發”，其目標就是將數據標準定義、指標規范定義、模型設計和數據開發體系連接在一起，實現“規范即設計，設計即開發”、以設計驅動開發，并通過流程管控卡點保障元數據的生成是按照規范落地的。在開發的過程中保障數據標準，數據質量，數據安全的落地，這就是將開發治理一體化，期望能達到“事半功倍”的事前治理方案。
在沒有“數據標準”產品之前我們，我們推薦客戶的數據體系構建工作流包含業務和需求調研，數據架構設計，指標規范定義，數據模型設計，數據開發五個過程。
- 數據架構設計指以維度建模為理論基礎，基于業務和需求調研的結果，通過需求聯動設計，對數倉進行整體規劃，包含確定數據域，抽象業務板塊，定義數據域下的業務過程；
- 指標規范定義，包括原子指標，業務限定如修飾詞、時間周期，派生指標則由原子指標和業務限定組合而成；也包含維度及屬性的規范定義；
- 數據模型設計是指基于原子指標，派生指標，維度屬性組合的維表、明細事實表和匯總事實表的模型設計；
- 數據開發：將邏輯模型變成物理模型，是設計與物理實現的統一。
再好的規范設計都需要工具來落地和約束，否則就是一紙空文，我們認為所有需求都可以拆解為指標和維度，指標和維度組合就是模型，所以用指標管理工具和模型設計中心去承載規范設計的落地：
- 數據研發同學在指標管理中配置化定義維度、業務過程、原子指標、時間周期的中英文名稱；這個過程已經完成維表和事實表的定義；
- 分析師或者數據口徑管理者負責定義派生指標的業務元數據，通過選擇原子指標和業務限定自動生成派生指標，派生指標全局唯一，這樣就輕松的消除數據的二義性；在這個過程其實就已經完成匯總表的定義。
- 通過前面兩步基本完成指標和模型的定義，數據研發同學就可以結合當前模型的情況在模型設計中心完成模型的設計或者修改。當前市面有些公司也是基于這個邏輯將模型設計和指標管理合二為一形成半AutoETL產品，自動生成指標/模型/調度關系。附模型設計原則：
在模型和指標的落地過程中，通過“庖丁解牛”式的產品配置將數據模型涉及的技術元數據/業務元數據進行標準化，標準化的好處是“車同軌，書同文，大家都說普通話”。可以說我們產品從一開始就實現了開發治理一體化。
2、“先污染后治理”
“先污染后治理”是當前數據治理的主流方案，與其說主流不如說是無奈的選擇，因為“先設計再開發”意味著重構，重構雖然是最徹底的方案但也是最難實操執行的，畢竟很多數據團隊最核心要交付的是短期業務價值，重構帶來需求交付效率的下降且短期無明顯價值增長，也有很多數據團隊就會選擇邊開發邊進行治理的方案，我們將網易的經驗和過程也在這里做一個介紹。
2.1 運動式治理
隨著業務的發展，網易內部業務線的計算和存儲達到瓶頸，但業務方很難判斷，是應該繼續擴容增加資源，還是對劣質數據進行治理來降低資源危機，但這個過程中，如何定義劣質數據，定義了劣質資源后，要怎么對其進行治理，都是亟待確定和解決的問題；另一方面，數據本身的加工鏈路長，數據的加工處理沒有統一的標準，整個團隊內到底有哪些數據，數據的負責人是誰，這些數據是通過哪些任務產出的，這些數據有沒有被有效的使用，數據的存在是否有意義，這些都是管理者比較關心的問題，但數據團隊都很難回答。通過運動式的專項治理我們還是沉淀出部分工具
2.2 度量體系的構建
基于元數據的建設，我們將底層的表信息、計算任務信息和任務/表之間的血緣信息，匯總為計算、存儲的元數據倉庫，結合內部自己的賬單體系對計算和存儲均進行了定價，從而將調度任務、自助查詢每次執行消耗的計算成本預估出來，對于存儲成本，一方面包含數據表本身的存儲成本，另一方面產出該表的計算任務也會分攤該數據表的成本，最終得到數據表總的存儲成本。將計算和存儲成本轉化為費用，更加一目了然的對治理效果進行量化評估。為了方便用戶理解，我們構建了統一的健康分度量體系
3、基于元數據的數據治理體系
無論“先設計后開發”亦或是“先污染后治理”，都少不了過程元數據的沉淀，這樣才會讓治理無論在任何階段都變得輕松可靠。在商業化實踐的過程中我們逐步地吸收了傳統行業一些優點，例如在21年底我們上線了數據標準、元數據管理這兩款產品，同時數據標準，元數據管理、數據質量、模型設計、指標管理、安全中心等產品做了打通能完成數據標準的校驗，讓數據標準不再是一紙空文。
越來越多行業的實踐讓我們開始思考我們的數據治理體系需要升級，首先是站在數據內容體系需要明確治理的范圍。
3.1 明確數據治理的范圍
3.1.1 倉內數據全生命周期
數據管理能力成熟度評估模型給出了數據管理能力成熟度評估模型以及相應的成熟度等級，定義了數據戰略、數據治理、數據架構、數據應用、數據安全、數據質量、數據標準和數據生存周期等8個能力域。
我們的數據治理的范圍參考了DCMM模型，同時也是圍繞數據的全生命周期展開的，在數據生產階段，需要對需求進行分析，明確業務口徑，對數據進行規范采集、任務開發和監控運維；在數據消費階段，涉及到快速地查找數據，對數據的分析和對數據質量的探查；在數據管理過程中，包含權限和成本管理等。整個流程涉及到成本、標準、質量、安全和價值，各個階段都會面臨對數據的治理工作。
在具體的數據治理產品層面做了一些微調：DCMM包含有數據標準，數據質量，數據安全，數據應用（我們叫數據價值），我們在這個標準的基礎上一方面完善數據標準的內容，另一方面也將成本治理加入到治理的范圍內。形成五大模塊：
- 數據標準治理，增加指標規范，模型規范。其中元數據規范治理也在這個模塊；
- 數據價值，通過數據應用在業務的使用情況治理無用或低頻數據；
- 數據成本，包含存儲成本和計算成本的治理；
- 數據質量治理，包含數據的準確性，一致性，及時性，完整性，唯一性；
- 數據安全治理，包含數據權限，功能權限，敏感數據識別，脫敏加密管理。
3.1.2 倉外元數據的治理
過去很長一段時間我們將數據治理的范圍定在倉內，很多公司經歷了多年的建設，擁有大量獨立的數據應用體系，數據架構非常復雜，也是數據治理繞不開的一道墻。尤其是在構建數據資產大盤時就需要考慮倉外元數據的管理以及一些手工元數據的管理。
為此我們研發了元數據管理模塊，用于統一管理倉內和倉外元數據。它包括元數據登記、元數據注冊采集、元數據存儲、元數據分析等，涵蓋了元數據的全鏈路生命周期管理。支持元數據的自動采集和調度管理，支持手工創建和變更元數據，并配合版本管理，便于用戶跟蹤元數據整個生命周期動態和變化。
3.2 數據治理產品的優化
3.2.1 開發治理一體化
3.2.1.1 面臨的問題
從網易內部的實踐來看，過重的設計不行（例如使用ERwin、power designer類似的工具交付設計ER圖），無設計也不行。開發治理一體化理想很完美，大家也很認可“先設計后開發”的理念，但很多業務中也面臨執行不到位。例如：業務探索期/高速發展期需要快速獲取運營數據，業務方能接受的排期不會超過1周，留給數據建設的周期并不長，很多報表直接從ODS源表進行加工，為了快速上線犧牲設計，效率優先，且缺乏協作。從商業化的客戶來看有數產品體系中的指標管理和模型管理還是停留在治理體系，與開發體系的元數據管理、數據傳輸、數據質量的聯動性不足。
- 設計、開發和治理體系缺少一個連接點，能平滑地將三者融合；
- 缺少流程管控，或以犧牲開發效率的目標的“先設計后開發”是不完整的研發治理一體化。
3.2.1.2 更完善的“先設計后開發”
很長時間內我們在規范這塊缺乏能平滑地將設計、開發和治理融合的產品，直到2021年推出了數據標準；同時為了更好的流程協作管理，我們優化了流程協作與消息中心，構建能自定義的流程引擎、企業組織架構和消息通知。
“先設計后開發”核心是元數據的規范，在設計階段就約束元數據的定義，開發階段則通過流程管控保證規范元數據的生成，這樣就能保障邏輯與物理的統一。數據標準的目標就是完成元數據規范的定義，結合指標和模型兩款產品，將數據標準規范定義、指標規范定義、模型設計和數據開發體系通過流程引擎連接在一起，以實現“規范即設計，設計即開發，開發即治理”的開發治理一體化。
- 數據標準：通過制定數據的標準保障數據的內外部使用和交換的一致性和準確性的規范性約束。對指標的元數據進行規范定義，從業務屬性、技術屬性、管理屬性三個方面對元數據進行描述。在實踐過程中將數據元與指標關聯打通，并可以對指標在數據質量、數據安全、模型設計規范等方面的執行情況進行事后檢查評估。
- 指標管理：自動化生成指標，消除數據的二義性。指標的設計需要符合數據標準的規范，完善指標的技術、業務、管理元數據。
- 模型設計：負責數據模型的設計，也需要遵循數據標準的規范，將指標與模型掛鉤，規范表和字段的元數據；
- 數據開發體系：將數據開發的過程與數據規范結合實現業務規則的數字化落地。負責將設計的數據模型實現，將技術元數據（血緣，質量，負責人，調度任務信息等）和標準規范結合，實現模型設計與數據開發的協同，真正意義的完成了元數據的標準化落地。
- 規范約束：數據標準負責定義“好數據”的標準，包含質量、安全等；指標工具負責設計好的指標和維度；每個指標需要與數據標準關聯；模型設計中心負責設計好的數據模型，模型的每個字段必須來自指標管理的定義好的指標和維度才能完成物理建表；數據開發體系按照設計要求完成代碼的開發，負責生產“好數據”和“好元數據”。
指標、模型設計這塊的落地方案，我在第一章已有詳細的介紹，這里就不單獨再介紹了。再強調一下再好的規范沒有工具產品來匹配落地就是一紙空文。工具產品必須有所卡點才能保障設計和落地的一致性，需要通過流程引擎保障先設計后開發的流程、保障規范的落地。這些卡點包含：
- 數據標準的規范在指標和模型的引用率，事后需要檢查規范的執行情況
- 指標系統的指標需要自動生成，且保障唯一性，同時也需要檢驗指標的相似度。
- 模型的設計時模型的分層，數據域，業務過程，時間周期等變量的定義是選擇題而非填空題，模型設計與建表一體化，建議關閉其他通道DDL執行。同時模型的規范事后需要檢測：如相似度，復用度，穿透率，覆蓋率，閑置率等，如有必要保障模型建表唯一通道
- 上線前數據模型、質量、安全等規范未落地不允許發布上線。
將數據開發與數據治理結合起來既是對開發過程的管控，也是保障數據質量的有效方法。需求階段主要對業務數據進行調研、拆解數據、確定詞根、數據項以及業務指標。設計階段基于調研的內容進行標準和指標的設計并應用于模型和質量，設計完成后進行元數據的注冊并完成業務信息的錄入。開發階段根據設計階段的規范進行數據開發、約束開發流程，通過元數據掃描完成元數據技術信息的錄入，最后將元數據進行審核并發布。在數據的全生命周期內各個模塊協同的案例：
- 數據標準與模型設計：在數據模型設計中關聯數據標準，數據標準中字段命名可以直接應用在模型字段上。
- 數據標準與數據質量：數據標準中的數據元對應的值閾約束可以關聯稽核規則。
- 數據標準與數據安全：數據標準中的數據元可以關聯數據安全的數據敏感等級和數據脫敏規則。
- 數據質量與模型設計：數據模型關聯的數據元所關聯的數據質量稽核規則，可以直接應用到這個模型的稽核任務上。
- 數據安全與模型設計：模型發布，自動應用安全中心的脫敏規則。
開發治理一體化對于很多公司意味著數據體系的重構。在重構的過程中用流程約束元數據的生成，保證元數據的規范性。事前治理的方案對客戶數據建設所處的時機要求就會比較高，雖然也可以按照數據域逐一重構遷移，整體建設周期較長，價值也不能立竿見影；但是數據體系的建設本就是數據“熵增”的過程，我們在建設中對他做功，這樣熵增加的比例是在可控的范圍內，事前做功對數據治理來說事“事半功倍”的選擇。對過程做功會帶來效率的降低，未來如果搭配可視化ETL和AutoETL工具就能在效率和治理上實現雙豐收。
3.2.2 數據健康評估與優化工具
3.2.2.1 面臨的問題
數據治理的訴求在互聯網公司早期并不那么強烈，一般的關注點也只是在成本不足、數據產出不及時、指標口徑對不上、數據質量出現重大問題的時候會發起治理專項，然后等著再污染再治理。這個階段主要呈現出的特點是：被動式（無抓手），運動式。一套基于數據建設的健康度評估體系加優化工具就應運而生。
在網易的實踐過程中我們發明了一套基于ROI的數據資產沉淀方法，我們研發了基于Hadoop的元數據分析服務，可以精準計算出每個任務消耗了多少計算，存儲資源，同時打通數據生產和消費的全鏈路的數據血緣，按照任務引用進行下游分攤，最終可測算出每個應用（數據報表、數據API）消耗了多少資源，同時還有數據應用的使用情況（PV/UV/重要程度），可以找到沒有使用卻消耗很大資源的應用，同時采用“剝洋蔥”式的數據下線方式，從上層數據應用開發逐層推動數據下線。依托于這套方法我們構建了基于成本、規范、質量、安全、價值的數據健康分體系。
我們希望通過”評分賽馬”的機制來驅動開發同學自助完成數據治理，也取得了很多成效，嚴選/音樂/傳媒在這套治理體系內在成本/質量/標準規范上都有顯著的提升。那么這一套治理體系為什么不能在傳統行業快速應用起來呢，我的理解有兩點：
（1）傳統行業的開發及治理方面其實更偏“管理”，以銀行證券行業為例一方面業務層面被強監管，業務過程非常穩定，主管單位會下發國家標準，合規性非常重要；另一方面數據團隊的構成上有大量的外包人員，由一個甲方領導幾十個外包人員，安全和穩定是第一位的，所以管理流程是非常必要，而互聯網更重視效率，所以我們的產品在管理上很松散的，也導致管理元數據的缺乏；
（2）互聯網公司很多時候其實依賴的是人治，依賴數據開發同學的個人專業能力去減少后期治理的事情，就像阿里的OneData體系也只是給開發人員使用，我們也推薦“先設計后開發”的開發治理一體化。傳統行業有專職數據治理團隊負責治理體系，而我們的產品缺乏為這類角色服務，沒有符合他們使用場景的功能和流程。
3.2.2.2 更完善的事后治理體系
（1）構建數據治理的價值體系
基于數據的全生命周期，包含了成本、質量、安全、標準和價值五個方面，針對每個方面，都要建立大家認同的可量化的指標，通過指標去衡量數據治理的價值，統一數據健康診斷的度量衡。
對于成本，包括計算和存儲成本的費用量化，對無用數據的下線治理等；對于價值，需要能夠評估每個數據模型、數據報告和API的應用價值；對于質量，會包含監控任務覆蓋了多少稽核規則，涵蓋了多少強弱規則；對于標準規范，需要對數據標準、指標和模型進行規范度和復用性的評估；對于安全，會包含數據安全等級和數據權限的治理等內容的評估。
（2）體系化治理手段
數據治理不是一個臨時性要做的工作，從數據生命周期的全過程到治理體系的健康運行，需要一個長效的治理機制來保證，體系化的數據治理。
- 最開始是發現問題，包含成本、標準、質量、安全和價值五個方面，明確需要進行治理的內容；
- 然后基于需要治理的內容配套專題的治理工具，比如對無用數據的推薦下線，對表生命周期的管理，對計算任務的優化等；
- 最后在治理工作過程中，持續有治理抓手，包括推送整個項目、個人的資產賬單，數據治理的紅黑榜，并將資產健康分和個人的任務優先級或資源申請等掛鉤
- 持續運營：例如舉辦數據治理大賽、業務線專項治理活動等來持續運營和打磨產品的能力。
整體通過發現問題-->解決問題-->持續運營和持續沉淀形成資產治理的閉環。
（3）強化管理屬性
- 統一數據治理控制臺作為所有治理項的入口，一方面是系統預置治理規則掃描的待治理項，包含成本、質量、安全、規范和價值五個方面；另一方面是通過工單形式指派給相關治理管理者的治理項；
- 用戶分層，從項目組、項目和用戶角度呈現待治理和已治理項，強化數據治理專員這個角色；
- 自定義數據治理流程，例如待我治理/待處理工單，數據消費者、項目負責人、數據治理專員都可以發起資產的治理工單（比如字段描述缺失、數據質量分較低等）系統會將治理工單下發給資產負責人，所有工單信息都會體現在“待我治理”模塊；
- 數據治理的流程定義與企業組織架構、消息系統如IM等進行打通，形成管理閉環。
3.3 產品整體方案
經過上面的介紹可知我們的數據治理產品包含事前和事后兩條路線。覆蓋數據的全生命周期（從元數據的注冊到數據應用消費），包含”先設計再開發“的事前治理、數據健康評估與優化（事后治理）這兩條線，以實現建設“規范的元數據”和“好的數據”。同時在消費端將健康的資產通過業務分類和標簽等方式來組織，便于普通用戶在數據消費時能“找的到、讀的懂、信的過”。
- 數據消費者對數據資產有任何問題可以一鍵發起數據治理工單，資產責任人則需要完成響應。
- 資產責任人需要完成系統識別的治理內容和數據消費者、負責人、治理負責人發起的治理內容。
- 項目負責人，治理負責人可以發起數據治理工單。
- 治理負責人包含數據治理專員及治理負責人，對企業數據資產質量負責。
3.4 元數據數據治理滿足的場景
- 元數據管理，包含倉內、倉外，手工元數據的整體納管，數據資產一體化構建企業統一數據資產地圖，讓數據消費者找的到、讀的懂、信的過；
- 通過覆蓋元數據注冊-采集-掃描-審批-發布-使用-變更-廢棄的全生命周期，構建一條完整的元數據治理鏈路；
- 覆蓋數據研發，數據治理，數據服務，到數據應用的全鏈路數據血緣，從而構建基于ROI的數據資產沉淀體系和”剝洋蔥“式的從應用到底層的數據下線機制；
- 制定和管理企業的數據標準，保障數據的內外部使用和交換的一致性和準確性的規范性
- 構建統一指標庫，消除數據的二義性；
- 數倉模型優化，從規范性，復用性，應用價值上構建健康的數據體系；
- 成本治理，包含存儲，計算成本優化，降本增效；
- 數據質量治理，通過數據開發前數據比對，形態探查，數據測試報告，數據任務運行中的強弱規則阻斷下游任務防止數據污染，事后提升數據質量監控覆蓋率等方式全面提升數據質量；
- 數據安全治理，包含數據資產的分類分級，脫敏加密，安全掃描，安全審計，權限治理等。
4、基于邏輯數據湖的數據治理介紹
我們在調研外部用戶需求的過程中，經常會碰到的問題：每個企業用戶的技術建設情況不同，業務復雜度也不一，很多傳統企業已有的IT系統已運行了很多年，只是無法再支持日益增長的數據需求，他們在大數據技術體系的經驗幾乎空白，當面對一個比如lambda架構的大數據解決方案時，往往會覺得過于復雜和難以掌握，對落地成效心存疑慮。還有部分用戶的業務在現有技術框架上（比如MPP）運行良好，出于對未來發展的前瞻性考慮，需要提前進行大數據的基礎技術建設，這部分用戶對于大數據未來的必要性是肯定的，但是會特別關心其適用的場景、業務覆蓋度以及如何平滑地進行業務的遷移。
數據湖&Hadoop解決的是數據統一匯聚的問題，而統一元數據則是解決數據連接、資產、管理的問題，對于相當部分的用戶而言，當前最大的痛點不是海量數據的存儲，而是如何將散落到各個子數據系統的數據孤島統一管控起來。因此通過構建一個邏輯層面的數據湖，實現統一的元數據+分散的物理存儲，避免不必要的物理數據入倉（湖），從而將產品上層功能比如主題域構建、數據地圖等等及早給用戶使用才是解決問題的根本之道，邏輯數據湖方案，依然可以使用物理湖&Hadoop，同時提供通過虛擬表直連數據源的方案將其他類型的數據源也納入平臺的管控中，用戶可以根據實際的需要選擇適合的存儲方案。
我們的構建方法論主要分為如下三個大的層面：
數據源支持類型：除了Hadoop（Hive）體系，MPP、RDMS、HTAP、KV、MQ等都需要支持，并且一視同仁，都可以作為具體邏輯數據湖具體對象的物理存儲。
統一數據源 & 統一元數據：統一數據源要做的是規范每種數據源的登記注冊，包括數據源URL格式、數據源Owner、唯一性校驗、賬號映射、聯通性校驗、支持的版本、特定的參數等；統一元數據，則是將數據源的技術（物理）元信息和業務元信息進行關聯，提供統一的查詢修改接口。
統一數據開發、治理和查詢分析：這三個屬于構建在統一元數據&數據源基礎之上的應用層。統一的數據開發，包括不同物理數據源之間的交換、離線&實時開發、同源&跨源查詢；統一的數據治理，則包括數據主題建設、權限管控、數據生命周期、資產地圖等；統一查詢分析，則是在完成數據主題建設、數據開發產出以后，提供同源&跨源的模型分析能力。
