雲娜:從計算、存儲角度,談網易數據治理工具產品實踐

導讀:在公司內部,業務線經常面臨數據有哪些、品質如何、是否可用、能產生多大價值的困惑,並且,隨著數據量的增加,計算和存儲資源面臨瓶頸。本次將圍繞數據治理重點關注的計算、存儲等方面,分享數據治理的產品實踐。通過分享,一方面可以了解當前業務線主要面臨的待治理的數據問題;另一方面,從計算、存儲等主要方面,了解數據治理需要重點關注的內容,同時,對數據治理的整體產品實踐有宏觀的認識,對內部業務線的數據治理提供針對性的建議。本次分享將主要包括以下幾大方面:

  • 過往數據治理回顧
  • 當前治理痛點
  • 產品整體策略
  • 未來規劃

01 過往數據治理回顧

這部分主要介紹網易內部業務線,包括嚴選、傳媒和音樂,做數據治理工作中遇到的問題、對應的產品解決策略,以及治理成果。

1. 專項治理背景回顧

專項數據治理活動有著以下背景:

  • 隨著業務的發展,數據部門的存儲、計算資源會陸續遇到瓶頸;
  • 難以判斷是否應該繼續擴容還是通過治理解決成本危機;
  • 難以清晰定義和處理劣質資源;
  • 缺乏統一數據標準;
  • 沒有明確數據的權責;
  • 無法判斷數據的價值意義。

2. 專項治理策略

file

在專項治理活動中,我們對各個業務線面臨的問題給出了針對性的策略。

首先是確權,明確責任人,每個數據表和調度任務都要落實到一個具體的責任人。由責任人負責推進治理中的具體任務。對於無人認領的資產,要各個業務線指定專項治理的負責人去做處理。
第二,優化存儲資源。首先要定義什麼是「無用數據」,把分析自動化,工具化之後進行優化操作,形成分析閉環。
第三,優化計算資源。從離線任務、實時計算到即席查詢,所有的消耗計算資源的任務都要納入成本分析核算。業務方看到相應的計算任務和成本後,才可以做優化治理的決策。另外要提供優化前後的效果分析比對來看是否達到預期。
第四,量化治理成效。存儲、計算治理累計的效果、單次的效果,需要變成一種量化指標。讓治理的成果一目了然。

file

上圖是成本度量體系的設計。紅色線框中是賬單體系,定義了成本的演算法,讓用戶輕鬆理解自己的賬單費用。黃色線框中是計算成本模組,根據規則把調度執行的計算成本算好形成賬單。綠色線框中會算出存儲成本。上邊的功能都會依賴於底層的調度任務/表的血緣等元數據資訊。

3. 產品功能落地

針對於上節所說的策略,我們做了對應產品功能的落地。整體有八個功能模組:

  • 任務/表具體化到責任人:負責人可以查看、篩選、治理、交接自己負責的資源。
  • 無用數據下線功能:負責人使用這個模組來完成下線治理操作,下線的資源會放入回收站一段時間後刪除。
  • 表生命周期設置:任何資源,包括內部表和外部表都需要設置生命周期,到期後如果不進行延期就會自動下線刪除。
  • 計算任務成本分析:給用戶提供計算成本的明細視圖。
  • 負責人紅黑榜:通過這個抓手,把各個負責人的資產健康好壞做一個榜單,推動促進治理。
  • 費用和下線指標:這塊展示治理的成效,用戶在這裡可以看到治理累計下線了多少邏輯數據、物理數據、節省的費用。也包括自動下線的成效。
  • 郵件通知 & 內部工具通知:通知內容分為了兩個視角,一方面是治理負責人,可以了解當前自己還有哪些數據需要進行治理,治理後可以給項目節省多少年費用;另一方面是項目的管理員/負責人,可以知道當前項目下一共還有多少數據需要治理,治理後總共可以節省多少年費用,也可以知道整個項目中治理做的好的負責人Top5,以及還有哪些人佔據的成本最多,可以以此為依據,催促負責人進行治理工作。

下邊是產品功能截圖:

