導讀：

本文結合過去一段時間云音樂數據開發團隊在數倉建設、數據治理方面的具體實踐，分享我們在數據治理方面的一些思路。

如今的云音樂已經成為一款大眾產品，用戶每天來云音樂聽歌、看評論、逛社區，這個過程中沉淀下來了海量用戶數據。平臺現在每天收集處理的用戶日志已經達到千億級別，整個集群處理加工使用的數據總量達到了200PB。解決這么大規模下數據存儲、處理、使用中的技術問題，作為一名數據開發首先是感到興奮，但另一方面更多的數據意味著花費更大硬件支出去做計算、存儲。如何發揮數據的價值，證明這筆錢花得值，同時降本增效最大化數據使用的ROI，是我們一直以來思考并且努力去解決的問題。

從我們調研大量類似發展階段公司的經驗來看，在這個時期推動數據治理，是一條被證明可行并能帶來巨大價值的道路。

那么什么是數據治理？實際上數據治理的范疇相當廣泛，按照Google對于數據治理的定義，它包含了數據生命周期（從獲取、使用到處置）內對其進行管理的所有原則性方法。涵蓋確保數據安全、私有、準確、可用和易用所執行的所有操作，包括必須采取的行動、必須遵循的流程以及在整個數據生命周期中為其提供支持的技術。

這么一看好像我們做的很多事情都可以往這個框子里裝。但同時數據治理有那么多的方向可以做，又可以從什么點入手？下面的篇幅中，我分享一些云音樂數據團隊過去在數據建設中做的工作，以及近期在做數據治理方面的思路和進展，最后會整理總結下在現階段我們眼中的數據治理體系是什么樣的？

在前面幾年的工作中云音樂數據團隊在數倉建設方面主要經歷了幾個階段：

1.1 完善公共層建模及建立相應的設計、研發規范。

通過“任督計劃”，團隊重點完成了幾件事情：編寫整理了《云音樂數據倉庫建模規范》，并在該規范基礎上與杭研共建了“easyDesign”數倉模型設計系統。同時也對云音樂的數據主題域、主題域之間關系進行了系統性的梳理輸出，完善了覆蓋全業務的總線矩陣。以上工作的開展讓云音樂的數據資產沉淀開始變得有方向，在后面的大半年內，完成了關于人、物、場景等實體的大量數據公共層建設。

1.2 數據鏈路治理

在完善自身的開發設計規范之外，我們總結用戶使用中反饋的問題，也把一部分精力投入到上下游數據鏈路的治理中。其中碰到比較突出的問題是埋點質量，我們在20年初開始做了第一個埋點治理的項目，主要的目標是希望通過標準的流程和對應的平臺工具把埋點的設計、開發、測試這個過程規范起來，做好事前、事中、事后的管理。音樂相關團隊和杭研經過碰撞共建，討論制定埋點流程、規范并完成系統化，埋點管理平臺“EasyTracker”面世。在此基礎上，數倉的小伙伴又花了大約半年的時間，把原有幾千個埋點做了遷移，基本實現了埋點格式的標準化以及埋點流程的規范和可管理。

1.3 推動自助取數，發揮數據生產力

杭州研究院汪院之前提出要做到人人用數據，天天看數據。我們重點去思考了怎么解決數據最后一公里問題。在工具層面，有數很快給出了EasyFetch（自助取數）的原型，后面的一段時間兩邊同學基本上是背靠背在解決各個問題，優化體驗。經過幾輪迭代下來，EasyFetch在功能性和易用性方面均能滿足業務的訴求。而我們重點思考的是怎么樣把工具的價值發揮到最大，這中間的核心還是數據，要有好用的適合自助取數分析的數據模型。通過大量的貼近業務線的應用層關鍵數據模型建設，以及開展的以下幾件事情：

明確每個指標、口徑，并明確其使用方法；

加入數據首頁，對每個數據模塊進行使用場景介紹；

前前后后約30+場線上線下培訓，針對每條業務線的運營、策劃成立自助取數POPO運維群，甚至一對一解決問題。

基本上做到自助取數的業務全覆蓋，整個2020年通過EasyFetch完成的自助取數超過15萬次，內部用戶400多人，最大日活超過100人。

