網(wǎng)易內部如嚴選、云音樂、傳媒等數(shù)據(jù)團隊對數(shù)據(jù)內容體系的治理思路都是將治理規(guī)范融入到開發(fā)過程中，將治理的動作提前，這其實就是“開發(fā)治理一體化”；事后依賴數(shù)據(jù)資產健康評估和治理工具進行數(shù)據(jù)的治理，建立事前加事后的數(shù)據(jù)治理體系。

隨著網(wǎng)易數(shù)帆商業(yè)化的發(fā)展，遇到很多金融及大型國企客戶，我們發(fā)現(xiàn)互聯(lián)網(wǎng)的這套數(shù)據(jù)治理的打法并不能全部適應傳統(tǒng)行業(yè)客戶的場景。我們開始向客戶和競爭對手學習，為此打磨出元數(shù)據(jù)管理，數(shù)據(jù)標準，數(shù)據(jù)資產目錄等子產品，沉淀出一套數(shù)據(jù)治理的產品體系。

本文主要內容包括以下四個方面：

• “先設計后開發(fā)”
• “先污染后治理”
• 基于元數(shù)據(jù)的數(shù)據(jù)治理體系
• 基于邏輯數(shù)據(jù)湖的數(shù)據(jù)治理介紹

1、“先設計后開發(fā)”

在軟件工程中良好的設計具有不可比擬的意義，它勝于需求、編碼、維護等環(huán)節(jié)，秉承設計優(yōu)先的原則會讓軟件開發(fā)變得簡單高效，可以盡量避免掉因設計失誤而導致的缺陷，一個健壯的程序必然有良好的設計。

網(wǎng)易數(shù)帆有數(shù)數(shù)據(jù)中臺產品的特色之一“先設計后開發(fā)”，其目標就是將數(shù)據(jù)標準定義、指標規(guī)范定義、模型設計和數(shù)據(jù)開發(fā)體系連接在一起，實現(xiàn)“規(guī)范即設計，設計即開發(fā)”、以設計驅動開發(fā)，并通過流程管控卡點保障元數(shù)據(jù)的生成是按照規(guī)范落地的。在開發(fā)的過程中保障數(shù)據(jù)標準，數(shù)據(jù)質量，數(shù)據(jù)安全的落地，這就是將開發(fā)治理一體化，期望能達到“事半功倍”的事前治理方案。

在沒有“數(shù)據(jù)標準”產品之前我們，我們推薦客戶的數(shù)據(jù)體系構建工作流包含業(yè)務和需求調研，數(shù)據(jù)架構設計，指標規(guī)范定義，數(shù)據(jù)模型設計，數(shù)據(jù)開發(fā)五個過程。

• 數(shù)據(jù)架構設計指以維度建模為理論基礎，基于業(yè)務和需求調研的結果，通過需求聯(lián)動設計，對數(shù)倉進行整體規(guī)劃，包含確定數(shù)據(jù)域，抽象業(yè)務板塊，定義數(shù)據(jù)域下的業(yè)務過程；
• 指標規(guī)范定義，包括原子指標，業(yè)務限定如修飾詞、時間周期，派生指標則由原子指標和業(yè)務限定組合而成；也包含維度及屬性的規(guī)范定義；
• 數(shù)據(jù)模型設計是指基于原子指標，派生指標，維度屬性組合的維表、明細事實表和匯總事實表的模型設計；
• 數(shù)據(jù)開發(fā)：將邏輯模型變成物理模型，是設計與物理實現(xiàn)的統(tǒng)一。

再好的規(guī)范設計都需要工具來落地和約束，否則就是一紙空文，我們認為所有需求都可以拆解為指標和維度，指標和維度組合就是模型，所以用指標管理工具和模型設計中心去承載規(guī)范設計的落地：

• 數(shù)據(jù)研發(fā)同學在指標管理中配置化定義維度、業(yè)務過程、原子指標、時間周期的中英文名稱；這個過程已經(jīng)完成維表和事實表的定義；
• 分析師或者數(shù)據(jù)口徑管理者負責定義派生指標的業(yè)務元數(shù)據(jù)，通過選擇原子指標和業(yè)務限定自動生成派生指標，派生指標全局唯一，這樣就輕松的消除數(shù)據(jù)的二義性；在這個過程其實就已經(jīng)完成匯總表的定義。

