一、音樂數(shù)據(jù)平臺的規(guī)模和現(xiàn)狀

我們通過數(shù)據(jù)平臺整合技術(shù)和業(yè)務(wù)，對業(yè)務(wù)賦能，使用戶能夠高效、穩(wěn)定、安全、經(jīng)濟(jì)和準(zhǔn)確地使用數(shù)據(jù)。

云音樂是網(wǎng)易集團(tuán)一個(gè)比較大的BU，我們基于集團(tuán)的數(shù)據(jù)平臺數(shù)帆結(jié)合音樂的業(yè)務(wù)打造了面向音樂業(yè)務(wù)的相對垂類的數(shù)據(jù)開發(fā)平臺 - 云村數(shù)據(jù)平臺。我們的用戶和網(wǎng)易數(shù)帆有些不同，我們的用戶主要是音樂的開發(fā)。云音樂經(jīng)過10年的發(fā)展，已經(jīng)到了一個(gè)人人用數(shù)據(jù)的階段。除數(shù)倉開發(fā)以外，技術(shù)中心的開發(fā)、前端、后端、QA、甚至一些非技術(shù)的運(yùn)營都會用我們的平臺來使用數(shù)據(jù)、做數(shù)據(jù)處理工作。

我們的很多組件是基于業(yè)務(wù)需求定制的，希望能夠減少用戶的使用成本，讓數(shù)據(jù)開發(fā)工作的門檻更低，可以更高效、更安全地處理數(shù)據(jù)、使用數(shù)據(jù)。

我們提供了很多能力，除基礎(chǔ)的JAR包任務(wù)、SQL等，我們還根據(jù)業(yè)務(wù)的需求做了很多定制模塊，例如實(shí)時(shí)NoteBook、離線數(shù)據(jù)傳輸、離線數(shù)據(jù)郵件、離線NoteBook、離線數(shù)據(jù)流等等，并基于這些基礎(chǔ)組件打造了批流一體的低代碼的平臺FastX，這是我們近兩年在做的主要工作，一切都圍繞業(yè)務(wù)需求來建設(shè)。

云音樂上線十年左右，我們的平臺建設(shè)也已經(jīng)有五年多的時(shí)間，累計(jì)用戶超過800，每天的UV有200多，因?yàn)榇蟛糠钟脩舳际欠菙?shù)倉專業(yè)的數(shù)據(jù)開發(fā)，所以面對的問題就更多。

業(yè)務(wù)類型上，主要場景有算法特征開發(fā)、樣本生成、索引構(gòu)建、內(nèi)容監(jiān)控、數(shù)據(jù)報(bào)表、線上統(tǒng)計(jì)服務(wù)等等，支撐音樂主站、直播、心遇等所有音樂的業(yè)務(wù)。

任務(wù)規(guī)模上，我們目前的離線調(diào)度任務(wù)有7000+，執(zhí)行中的實(shí)時(shí)任務(wù)有1500+，比較好的是我們80%以上的任務(wù)都是基于平臺現(xiàn)成的組進(jìn)行開發(fā)的，而不是自由度更高但是運(yùn)維更難的JAR包任務(wù)，這對于我們?nèi)粘＿\(yùn)維支持工作是非常有利的，我們能夠很清楚地知道用戶的業(yè)務(wù)邏輯，更加方便地進(jìn)行指導(dǎo)和優(yōu)化。

集群規(guī)模上，我們目前的計(jì)算節(jié)點(diǎn)有2000多臺，每天的日志量達(dá)到千億級別，在這個(gè)數(shù)據(jù)量的背景下，整體穩(wěn)定性還是有一些挑戰(zhàn)的。

二、治理平臺的建設(shè)背景和目標(biāo)

接下來介紹一下治理平臺的背景。

首先來看一下我們面對的問題。

開發(fā)質(zhì)量問題：在我們大部分用戶為非專業(yè)數(shù)據(jù)開發(fā)的背景下，平臺上任務(wù)的開發(fā)質(zhì)量問題是非常凸顯的。

