一、音樂數據平臺的規模和現狀

我們通過數據平臺整合技術和業務，對業務賦能，使用戶能夠高效、穩定、安全、經濟和準確地使用數據。

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

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

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

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

業務類型上，主要場景有算法特征開發、樣本生成、索引構建、內容監控、數據報表、線上統計服務等等，支撐音樂主站、直播、心遇等所有音樂的業務。

任務規模上，我們目前的離線調度任務有7000+，執行中的實時任務有1500+，比較好的是我們80%以上的任務都是基于平臺現成的組進行開發的，而不是自由度更高但是運維更難的JAR包任務，這對于我們日常運維支持工作是非常有利的，我們能夠很清楚地知道用戶的業務邏輯，更加方便地進行指導和優化。

集群規模上，我們目前的計算節點有2000多臺，每天的日志量達到千億級別，在這個數據量的背景下，整體穩定性還是有一些挑戰的。

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

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

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

開發質量問題：在我們大部分用戶為非專業數據開發的背景下，平臺上任務的開發質量問題是非常凸顯的。

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

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

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

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

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

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

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

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

為了解決以上問題，我們希望打造一個自動化的、智能化的治理平臺，做到問題早發現早治理，責任到人，保持整個數據生態的健康發展：

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

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

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

三、治理平臺的建設落地

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

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

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

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

• 元數據模塊：包含特征插件和迭代插件。
• 規模模塊：沉淀規則，發現有問題的資源。
• 治理模塊：負責和三方系統對接上報數據，回收治理結果。

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

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

1、元數據模塊

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

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

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

2、規則模塊

規則模塊遍歷所有資源，發現有問題的資源。或者被主動調用通過規則匹配，返回不同的結果。

規則模塊包含以下屬性：

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

3、治理模塊

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

4、落地實踐

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

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

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

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

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

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

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

接下來是規則配置：

有了豐富的元數據，我們需要考慮的就是配置正確的規則來發現無用的閑置表，在這里我們平臺支持通過Python腳本來配置規則，這里我們主要考慮幾點：

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

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

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

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

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

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

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

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

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

四、治理平臺的未來規劃

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

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

以上就是本次分享的內容，謝謝！

五、Q&A

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

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

問：數據膨脹是做數據收集？還是在開發時給用戶些建議？比如數據集成或生產開發產生的臨時文件，或者有些SQL不太優雅產生非常多的小文件。

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

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

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