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

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

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

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

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

云音樂上線十年左右，我們的平臺建設也已經(jīng)有五年多的時間，累計用戶超過800，每天的UV有200多，因為大部分用戶都是非數(shù)倉專業(yè)的數(shù)據(jù)開發(fā)，所以面對的問題就更多。

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

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

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

二、治理平臺的建設背景和目標

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

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

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

• 非專業(yè)用戶數(shù)據(jù)開發(fā)相關技術的知識儲備是非常薄弱的，很多時候我們都是回答用戶很基礎的開發(fā)問題，例如配置任務資源、任務怎么去開發(fā)實現(xiàn)他們的業(yè)務邏輯等。特別是實時任務，不像離線任務的SQL已經(jīng)很成熟，實時SQL雖然有，而且功能也已經(jīng)比較強大了，但是因為和離線有比較大的差異，整體問題就更加多，整體運維壓力也更大。
• 用戶的數(shù)據(jù)意識是非常薄弱的，在很多人眼里的數(shù)據(jù)任務還是等同于不重要的任務，任務的運維報警處理意識差。
• 代碼質(zhì)量問題多：因為用戶的背景問題，用戶的代碼治理問題也比較多，如用戶不知道用分區(qū)表必須指定分區(qū)、實時任務狀態(tài)如何選擇、或者使用不合法或不規(guī)范的SQL。

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

運維負擔問題：以上的問題會導致非常非常大的運維負擔。

• 從我們的系統(tǒng)工單上看，平均每月100個左右工單問題，其中有60%以上的問題都是一些基本的使用問題。
• 日常治理的推進：因為這兩年是降本增效的大年，我們要花大量的人力去推進用戶做任務下線、數(shù)據(jù)下線、離職的轉讓、資源的優(yōu)化等等，任務繁瑣、耗費人力。
• 開發(fā)輔助：日常除了解答一些問題以外，我們要去輔導用戶做一些任務的開發(fā)、資源的調(diào)優(yōu)等工作，非常瑣碎，其中重復的、可沉淀的東西非常多。

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

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

• 首先我們會以人工或者腳本的方式掃描出來想要治理的類型的任務或者表，簡單的時候一條SQL就可以找到，復雜的時候需要收集大量資源的元數(shù)據(jù)，然后通過人工或者腳本的方式才能梳理出我們想要的治理資源。
• 找到這些資源以后，我們需要推進用戶進行治理工作，在這個階段，我們一般是先整理一個共享的Excel協(xié)作文檔，然后拉齊所有的開發(fā)推進治理，準備一個操作文檔，讓用戶按照操作進行治理工作。
• 開發(fā)收到通知以后，按照治理文檔，手動進行治理工作，然后把治理的狀態(tài)和結果手動登記到共享文檔上。

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

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

• 在開發(fā)階段：提供如代碼優(yōu)化建議、資源配置建議、運維配置檢查等等，保證整體的代碼質(zhì)量。
• 在服務階段：任務健康度巡檢：如任務自身日志量監(jiān)控、閑置任務探查、是否多次異常failover、資源合理性檢查、資源利用率是否充分等等。
• 在下線階段：推進資源及時下線、自動化的回收治理效果，以及輸出一些紅黑榜的機制、質(zhì)量分機制來提高用戶治理的積極性等。

在系統(tǒng)功能的設計上，我們希望做到以下幾點：

• 自動化：系統(tǒng)要具備調(diào)度能力，自動化巡檢所有的資源，發(fā)現(xiàn)不合理的資源，自動發(fā)送統(tǒng)計中推進用戶進行治理動作，回收治理效果。
• 智能化：通過靈活的規(guī)則配置和優(yōu)化，讓系統(tǒng)隨著迭代成長，智能化、準確地發(fā)現(xiàn)不合理的資源，智能化地為用戶提供開發(fā)建議，高效地完成開發(fā)工作。
• 易擴展：系統(tǒng)要具備靈活擴展的能力，可以方便地支持多種多樣的資源對象，各種形式的規(guī)則配置以及各種形式和任意的三方系統(tǒng)進行對接。
• 可復用：除了數(shù)據(jù)治理場景以外，我們希望這個平臺遷移到其它的場景，多樣的資源治理場景，比如服務治理、Kafka topic治理、機器資源治理等等。

三、治理平臺的建設落地

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

先來介紹平臺幾個大的概念：

