一、數據治理的概況和解法

騰訊 PCG 內容與平臺事業群，包括大家所熟知的 QQ、騰訊視頻、騰訊新聞、閱文集團，以及騰訊音樂等業務。在沒有治理平臺之前，數據治理是運動式的，有兩個比較大的難點：

• 數據量大且復雜。每天大概有萬億級別的數據增量，而且數據的格式多樣化，覆蓋文本、圖文、長短視頻與語音等各種結構化、非結構化數據。
• 數據技術架構復雜。騰訊內部有多個業務，每個業務又有很多產品線，每個產品線用的技術架構又不盡相同。調度系統有用 Venus 的，也有用 US 的；數據治理腳本開發有用 pySQL 或 pySpark 的，也有用 Hive 的，還有用內部 SQL 腳本的。

數據治理的困境，可以從面向的不同用戶的不同場景來看：

• 管理層。作為業務負責人，需要控制成本、減少浪費，需要持續關注成本的變化，對未來做預估。為了把成本壓下來，需要跟團隊開很多次會議，定目標、過進展、報風險。但由于缺乏數據的深度治理和挖掘，以及數據治理平臺，對數據治理任務的選擇，難易、風險評估等，缺少定性、定量的方法。
• 數據管理者。作為一線數據 leader，定下了目標，怎么定策略、如何推進，也有難度。對于數據治理的整體鏈路，各個結點（如埋點、傳輸、計算等）的情況，也缺少及時準確的信息。數據治理任務推進困難。
• 一線數據人。作為數據生產者，每天需求已經很多了，還要關注老板定的成本目標。不斷地分析哪里可優化，性能滿不滿足要求，如何優化。簡單的治理可以做，復雜的涉及面廣的就難以實施。

綜上，原數據治理多為運動式、脈沖式的，成本高、效率低，需要新的數據治理解決方案，優化數據治理任務。

對于管理者，數據可用性差，成本日益增長，治理任務難推進。我們希望通過提供一套整體的解決方案，把一些日常的治理策略平臺化和工具化，將經驗沉淀下來。具體來說，提供三個功能：

• 幫助管理者看清楚大盤，了解資源利用率，發現治理機會；
• 輔助管理者去制定治理策略，并向相關人員推送，推進執行；
• 對數據治理的效果進行復盤，并輔助管理者推進迭代和優化，將運動式治理變成常態化治理。

對于數據生產者，數據治理推進難有三個原因：

• 治理能力參差不齊，治理門檻相對較高。
• 降本提效背景下，需要高效完成治理。
• 個人治理效果難衡量，治理積極性差。

我們為數據生產者提供平臺，以降低數據治理門檻，一站式完成治理執行。例如對于某表，生命周期是 180 天，但我們發現，該表只用到最近 7 天，大部分時間都是浪費的，那么可以一鍵推送治理，修改生命周期，降低存儲。對于某些做備份的任務，通過提供一系列和各個系統交互的接口，可以一鍵完成數據備份，從而降低數據治理的門檻。

基于一站式數據治理平臺，我們建立了一個“長效”治理的方法論體系。

從用戶角色層看，支持數據管理者和數據 owner 兩種用戶角色。

對于數據管理者。我們為其提供多領域、多維度的視角，提供資產盤點和元倉建設兩類解決方案。

• 資產盤點：比如通過對各組織的中間件、存儲、隊列等，提供各種維度下的資產詳情，來幫助管理者看清楚資產的分布，進而輔助他進行下一步的治理。
• 基于元倉建設，我們抽象出很多治理策略來提供治理服務。

為支持資產盤點和元倉建設，從產品架構層，還抽象出了資產分，通過對用戶下各類資產的打分和匯總，來代表用戶所有資產的大致水平，資產分可以匯總到組織甚至業務 BG 粒度。資產分可以匯總用戶資產的健康度、水位。

后面會介紹數據治理引擎，對所有資產不合理的地方進行抽象，得到一些治理項。這些治理項本身又是和資產分析掛鉤的，如果資產項治理得好，資產分就會越來越高，如果長久不處理，那資產分可能會停止甚至會下降。通過資產分，管理者更易定KPI，也方便執行。

如上圖，數據治理平臺整體產品架構的演進過程，包括三個步驟：