file
file
file

4. 初步取得成效

從下圖中可以看到我們的治理成果數據。通過上述的多種策略,初步取得了治理成效。2020年,為雲音樂和嚴選分別優化了47.6%和61%的表,也為傳媒業務線節省了約38%的計算資源,數據治理各個業務線的專項活動策略得到了業務方的肯定。

file

02 當前治理痛點

這部分主要介紹當前治理的痛點,以及我們在制定落地策略的時候,會遇到的各種各樣的「坑」。

1. 當前遇到的痛點

file

上圖是我們已經解決的一些痛點:

  • 首先就是數據開發中的痛點。在做開發過程當中,缺少經驗的同學,會創建一些不規範的目錄;沒有按照規範創建外表等問題都會導致在下線刪除資源時候帶來丟失數據的風險。
  • 由於業務數據需求的優先順序高於治理,所以開發會疲於治理,缺少動力。再加上由於人員變更帶來的大量歷史遺留任務,治理起來比較費力。
  • 沒有形成治理的閉環,周期性的被動去做治理,沒有形成長效治理運營機制,無法形成良性循環。
  • 治理效果量化粗糙,導致價值無法精準體現,影響治理參與人的積極性。

2. 依舊填不完的數據「坑」

file

當前我們依然面臨成本問題,對於歷史數據較多的公司,數據治理需要一個過程。這個過程「前路漫漫,道阻且長」,我們亟待解決的幾方面問題包括存儲成本、計算成本、數據品質、模型規範、數據安全和數據價值這幾方面。具體如下圖所示:

file

03 產品整體策略

file

正如上文提到的諸多痛點,解決起來無法一蹴而就。我們選擇採取了階梯化的治理方案,整體分為三個階段:

  • 首先就是要明確治理的範圍,從數據產出到數據管理的整體流程中,明確哪些要做,順序是什麼,產出的預期效果是什麼。能夠讓決策者知道我們行動的範圍和影響範圍。
  • 第二就是明確和量化治理的價值。通過一套度量體系作為抓手,讓管理者在內的所有干係人看到我們治理會帶來的價值,為治理的行動創造良好的環境。
  • 第三就是體系化治理,把短期運營治理的方法策略工具化產品化,在流程上形成長期建設機制,形成一個良性的閉環,提升治理的效率和數據品質。讓所有人都從中受益看到效果。

1. 明確治理範圍

file

我們圍繞數據生命周期,從生產、消費到管理來梳理治理的範圍。在數據生產階段,需要對需求進行分析,明確業務口徑,對數據進行規範採集、任務開發和監控運維;在數據消費階段,涉及到快速的查找數據,對數據的分析和對數據品質的探查;在數據管理過程中,包含許可權和成本管理等。整個流程涉及到成本、標準、品質、安全和價值,各個階段都會面臨對數據的治理工作。

2. 量化數據治理價值

file

我們基於數據的全生命周期,通過資產的健康分來體現數據治理的價值,健康分涵蓋了成本、品質、安全、標準和價值五個維度,每個維度都要有可量化的指標項。

  • 首先是成本分,治理前後的成本變化可以體現治理的價值,成本是也衡量業務數據使用ROI的必要指標。
  • 第二是價值分,價值分體現衡量數據資產在業務上的重要程度,也是計算業務ROI的重要數據。有了成本和價值分,就為評估數據資產的優劣打了一個基礎。
  • 第三是品質分,通過一組規則來體現數據品質,這個是體現數據負責人和開發團隊對數據品質管理控的好壞,同時為數據品質的治理提供了參考依據。
  • 第四是標準分,涉及到數倉模型規範。規範的模型利於上層應用的效率,也是治理的一個重點。
  • 第五是安全分,涉及到資產安全等級和許可權管控的好壞。
  • 五個方面,每一個方面都會有一個計算權重,最後形成資產健康分。不同健康程度的資產涉及到不同的處理策略,比如說某人負責的數據低於某一個分值的時候,我們會限制此人新建任務的優先順序。我們通過類似的手段來推進數據治理的運營和數據健康的提升。

