導讀：大數據時代的到來，讓很多企業看到了數據資産的價值，開始探索應用場景和商業模式，并建設相關技術平台。因此，數據治理成為了挖掘數據價值的重要手段和工具。但數據治理不僅需要完善的保障機制，還需要理解具體的治理内容，比如數據該怎麼規範，元數據該怎麼管理等。這些問題是數據治理過程中最實際也是最複雜的問題，今天我将從數據治理的各個核心領域來和大家分享一下雲音樂在數據治理中的探索與實踐。

本文會圍繞以下四個方面展開：

• 音樂數倉概況
• 數據規範
• 埋點治理
• 資産治理

01音樂數倉概況

首先介紹一下雲音樂目前所面臨的一些問題與挑戰，也就是為什麼要做數據治理。

1. 整體情況

• 數據體量大。
• 業務場景複雜。
• 曆史包袱重。

以上幾方面導緻了數據倉庫在保障數據質量、控制計算與成本等方面面臨了越來越大的挑戰。

2. 問題與挑戰

問題主要有三個方面：

• 數據規範：因為早期數倉建設的時候疊代速度快，沒有一個标準的設計模式，導緻數據非常淩亂。
• 數據生産：雲音樂是個内容流量産品，目前在數據埋點這方面存在埋點定義混亂，埋點質量問題多，以及埋點信息不夠全面等問題。埋點信息不夠全面也導緻我們無法支持要求越來越高的精細化運營場景。
• 數據資産：大數據開發經常面臨開發周期長、交付質量差的問題；另外計算和存儲的成本迅速增長也是我們目前急需解決的問題。

接下來就針對上述三方面來展開介紹一下雲音樂的數據治理工作。

02數據規範

數據規範是數據治理建章立制的一個基礎。在音樂數據倉庫這一塊，我将從設計規範和開發規範這兩方面來介紹我們雲音樂标準化改造的過程。

1. 設計規範-問題和痛點

在設計規範方面遇到的主要問題和痛點：

• 缺乏頂層設計：早期數據開發以需求為導向，跟随業務的變化而快速疊代，因此數據模型複用率低，造成了大量的跨層引用。比如大量的數據報告表都是直接從原始日志或者業務表中提取數據來做分析的。
• 數據孤島：數據開發的模式主要是按照業務來劃分的，開發相對獨立，信息也相對獨立，所以缺少公共數據資産的沉澱，從而導緻難以應對跨業務的需求。
• 數據質量：數據異常，如空值、缺失、髒數據；數據的一緻性問題，如活躍，留存，CRT等在不同的報表裡面結果可能是不一樣的。

這塊我們需要從數據的穩定、效率和質量方面來解決。

2. 設計規範-數據域

從整體架構上來講，我們将雲音樂的整個數據進行了一個數據域的劃分，用來确定一個高穩定性的數據倉庫。主題域是一個要保持穩定不變的高度抽象的概念。我們将整個雲音樂劃分為參與者、服務及産品、事實、協議，以及公共數據這五個主題域。基于這五個主題域，我們又對業務場景做了進一步的子主題的劃分，子主題的劃分也是相對穩定的。數據劃分後，當業務發生疊代時，新的數據也能夠有一個相對明确的數據域的歸屬。

數據的劃分主要是為了實現業務形态和實體關系的表達。我們按照以上五個主題域來進行劃分是因為我們的數據核心其實就是參與者和服務及産品這兩個方面。參與者就是用戶，服務及産品主要是内容。

參與者和服務及産品之間會達成一些協議，比如直播協議，版權協議等。另外，參與者和服務及産品之間會産生各種各樣的業務過程，這就是事實。其中主要包括流量數據，互動數據，支付數據。

在人、坑位和資源的不同粒度中，我們的分層模型設計就是針對這樣的核心數據來進行的。

3. 設計規範-模型分層

上圖是雲音樂數據倉庫分層的一個基本情況。跟大部分流量型産品的數據分層一樣，我們也分為ODS貼源層，DIM的維度，以及DWD的明細，DWS的彙總層。另外我們在應用層支持了非常多的産品，比如活動跟蹤、用戶歌曲畫像、流量羅盤，以及各種to C和to B的數據産品。

我們模型設計的核心是對DWS這個彙總層進行了進一步的拆分，比如在這個圖裡我們可以看到有橫向拆分和縱向拆分。