非專業(yè)用戶數(shù)據(jù)開發(fā)相關(guān)技術(shù)的知識儲備是非常薄弱的，很多時(shí)候我們都是回答用戶很基礎(chǔ)的開發(fā)問題，例如配置任務(wù)資源、任務(wù)怎么去開發(fā)實(shí)現(xiàn)他們的業(yè)務(wù)邏輯等。特別是實(shí)時(shí)任務(wù)，不像離線任務(wù)的SQL已經(jīng)很成熟，實(shí)時(shí)SQL雖然有，而且功能也已經(jīng)比較強(qiáng)大了，但是因?yàn)楹碗x線有比較大的差異，整體問題就更加多，整體運(yùn)維壓力也更大。

用戶的數(shù)據(jù)意識是非常薄弱的，在很多人眼里的數(shù)據(jù)任務(wù)還是等同于不重要的任務(wù)，任務(wù)的運(yùn)維報(bào)警處理意識差。

代碼質(zhì)量問題多：因?yàn)橛脩舻谋尘皢栴}，用戶的代碼治理問題也比較多，如用戶不知道用分區(qū)表必須指定分區(qū)、實(shí)時(shí)任務(wù)狀態(tài)如何選擇、或者使用不合法或不規(guī)范的SQL。

資源浪費(fèi)問題：開發(fā)質(zhì)量問題會造成資源浪費(fèi)：閑置表不及時(shí)下線、代碼質(zhì)量、資源配置不對導(dǎo)致的資源浪費(fèi)、以及一些做活動的業(yè)務(wù)萎縮，但任務(wù)資源沒有及時(shí)調(diào)整導(dǎo)致的資源浪費(fèi)等。

運(yùn)維負(fù)擔(dān)問題：以上的問題會導(dǎo)致非常非常大的運(yùn)維負(fù)擔(dān)。

從我們的系統(tǒng)工單上看，平均每月100個(gè)左右工單問題，其中有60%以上的問題都是一些基本的使用問題。

日常治理的推進(jìn)：因?yàn)檫@兩年是降本增效的大年，我們要花大量的人力去推進(jìn)用戶做任務(wù)下線、數(shù)據(jù)下線、離職的轉(zhuǎn)讓、資源的優(yōu)化等等，任務(wù)繁瑣、耗費(fèi)人力。

開發(fā)輔助：日常除了解答一些問題以外，我們要去輔導(dǎo)用戶做一些任務(wù)的開發(fā)、資源的調(diào)優(yōu)等工作，非?，嵥?，其中重復(fù)的、可沉淀的東西非常多。

回到治理場景，我們在搭建治理平臺以前，任務(wù)治理、表治理大概的流程如下：

這里展示的是日常我們做任務(wù)治理、表治理的一個(gè)通用的流程：

首先我們會以人工或者腳本的方式掃描出來想要治理的類型的任務(wù)或者表，簡單的時(shí)候一條SQL就可以找到，復(fù)雜的時(shí)候需要收集大量資源的元數(shù)據(jù)，然后通過人工或者腳本的方式才能梳理出我們想要的治理資源。

找到這些資源以后，我們需要推進(jìn)用戶進(jìn)行治理工作，在這個(gè)階段，我們一般是先整理一個(gè)共享的Excel協(xié)作文檔，然后拉齊所有的開發(fā)推進(jìn)治理，準(zhǔn)備一個(gè)操作文檔，讓用戶按照操作進(jìn)行治理工作。

開發(fā)收到通知以后，按照治理文檔，手動進(jìn)行治理工作，然后把治理的狀態(tài)和結(jié)果手動登記到共享文檔上。

整個(gè)流程走下來，顯而易見，效率非常低下，用戶也很難一直保持積極性來配合平臺進(jìn)行治理工作；在操作的時(shí)候，用戶也不一定會嚴(yán)格按照文檔進(jìn)行治理動作，治理期間也可能導(dǎo)致問題、嚴(yán)重點(diǎn)可能會產(chǎn)生事故；其次治理期間梳理的腳本，沒有地方統(tǒng)一沉淀迭代；或許如果換一個(gè)人來推進(jìn)，或者中間隔了很久的話，又會產(chǎn)生大量的重復(fù)工作，另外一點(diǎn)就是，我們這些治理工作往往都是運(yùn)動式的，沒法做到健康的可持續(xù)發(fā)展的狀態(tài)。

為了解決以上問題，我們希望打造一個(gè)自動化的、智能化的治理平臺，做到問題早發(fā)現(xiàn)早治理，責(zé)任到人，保持整個(gè)數(shù)據(jù)生態(tài)的健康發(fā)展：