• 通過前面兩步基本完成指標和模型的定義，數(shù)據(jù)研發(fā)同學就可以結合當前模型的情況在模型設計中心完成模型的設計或者修改。當前市面有些公司也是基于這個邏輯將模型設計和指標管理合二為一形成半AutoETL產品，自動生成指標/模型/調度關系。附模型設計原則：

dwd_{業(yè)務縮寫/pub}_{數(shù)據(jù)域縮寫}_{業(yè)務過程縮寫}_[{自定義表命名標簽縮寫}]_{刷新周期標識}{單分區(qū)增量全量標識}dws_{業(yè)務縮寫/pub}_{數(shù)據(jù)域縮寫}_{數(shù)據(jù)主粒度縮寫}_[{自定義表命名標簽縮寫}]_{統(tǒng)計時間周期范圍縮寫}/{刷新周期標識}{單分區(qū)增量全量標識}

在模型和指標的落地過程中，通過“庖丁解?！笔降漠a品配置將數(shù)據(jù)模型涉及的技術元數(shù)據(jù)/業(yè)務元數(shù)據(jù)進行標準化，標準化的好處是“車同軌，書同文，大家都說普通話”?？梢哉f我們產品從一開始就實現(xiàn)了開發(fā)治理一體化。

2、“先污染后治理”

“先污染后治理”是當前數(shù)據(jù)治理的主流方案，與其說主流不如說是無奈的選擇，因為“先設計再開發(fā)”意味著重構，重構雖然是最徹底的方案但也是最難實操執(zhí)行的，畢竟很多數(shù)據(jù)團隊最核心要交付的是短期業(yè)務價值，重構帶來需求交付效率的下降且短期無明顯價值增長，也有很多數(shù)據(jù)團隊就會選擇邊開發(fā)邊進行治理的方案，我們將網(wǎng)易的經(jīng)驗和過程也在這里做一個介紹。

2.1 運動式治理

隨著業(yè)務的發(fā)展，網(wǎng)易內部業(yè)務線的計算和存儲達到瓶頸，但業(yè)務方很難判斷，是應該繼續(xù)擴容增加資源，還是對劣質數(shù)據(jù)進行治理來降低資源危機，但這個過程中，如何定義劣質數(shù)據(jù)，定義了劣質資源后，要怎么對其進行治理，都是亟待確定和解決的問題；另一方面，數(shù)據(jù)本身的加工鏈路長，數(shù)據(jù)的加工處理沒有統(tǒng)一的標準，整個團隊內到底有哪些數(shù)據(jù)，數(shù)據(jù)的負責人是誰，這些數(shù)據(jù)是通過哪些任務產出的，這些數(shù)據(jù)有沒有被有效的使用，數(shù)據(jù)的存在是否有意義，這些都是管理者比較關心的問題，但數(shù)據(jù)團隊都很難回答。通過運動式的專項治理我們還是沉淀出部分工具

2.2 度量體系的構建

基于元數(shù)據(jù)的建設，我們將底層的表信息、計算任務信息和任務/表之間的血緣信息，匯總為計算、存儲的元數(shù)據(jù)倉庫，結合內部自己的賬單體系對計算和存儲均進行了定價，從而將調度任務、自助查詢每次執(zhí)行消耗的計算成本預估出來，對于存儲成本，一方面包含數(shù)據(jù)表本身的存儲成本，另一方面產出該表的計算任務也會分攤該數(shù)據(jù)表的成本，最終得到數(shù)據(jù)表總的存儲成本。將計算和存儲成本轉化為費用，更加一目了然的對治理效果進行量化評估。為了方便用戶理解，我們構建了統(tǒng)一的健康分度量體系

3、基于元數(shù)據(jù)的數(shù)據(jù)治理體系

無論“先設計后開發(fā)”亦或是“先污染后治理”，都少不了過程元數(shù)據(jù)的沉淀，這樣才會讓治理無論在任何階段都變得輕松可靠。在商業(yè)化實踐的過程中我們逐步地吸收了傳統(tǒng)行業(yè)一些優(yōu)點，例如在21年底我們上線了數(shù)據(jù)標準、元數(shù)據(jù)管理這兩款產品，同時數(shù)據(jù)標準，元數(shù)據(jù)管理、數(shù)據(jù)質量、模型設計、指標管理、安全中心等產品做了打通能完成數(shù)據(jù)標準的校驗，讓數(shù)據(jù)標準不再是一紙空文。

