一、數(shù)據(jù)背景

首先來介紹一下業(yè)務(wù)背景和數(shù)據(jù)現(xiàn)狀。

云音樂在過去九年中發(fā)布過九款獨(dú)立的產(chǎn)品，包括國內(nèi)產(chǎn)品和海外產(chǎn)品。國內(nèi)產(chǎn)品除了大家熟知的網(wǎng)易云音樂之外，還有五款社交類型的產(chǎn)品。海外主要打造了三款社交類型的產(chǎn)品。所有產(chǎn)品的數(shù)據(jù)支撐都在數(shù)倉開發(fā)部門。

從數(shù)據(jù)角度來看，在過去的八九年中，做過一系列的重構(gòu)和迭代工作，在這個(gè)背景下，我們從多個(gè)角度對數(shù)據(jù)現(xiàn)狀進(jìn)行了分析：

（1）在規(guī)模上，目前承載的產(chǎn)品有九個(gè)，線上正在調(diào)度的任務(wù)有 2 萬個(gè)以上，表數(shù)量有 5 萬多張。目前我們在猛犸數(shù)據(jù)開發(fā)平臺上制作申請的項(xiàng)目有 12 個(gè)，數(shù)據(jù)方面直接觸達(dá)的用戶群體有 600 個(gè)以上。

（2）成本方面，日存儲量有 80 多 PB，存儲費(fèi)用在 19 萬以上，計(jì)算方面日常調(diào)度的任務(wù)成本是 27 萬。

（3）質(zhì)量方面，之前在核心時(shí)段的資源水位是非常高的，在 95% 以上，對整體基線運(yùn)維造成了比較大的風(fēng)險(xiǎn)。初期隊(duì)列的使用也比較混亂，使用的姿勢也是各式各樣的，為數(shù)據(jù)運(yùn)維帶來了比較大的困難。

（4）效率上，由于歷史原因，有大量任務(wù)跑在 Hive 和 Spark2 引擎上，存在著資源效率，以及小文件等問題。另外，由于前期數(shù)倉建設(shè)內(nèi)容推廣覆蓋的不到位，存在大量的任務(wù)直接去讀 ODS 原表，特別是對于日志數(shù)據(jù)存在大量的小需求，耗費(fèi)資源。

（5）環(huán)境方面，目前國內(nèi)我們有五套 Hadoop 集群，海外包括 AWS 和阿里云。

總體來講，目前數(shù)據(jù)面臨的問題是：體量大、環(huán)境雜、缺規(guī)范和資源浪費(fèi)。

二、治理思路

接下來介紹在上述數(shù)據(jù)背景下，我們是如何去明確治理方向的。

首先，從技術(shù)視角來看，在大數(shù)據(jù)體制下，數(shù)據(jù)內(nèi)容的分布情況如上圖所示。文件都是存儲在 Hadoop 集群的 HDFS 文件系統(tǒng)中；在 HDFS 文件系統(tǒng)之上，我們會建立一系列 Hive 庫和表來管理數(shù)據(jù)；數(shù)據(jù)開發(fā)會在上面進(jìn)行模型設(shè)計(jì)和數(shù)據(jù)分層設(shè)計(jì)；再往上則是數(shù)據(jù)處理方面的內(nèi)容，包括任務(wù)調(diào)度、執(zhí)行引擎等。

隨著業(yè)務(wù)的快速發(fā)展，數(shù)倉的不斷迭代， 每塊內(nèi)容可能或者必然存在著哪些問題：

（1）在數(shù)據(jù)保障方面，存在大量任務(wù)仍然運(yùn)行在 Hive 和 Spark2 引擎上，存儲、計(jì)算、小文件問題都存在較大提升空間。

（2）在模型設(shè)計(jì)合理性上，存在依賴混亂、使用姿勢暴力粗糙和庫表大量閑置的問題，造成資源的過度浪費(fèi)，影響改造重構(gòu)的效率。

（3）缺乏管理規(guī)范，數(shù)據(jù)庫擴(kuò)展不受限制，用途不詳，同時(shí)建表方式凌亂，存在大量不規(guī)范表，為之后的移交和管理工作帶來了較大困擾。