前期幾方面的工作下來可以說解決了階段性的問題，進入21年云音樂啟動了IPO，整個21年分析師團隊和數據開發花了大量時間產出各類投資人關注的數據、指標、報告。同時業務方在更大的業務目標牽引下，有了更多、更精細化的運營動作，隨之而來的又是大量的分析、取數需求，更多的數據模型建設需求，還有更快速的響應時效要求。

2021年12月云音樂順利上市，團隊很好的完成了IPO數據項目。下個階段，如何做得更好？數據建設、數據治理最終是要服務于業務發展目標。下個階段團隊核心的目標是要能支持業務挖掘增量、運營存量，實現更精細化的運營。所以在數據的生產端，我們提出了要建立數據的精益生產體系，為業務提供統一、易用、準確、穩定的數據倉庫的目標。

在已有數據建設的基礎上要實現這個目標，有賴于開展更有效、體系化的數據治理，其中我們把質量治理、資產化、降本增效作為22年工作的重點目標。通過吸收已有的數據治理方法論（如DAMA）和業內公司的一些好的實踐經驗，展開了大量工作。

2.1 質量治理

很多人會問，你們做了這么久的數倉為什么還在抓質量問題？數據建模的設計、開發標準化是不是已經解決了這個問題？我的回答是：魔鬼在細節。就像每個汽車生產企業，對于車輛的生產過程，基本上也是標準化的，但豐田的質量就要比發明標準化流水線的福特更好。核心還在于對生產過程更細致的拆解和更有效的管理。所以質量管理是一個永無止境的問題，針對現階段的目標，我們重點從制定質量標準、強化規范執行、優化平臺工具幾方面去開展工作。

上圖是我們針對質量穩定性拆解需要做的事情，而每一個工作又可以細化出一個專項甚至幾個。

以元數據中心為例：作為定義數據的數據，元數據幫助我們更好的理解和刻畫數據本身以及反應數據與數據的準確關系，是數據治理的基礎。另一方面，元數據本身也是一種數據，也存在缺失、不準確等等問題，也需要治理。在云音樂的數據治理工作中，我們把元數據梳理及可獲取列為優先的工作開展。

上面的表格列了具體的分類細項和我們推動解決的一些問題，中間和有數一起花了一個季度的時間，通過雙周迭代的方式最終做到元數據可獲取，完整性準確性達到了我們治理的要求，也為我們后續的數據治理打下了一個堅實的基礎。

再以執行側的任務運維為例，生產環境的穩定性和安全對每個數據團隊來說都是頭等大事。曾經有一份統計，工業化生產過程中大部分安全問題來自于人，具體到杜邦的數據是96%。作為技術人員我們總是期望開發更好的工具去規避風險，而往往忽視了人的能動性。這并不是說把質量、安全這件事情簡單轉化為對人的考核。當一個人不知道應該做什么事情去達成目標時，他也沒法為這件事情負責。團隊前期花了非常多的時間去整理值班運維手冊，把信息同步、問題告警、原因分析、問題升級、記錄&復盤等等環節做成了SOP，同時制定了最重要的兩條軍規，（1）生產無小事”——再小的生產問題都要重視。（2）“哪里來的問題回到哪里去”——有始有終，最終處理結論一定要同步到問題開始的地方。一段時間下來執行效果顯著，今年上半年，整體任務破線率下降了60%，另一個重要的指標，線上修復時長降低了80%，這代表數據問題得到了更快速的處置。其他每個細項的工作，限于篇幅不再一一展開介紹，有機會單獨整理分享。

2.2 資產化

數據資產化的前提是數據成為生產要素，核心是要在生產中被使用且帶來價值，對于數倉建設來說就要解決可用、易用問題，同時要解決數據與業務價值關聯性的問題。而這些問題是否解決了，解決的程度如何需要有明確的標準來衡量。雖然我們每天在與各種指標打交道，但對于自身數據建設，我們在量化評估指標體系這件事情上思考是不足的。如何準確快速地回答“你們的數倉建得怎么樣？”這類問題經常困擾我們，如果把它當做一道證明題去回答，可能需要從幾個方面闡述：首先介紹下我們數倉整體的設計規范是什么樣的，從業務過程梳理到標準業務總線矩陣輸出，再到具體模型的設計遵循哪些原則和范式。然后可能會貼一張大圖，闡述下基本的分層，業務線的劃分等等?；蛘咴傺a充下我們已經建了多少個表，事實表有多少，維表有多少等等。或者再從價值層面做補充，通過一些show case去證明數據的magic power。