越來越多行業(yè)的實踐讓我們開始思考我們的數(shù)據(jù)治理體系需要升級，首先是站在數(shù)據(jù)內容體系需要明確治理的范圍。

3.1 明確數(shù)據(jù)治理的范圍

3.1.1 倉內數(shù)據(jù)全生命周期

數(shù)據(jù)管理能力成熟度評估模型給出了數(shù)據(jù)管理能力成熟度評估模型以及相應的成熟度等級，定義了數(shù)據(jù)戰(zhàn)略、數(shù)據(jù)治理、數(shù)據(jù)架構、數(shù)據(jù)應用、數(shù)據(jù)安全、數(shù)據(jù)質量、數(shù)據(jù)標準和數(shù)據(jù)生存周期等8個能力域。

我們的數(shù)據(jù)治理的范圍參考了DCMM模型，同時也是圍繞數(shù)據(jù)的全生命周期展開的，在數(shù)據(jù)生產階段，需要對需求進行分析，明確業(yè)務口徑，對數(shù)據(jù)進行規(guī)范采集、任務開發(fā)和監(jiān)控運維；在數(shù)據(jù)消費階段，涉及到快速地查找數(shù)據(jù)，對數(shù)據(jù)的分析和對數(shù)據(jù)質量的探查；在數(shù)據(jù)管理過程中，包含權限和成本管理等。整個流程涉及到成本、標準、質量、安全和價值，各個階段都會面臨對數(shù)據(jù)的治理工作。

在具體的數(shù)據(jù)治理產品層面做了一些微調：DCMM包含有數(shù)據(jù)標準，數(shù)據(jù)質量，數(shù)據(jù)安全，數(shù)據(jù)應用（我們叫數(shù)據(jù)價值），我們在這個標準的基礎上一方面完善數(shù)據(jù)標準的內容，另一方面也將成本治理加入到治理的范圍內。形成五大模塊：

• 數(shù)據(jù)標準治理，增加指標規(guī)范，模型規(guī)范。其中元數(shù)據(jù)規(guī)范治理也在這個模塊；
• 數(shù)據(jù)價值，通過數(shù)據(jù)應用在業(yè)務的使用情況治理無用或低頻數(shù)據(jù)；
• 數(shù)據(jù)成本，包含存儲成本和計算成本的治理；
• 數(shù)據(jù)質量治理，包含數(shù)據(jù)的準確性，一致性，及時性，完整性，唯一性；
• 數(shù)據(jù)安全治理，包含數(shù)據(jù)權限，功能權限，敏感數(shù)據(jù)識別，脫敏加密管理。

3.1.2 倉外元數(shù)據(jù)的治理

過去很長一段時間我們將數(shù)據(jù)治理的范圍定在倉內，很多公司經(jīng)歷了多年的建設，擁有大量獨立的數(shù)據(jù)應用體系，數(shù)據(jù)架構非常復雜，也是數(shù)據(jù)治理繞不開的一道墻。尤其是在構建數(shù)據(jù)資產大盤時就需要考慮倉外元數(shù)據(jù)的管理以及一些手工元數(shù)據(jù)的管理。

為此我們研發(fā)了元數(shù)據(jù)管理模塊，用于統(tǒng)一管理倉內和倉外元數(shù)據(jù)。它包括元數(shù)據(jù)登記、元數(shù)據(jù)注冊采集、元數(shù)據(jù)存儲、元數(shù)據(jù)分析等，涵蓋了元數(shù)據(jù)的全鏈路生命周期管理。支持元數(shù)據(jù)的自動采集和調度管理，支持手工創(chuàng)建和變更元數(shù)據(jù)，并配合版本管理，便于用戶跟蹤元數(shù)據(jù)整個生命周期動態(tài)和變化。

3.2 數(shù)據(jù)治理產品的優(yōu)化

3.2.1 開發(fā)治理一體化

3.2.1.1 面臨的問題