在開發(fā)階段：提供如代碼優(yōu)化建議、資源配置建議、運(yùn)維配置檢查等等，保證整體的代碼質(zhì)量。

在服務(wù)階段：任務(wù)健康度巡檢：如任務(wù)自身日志量監(jiān)控、閑置任務(wù)探查、是否多次異常failover、資源合理性檢查、資源利用率是否充分等等。

在下線階段：推進(jìn)資源及時(shí)下線、自動化的回收治理效果，以及輸出一些紅黑榜的機(jī)制、質(zhì)量分機(jī)制來提高用戶治理的積極性等。

在系統(tǒng)功能的設(shè)計(jì)上，我們希望做到以下幾點(diǎn)：

自動化：系統(tǒng)要具備調(diào)度能力，自動化巡檢所有的資源，發(fā)現(xiàn)不合理的資源，自動發(fā)送統(tǒng)計(jì)中推進(jìn)用戶進(jìn)行治理動作，回收治理效果。

智能化：通過靈活的規(guī)則配置和優(yōu)化，讓系統(tǒng)隨著迭代成長，智能化、準(zhǔn)確地發(fā)現(xiàn)不合理的資源，智能化地為用戶提供開發(fā)建議，高效地完成開發(fā)工作。

易擴(kuò)展：系統(tǒng)要具備靈活擴(kuò)展的能力，可以方便地支持多種多樣的資源對象，各種形式的規(guī)則配置以及各種形式和任意的三方系統(tǒng)進(jìn)行對接。

可復(fù)用：除了數(shù)據(jù)治理場景以外，我們希望這個(gè)平臺遷移到其它的場景，多樣的資源治理場景，比如服務(wù)治理、Kafka topic治理、機(jī)器資源治理等等。

三、治理平臺的建設(shè)落地

接下來介紹我們治理平臺的建設(shè)和落地實(shí)踐。

先來介紹平臺幾個(gè)大的概念：

資源對象：指我們治理的對象或者相關(guān)的對象，比如平臺任務(wù)、用戶、HIVE表、Kafak Topic等。

元數(shù)據(jù)：資源對象的屬性數(shù)據(jù)，或者說是特征數(shù)據(jù)，比如任務(wù)的代碼，任務(wù)的負(fù)責(zé)人、失敗率、類型；用戶的部門、在職狀態(tài)等等，在元數(shù)據(jù)這塊我們需要做到豐富準(zhǔn)確，保證數(shù)據(jù)夠用、數(shù)據(jù)能用。

規(guī)則：讀取資源對象的元數(shù)據(jù)，遍歷所有的資源對象，根據(jù)規(guī)則發(fā)現(xiàn)問題資源，給出開發(fā)建議，規(guī)則可以是簡單的if else、也可以是復(fù)雜的的模型，在規(guī)則這一部分我們希望做到是全面、智能、準(zhǔn)確，能夠盡量全面的考慮各種場景，掃描出不合理的問題，智能的給出準(zhǔn)確的開發(fā)和治理建議。

治理：訂閱讀取規(guī)則的執(zhí)行結(jié)果，和三方系統(tǒng)對接，推進(jìn)用戶，走標(biāo)準(zhǔn)化的治理流程，執(zhí)行治理動作，推動資源對象問題收斂，在這一步我們需要做到有效觸達(dá)，保障用戶在知曉問題的同時(shí)，也有足夠的動力來進(jìn)行治理動作；同時(shí)也需要提供高效的治理平臺，讓用戶能夠高效準(zhǔn)確的進(jìn)行治理操作。

上圖是平臺的整體架構(gòu)，其中紫色部分都是可以擴(kuò)展的，包含元數(shù)據(jù)模塊、規(guī)則模塊和治理模等。

元數(shù)據(jù)模塊：包含特征插件和迭代插件。

規(guī)模模塊：沉淀規(guī)則，發(fā)現(xiàn)有問題的資源。

治理模塊：負(fù)責(zé)和三方系統(tǒng)對接上報(bào)數(shù)據(jù)，回收治理結(jié)果。