（4）缺乏有效的管理監(jiān)控內(nèi)容，導(dǎo)致出現(xiàn)了大量的系統(tǒng)級無效文件和數(shù)據(jù)級無效文件，直接影響了 Hadoop 集群的穩(wěn)定性。

在明確了具體的治理方向之后，我們要做的就是如何在這些方向找到具體的治理內(nèi)容。

（1）首先，我們在 HDFS 文件上定義了游離 HDFS 文件的概念，這種文件存在于 Hadoop 系統(tǒng)里面，但是沒有任何的表或者任務(wù)去直接使用它。要定位這種文件，就要用到 HDFS 元數(shù)據(jù)信息；

（2）其次，針對庫表的使用現(xiàn)狀，我們需要用到庫表元數(shù)據(jù)信息，對現(xiàn)有的庫表進(jìn)行梳理；

（3）另外，在模型設(shè)計(jì)合理性方面，我們引入了三度指標(biāo)的概念，通過三度指標(biāo)去衡量整個(gè)模型建設(shè)的健康度，而三度指標(biāo)的計(jì)算需要用到數(shù)據(jù)血緣的信息；

（4）最后，在任務(wù)調(diào)度方面有著較大的提升空間，我們要對任務(wù)進(jìn)行梳理，需要用到全局的任務(wù)執(zhí)行元數(shù)據(jù)信息。

所有的問題都指向了同一個(gè)方向，就是我們要獲取到完整準(zhǔn)確的元數(shù)據(jù)信息，只有這樣才能進(jìn)行有效的數(shù)據(jù)治理。

三、治理方案

這一章節(jié)將介紹我們的治理方案。

從元數(shù)據(jù)出發(fā)，首先是從猛犸平臺上獲得了比較完備的元數(shù)據(jù)信息，包括表的元數(shù)據(jù)信息，以及任務(wù)的元數(shù)據(jù)信息?；谶@些元素信息進(jìn)行數(shù)據(jù)建模，在 CDM 層產(chǎn)出了比較豐富的模型，可以從各種視角看到整個(gè)資產(chǎn)的情況，以及模型設(shè)計(jì)健康度的情況，可以從平臺的視角來看我們整個(gè)平臺的變化情況，也可以按數(shù)據(jù)使用團(tuán)隊(duì)去看不同團(tuán)隊(duì)在使用過程中的成本情況。整個(gè)元數(shù)據(jù)建模支撐了云音樂的整個(gè)數(shù)據(jù)治理體系。

上圖描述了整個(gè)云音樂數(shù)據(jù)治理體系的內(nèi)容，基于元數(shù)據(jù)建模，數(shù)據(jù)治理事項(xiàng)包括：建監(jiān)控、定規(guī)范、搭工具、做治理。前三個(gè)動作都是為了做治理而去做準(zhǔn)備，同時(shí)在做治理的過程中也會去反哺前三項(xiàng)，做治理的過程中也可以逐步豐富規(guī)范內(nèi)容，同時(shí)也可以進(jìn)一步沉淀和落地監(jiān)控及工具。

整個(gè)治理過程遵循的治理原則為：治理有依據(jù)，權(quán)責(zé)有歸屬，機(jī)制可持續(xù)，效果可回收，方法可沉淀。

四、治理實(shí)踐

在前文提到的治理原則中，權(quán)責(zé)有歸屬和機(jī)制可持續(xù)是在整個(gè)治理事項(xiàng)推進(jìn)過程中的兩個(gè)技能點(diǎn)，只有明確了這兩個(gè)內(nèi)容，在后面的推動中才能夠更加順暢的進(jìn)行。因此在治理實(shí)踐中，首先要做的就是權(quán)責(zé)有歸屬。

1、權(quán)責(zé)有歸屬

所有的數(shù)據(jù)、表和任務(wù)都應(yīng)該有具體的責(zé)任人對其負(fù)責(zé)，這樣在發(fā)現(xiàn)問題時(shí)才能找到具體的人去進(jìn)行處理。目前在權(quán)責(zé)有歸屬這部分做了三件事情：ODS 任務(wù)和表的歸屬操作、離職人員任務(wù)和表的歸屬操作，以及項(xiàng)目賬號表的歸屬治理。

2、機(jī)制可持續(xù)