• 橫向是對不同的彙總粒度和方式進行的拆分。彙總粒度既包括明細/輕度/高度，又區分多維度/雙實體/單實體。彙總方式包含周期快照以及累積快照。
• 縱向區分主要針對的是維度和業務過程的一個拆分。維度主要是一些核心的實體，就是人、資源、坑位。業務過程主要包括交易營收、社交互動，以及場景流量。

我們最終的設計目标是，通過這樣一個模型設計來達到高效率高質量的數據生産和使用。

4. 設計規範-平台管控

我們通過網易數帆開發平台對設計規範的落地進行管控。上圖是平台提供的一個工單機制，對我們的數據域、分層結構進行設置和規範，也對表和字段的命名也進行規範，幫助我們将設計思想真正落到實際的生産過程中去。

5. 數據規範-開發規範

開發規範造成的問題也是屢見不鮮，我們也在新的體系下對開發工作進行調整和改進：

• 很多任務會直接讀寫文件，導緻數據血緣缺失。為達到一個完備的數據血緣，新的規範會強制要求所有人要在讀寫表的基礎上進行。
• 任務會有純SQL，或者是SQL和API結合的方式。為了統一開發規範和流程，降低運維成本，新規範要求公共層模型必須用純SQL來執行，并且我們定義了一個SQL規範來去執行。
• 多表和多任務可能會合并到一個workflow裡面去，導緻一個workflow裡可能有幾十個甚至上百個任務節點，對任務管理造成了比較大的影響，也不利于性能和資源分析，因此我們要求一個workflow隻能輸出一個正式表，額外的好處是任務的查找也變得更加方便。
• 多workflow間通過數據檢查依賴去執行的方式，對運維也造成了一定影響。比如任務出現了失敗或者異常如何快速做數據恢複。在新的規範裡，我們基于開發平台做跨流任務依賴，以此構建任務血緣，進而有效地進行基線診斷和運維。

6. 數據規範-DQC

另外我們的數據開發平台提供了一個數據質量控制的功能，上圖是一個規則配置的頁面。這個功能除了可以支持标準化表組件的唯一性檢測，表行數檢查，字段空值檢查，字段枚舉值檢查等模闆規則，還可以支持一些我們自定義的規則。這樣我們能夠在任務上線之後，對數據質量進行監控，及時發現并阻塞異常向下遊擴散。

03埋點治理

數據治理中解決數據源頭問題是關鍵，下面将從技術方案和流程管理兩方面來介紹埋點治理工作。

1. 埋點治理-問題和痛點

雲音樂目前在埋點這方面遇到的問題和痛點，主要分為四個方面。

• 格式淩亂：埋點字段含義不統一，規則定義不精确，管理平台功能單一，埋點查找困難。
• 數據質量低下：上線較為随意，埋點的多錯漏難以檢查。另外我們數據方面的設計，以及客戶端都是面向單次需求開發的，導緻新老埋點容易相互影響，造成數據異常頻出。
• 開發效率低：人工進行埋點編碼和開發ETL任務占據了大量工作，數據需求也是直接從原始日志來進行解析的。另外業務數據，比如說像歸因分析這樣的需求還是依賴數據層面的複雜邏輯加工來實現的。
• 看數困難：目前的埋點無法支持自動化的取數看數以及精細化的指标産出。雖然我們也去落地了一些取數平台以及流量羅盤，但是這些産品基于老的埋點體系更新十分繁瑣，更新周期也特别長。

為此雲音樂啟動了一套全新的埋點改造方案。

2. 技術方案-SDK

技術方案是聯合客戶端來進行設計和實施的。客戶端實現了一個埋點的SDK來對埋點生産進行标準化，其中有以下幾個重點：

• 對SPM和SCM進行一個對象化，對像化的核心就是對象能夠複用，大大降低了設計和開發的成本。
• 複用的意思如右圖，每個節點每個位置都是一個對象，不同的對象組裝成一個對象邏輯樹。如果對象發生了位置的修改，隻需要修改它所在的父節點的位置，這樣就能夠大大簡化設計和開發的效率。
• 點擊和播放事件埋點，每個埋點會帶上它的Refer信息。Refer信息包含了跳轉到某個頁面或坑位的多級行為鍊路及其關聯的資源和策略。