整個(gè)系統(tǒng)的邏輯是這樣一個(gè)流程：從三方系統(tǒng)讀取、沉淀資源對象的元數(shù)據(jù)；規(guī)則模塊利用這些元數(shù)據(jù)，給出有問題的資源數(shù)據(jù)通過治理模塊上報(bào)到三方系統(tǒng)；或者三方系統(tǒng)通過API主動調(diào)用規(guī)則模塊獲取開發(fā)建議；最后用戶在三方系統(tǒng)上執(zhí)行治理動作，同時(shí)把治理結(jié)果數(shù)據(jù)回流給治理模塊。

接下來詳細(xì)介紹每個(gè)模塊的設(shè)計(jì)。

1、元數(shù)據(jù)模塊

元數(shù)據(jù)模塊包含以下幾個(gè)部分，第一個(gè)部分是資源對象，剛才已經(jīng)介紹過，就是治理的對象或者相關(guān)對象，比如任務(wù)、表等，是這些對象的特征列表，每個(gè)特征包含名字、類型、讀取方式等，主鍵特征，唯一定位資源對象實(shí)例的特征，如任務(wù)ID、表的庫表名等、用戶的郵箱等。

元數(shù)據(jù)模塊有兩大類的可擴(kuò)展的插件，迭代器插件和特征插件。

迭代器插件：類似于table scan，遍歷所有的資源，在做資源巡檢的時(shí)候通過迭代器來遍歷所有的資源對象。

特征插件：遍歷到資源以后，要通過特征插來讀取所需要的資源的特征數(shù)據(jù)，我們的特征主要有兩種類型，主鍵特征和普通特征，主鍵特征唯一標(biāo)識資源對象，類似表的主鍵，迭代器返回的就是資源的主鍵特征的值，普通特征就是資源其它的一些特征值，如表類型、存儲大小、上下游任務(wù)等等，每個(gè)特征值都有自己的數(shù)據(jù)類型；特征的讀取方式有兩種：一個(gè)是倉庫讀取，一個(gè)是插件讀取。倉庫讀取會把特征先落到我們自己治理平臺的KV里，然后從KV讀取，這樣做的好處是使用的時(shí)候不會對三方系統(tǒng)造成任何影響。而第二種方式插件讀取直接調(diào)用三方平臺接口或者直接讀取三方平臺數(shù)據(jù)庫拿到特征數(shù)據(jù)，雖然會對三方系統(tǒng)造成一定的調(diào)用量，產(chǎn)生一定的影響，但是數(shù)據(jù)非常實(shí)時(shí)準(zhǔn)確，不像倉庫讀取可能會有一定延遲。兩種讀取方式會有不同的使用場景，接下來會有介紹。

2、規(guī)則模塊