• 第一步，實現治理工具化。比如，先盤點所有離線表資產情況，然后生成治理項并制定治理方案，再將方案發給數據 owner 進行執行，最后對治理效果進行復盤，最后再重復這個流程。
• 第二步，大數據全鏈路治理。對于一些中間環節，第一步已成功，就可以對其它治理對象應用這個模式。我們最早做的數據表，后面對整個數據生產鏈路里面的每一個環節，包括埋點上報、數倉加工、對外服務整個流程里的中間節點，都按照這個模式進行治理。如，埋點這里的治理項包括：參數空值率、參數異常率、事件重復率、事件丟失率等，并最終形成資產分。
• 第三步，業務自定義治理。通過支持個性化治理，提升產品通用性。

以上對數據治理的現狀、困難以及解決的路徑進行了概要的介紹。接下來介紹實現數據治理的一些關鍵工作。

二、騰訊 PCG 元倉建設：專注特征挖掘、構建治理引擎基石

在元倉建設層，我們專注于特征挖掘，這里包括三個方面：

• 全鏈路的數據整合清洗
• 全鏈路的血緣構建
• 基于血緣數據的治理特征挖掘

1、資源整合

如上圖，資源整合自下而上，依次包括數據源、基礎層、資產層、應用層。

數據源層：包括任務調度平臺 US 和 VENUS、報表平臺 data talk 和 data insight、以及一些數據鏈路加工平臺、業務數據庫，以及實驗信息、臨時查詢等生產工具。為了保證數據準確和及時，大多數據是近實時的，通過消息隊列獲取，離線也每天同步并進行整合。

基礎層：獲取所有數據后，會進行標準化治理。

資產層：重點考慮數據熱度以及數據間的依賴關系，包括數據鏈路血緣、任務間依賴、寬表、出入庫模型等。

應用層：最后通過應用層，實現數據的高質量交付。這里，一方面，需要全面梳理以發現數據治理的機會和價值。另一方面，也要保證整體產出的時效性以及質量。

應用層有個重點是成本分攤，即對每個細粒度的資源，都和成本進行關聯。如一個表等，我們可以知道它的存儲成本、計算成本。任何一種資源包括隊列、埋點、上報等，都和成本關聯，就可以清楚地知道，進行數據治理，可以帶來多少成本收益。

2、全鏈路實時血緣

上圖表示了大部分數據的加工流程：從前端埋點到上報，經過消息隊列，離線、實時加工任務，到最終展現。我們對整個過程方案中所有的中間件實體進行抽象，挖掘出實體關聯的可治理屬性，包括成本、用量等，形成一個大圖。

形成血緣大圖后，通過圖算法，可以做很多工作。比如，發現無用的數據看板，并順著圖，發現看板上游無用的節點，一直往前走，直到埋點上報表層。這樣就可以一起處理，節省成本。

數據治理平臺的血緣解析模型，也就是 SQL 解析模塊。支持 4 種腳本類型：

• SuperSQL，騰訊內部的查詢語句，屏蔽了多種常用 SQL 之間的差異性，使用 Calcite 定制解析。
• Thive，為了解決早期版本的性能問題內部定制的 Hive 版本，定制化 Antlr3 解析。
• Hive，原生 Antlr3/4 解析。
• Spark 腳本，主要指 Spark SQL，Antlr4 解析。

我們通過血緣解析引擎，定義了增強型的語法結構，屏蔽不同 SQL 腳本的差異性，對外提供統一視圖。

其中，基礎語法結構，包括實體、邏輯、模型三部分。

• 實體，是指 SQL 讀了哪些表，有哪些字段。
• 邏輯，是指表之間是如何關聯，字段如何篩選，加工邏輯是什么，以及針對 UDF 定義的關系。
• 模型，主要是從語義層面分析，這個 SQL 是干什么的。

有了上面的語法結構，就能夠做一些深層次的特征挖掘。如兩個 SQL 是否相似，只是一個比另一個多幾個字段；或者某個表，很多字段下游根本沒有引用，那么可以做冷字段處理。

血緣解析模塊支持表級和字段級血緣解析，也可以自定義解析配置。用戶可以使用一些接口，根據提供的模型，直接解析所需內容。我們也提供了協議解析模塊的SDK，可以從 maven 庫引入使用。

3、治理特征挖掘

元倉建設中最關鍵的是挖掘治理特征，但治理特征和治理項之間有一定的 gap。

下面，我們從簡單的治理項講起，根據特征通過簡單的規則就可以實現治理。例如：

• 表熱度?？梢杂萌N不同的原數據，一是查看表是否被任務調度系統的任務使用；二是這個表有沒有被臨時查詢，是否經常被使用；三是掃描表底層文件的讀取，是否被使用。通過這些數據，計算出表熱度，并根據表熱度生成一系列的治理項。
• 字段熱度。同樣的，根據血緣模塊直接生成。