從網(wǎng)易內部的實踐來看，過重的設計不行（例如使用ERwin、power designer類似的工具交付設計ER圖），無設計也不行。開發(fā)治理一體化理想很完美，大家也很認可“先設計后開發(fā)”的理念，但很多業(yè)務中也面臨執(zhí)行不到位。例如：業(yè)務探索期/高速發(fā)展期需要快速獲取運營數(shù)據(jù)，業(yè)務方能接受的排期不會超過1周，留給數(shù)據(jù)建設的周期并不長，很多報表直接從ODS源表進行加工，為了快速上線犧牲設計，效率優(yōu)先，且缺乏協(xié)作。從商業(yè)化的客戶來看有數(shù)產品體系中的指標管理和模型管理還是停留在治理體系，與開發(fā)體系的元數(shù)據(jù)管理、數(shù)據(jù)傳輸、數(shù)據(jù)質量的聯(lián)動性不足。

• 設計、開發(fā)和治理體系缺少一個連接點，能平滑地將三者融合；
• 缺少流程管控，或以犧牲開發(fā)效率的目標的“先設計后開發(fā)”是不完整的研發(fā)治理一體化。

3.2.1.2 更完善的“先設計后開發(fā)”

很長時間內我們在規(guī)范這塊缺乏能平滑地將設計、開發(fā)和治理融合的產品，直到2021年推出了數(shù)據(jù)標準；同時為了更好的流程協(xié)作管理，我們優(yōu)化了流程協(xié)作與消息中心，構建能自定義的流程引擎、企業(yè)組織架構和消息通知。

“先設計后開發(fā)”核心是元數(shù)據(jù)的規(guī)范，在設計階段就約束元數(shù)據(jù)的定義，開發(fā)階段則通過流程管控保證規(guī)范元數(shù)據(jù)的生成，這樣就能保障邏輯與物理的統(tǒng)一。數(shù)據(jù)標準的目標就是完成元數(shù)據(jù)規(guī)范的定義，結合指標和模型兩款產品，將數(shù)據(jù)標準規(guī)范定義、指標規(guī)范定義、模型設計和數(shù)據(jù)開發(fā)體系通過流程引擎連接在一起，以實現(xiàn)“規(guī)范即設計，設計即開發(fā)，開發(fā)即治理”的開發(fā)治理一體化。

• 數(shù)據(jù)標準：通過制定數(shù)據(jù)的標準保障數(shù)據(jù)的內外部使用和交換的一致性和準確性的規(guī)范性約束。對指標的元數(shù)據(jù)進行規(guī)范定義，從業(yè)務屬性、技術屬性、管理屬性三個方面對元數(shù)據(jù)進行描述。在實踐過程中將數(shù)據(jù)元與指標關聯(lián)打通，并可以對指標在數(shù)據(jù)質量、數(shù)據(jù)安全、模型設計規(guī)范等方面的執(zhí)行情況進行事后檢查評估。
• 指標管理：自動化生成指標，消除數(shù)據(jù)的二義性。指標的設計需要符合數(shù)據(jù)標準的規(guī)范，完善指標的技術、業(yè)務、管理元數(shù)據(jù)。
• 模型設計：負責數(shù)據(jù)模型的設計，也需要遵循數(shù)據(jù)標準的規(guī)范，將指標與模型掛鉤，規(guī)范表和字段的元數(shù)據(jù)；
• 數(shù)據(jù)開發(fā)體系：將數(shù)據(jù)開發(fā)的過程與數(shù)據(jù)規(guī)范結合實現(xiàn)業(yè)務規(guī)則的數(shù)字化落地。負責將設計的數(shù)據(jù)模型實現(xiàn)，將技術元數(shù)據(jù)（血緣，質量，負責人，調度任務信息等）和標準規(guī)范結合，實現(xiàn)模型設計與數(shù)據(jù)開發(fā)的協(xié)同，真正意義的完成了元數(shù)據(jù)的標準化落地。
• 規(guī)范約束：數(shù)據(jù)標準負責定義“好數(shù)據(jù)”的標準，包含質量、安全等；指標工具負責設計好的指標和維度；每個指標需要與數(shù)據(jù)標準關聯(lián)；模型設計中心負責設計好的數(shù)據(jù)模型，模型的每個字段必須來自指標管理的定義好的指標和維度才能完成物理建表；數(shù)據(jù)開發(fā)體系按照設計要求完成代碼的開發(fā)，負責生產“好數(shù)據(jù)”和“好元數(shù)據(jù)”。