規(guī)則模塊遍歷所有資源，發(fā)現(xiàn)有問題的資源?；蛘弑恢鲃诱{(diào)用通過規(guī)則匹配，返回不同的結(jié)果。

規(guī)則模塊包含以下屬性：

迭代器，在巡檢模式下，巡檢資源時(shí)，使用哪個(gè)資源迭代器遍歷資源對象，進(jìn)行規(guī)則過濾。

資源對象，規(guī)則治理的資源對象是什么。

調(diào)度策略，在巡檢模式下，以怎樣的頻率，什么時(shí)候進(jìn)行巡檢操作。

治理模塊，規(guī)則的結(jié)果需要上報(bào)給哪些治理規(guī)模。

觸達(dá)用戶，如果規(guī)則命中，需要通知哪些用戶，這個(gè)用戶可以是資源的某一個(gè)特征，也可以是一個(gè)固定的用戶或者用戶組。

執(zhí)行方式：巡檢模式：定時(shí)調(diào)用，發(fā)現(xiàn)有問題的任務(wù)和資源；主動調(diào)用：被主動調(diào)用用來輔助開發(fā)，或者做一些流程卡點(diǎn)的動作。

特征讀取策略，在執(zhí)行規(guī)則時(shí)，優(yōu)先以那種方式讀取特征，是倉庫讀取還是通過插件讀取，在我們的設(shè)計(jì)中，一個(gè)特征可以同時(shí)支持通過倉庫讀取還是插件讀取，在巡檢模式下，需要遍歷所有的對象，這種方式一般對特征的實(shí)時(shí)性要求不高（如閑置表下線），但是調(diào)用量大，為了不對三方系統(tǒng)造成壓力，比較適合使用倉庫優(yōu)先的方式讀取，保障三方系統(tǒng)的穩(wěn)定；在主動調(diào)用模式下，這種往往是做些開發(fā)輔助的工作，如上線校驗(yàn)卡點(diǎn)、資源配置推薦、任務(wù)問題診斷等。往往執(zhí)行單個(gè)資源，調(diào)用量小，但是數(shù)據(jù)特征必須是最新的，這種Case下就必須使用插件優(yōu)先的方式操作，獲取實(shí)時(shí)準(zhǔn)確的數(shù)據(jù)。在規(guī)則配置上我們可以通過對接口的二次封裝來支持各種形式的規(guī)則配置，最基礎(chǔ)的是通過JAR包方式，繼承左邊接口來擴(kuò)展，經(jīng)過封裝， 我們可以使用Python腳本、可視化的方式來擴(kuò)展規(guī)則，降低規(guī)則配置的門檻，上面的代碼為規(guī)則插件最上層的接口方法。

3、治理模塊

治理模塊主要負(fù)責(zé)訂閱規(guī)則模塊的結(jié)果數(shù)據(jù)，上報(bào)到三方系統(tǒng)，以及回收三方系統(tǒng)的治理的效果數(shù)據(jù)，它是治理平臺和三方系統(tǒng)之間的一個(gè)橋梁。比如我們需要做一個(gè)閑置表治理的工具，在我們的數(shù)據(jù)開發(fā)平臺上提供一個(gè)閑置表治理頁面，那么閑置表治理頁面的后臺，就需要通過治理模塊和治理平臺進(jìn)行聯(lián)動，接收治理規(guī)則巡檢掃描出來的的數(shù)據(jù)，然后展示到治理頁面上，用戶可以通過這個(gè)治理頁面，快速地看到有問題的資源數(shù)據(jù)，同時(shí)通過這個(gè)頁面進(jìn)行高效的治理操作；在三方系統(tǒng)完成治理動作以后，同時(shí)還需要執(zhí)行回調(diào)，把治理結(jié)果返回給治理模塊，回收治理效果，形成數(shù)據(jù)閉環(huán)。如上圖所示，治理模塊插件的擴(kuò)展接口很簡單，只有一個(gè)report方法，把規(guī)則的掃描結(jié)果上報(bào)給三方平臺。其中第一個(gè)參數(shù)是拿取任何資源對象特征的service；第二是默認(rèn)展示的特征列表，需要哪些特征會通過dispalyFeathers傳進(jìn)來，然后再上報(bào)出去；接下來是runtimeContext運(yùn)行環(huán)境、resourceKey資源主鍵、以及規(guī)則的執(zhí)行結(jié)果；最后需要觸達(dá)的用戶列表數(shù)據(jù)。

4、落地實(shí)踐

我們現(xiàn)在已經(jīng)落地的包括任務(wù)的連續(xù)失敗下線、任務(wù)的報(bào)警頻繁不處理、任務(wù)無效歸屬，負(fù)責(zé)人已經(jīng)轉(zhuǎn)崗或者離職、任務(wù)重試率高，數(shù)倉閑置表治理、數(shù)倉游離表治理、數(shù)倉表業(yè)務(wù)線沒有歸屬等等規(guī)則，這些規(guī)則結(jié)果會通過開發(fā)平臺上治理頁面透出，通過網(wǎng)易內(nèi)部POPO聊天工具發(fā)起通知，并通過和質(zhì)量分對接來推進(jìn)用戶及時(shí)操作治理。

接下來我們通過數(shù)倉閑置表治理這個(gè)非常典型的場景來講一下我們是如何使用這個(gè)平臺進(jìn)行治理工作的。

閑置表治理的目標(biāo)是希望不再使用的表能夠及時(shí)下線，減少存儲成本，同時(shí)降低HDFS以及HiveMetaStore的壓力，落地閑置表治理包含以下幾塊工作：

第一個(gè)是收集元數(shù)據(jù)：收集HIVE表相關(guān)數(shù)據(jù)，作為規(guī)則的輸入。

第二個(gè)是配置規(guī)則：讀取元數(shù)據(jù)判斷數(shù)倉表是否為閑置表。

第三個(gè)是對接治理頁面：和平臺對接，提供前端方便用戶進(jìn)行治理操作。

最后一個(gè)是要推進(jìn)用戶主動去做，提高用戶的積極性，這一點(diǎn)反而是最難的。

首先是元數(shù)據(jù)收集部分，在Hive閑置表治理場景，我們需要收集的元數(shù)據(jù)主要包含三類：

Hive表的基礎(chǔ)元信息，包含存儲信息、生命周期信息、更新信息、負(fù)責(zé)人信息等。

血緣信息，包含各種來源的血緣，靜態(tài)代碼掃描的血緣，Hive、Spark上報(bào)的運(yùn)行時(shí)血緣，Impala血緣，以及相關(guān)下游報(bào)表的血緣。

Hive表相關(guān)的業(yè)務(wù)信息，比如HIVE表的主題域、重要等級、是否白名單、負(fù)責(zé)人信息等包含負(fù)責(zé)人的部門，直接上級，當(dāng)前在職狀態(tài)等等。

在元數(shù)據(jù)部分我們需要做到豐富準(zhǔn)確，保障數(shù)據(jù)質(zhì)量和覆蓋面，既要夠用也要能用，特別是在閑置表治理場景對數(shù)據(jù)的全面和準(zhǔn)確要求非常高，因?yàn)殄e誤的元數(shù)據(jù)很容易導(dǎo)致錯誤的結(jié)果，導(dǎo)致真正有用的表被下線，造成事故。