實際情況是提問的人可能并沒有那么耐心花一個小時去聽，然后還需要自己去判斷得出結論。對于最終用戶來說什么樣的設計規范和生產流程真的是他們最關心的嗎？顯然不是。所以最近的一段時間我們反思了過去的一些不成功經驗，也吸收了很多業內好的實踐，提出了新的用戶視角的標準來衡量數據倉庫建設的現狀。即“三度模型”，從建設進度、資產健康度、業務價值度這幾方面制定了量化的目標來定義建設水平，并且從這些目標出發制定了數據資產化的整體規劃。

在完成上述目標的過程中，團隊也逐步摸索總結出一套工作的方法論（如上圖），從制定相應的標準，到通過流程和工具完善治理能力，再到與相關方建立渠道持續運營，三板斧下來，拿到結果變得可以預期。經過一段時間持續的溝通（安利）和討論，各業務團隊的用戶逐漸對這套標準建立了共識。

少了長篇大論做證明題，而是定期把各項達成共識的指標透明化出來，結合結果做分析輸出，溝通成本變低了！對用戶來說，交付結果更可追蹤可預期，對數據團隊來說工作的努力、拿到的結果也更容易從數據層面來體現。

就以資產復用率為例，經過大半年的模型重構，以及對老模型的逐步下線（累計下線2.4萬張表），我們的數據資產復用率從30%，直接提升到55%，這表示我們的數據使用效率上得到了接近一倍的提升，同時這個數據與業內工作進行比較也看到目前云音樂數據資產整體的復用率在一個比較健康的水平，未來半年內我們也有信心可以提升到比較先進的水平。

2.3 降本增效

近期大環境的影響讓很多公司感受到“寒氣”，在業務面臨多重壓力，“降本增效”顯得尤為重要：通過降本增效提升企業生存耐力，為未來更快增長積蓄潛力，成為一種戰略手段。云音樂數據團隊的降本增效工作大致是從三個方面展開：

（1）成本

首先要算清大帳，關于這一點要感謝有數的同學，雖然每個月的賬單都讓人看得心驚肉跳，但是整體的收費情況，每個服務類目的支出以及對應的變更日志都列的非常清楚。使得我們可以把精力花在盤點各個服務水位上。有了總的和分類目的支出，以及各服務的水位整體情況，基本上可以對大帳有個清晰的概念，如下表（音樂離線集群部分盤點）：

有了成本大圖，需要進一步把成本下鉆拆解到業務線、團隊以及個人，拆解的過程中也碰到一些諸如任務歸屬責任人不清楚，血緣數據缺失等等問題，更進一步證明了元數據在數據治理中的重要性，好在我們和有數的同學花了一個季度的時間終于把元數據的問題搞定，做到了可用并且可視化。

（2）計劃

這里簡單列一下我們整體的計劃大綱，確定了幾個重點：1.前面介紹到的先搞定元數據，讓治理結果有數可依，治理過程精準把控。2.優先解決占成本大頭的存儲和計算的優化問題。

除了大綱確定具體方向和專項目標以外，具體到推進過程中我們從正反兩個思路去解決一個一個問題：正推，陣地戰，對于那些可以通過元數據的掃描梳理出治理目標，推進相對容易，可以按照迭代推進，逐步拿到結果。反推，攻堅戰，很多資源消耗產出鏈路是正常的，對應著正常的下游報表和功能。但經過多年的迭代，很多數據和功能已經不看了或者有更好的替代，需要去從最終的使用情況盤點和推進解決，這個過程中需要依賴數據，也要有重點地搞。甚至，在溝通中還需要那么一點戰斗精神...

（3）優化

