一、數(shù)據(jù)治理的概況和解法

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

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

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

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

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

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

• 幫助管理者看清楚大盤，了解資源利用率，發(fā)現(xiàn)治理機會；
• 輔助管理者去制定治理策略，并向相關人員推送，推進執(zhí)行；
• 對數(shù)據(jù)治理的效果進行復盤，并輔助管理者推進迭代和優(yōu)化，將運動式治理變成常態(tài)化治理。

對于數(shù)據(jù)生產(chǎn)者，數(shù)據(jù)治理推進難有三個原因：

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

我們?yōu)閿?shù)據(jù)生產(chǎn)者提供平臺，以降低數(shù)據(jù)治理門檻，一站式完成治理執(zhí)行。例如對于某表，生命周期是 180 天，但我們發(fā)現(xiàn)，該表只用到最近 7 天，大部分時間都是浪費的，那么可以一鍵推送治理，修改生命周期，降低存儲。對于某些做備份的任務，通過提供一系列和各個系統(tǒng)交互的接口，可以一鍵完成數(shù)據(jù)備份，從而降低數(shù)據(jù)治理的門檻。

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

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

對于數(shù)據(jù)管理者。我們?yōu)槠涮峁┒囝I域、多維度的視角，提供資產(chǎn)盤點和元倉建設兩類解決方案。

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

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

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

如上圖，數(shù)據(jù)治理平臺整體產(chǎn)品架構的演進過程，包括三個步驟：

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

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

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

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

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

1、資源整合

如上圖，資源整合自下而上，依次包括數(shù)據(jù)源、基礎層、資產(chǎn)層、應用層。

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

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

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

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

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

2、全鏈路實時血緣

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

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

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

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

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

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

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

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

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

3、治理特征挖掘

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

下面，我們從簡單的治理項講起，根據(jù)特征通過簡單的規(guī)則就可以實現(xiàn)治理。例如：

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

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

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

三、資產(chǎn)分體系：開放、可持續(xù)迭代的資產(chǎn)分體系

1、資產(chǎn)分-衡量數(shù)據(jù)資產(chǎn)健康度的核心指標

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

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

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

2、特征工程&扣分規(guī)則

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

3、引入規(guī)則引擎、低 ETL 代碼

如何根據(jù)特征生成治理項，并最終生成資產(chǎn)分？這里依賴特征中間層以及生成治理項的規(guī)則引擎。

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

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

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

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

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

4、治理引擎數(shù)據(jù)全流程

上圖展示了治理引擎數(shù)據(jù)的全流程。

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

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

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

1、看清業(yè)務資產(chǎn)及成本現(xiàn)狀

從管理員的視角，按 HR 系統(tǒng)的架構，進行資產(chǎn)歸屬，將所有數(shù)據(jù)歸屬到個人，方便管理。并看清當前業(yè)務的資產(chǎn)現(xiàn)狀，資產(chǎn)分，資產(chǎn)率，以及資源的明細。通過這些，來幫助管理層發(fā)現(xiàn)大數(shù)據(jù)的問題及治理機會。

2、管理者制定治理方案

平臺內(nèi)置了 100+ 治理項，覆蓋從埋點到應用的整個環(huán)節(jié)，并可以根據(jù)不同的粒度自定義治理項，定制治理方案。管理者可一鍵催辦，讓一線的數(shù)據(jù) owner 去執(zhí)行對應的治理方案。

3、數(shù)據(jù) Owner 執(zhí)行治理

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

4、治理效果復盤

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