更復雜的一些挖掘特征，可能需圖算法來處理。比如重復計算，如何判斷兩個 SQL 相似？通過血緣分析，也可以發現跨層依賴、穿透等違反開發規范的情況。

在這一章節中，我們通過元倉建設和血緣分析，發現一些治理特征，為進一步形成治理項提供了基礎。

三、資產分體系：開放、可持續迭代的資產分體系

1、資產分-衡量數據資產健康度的核心指標

下面介紹資產分體系，從五個維度對所有資產進行細粒度的刻畫。

• 規范分。包括命名規范：是否遵循標準的市場分層，是否有業務語義等；注釋規范；依賴規范等。
• 成本分。包括計算成本和存儲成本。
• 安全分。包括歸屬合規：是否存在有離職或者轉崗的同學，或者權限不合格的情況；安全等級；敏感字段加固：有沒有敏感字段直接是裸數據。
• 質量分。
• 應用分。

通過這 5 個維度可以看出，資產分，不僅考慮了成本，也考慮了規范和安全方面情況。

2、特征工程&扣分規則

資產分基于扣分規則來生成。使用的特征包括前面幾個維度的一些細則，比如：安全字段沒有加固，扣 10 分；表注釋不規范，扣幾分。對每個維度，不同特征的治理項都做了扣分，匯總后，分數越高，說明資產的質量越高。若分數較低，就需要推動去做治理。

3、引入規則引擎、低 ETL 代碼

如何根據特征生成治理項，并最終生成資產分？這里依賴特征中間層以及生成治理項的規則引擎。

針對特征，我們構建了標準化結構化的治理中間層，包括對象、維度、特征三個要素。其中，特征有兩類：

• 直接特征：經過復雜算法加工出來的定性的結論。如是否存在跨層依賴，是否重復計算；
• 間接特征：可供進一步挖掘的特征。比如：近 XX 天無人訪問，隊列使用率 X% 等。

特征和治理項之間還有 gap。比如說近多少天無人，近 3 天無人訪問，這是個特征，但它不一定是個治理項。有的業務近一天不訪問，就需要治理，有的業務 90 天沒人訪問也無所謂，不需處理。再比如隊列使用率 80% 就一定治理嗎？不一定。

所以，需要把特征轉化成治理項?？梢酝ㄟ^引入規則引擎，采用界面的方法，生成一些業務自定義的治理項。

• 通過將各治理項歸屬到資產分的五個分類里，可以得出整個資產分的值。
• 通過標準化治理分層，利用中間層，將產品方案和前端元數據解耦；也就是對于其它公司，若已有元倉，只需要將這些特征灌到治理中間層，不需任何改動，就可以直接生成一套數據。

4、治理引擎數據全流程

上圖展示了治理引擎數據的全流程。

首先，治理項規則引擎接收治理對象的特征和一些定性結論，根據配置文件，將這些特征識別成治理項；然后，打分規則引擎根據治理項打分，根據另外一個配置文件，計算出在各分類下分值；最后，將這個分值推送給用戶，同時治理項的明細和個人及組織綁定，打包成治理方案推送給管理者及一線數據 owner。

四、治理工作臺：一站式治理平臺

下面，我們介紹一下一站式治理平臺的具體實現，主要包括以下功能：

1、看清業務資產及成本現狀

從管理員的視角，按 HR 系統的架構，進行資產歸屬，將所有數據歸屬到個人，方便管理。并看清當前業務的資產現狀，資產分，資產率，以及資源的明細。通過這些，來幫助管理層發現大數據的問題及治理機會。

2、管理者制定治理方案

平臺內置了 100+ 治理項，覆蓋從埋點到應用的整個環節，并可以根據不同的粒度自定義治理項，定制治理方案。管理者可一鍵催辦，讓一線的數據 owner 去執行對應的治理方案。

3、數據 Owner 執行治理

平臺為數據 owner 提供一站式的治理工作臺，對于一些基本操作，比如刪表等，提供一鍵性的操作。用戶，不僅包括數據開發者，也包括運營或產品同學，都可以看到自己的數據資產明細，包括資產分、排名、數量等。

4、治理效果復盤

無論是管理者還是數據 Owner，通過平臺可以了解一段時間的治理效果，成本節省了多少，資產分提升了多少。每個月都會向組織和個人推送治理報告。