作為碼農團隊，降本增效只靠運動式大掃除短期內能拿到確定性結果，長期做肯定不行，技術優化還是第一生產力。舉個例子，音樂業務優化結果比較顯著的一塊是通過和有數合作的Spark3+Z-order+Zstd改造優化拿到的。Spark3發布以來團隊一直在關注AQE等重要特性，希望通過優化大量的SQL執行計劃，提高整體集群Spark作業的性能和穩定性。而杭研的同學在Spark方面有大量深入的研究，經過調研除了AQE，也推薦我們通過引入Z-order提升文件壓縮率，從而提升整體的存儲資源效率。上半年經過多輪迭代、測試以及任務改造，我們完成了：

hive任務升級spark3.1，升級任務266個,升級任務消耗資源占比95%，優化之后的執行耗時降低60%以上，優化之后計算資源費用減少60%；

spark2升級spark3,完成631個spark2任務的升級，升級任務消耗資源占比90%，優化之后資源節省28.71%，性能提升52.07%；

spark3.1+zorder+gzip專項治理：升級優化170個，節省存儲占比68%，節省日均存儲55T，折合存儲成本798.3W/Y。

計算資源方面，經過一系列的升級動作，集群的穩定性在較長的一段時間內保持穩定，給后續的基線530項目（核心產出提前到每天5:30）提供了較好的保障。

存儲方面，日增趨勢放緩，由原來的日增170T，下降到日增50T(有一部分來自生命周期管理效果)。

近期一段時間的數據治理工作坐下來，簡單總結下我們所做的事情，大概可以以一張圖來簡單概括：

（1）方法論：沒有理論指導的實踐是盲目的，數倉建模、數據治理，都已經沉淀了較為成熟的理論體系，無論是熟知的DAMA數據管理知識體系，還是業內各團隊的專家對于數據治理的總結思考都為我們提供了非常好的理論和方法指引。

另一方面這些方法本質上是工具箱，不同團隊的發展階段、業務訴求不同，對應的數據治理方向和目標也就不同，必然對應著使用不同的工具去解決問題。

（2）標準：我們現階段在云音樂做的數據全生命周期治理，相應的標準化是貫穿在事前、事中、事后全過程的。事前建立共識、明確的可量化的目標，最好簽字畫押。比如我們的質量穩定性SLA標準、數據資產三度評估標準、資源水位量化評估標準等，事中要細化每一個執行環節制定標準動作，包括流程的建立，以及在每個節點上的SOP（比如我們的運維軍規、研發紅線），做到執行者有章可循。事后也要結合事前的目標，用評估標準來衡量完成的質量和進度，開始下一個循環。

（3）組織：數據治理一定是服務于業務的愿景和戰略，并不是一個脫離具體環境的萬金油任務，數據治理解決什么問題需要被明確定義。在云音樂，業務發展進入成熟期，精細化運營對取數看數質量、易用性等訴求以及整體降本增效的大背景促使我們提出了質量、資產化、降本增效三方面的目標。

關于執行以及角色分工，我們認為數據治理應該是一個融入生產過程，全員參與的事情。不建議通過增加新的獨立崗位，或者設立委員會的方式去推動數據治理的落地，而是通過明確職責分工，落實主體責任來進行。另外，為了防止數據團隊既當裁判員又當運動員，整個體系增加對抗性來保持穩定運行，我們在很多治理過程是通過與兄弟團隊合作來完成。比如在質量穩定性目標中，雖然sla標準整體由數據團隊來牽頭，但過程的考核監督、報告、復盤是由QA團隊來完成。

（4）技術：對于平臺化工具，我們堅持的觀點是先有具體問題，再有對應流程規范、最后才是工具。我們雖然有平臺開發小組，整體工作并沒有追求大而全，更多還是以實用為主，無用的輪子也少很多。

以上可以認為是數據治理中我們可以拿到的α收益，但有時新技術的創新、演進可能超出我們的想象，所以拿到新技術發展的β收益，要求我們必須保持對新技術的跟蹤同時經常與杭研公技團隊做技術交流。這是一件必須要堅持做的事情，過去的工作中帶給我們非常大的收益，這里也感謝有數團隊對我們的支持。