埋點生産标準化的結果是埋點格式的變化。埋點格式，我們以往是用扁平的JSON方式，裡面就是key/value。但在新的标準下，我們會生成一套嵌套的JSON，裡面攜帶全局公參、事件公參、對象标準參數、對象業務參數。

3. 技術方案-數據倉庫

• 數據倉庫我們也會重新接入新的埋點數據，使我們能夠實現離線和實時統一數據源接入和模型設計。
• 離線和實時都将具備精确的歸因分析能力。
• 在數據倉庫的數據易用性角度，我們對改造之後的嵌套JSON做了适當的扁平化。
• 針對這樣一個标準的埋點範式進行自動的ETL，使得能夠更高效地支持Ad-hoc查詢以及敏捷的數據探索。

右邊是我們基于新的埋點方案的數據流示意圖。通過這次埋點治理，我們會同步推進曆史任務的治理。以前很多任務都是直接從ODS上提取和解析數據的，希望這次通過對埋點格式的修改，能夠切斷以往ODS直接訪問的方式，将我們之前的分層模型設計實實在在地落地到整個數據生産的環節當中去。

4. 技術方案-歸因設計

我們的歸因大緻分為以下幾方面：渠道歸因、内容歸因、搜索歸因、策略歸因。

• 渠道歸因，主要指内容在App中分發的資源位，如首頁不同模塊。
• 内容歸因，主要指内容的包裝形式，如歌單、相關資源推薦。
• 搜索歸因，根據一次搜索請求産生的後續整個鍊路的流向，去分析這個搜索的效果。
• 策略歸因，主要指推薦或算法模型的歸因，我們通過這個策略歸因來支持算法模型的離線或者實時的模型訓練。

右邊展示了我們目前設計的幾個refer的形式，refer同時包含了SPM和SCM的信息。比如：

• _psrefer是頁面對象創建，就是首次曝光時生成的來源對象；
• _pgrefer是頁面 每一次曝光時生成的來源對象；
• _hsrefer是App内整個消費起始鍊路的來源；
• _multirefers是行為鍊路上的5級頁面的_psrefer順序拼接；
• _addrefer和_playrefer主要是針對雲音樂的播放場景，_addrefer是觸發内容添加到播放列表的對象，_playrefer是觸發内容播放的對象；
• _rqrefer主要是針對一些互動行為，比如評論，收藏，點贊等行為，由客戶端觸發服務端請求對象來記錄并傳給服務端來打點。

5. 埋點治理-流程管理

埋點治理的另一個重點是流程管理，因為整個埋點流程會涉及到很多團隊，決定了技術方案能否高效率高質量的應用到生産流程當中。

• 第一步，策劃、BI以及數倉的開發會錄入埋點需求以及參與方案的設計；
• 第二步，大前端開發會根據埋點設計來設置剛剛說的一些對象參數；
• 第三步是SDK，根據業務設置的一些對象信息來自動構建對象邏輯樹，并自動進行曝光和點擊的埋點，同時會帶入歸因相關的refer的信息。
• 接下來一步，依據選擇的需求中對象和樹的規則進行埋點上報，上報到系統裡，由QA進行實時的埋點驗證和測試。

當整套流程都測試通過之後，埋點才能最終上線接入到數據倉庫，進入到後續的數據分析中去。其中有兩個關鍵的環節，就是埋點設計和數據測試，這兩塊會接入到我們新的埋點平台來進行管控。

6. 埋點治理-埋點平台

上圖是我們埋點平台大緻的頁面情況。

埋點平台主要面向的是上述埋點流程中會涉及到的團隊和角色：産品策劃、數據開發、大前端開發以及QA。

埋點平台承載的功能是一些元數據管理，包含一些對象管理，版本管理等，以及整個需求工作流的管理和實時埋點測試。未來還會規劃更多功能，比如說質量監控，BI分析等

7. 埋點治理-預期成效

埋點治理的改造項目是一項正在進行的工作，我們希望能夠通過流程管控和技術支撐來提高開發效率，實現數據質量和數據價值的提升，主要包含以下三個方面：

• 不需要再人工進行坑位标準化，所見即所得，埋點上線後直接用于數據分析、數據産品等；
• 歸因鍊路不需要再人工梳理和單點開發，埋點上線後攜帶多種歸因字段，精确的位置和資源信息，支持實時歸因；
• 埋點質量提升，埋點時機口徑标準化，多端一緻，上線流程優化。