接下來是規(guī)則配置：

有了豐富的元數(shù)據(jù)，我們需要考慮的就是配置正確的規(guī)則來發(fā)現(xiàn)無用的閑置表，在這里我們平臺支持通過Python腳本來配置規(guī)則，這里我們主要考慮幾點(diǎn)：

首先我們要確定它是否在治理范圍內(nèi)，有些新表或者生命周期本身就很短的表是不用治理的，比如這個(gè)表才創(chuàng)建十天，它雖然沒有人讀，可能用戶還沒有開發(fā)好，所以創(chuàng)建時(shí)間大于60天的表我們才會把它囊括進(jìn)來。另外，如果表的生命只有60天，就沒有治理的必要。最后還要看是否白名單，如果這個(gè)表是備份用的，用戶加了白名單，也沒有掃描治理的必要。

第二判斷它是否還有在使用。其實(shí)前面幾點(diǎn)都比較簡單，就是通過Hive血緣、Spark血緣、Impala血緣、任務(wù)依賴等，來判斷相關(guān)數(shù)據(jù)表是否還在使用。

然后就是相關(guān)表，目前我們主要判斷兩種情況：第一如果產(chǎn)生這張表的任務(wù)，同時(shí)產(chǎn)生兩張表，雖然沒有直接的上下游關(guān)系，如果一張表下線了會對另外一張表也會產(chǎn)生影響，其次就是兩張表指向同一個(gè)路徑情況，如果把這個(gè)表下線，可能另外一張表有人讀，會導(dǎo)致系統(tǒng)問題，所以我們需要找出指向同一個(gè)路徑的表，不能把它下線。

最后還需要考慮表底層文件的使用情況，因?yàn)镠ive本身底層是HDFS文件，不是所有的開發(fā)、或者框架都會通過表去讀取數(shù)據(jù)，我們遇到過最多的是算法模型訓(xùn)練的場景，他們的TF框架很多都是直接讀數(shù)據(jù)文件，我們需要拿到這個(gè)表的相關(guān)文件的open時(shí)間，去做文件的審計(jì)追蹤，來關(guān)聯(lián)判斷相關(guān)表是否還在被使用，防止表被下線，導(dǎo)致下游任務(wù)出現(xiàn)問題。

以上就是閑置表治理整個(gè)規(guī)則判斷的一個(gè)概述。在規(guī)則配置這塊我們要結(jié)合使用場景和歷史經(jīng)驗(yàn)盡量考慮全面，不斷迭代，做到比人工判斷更準(zhǔn)確。右邊是我們平臺的一個(gè)截圖，目前還是通過Python腳本的方式來配置規(guī)則，后續(xù)我們希望能夠提供更加方便可視化的規(guī)則配置方式。

下面是平臺對接，規(guī)則巡檢完成以后，除了會將結(jié)果落地以外，還會將結(jié)果對接到三方的治理平臺當(dāng)中，三方系統(tǒng)訂閱接收規(guī)則模塊上報(bào)的數(shù)據(jù)結(jié)果，將這些問題的資源在系統(tǒng)展示，然后通知用戶在治理平臺進(jìn)行操作治理，最后將治理效果回調(diào)給治理平臺，回收治理效果；在這個(gè)部分治理平臺需要做到以下幾點(diǎn)：