指標、模型設計這塊的落地方案，我在第一章已有詳細的介紹，這里就不單獨再介紹了。再強調一下再好的規(guī)范沒有工具產品來匹配落地就是一紙空文。工具產品必須有所卡點才能保障設計和落地的一致性，需要通過流程引擎保障先設計后開發(fā)的流程、保障規(guī)范的落地。這些卡點包含：

• 數(shù)據(jù)標準的規(guī)范在指標和模型的引用率，事后需要檢查規(guī)范的執(zhí)行情況
• 指標系統(tǒng)的指標需要自動生成，且保障唯一性，同時也需要檢驗指標的相似度。
• 模型的設計時模型的分層，數(shù)據(jù)域，業(yè)務過程，時間周期等變量的定義是選擇題而非填空題，模型設計與建表一體化，建議關閉其他通道DDL執(zhí)行。同時模型的規(guī)范事后需要檢測：如相似度，復用度，穿透率，覆蓋率，閑置率等，如有必要保障模型建表唯一通道
• 上線前數(shù)據(jù)模型、質量、安全等規(guī)范未落地不允許發(fā)布上線。

將數(shù)據(jù)開發(fā)與數(shù)據(jù)治理結合起來既是對開發(fā)過程的管控，也是保障數(shù)據(jù)質量的有效方法。需求階段主要對業(yè)務數(shù)據(jù)進行調研、拆解數(shù)據(jù)、確定詞根、數(shù)據(jù)項以及業(yè)務指標。設計階段基于調研的內容進行標準和指標的設計并應用于模型和質量，設計完成后進行元數(shù)據(jù)的注冊并完成業(yè)務信息的錄入。開發(fā)階段根據(jù)設計階段的規(guī)范進行數(shù)據(jù)開發(fā)、約束開發(fā)流程，通過元數(shù)據(jù)掃描完成元數(shù)據(jù)技術信息的錄入，最后將元數(shù)據(jù)進行審核并發(fā)布。在數(shù)據(jù)的全生命周期內各個模塊協(xié)同的案例：

• 數(shù)據(jù)標準與模型設計：在數(shù)據(jù)模型設計中關聯(lián)數(shù)據(jù)標準，數(shù)據(jù)標準中字段命名可以直接應用在模型字段上。
• 數(shù)據(jù)標準與數(shù)據(jù)質量：數(shù)據(jù)標準中的數(shù)據(jù)元對應的值閾約束可以關聯(lián)稽核規(guī)則。
• 數(shù)據(jù)標準與數(shù)據(jù)安全：數(shù)據(jù)標準中的數(shù)據(jù)元可以關聯(lián)數(shù)據(jù)安全的數(shù)據(jù)敏感等級和數(shù)據(jù)脫敏規(guī)則。
• 數(shù)據(jù)質量與模型設計：數(shù)據(jù)模型關聯(lián)的數(shù)據(jù)元所關聯(lián)的數(shù)據(jù)質量稽核規(guī)則，可以直接應用到這個模型的稽核任務上。
• 數(shù)據(jù)安全與模型設計：模型發(fā)布，自動應用安全中心的脫敏規(guī)則。

開發(fā)治理一體化對于很多公司意味著數(shù)據(jù)體系的重構。在重構的過程中用流程約束元數(shù)據(jù)的生成，保證元數(shù)據(jù)的規(guī)范性。事前治理的方案對客戶數(shù)據(jù)建設所處的時機要求就會比較高，雖然也可以按照數(shù)據(jù)域逐一重構遷移，整體建設周期較長，價值也不能立竿見影；但是數(shù)據(jù)體系的建設本就是數(shù)據(jù)“熵增”的過程，我們在建設中對他做功，這樣熵增加的比例是在可控的范圍內，事前做功對數(shù)據(jù)治理來說事“事半功倍”的選擇。對過程做功會帶來效率的降低，未來如果搭配可視化ETL和AutoETL工具就能在效率和治理上實現(xiàn)雙豐收。

3.2.2 數(shù)據(jù)健康評估與優(yōu)化工具

3.2.2.1 面臨的問題

數(shù)據(jù)治理的訴求在互聯(lián)網(wǎng)公司早期并不那么強烈，一般的關注點也只是在成本不足、數(shù)據(jù)產出不及時、指標口徑對不上、數(shù)據(jù)質量出現(xiàn)重大問題的時候會發(fā)起治理專項，然后等著再污染再治理。這個階段主要呈現(xiàn)出的特點是：被動式（無抓手），運動式。一套基于數(shù)據(jù)建設的健康度評估體系加優(yōu)化工具就應運而生。