04資産治理

降本提效是資産治理的一個核心，這一塊将從數據流治理和生命周期治理兩方面來介紹我們的工作。

1. 資産治理-問題和痛點

資産核心就兩個部分：計算資源和存儲資源。

• 計算資源：目前整個集群CPU内存的使用率絕大多數時間都在80%以上，我們的任務在半年内增長了15%，接下來我們可能就會遇到一個數據開發團隊普遍會遇到的問題，就是核心任務延遲。
• 存儲資源：整個集群存儲量的日均增長近0.4%，在整個量級是PB級的存儲情況下，這個增量也是非常可觀的；另外還有90%的表可能都是無引用的表。

從計算和存儲兩方面來看，也有很多曆史包袱的問題。比如可能存在大量的無人浏覽的報表，大量的曆史遺留任務等，這些都是我們在資産治理方面需要解決的問題。

2. 資産治理-數據流治理

數據流治理又分兩個小點：分層模型數據和治理、單任務内數據流治理。

分層模型治理，本質上是數據标準、數據規範的一個落地。

• 當我們遇到一個數據産品各項指标需求的時候，需要去分析什麼樣的指标是可以沉澱到公共模型去的，什麼樣的指标是需要在ADS才完成的。比如我們ADS處理的是一些不可加指标、自定義規則标簽以及自定義的多維分析。
• 我們也需要去分析什麼樣的指标是需要沉澱到我們的公共資産裡面去的。比如說客觀事實的派生指标可能需要的團隊不同，可能時間周期要求不一樣，可能有的要求看1日的指标，有的想看7日的，有的30日，有的3日。這些可能在我們的整個DWS層處于同一個加工流程隻是一個不同時間周期的處理。另外多團隊一緻複雜指标的典型案例就是我們對一些資源或者用戶會進行一個綜合評分，綜合評分會用到多種多樣的場景。
• 一些缺失的原子指标必然需要從我們的DWD層去重新加工。

單任務内數據流治理這塊主要講一下我們在做單任務優化的時候的大任務拆解策略。

大任務内部邏輯是否需要拆解我們從兩個方面來考慮：

• 拆解執行過程，降低任務的失敗或者延遲恢複的成本。因為某一個節點失敗之後，可能我們隻需要從這個節點重新進行恢複，不需要重新執行整個任務，因為有時候重新執行整個任務需要好幾個小時。
• 避免做過度拆解，因為可能多餘的任務啟動和IO的過程反而會導緻效率的下降。

這邊簡要總結幾個我們在優化過程中的經驗：

• 需要緩存的中間結果拆解。要考慮先做子節點的拆解，避免重複計算。
• 盡量避免拆解為串行任務。拆為串行任務并沒有優化整個執行過程，反而導緻了多餘任務啟動還有IO過程的問題。
• 依賴産出不穩定的多個部分拆解。比如将上遊産出不穩定的部分拆分為多個節點，這樣就能夠降低上遊任務的影響，分散計算資源占用的時間。

案例：我們有一款數據産品是一個推歌的産品，核心是生産歌曲畫像标簽。歌曲畫像我們總共做了400多個标簽，之前随着産品快速疊代和煙囪式開發，産生了大量ADS表，其中包含許多重複的數據加工邏輯。在落地我們的模型設計規範之後，減少了十個ADS表，沉澱了50多個指标到CDM，讓我們整個數據的産出時間提早了兩個多小時。有的任務裡面可能會加工特别多的數據，我們通過對單任務數據流的優化，實現了單表耗時減少30%以上。

3. 資産治理-生命周期治理

資産治理的另外一部分就是生命周期治理，生命周期治理主要考慮三個部分：

• 業務場景分析：在模型設計的時候，需要我們綜合業務場景、應用場景去規範設置表的生命周期，并對過期的任務和數據進行清理；同時對于一些新老模型更替的情況，即使對老任務和相關依賴進行遷移和下線。
• 數據血緣分析：數據血緣能夠幫助我們去識别表被引用和訪問的情況，做自動的生命周期診斷，基于分析結果進行針對性清理。
• 成本分析：成本分析是幫助我們針對一些高計算、高存儲成本的任務和數據進行重點排查和治理，針對不同的情況做優化、改造或下線。