在推進(jìn)過程中，面臨的問題是具體要做的治理事項(xiàng)需要覆蓋到不同的團(tuán)隊(duì)或者不同的部門去執(zhí)行，而且每個(gè)具體事項(xiàng)的治理動作也是多元化的，不同業(yè)務(wù)團(tuán)隊(duì)以及不同人的認(rèn)知以及能力、精力的投入都是不一樣。因此，我們統(tǒng)一建立了一個(gè)通用的推進(jìn)機(jī)制，以及一個(gè)通用的治理原則。

在推進(jìn)機(jī)制方面，我們建立了一個(gè)專項(xiàng)機(jī)制，明確治理內(nèi)容以及相應(yīng)的價(jià)值。在治理過程中，我們會把做要做的具體動作進(jìn)行公示，比如郵件公示或者群公示的方式，公示之后才進(jìn)行下一個(gè)操作。操作之后如果發(fā)現(xiàn)問題，可以進(jìn)行回滾操作。

治理原則為：

（1）“源頭”干凈，保證源頭數(shù)據(jù)治理干凈。

（2）“復(fù)雜”二八，對于復(fù)雜的情況，保證通過較少的投入獲得更高的收益。

（3）“穩(wěn)定”保障，盡可能保證線上的穩(wěn)定。

3、具體實(shí)踐

（1）HDFS 層面-游離 HDFS 文件治理

首先針對前文中提到的游離文件問題，我們通過行業(yè)給到的表元數(shù)據(jù)信息以及文件的元數(shù)據(jù)信息進(jìn)行匹配和關(guān)聯(lián)，定位出游離文件，再根據(jù)游離文件中的審計(jì)信息去判斷這些文件是不是真正的無效文件。我們目前達(dá)到的效果是下線存儲達(dá)到 7P 以上的邏輯存儲，清理掉的文件數(shù)量在 450 萬以上，為 Hadoop 元數(shù)據(jù)釋放了比較大的壓力。

（2）庫表層面-庫治理

在數(shù)據(jù)庫方面，目前數(shù)據(jù)服務(wù)的角色是非常多的，除了數(shù)倉、算法、數(shù)據(jù)產(chǎn)品之外，還有業(yè)務(wù)服務(wù)端、廣告和安全中臺等等。由于之前我們對數(shù)據(jù)庫的管控不是很到位，導(dǎo)致存在非常多的庫，有很多庫的用法也不透明，一些庫的作用不明確，還有一些庫不合規(guī)。在這種情況下，我們進(jìn)行了一系列的數(shù)據(jù)庫治理操作，最后把數(shù)據(jù)庫審批權(quán)限進(jìn)行回收。

（3）庫表層面-表治理

在表治理方面也進(jìn)行了許多的實(shí)踐，包括臨時(shí)表治理專項(xiàng)、生命周期治理規(guī)范、巨型表治理專項(xiàng)和 A/B test 治理專項(xiàng)。

（4）模型設(shè)計(jì)層面-“三度”指標(biāo)治理

在模型設(shè)計(jì)層面，制定了“三度”指標(biāo)治理方案，包括健康度、價(jià)值度和進(jìn)度指標(biāo)。其中健康度包括復(fù)用率和穿透率，價(jià)值度包括資產(chǎn)規(guī)范率和資產(chǎn)引用率，進(jìn)度指標(biāo)包括覆蓋率和閑置率。

覆蓋率和閑置率是針對 ods 表利用率的一個(gè)衡量。通過對 ods 層表的治理可以進(jìn)一步提升覆蓋率，降低閑置率。這個(gè)過程中我們可以下線大量的無效 ods 表以及相應(yīng)的任務(wù)。

復(fù)用率和穿透率是用來反饋我們 cdm 層表引用健康度情況，目前通過一系列的治理。復(fù)用率已經(jīng)由 30% 提升到了 60%，穿透率由 20% 下降到了 10%。

資產(chǎn)規(guī)范率和資產(chǎn)引用率是針對我們 cdm 層表的規(guī)范化情況的一個(gè)衡量，這兩個(gè)指標(biāo)我們是保持在 85% 以上，并且通過一系列的規(guī)范落地，指標(biāo)會逐步提升。

通過三度指標(biāo)的一個(gè)治理，可以清理掉大量無效的任務(wù)和表，在存儲資源和計(jì)算資源上可以減少不少成本。