提供高效的治理操作，比如在閑置表治理這個(gè)場景，我們提供了一鍵下線、批量下線等支持，同時(shí)還支持同時(shí)下線表相關(guān)的生產(chǎn)任務(wù)，保障用戶高效地一站式完成下線操作。

透明的判定數(shù)據(jù)，在平臺上需要讓用戶清楚表為什么被判定為閑置表，同時(shí)透出相關(guān)的數(shù)據(jù)，給出判斷依據(jù)，讓用戶能夠看到足夠的信息，再做一次人工check校驗(yàn)。

自動的效果回收，在用戶操作完下線以后我們需要自動回收下線數(shù)據(jù)，包含下線的記錄（表和任務(wù)）、節(jié)省的存儲、計(jì)算資源、以及相應(yīng)的成本。

兜底的回滾策略，當(dāng)平臺產(chǎn)生誤判，用戶下線了不應(yīng)該下線的數(shù)據(jù)時(shí)，平臺需要提供快速高效的回滾能力，保障數(shù)據(jù)能夠快速恢復(fù)，止損。

最后一個(gè)是有效的反饋機(jī)制，當(dāng)平臺發(fā)生誤判時(shí)，用戶可以通過平臺直接反饋，幫助平臺不斷地優(yōu)化規(guī)則，及時(shí)發(fā)現(xiàn)平臺問題，提升后續(xù)規(guī)則判斷的準(zhǔn)確度。

最后一步是推進(jìn)治理，對于我們這些做技術(shù)的同學(xué)來說是最難的。我們面對的幾百個(gè)用戶，每個(gè)用戶的業(yè)務(wù)目標(biāo)都是不同的，每個(gè)用戶對于治理操作的積極性也是不同的。所以這里我們需要做的關(guān)鍵點(diǎn)是：

有效觸達(dá)：找到對的用戶，讓用戶知道有些資源需要治理，為什么需要治理，不治理會有哪些影響等，這一點(diǎn)相對簡單，我們通過公司內(nèi)部的IM工具每天發(fā)送相關(guān)報(bào)表，自動發(fā)送發(fā)閑置表的情況，告訴他閑置表有多少張要治理，多少成本；還會同時(shí)發(fā)給團(tuán)隊(duì)leader，告訴他團(tuán)隊(duì)的閑置表的匯總情況。

對齊目標(biāo)，讓用戶有動力、有積極性去做治理操作，這一點(diǎn)往往是比較難的，目前主要有以下幾個(gè)手段：

整合開發(fā)的質(zhì)量分，把資源使用不合理、開發(fā)質(zhì)量不合理等整合進(jìn)云音樂內(nèi)部skynet的質(zhì)量分，這個(gè)質(zhì)量分相當(dāng)于是一個(gè)評比，每個(gè)團(tuán)隊(duì)有一個(gè)合格分，通過上層對下層的制度約束去推進(jìn)相關(guān)開發(fā)的治理積極性，主動進(jìn)行治理操作。

第二個(gè)就是紅黑榜，通過榜單說明誰做的好誰做的不好，通過這種通曬評比的方式來提升。

最后一個(gè)殺手锏是關(guān)聯(lián)治理效果和平臺使用權(quán)限，如果整體資源的健康指標(biāo)達(dá)不到合格的標(biāo)準(zhǔn)，平臺直接禁止一些操作權(quán)限，如新任務(wù)、新表創(chuàng)建、限制自主分析查詢資源等。例如如果某個(gè)用戶的閑置表治理情況不合格，提前一周開始預(yù)警，如果長期不治理就禁止其創(chuàng)建新的任務(wù)，甚至直接禁止相關(guān)用戶所在團(tuán)隊(duì)的使用權(quán)限。這樣用戶自然而然就會有動力做這個(gè)事情。

整套流程走下來，達(dá)成治理目標(biāo)主要有四大關(guān)鍵點(diǎn)：

第一是要有豐富準(zhǔn)確的特征數(shù)據(jù)。

第二是有一個(gè)準(zhǔn)確的智能的規(guī)則。

第三是有一個(gè)好用的治理工具。

最后一個(gè)是有效的推進(jìn)機(jī)制。