這塊我們也借助網易數帆開發平台中的數據資産中心，支持我們做存儲分析、計算分析、報表分析，來幫助我們去更好地管理任務和表的生命周期。通過這個平台我們已經下線了100多個報表和相關的任務，節省存儲超過1PB。

05展望

最後對我們雲音樂未來數據治理做一些規劃和展望，我們希望做到的是自動化的數據治理方案。主要有幾個方面：

• 數據資産的可視化。将我們整個數據倉庫的标準做一個可視化，讓更多的數據使用方明确地知道倉庫裡面有什麼樣的數據，怎樣使用倉庫中的數據。
• SQL靜态代碼檢查以及性能監測與告警。目前數倉開發需要同時完成開發和測試工作，而且數倉團隊的規模也在不斷擴大，光靠人工保障開發質量是不可控，還是需要結合平台能力來對我們的代碼進行管控。
• 制定健康度評分。這個是希望從數據生産和使用的多個方面，對數據本身或者數據工作者進行一個綜合的判斷，并反過來去指導我們更高效更合理地做數據生産和分析。

06

精彩問答

Q：數據治理之後的顯著成果有哪些？

A：第一個是數據規範的落地。之前整個數倉是沒有一個明确的分層定義的，現在我們會将整個數據資産搬到我們的數據平台去，重新定義好分類，重新構建DWD、DWS、DIM。現在有一百多個已經分好數據域數據分層的模型。第二個是新的埋點正在逐步上線。因為涉及到曆史埋點和新埋點的兼容問題，所以目前正在做上線前的測試以及新老數據的對比工作。資産治理方面，通過數據平台管理任務，我們下線了100多個報表，使得線上的一些核心任務能夠能有更好的計算資源的保證。

Q：數據治理的成果如何來通過指标來量化？

A：基于我們網易的開發平台，有一些資産大盤。我們現在目前整個存儲增長是一個什麼樣的情況，表的生命周期管理是什麼樣的情況，有多少推薦下線的表以及我們真的下線了多少，這些具體指标我們平台裡面都會有。

Q：能詳細說一下技術架構嗎？

A：這個架構圖DIM層、DWD層可能各個公司都一樣，主要講一下DWS層。比如從社交互動這一塊，因為我們是個内容平台，除了有消費者之外還有生産者。所以我們根據内容、生産者、消費者這三個核心，以及坑位來去設計這一塊。這裡總共分了兩條線，一個是我們區分多個維度的一個聚合的快照；另外一個是我們在做一些活動、報告或者總結的時候，經常會用到的比如用戶的首次行為是什麼樣子的，歌曲的首次行為樣子的這種信息。我們會針對這類需求再做一些公共模型，比如落到每種資源的首末次詳情。除此之外，我們還會做比如播放或者互動行為的留存情況。這一塊的設計是，在流量這塊我們也會有一個簡單的多維分析的聚合，也會有針對用戶和坑位的首末次情況，以及用戶和坑位的留存情況。其實在整體設計上來說，思路都是一樣的，隻不過我們從橫向和縱向再進一步做了一個拆解。然後頂層這一塊，因為我們經常會用到，比如歌曲畫像裡面，歌曲什麼時候達到了它的播放峰值，還有其他類似相關的時間點級對應數據的記錄，我們針對這類需求場景做了一些的累計實時的快照表，這樣方便我們去對資源或者對用戶進行整個生命周期的分析。

Q：可以聊一下數據和業務之間的關系嗎？哪一個更重要？

A：數據和業務應該不存在說哪個更重要，因為我們數據需要根據業務來做疊代，業務需要用數據來做支撐。比如說怎樣合理的分配我們的流量，怎樣合理的分發歌曲，怎樣合理的設計産品，這些東西都需要我們數據去做支撐。另外一個就是數據的價值，音樂版權的采買情況或者是ROI的分析，需要我們從數據層面來進行支撐。通過這一套數據我們做了一個版權評估系統去支持我們的業務做相關決策。

今天的分享就到這裡，謝謝大家。

分享嘉賓：

分享嘉賓：宋志毅 網易雲音樂

編輯整理：王劍芬 杭州覓谷科技

出品平台：DataFunTalk

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!