在網(wǎng)易的實踐過程中我們發(fā)明了一套基于ROI的數(shù)據(jù)資產沉淀方法，我們研發(fā)了基于Hadoop的元數(shù)據(jù)分析服務，可以精準計算出每個任務消耗了多少計算，存儲資源，同時打通數(shù)據(jù)生產和消費的全鏈路的數(shù)據(jù)血緣，按照任務引用進行下游分攤，最終可測算出每個應用（數(shù)據(jù)報表、數(shù)據(jù)API）消耗了多少資源，同時還有數(shù)據(jù)應用的使用情況（PV/UV/重要程度），可以找到?jīng)]有使用卻消耗很大資源的應用，同時采用“剝洋蔥”式的數(shù)據(jù)下線方式，從上層數(shù)據(jù)應用開發(fā)逐層推動數(shù)據(jù)下線。依托于這套方法我們構建了基于成本、規(guī)范、質量、安全、價值的數(shù)據(jù)健康分體系。

我們希望通過”評分賽馬”的機制來驅動開發(fā)同學自助完成數(shù)據(jù)治理，也取得了很多成效，嚴選/音樂/傳媒在這套治理體系內在成本/質量/標準規(guī)范上都有顯著的提升。那么這一套治理體系為什么不能在傳統(tǒng)行業(yè)快速應用起來呢，我的理解有兩點：

（1）傳統(tǒng)行業(yè)的開發(fā)及治理方面其實更偏“管理”，以銀行證券行業(yè)為例一方面業(yè)務層面被強監(jiān)管，業(yè)務過程非常穩(wěn)定，主管單位會下發(fā)國家標準，合規(guī)性非常重要；另一方面數(shù)據(jù)團隊的構成上有大量的外包人員，由一個甲方領導幾十個外包人員，安全和穩(wěn)定是第一位的，所以管理流程是非常必要，而互聯(lián)網(wǎng)更重視效率，所以我們的產品在管理上很松散的，也導致管理元數(shù)據(jù)的缺乏；

（2）互聯(lián)網(wǎng)公司很多時候其實依賴的是人治，依賴數(shù)據(jù)開發(fā)同學的個人專業(yè)能力去減少后期治理的事情，就像阿里的OneData體系也只是給開發(fā)人員使用，我們也推薦“先設計后開發(fā)”的開發(fā)治理一體化。傳統(tǒng)行業(yè)有專職數(shù)據(jù)治理團隊負責治理體系，而我們的產品缺乏為這類角色服務，沒有符合他們使用場景的功能和流程。

3.2.2.2 更完善的事后治理體系

（1）構建數(shù)據(jù)治理的價值體系

基于數(shù)據(jù)的全生命周期，包含了成本、質量、安全、標準和價值五個方面，針對每個方面，都要建立大家認同的可量化的指標，通過指標去衡量數(shù)據(jù)治理的價值，統(tǒng)一數(shù)據(jù)健康診斷的度量衡。

對于成本，包括計算和存儲成本的費用量化，對無用數(shù)據(jù)的下線治理等；對于價值，需要能夠評估每個數(shù)據(jù)模型、數(shù)據(jù)報告和API的應用價值；對于質量，會包含監(jiān)控任務覆蓋了多少稽核規(guī)則，涵蓋了多少強弱規(guī)則；對于標準規(guī)范，需要對數(shù)據(jù)標準、指標和模型進行規(guī)范度和復用性的評估；對于安全，會包含數(shù)據(jù)安全等級和數(shù)據(jù)權限的治理等內容的評估。

（2）體系化治理手段

數(shù)據(jù)治理不是一個臨時性要做的工作，從數(shù)據(jù)生命周期的全過程到治理體系的健康運行，需要一個長效的治理機制來保證，體系化的數(shù)據(jù)治理。

• 最開始是發(fā)現(xiàn)問題，包含成本、標準、質量、安全和價值五個方面，明確需要進行治理的內容；
• 然后基于需要治理的內容配套專題的治理工具，比如對無用數(shù)據(jù)的推薦下線，對表生命周期的管理，對計算任務的優(yōu)化等；
• 最后在治理工作過程中，持續(xù)有治理抓手，包括推送整個項目、個人的資產賬單，數(shù)據(jù)治理的紅黑榜，并將資產健康分和個人的任務優(yōu)先級或資源申請等掛鉤
• 持續(xù)運營：例如舉辦數(shù)據(jù)治理大賽、業(yè)務線專項治理活動等來持續(xù)運營和打磨產品的能力。