• 資源對象：指我們治理的對象或者相關的對象，比如平臺任務、用戶、HIVE表、Kafak Topic等。
• 元數(shù)據(jù)：資源對象的屬性數(shù)據(jù)，或者說是特征數(shù)據(jù)，比如任務的代碼，任務的負責人、失敗率、類型；用戶的部門、在職狀態(tài)等等，在元數(shù)據(jù)這塊我們需要做到豐富準確，保證數(shù)據(jù)夠用、數(shù)據(jù)能用。
• 規(guī)則：讀取資源對象的元數(shù)據(jù)，遍歷所有的資源對象，根據(jù)規(guī)則發(fā)現(xiàn)問題資源，給出開發(fā)建議，規(guī)則可以是簡單的if else、也可以是復雜的的模型，在規(guī)則這一部分我們希望做到是全面、智能、準確，能夠盡量全面的考慮各種場景，掃描出不合理的問題，智能的給出準確的開發(fā)和治理建議。
• 治理：訂閱讀取規(guī)則的執(zhí)行結果，和三方系統(tǒng)對接，推進用戶，走標準化的治理流程，執(zhí)行治理動作，推動資源對象問題收斂，在這一步我們需要做到有效觸達，保障用戶在知曉問題的同時，也有足夠的動力來進行治理動作；同時也需要提供高效的治理平臺，讓用戶能夠高效準確的進行治理操作。

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

• 元數(shù)據(jù)模塊：包含特征插件和迭代插件。
• 規(guī)模模塊：沉淀規(guī)則，發(fā)現(xiàn)有問題的資源。
• 治理模塊：負責和三方系統(tǒng)對接上報數(shù)據(jù)，回收治理結果。

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

接下來詳細介紹每個模塊的設計。

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

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

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

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

2、規(guī)則模塊

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

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

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

3、治理模塊

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

4、落地實踐

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

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

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

• 第一個是收集元數(shù)據(jù)：收集HIVE表相關數(shù)據(jù)，作為規(guī)則的輸入。
• 第二個是配置規(guī)則：讀取元數(shù)據(jù)判斷數(shù)倉表是否為閑置表。
• 第三個是對接治理頁面：和平臺對接，提供前端方便用戶進行治理操作。
• 最后一個是要推進用戶主動去做，提高用戶的積極性，這一點反而是最難的。

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

• Hive表的基礎元信息，包含存儲信息、生命周期信息、更新信息、負責人信息等。
• 血緣信息，包含各種來源的血緣，靜態(tài)代碼掃描的血緣，Hive、Spark上報的運行時血緣，Impala血緣，以及相關下游報表的血緣。
• Hive表相關的業(yè)務信息，比如HIVE表的主題域、重要等級、是否白名單、負責人信息等包含負責人的部門，直接上級，當前在職狀態(tài)等等。

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

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

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

• 首先我們要確定它是否在治理范圍內(nèi)，有些新表或者生命周期本身就很短的表是不用治理的，比如這個表才創(chuàng)建十天，它雖然沒有人讀，可能用戶還沒有開發(fā)好，所以創(chuàng)建時間大于60天的表我們才會把它囊括進來。另外，如果表的生命只有60天，就沒有治理的必要。最后還要看是否白名單，如果這個表是備份用的，用戶加了白名單，也沒有掃描治理的必要。
• 第二判斷它是否還有在使用。其實前面幾點都比較簡單，就是通過Hive血緣、Spark血緣、Impala血緣、任務依賴等，來判斷相關數(shù)據(jù)表是否還在使用。
• 然后就是相關表，目前我們主要判斷兩種情況：第一如果產(chǎn)生這張表的任務，同時產(chǎn)生兩張表，雖然沒有直接的上下游關系，如果一張表下線了會對另外一張表也會產(chǎn)生影響，其次就是兩張表指向同一個路徑情況，如果把這個表下線，可能另外一張表有人讀，會導致系統(tǒng)問題，所以我們需要找出指向同一個路徑的表，不能把它下線。
• 最后還需要考慮表底層文件的使用情況，因為Hive本身底層是HDFS文件，不是所有的開發(fā)、或者框架都會通過表去讀取數(shù)據(jù)，我們遇到過最多的是算法模型訓練的場景，他們的TF框架很多都是直接讀數(shù)據(jù)文件，我們需要拿到這個表的相關文件的open時間，去做文件的審計追蹤，來關聯(lián)判斷相關表是否還在被使用，防止表被下線，導致下游任務出現(xiàn)問題。

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

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