3. 體系化的數據治理

file

最後就是把數據治理進行體系化,讓數據治理活動形成閉環,能夠持續進行,從而保證數據資產的健康。首先是發現問題,我們配套多維度健康評估體系來量化發現問題。同時通過工具把問題和建議的解決方式推送給負責人去解決問題。配套資產賬單、治理紅黑榜,同時把健康分和預算申請進行關聯,促使治理能夠形成閉環。最後日常我們會做數據治理大賽、業務專項治理等專題活動來推動數據治理運營,讓數據治理形成一個良性的循環。

04 未來規劃

file

接下來用一個房子圖來介紹下我們的未來規劃。我們的願景是打造一款全流程、自動化、可落地、高品質的大數據評估和優化工具。數據治理工具的使命本是降本提效,省錢省力。

房子圖中願景以下分別是目標、抓手和支撐層。圖中可以看到,支撐層的完成度更高,因為這層是一個基礎。抓手層的兩大塊分別是健康分和通知機制,這兩塊已經實現了部分功能,已經能夠初步形成治理的閉環,接下來我們會繼續圍繞健康分把品質、安全和標準這部分做好。通過圍繞著健康分把數據治理的工作運營好,形成一個從問題發現到快速治理的高效閉環,來保證數據使用的效率、品質和安全,充分發揮數據價值。

05 精彩問答

Q:怎麼讓數據治理工作能夠內嵌到開發工作當中,而不是多出來的一項工作?

A:很多業務在使用數據的時候,是只開發不治理,這種方式會遺留下來不少需要治理的問題。很難避免要去單獨做數據治理。如果在業務開發初始階段就把數據規範、指標體系、指標口徑有一個規劃設計,並且按照規範落實。那麼後續會減少很多治理的動作。比如一開始創建表的時候,就要指定好是否分區表,數據的生命周期,這樣到期後,就可以自動刪除掉,也不會涉及這個表佔用了很多存儲,需要額外梳理和確定是否需要下線的工作。

Q:資產健康資產分是基於什麼得出來的?

A:健康分涉及到很多方面,成本、價值、規範、品質、安全等等。健康分的五個維度,都是從實際需要治理的任務抽象出來的,涉及到數據生命周期的各個環節。有了這樣一個資產健康分,再和用戶的開發許可權申請和資源申請進行掛鉤,能夠促進數據治理形成一個高效的閉環。

Q:數據治理,一般由誰來做?

A:數據治理涉及到資源方、使用方和管理方。一般來說我們會明確具體的負責人,他有義務對負責的表、任務做治理。實際執行時候,會碰到一些任務最早的負責人離職了,針對這種我們會指定專人治理。專人除了把自己負責的任務、表做好治理之外,還需要處理歷史遺留的治理任務。

Q:中台當中的數據治理都做什麼?只是資料庫表的原數據嗎?

A:其實剛才也說過,治理不只針對於資料庫表的原數據。數據從入倉到加工到後續生命周期的管理的這個流程上,每個階段都會涉及到數據治理。比如創建模型的時候,涉及到指標口徑的定義和模型的規範。再比如離線開發中的ETL加工,會涉及到數據源配置,數據品質校驗等,這些都涉及到治理的動作。那麼在應用層出報表時候,涉及到是否要建中間表等,也要有規範。整個生產應用的鏈條上都會涉及到治理,表和元數據只是其中的一方面,其他的比如涉及到計算資源的治理、安全的治理等。

Q:數據治理一般要花多長時間?

A:其實數據治理沒有一個既定的時間就能夠完成它,它不是做完之後就不用再做了,而是一個持續的過程。因為你的項目當中的表,你的計算任務隨著業務的需求肯定是慢慢在增加,一直在增加的。就像收拾屋子一樣,只要屋子有人用,總會再需要收拾。

Q:計算成本是怎麼核算的?

A:計算成本是看任務對CPU的消耗,折算成以CU為單位的數據,然後就可以根據硬體成本折算成費用。


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


分享嘉賓:

file
本文首發於微信公眾號「DataFunTalk」。