整體通過發(fā)現(xiàn)問題-->解決問題-->持續(xù)運營和持續(xù)沉淀形成資產治理的閉環(huán)。

（3）強化管理屬性

• 統(tǒng)一數(shù)據(jù)治理控制臺作為所有治理項的入口，一方面是系統(tǒng)預置治理規(guī)則掃描的待治理項，包含成本、質量、安全、規(guī)范和價值五個方面；另一方面是通過工單形式指派給相關治理管理者的治理項；
• 用戶分層，從項目組、項目和用戶角度呈現(xiàn)待治理和已治理項，強化數(shù)據(jù)治理專員這個角色；
• 自定義數(shù)據(jù)治理流程，例如待我治理/待處理工單，數(shù)據(jù)消費者、項目負責人、數(shù)據(jù)治理專員都可以發(fā)起資產的治理工單（比如字段描述缺失、數(shù)據(jù)質量分較低等）系統(tǒng)會將治理工單下發(fā)給資產負責人，所有工單信息都會體現(xiàn)在“待我治理”模塊；
• 數(shù)據(jù)治理的流程定義與企業(yè)組織架構、消息系統(tǒng)如IM等進行打通，形成管理閉環(huán)。

3.3 產品整體方案

經(jīng)過上面的介紹可知我們的數(shù)據(jù)治理產品包含事前和事后兩條路線。覆蓋數(shù)據(jù)的全生命周期（從元數(shù)據(jù)的注冊到數(shù)據(jù)應用消費），包含”先設計再開發(fā)“的事前治理、數(shù)據(jù)健康評估與優(yōu)化（事后治理）這兩條線，以實現(xiàn)建設“規(guī)范的元數(shù)據(jù)”和“好的數(shù)據(jù)”。同時在消費端將健康的資產通過業(yè)務分類和標簽等方式來組織，便于普通用戶在數(shù)據(jù)消費時能“找的到、讀的懂、信的過”。

• 數(shù)據(jù)消費者對數(shù)據(jù)資產有任何問題可以一鍵發(fā)起數(shù)據(jù)治理工單，資產責任人則需要完成響應。
• 資產責任人需要完成系統(tǒng)識別的治理內容和數(shù)據(jù)消費者、負責人、治理負責人發(fā)起的治理內容。
• 項目負責人，治理負責人可以發(fā)起數(shù)據(jù)治理工單。
• 治理負責人包含數(shù)據(jù)治理專員及治理負責人，對企業(yè)數(shù)據(jù)資產質量負責。

3.4 元數(shù)據(jù)數(shù)據(jù)治理滿足的場景

• 元數(shù)據(jù)管理，包含倉內、倉外，手工元數(shù)據(jù)的整體納管，數(shù)據(jù)資產一體化構建企業(yè)統(tǒng)一數(shù)據(jù)資產地圖，讓數(shù)據(jù)消費者找的到、讀的懂、信的過；
• 通過覆蓋元數(shù)據(jù)注冊-采集-掃描-審批-發(fā)布-使用-變更-廢棄的全生命周期，構建一條完整的元數(shù)據(jù)治理鏈路；
• 覆蓋數(shù)據(jù)研發(fā)，數(shù)據(jù)治理，數(shù)據(jù)服務，到數(shù)據(jù)應用的全鏈路數(shù)據(jù)血緣，從而構建基于ROI的數(shù)據(jù)資產沉淀體系和”剝洋蔥“式的從應用到底層的數(shù)據(jù)下線機制；
• 制定和管理企業(yè)的數(shù)據(jù)標準，保障數(shù)據(jù)的內外部使用和交換的一致性和準確性的規(guī)范性
• 構建統(tǒng)一指標庫，消除數(shù)據(jù)的二義性；
• 數(shù)倉模型優(yōu)化，從規(guī)范性，復用性，應用價值上構建健康的數(shù)據(jù)體系；
• 成本治理，包含存儲，計算成本優(yōu)化，降本增效；
• 數(shù)據(jù)質量治理，通過數(shù)據(jù)開發(fā)前數(shù)據(jù)比對，形態(tài)探查，數(shù)據(jù)測試報告，數(shù)據(jù)任務運行中的強弱規(guī)則阻斷下游任務防止數(shù)據(jù)污染，事后提升數(shù)據(jù)質量監(jiān)控覆蓋率等方式全面提升數(shù)據(jù)質量；
• 數(shù)據(jù)安全治理，包含數(shù)據(jù)資產的分類分級，脫敏加密，安全掃描，安全審計，權限治理等。