結(jié)合這四大要素，構(gòu)成一個(gè)智能化的治理流程閉環(huán)，做到比人更智能、比人更高效、以及比人更規(guī)范，最終達(dá)到一個(gè)可持續(xù)的健康生態(tài)，從平臺運(yùn)維運(yùn)動式治理的主動收益，變成平臺自動化推進(jìn)用戶主動操作治理的被動收益，平臺方躺著拿到治理的結(jié)果，形成一個(gè)健康的可持續(xù)發(fā)展的治理生態(tài)循環(huán)。

四、治理平臺的未來規(guī)劃

最后簡要介紹一下我們的未來規(guī)劃：

首先是更豐富更準(zhǔn)確的特征數(shù)據(jù)，巧婦難為無米之炊，不管做數(shù)據(jù)治理還是做模型訓(xùn)練，我們都會強(qiáng)調(diào)數(shù)據(jù)的豐富性和準(zhǔn)確性，因?yàn)橹挥杏辛烁嗟臄?shù)據(jù)、更準(zhǔn)確的數(shù)據(jù)、更詳細(xì)的數(shù)據(jù)，我們才能把治理做得更細(xì)致、更準(zhǔn)確、覆蓋面更廣。

第二是更好用的規(guī)則配置手段，我們的平臺目前是第一個(gè)版本，規(guī)則配置手段還是比較弱的，目前只支持Python腳本方式，未來我們會支持更多樣、更簡單的配置方式，比如增加可視化的拖拽的方式和低代碼的方式，降低整體的使用門檻，讓運(yùn)維和開發(fā)以外的更多的用戶來用，比如讓數(shù)倉同學(xué)也能夠快速地配置他們想要的規(guī)則來提高開發(fā)質(zhì)量分，我們可以提醒他高質(zhì)量表的熱度，有哪些表被穿透，哪些表是沒有被用的，在開發(fā)數(shù)倉過程中提供一些質(zhì)量監(jiān)督手段。

最后就是更多的場景覆蓋，有了更多的數(shù)據(jù)，更方便的配置手段，就要去覆蓋更多的業(yè)務(wù)。除數(shù)據(jù)場景以外，我們希望去做比如模型的治理、機(jī)器的治理、服務(wù)的治理、中間件的治理Kafka或者其他數(shù)據(jù)庫的表等等，希望能夠做成統(tǒng)一和通用的治理平臺。

以上就是本次分享的內(nèi)容，謝謝！

五、Q&A

問：HDFS方面有哪些治理的插件？

答：插件是針對規(guī)則的，目前我們針對HDFS的治理主要有兩點(diǎn)，第一是閑置數(shù)據(jù)，第二是小文件。在這塊我們優(yōu)化改造了文件的審計(jì)日志，在日志中除了能到客戶端IP、操作情況以外，還有任務(wù)的信息，比如ApplicationID也會傳入審計(jì)日志，這樣我們可以快速定位到產(chǎn)生問題的源頭。

問：數(shù)據(jù)膨脹是做數(shù)據(jù)收集？還是在開發(fā)時(shí)給用戶些建議？比如數(shù)據(jù)集成或生產(chǎn)開發(fā)產(chǎn)生的臨時(shí)文件，或者有些SQL不太優(yōu)雅產(chǎn)生非常多的小文件。

答：第一是監(jiān)控重點(diǎn)目錄，比如Flink的狀態(tài)文件、Spark/Hive的臨時(shí)文件等固定目錄。第二是超大目錄的掃描判斷。最后對于SQL產(chǎn)生的小文件，這點(diǎn)我們對我們的SQL引擎是有經(jīng)過改造的，默認(rèn)會在最后多做一步計(jì)算，自動合并小文件。

問：閑置表是怎么評價(jià)的？比如把表下發(fā)之后，怎么去確認(rèn)這個(gè)表有沒有用？

答：剛才規(guī)則部分已經(jīng)介紹，第一點(diǎn)是判斷表是否在治理范圍內(nèi)，通過表的生命周期和創(chuàng)建時(shí)間，配置是否有白名單；第二點(diǎn)是判斷表的使用情況，通過血源，任務(wù)的血源、報(bào)表的血源、Impala的血源，任務(wù)的依賴關(guān)系來判斷。同時(shí)還需要考慮相關(guān)表的使用情況。另外，我們還會把這些數(shù)據(jù)全部透出給用戶，讓用戶去做一次人工確認(rèn)。