• 提供高效的治理操作，比如在閑置表治理這個場景，我們提供了一鍵下線、批量下線等支持，同時還支持同時下線表相關的生產(chǎn)任務，保障用戶高效地一站式完成下線操作。
• 透明的判定數(shù)據(jù)，在平臺上需要讓用戶清楚表為什么被判定為閑置表，同時透出相關的數(shù)據(jù)，給出判斷依據(jù)，讓用戶能夠看到足夠的信息，再做一次人工check校驗。
• 自動的效果回收，在用戶操作完下線以后我們需要自動回收下線數(shù)據(jù)，包含下線的記錄（表和任務）、節(jié)省的存儲、計算資源、以及相應的成本。
• 兜底的回滾策略，當平臺產(chǎn)生誤判，用戶下線了不應該下線的數(shù)據(jù)時，平臺需要提供快速高效的回滾能力，保障數(shù)據(jù)能夠快速恢復，止損。
• 最后一個是有效的反饋機制，當平臺發(fā)生誤判時，用戶可以通過平臺直接反饋，幫助平臺不斷地優(yōu)化規(guī)則，及時發(fā)現(xiàn)平臺問題，提升后續(xù)規(guī)則判斷的準確度。

最后一步是推進治理，對于我們這些做技術的同學來說是最難的。我們面對的幾百個用戶，每個用戶的業(yè)務目標都是不同的，每個用戶對于治理操作的積極性也是不同的。所以這里我們需要做的關鍵點是：

• 有效觸達：找到對的用戶，讓用戶知道有些資源需要治理，為什么需要治理，不治理會有哪些影響等，這一點相對簡單，我們通過公司內(nèi)部的IM工具每天發(fā)送相關報表，自動發(fā)送發(fā)閑置表的情況，告訴他閑置表有多少張要治理，多少成本；還會同時發(fā)給團隊leader，告訴他團隊的閑置表的匯總情況。
• 對齊目標，讓用戶有動力、有積極性去做治理操作，這一點往往是比較難的，目前主要有以下幾個手段：
• 整合開發(fā)的質(zhì)量分，把資源使用不合理、開發(fā)質(zhì)量不合理等整合進云音樂內(nèi)部skynet的質(zhì)量分，這個質(zhì)量分相當于是一個評比，每個團隊有一個合格分，通過上層對下層的制度約束去推進相關開發(fā)的治理積極性，主動進行治理操作。
• 第二個就是紅黑榜，通過榜單說明誰做的好誰做的不好，通過這種通曬評比的方式來提升。
• 最后一個殺手锏是關聯(lián)治理效果和平臺使用權限，如果整體資源的健康指標達不到合格的標準，平臺直接禁止一些操作權限，如新任務、新表創(chuàng)建、限制自主分析查詢資源等。例如如果某個用戶的閑置表治理情況不合格，提前一周開始預警，如果長期不治理就禁止其創(chuàng)建新的任務，甚至直接禁止相關用戶所在團隊的使用權限。這樣用戶自然而然就會有動力做這個事情。

整套流程走下來，達成治理目標主要有四大關鍵點：

• 第一是要有豐富準確的特征數(shù)據(jù)。
• 第二是有一個準確的智能的規(guī)則。
• 第三是有一個好用的治理工具。
• 最后一個是有效的推進機制。

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

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

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

• 首先是更豐富更準確的特征數(shù)據(jù)，巧婦難為無米之炊，不管做數(shù)據(jù)治理還是做模型訓練，我們都會強調(diào)數(shù)據(jù)的豐富性和準確性，因為只有有了更多的數(shù)據(jù)、更準確的數(shù)據(jù)、更詳細的數(shù)據(jù)，我們才能把治理做得更細致、更準確、覆蓋面更廣。
• 第二是更好用的規(guī)則配置手段，我們的平臺目前是第一個版本，規(guī)則配置手段還是比較弱的，目前只支持Python腳本方式，未來我們會支持更多樣、更簡單的配置方式，比如增加可視化的拖拽的方式和低代碼的方式，降低整體的使用門檻，讓運維和開發(fā)以外的更多的用戶來用，比如讓數(shù)倉同學也能夠快速地配置他們想要的規(guī)則來提高開發(fā)質(zhì)量分，我們可以提醒他高質(zhì)量表的熱度，有哪些表被穿透，哪些表是沒有被用的，在開發(fā)數(shù)倉過程中提供一些質(zhì)量監(jiān)督手段。
• 最后就是更多的場景覆蓋，有了更多的數(shù)據(jù)，更方便的配置手段，就要去覆蓋更多的業(yè)務。除數(shù)據(jù)場景以外，我們希望去做比如模型的治理、機器的治理、服務的治理、中間件的治理Kafka或者其他數(shù)據(jù)庫的表等等，希望能夠做成統(tǒng)一和通用的治理平臺。

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

五、Q&A

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

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

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

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

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

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