4、基于邏輯數(shù)據(jù)湖的數(shù)據(jù)治理介紹

我們在調研外部用戶需求的過程中，經(jīng)常會碰到的問題：每個企業(yè)用戶的技術建設情況不同，業(yè)務復雜度也不一，很多傳統(tǒng)企業(yè)已有的IT系統(tǒng)已運行了很多年，只是無法再支持日益增長的數(shù)據(jù)需求，他們在大數(shù)據(jù)技術體系的經(jīng)驗幾乎空白，當面對一個比如lambda架構的大數(shù)據(jù)解決方案時，往往會覺得過于復雜和難以掌握，對落地成效心存疑慮。還有部分用戶的業(yè)務在現(xiàn)有技術框架上（比如MPP）運行良好，出于對未來發(fā)展的前瞻性考慮，需要提前進行大數(shù)據(jù)的基礎技術建設，這部分用戶對于大數(shù)據(jù)未來的必要性是肯定的，但是會特別關心其適用的場景、業(yè)務覆蓋度以及如何平滑地進行業(yè)務的遷移。

數(shù)據(jù)湖&Hadoop解決的是數(shù)據(jù)統(tǒng)一匯聚的問題，而統(tǒng)一元數(shù)據(jù)則是解決數(shù)據(jù)連接、資產、管理的問題，對于相當部分的用戶而言，當前最大的痛點不是海量數(shù)據(jù)的存儲，而是如何將散落到各個子數(shù)據(jù)系統(tǒng)的數(shù)據(jù)孤島統(tǒng)一管控起來。因此通過構建一個邏輯層面的數(shù)據(jù)湖，實現(xiàn)統(tǒng)一的元數(shù)據(jù)+分散的物理存儲，避免不必要的物理數(shù)據(jù)入倉（湖），從而將產品上層功能比如主題域構建、數(shù)據(jù)地圖等等及早給用戶使用才是解決問題的根本之道，邏輯數(shù)據(jù)湖方案，依然可以使用物理湖&Hadoop，同時提供通過虛擬表直連數(shù)據(jù)源的方案將其他類型的數(shù)據(jù)源也納入平臺的管控中，用戶可以根據(jù)實際的需要選擇適合的存儲方案。

我們的構建方法論主要分為如下三個大的層面：

數(shù)據(jù)源支持類型：除了Hadoop（Hive）體系，MPP、RDMS、HTAP、KV、MQ等都需要支持，并且一視同仁，都可以作為具體邏輯數(shù)據(jù)湖具體對象的物理存儲。

統(tǒng)一數(shù)據(jù)源 & 統(tǒng)一元數(shù)據(jù)：統(tǒng)一數(shù)據(jù)源要做的是規(guī)范每種數(shù)據(jù)源的登記注冊，包括數(shù)據(jù)源URL格式、數(shù)據(jù)源Owner、唯一性校驗、賬號映射、聯(lián)通性校驗、支持的版本、特定的參數(shù)等；統(tǒng)一元數(shù)據(jù)，則是將數(shù)據(jù)源的技術（物理）元信息和業(yè)務元信息進行關聯(lián)，提供統(tǒng)一的查詢修改接口。

統(tǒng)一數(shù)據(jù)開發(fā)、治理和查詢分析：這三個屬于構建在統(tǒng)一元數(shù)據(jù)&數(shù)據(jù)源基礎之上的應用層。統(tǒng)一的數(shù)據(jù)開發(fā)，包括不同物理數(shù)據(jù)源之間的交換、離線&實時開發(fā)、同源&跨源查詢；統(tǒng)一的數(shù)據(jù)治理，則包括數(shù)據(jù)主題建設、權限管控、數(shù)據(jù)生命周期、資產地圖等；統(tǒng)一查詢分析，則是在完成數(shù)據(jù)主題建設、數(shù)據(jù)開發(fā)產出以后，提供同源&跨源的模型分析能力。