（5）數(shù)據(jù)處理層面-計(jì)算治理

計(jì)算治理當(dāng)前階段主要是針對計(jì)算引擎升級做治理。

云音樂集群是在 2021 年年中上線了 Spark3 執(zhí)行引擎，經(jīng)過大半年的使用，我們確實(shí)在 Spark3 上體驗(yàn)到了非常棒的效果，杭研的數(shù)科同學(xué)也在 Spark3 上進(jìn)一步做了大量的優(yōu)化，例如 AQE 增強(qiáng)優(yōu)化、zorder 功能以及 shuffle 階段采用 zstd 壓縮算法。為了能夠更好的兼容升級過程，杭研也在 Spark 引擎上內(nèi)置了大量優(yōu)化參數(shù)。當(dāng)前 Spark3 引擎在計(jì)算資源、存儲資源、小文件問題上獲得了大幅的提升。在這個(gè)背景下我們在 2022 年 Q2 階段開始任務(wù)遷移至 Spark3 的專項(xiàng)。涉及的遷移事項(xiàng)有：

（1）Hive 遷移 Spark3。

（2）Spark2 版本的 SQL 任務(wù)遷移至 Spark3。

（3）核心任務(wù)和高成本任務(wù)的 Spark3+zorder+gzip 升級。

（4）Spark 工程任務(wù)遷移 Spark3 的專項(xiàng)。

每一項(xiàng)在節(jié)省資源上都獲得了巨大的提升。

五、治理成果

1、成本收益

通過數(shù)據(jù)治理，我們?nèi)〉昧艘幌盗械某晒?/span>

（1）首先，在存儲方面，一年可以節(jié)省 2500 萬人民幣，累計(jì)下線存儲 30P+，占整體存儲的 30%，同時(shí)放緩了表的增速，從日增 170T 下降至 55T。

（2）其次，是在計(jì)算資源上的節(jié)省，通過一系列任務(wù)的治理，在核心任務(wù)執(zhí)行過程中可以節(jié)約 30% 的資源，集群的穩(wěn)定性也得到了一定的提升。

（3）在臨時(shí)表和無效表的治理方面，減少了 25000 張表，表的數(shù)量由原來的 5.5W 下降到 3W。

2、治理資產(chǎn)沉淀-治理大盤

在整個(gè)治理過程中我們也將方法論和治理思路沉淀了一系列的可視化監(jiān)控看板和治理跟進(jìn)工具，確保整個(gè)治理事情是有序進(jìn)行并且過程可控的。

沉淀的治理大盤，包括：數(shù)據(jù)資產(chǎn)沙盤、“三度”指標(biāo)概覽、計(jì)存費(fèi)用沙盤和治理效果看板。

3、治理資產(chǎn)沉淀-治理跟進(jìn)工具

同時(shí)，針對每一項(xiàng)治理，我們都有產(chǎn)出一些治理跟進(jìn)工具，包括：個(gè)人指標(biāo)治理報(bào)告、臨時(shí)表治理報(bào)告、復(fù)用率治理列表和推薦歸屬治理監(jiān)控等。

4、數(shù)倉開發(fā)規(guī)范沉淀

治理過程中我們也逐步豐富了我們的數(shù)據(jù)開發(fā)規(guī)范。包括：數(shù)據(jù)庫使用規(guī)范、臨時(shí)表建表規(guī)范、任務(wù)節(jié)點(diǎn)命名規(guī)范、隊(duì)列使用規(guī)范、任務(wù)上線規(guī)范和數(shù)據(jù)下線流程規(guī)范。

六、未來規(guī)劃

數(shù)據(jù)治理是一個(gè)長期而且持續(xù)要做的事情，如何在治理的過程中達(dá)到更好的效果，我們一直秉持著一個(gè)治理理念：從分散到集約、從被動到主動到自動、從經(jīng)驗(yàn)到智能。

整個(gè)治理動作分為三部分，包括：事前、事中和事后。事前可以進(jìn)行預(yù)防性治理，推廣數(shù)據(jù)白皮書使用等；事中實(shí)現(xiàn)各類治理監(jiān)控指標(biāo)工具落地，及時(shí)發(fā)現(xiàn)問題并反饋；事后可以治理指引報(bào)告，給出治理理由、治理方案，也可以提供更便捷有效的治理工具。