全文將圍繞以下四部分展開：

• 傳媒業(yè)務介紹
• 數倉建設演進
• 數據管治體系
• 數據管治展望

01傳媒業(yè)務介紹

1. 業(yè)務介紹

?

網易從門戶網站到新聞客戶端，我們的目標是讓用戶在短時間內去中心化地獲取內容信息。整體的業(yè)務流程可以簡單理解為：內容生產者生產內容，平臺負責分發(fā)，用戶去消費這些內容。

大數據團隊的工作職責是：支撐業(yè)務運營日報等核心數據報告的產出，支撐ab實驗平臺、運營平臺、渠道分析等各個系統(tǒng)的一個數據產出，提供個性化自助報表及數據的多維分析服務，客戶端買點的數據采集以及買點規(guī)范化的數據建設。

2. 數據架構

數據架構從上到下分為數據接入層、數據計算層、數據服務層和數據應用層。

• 數據接入層：將業(yè)務數據庫的數據（比如內容生產數據、用戶信息）、公司集團的數據（如用戶畫像等），還有客戶端日志、服務端日志等，這些結構化和半結構化的數據統(tǒng)一接入數倉。
• 數據計算層：采用Lambda架構，離線計算和實時計算分離，離線計算采用Spark on Hive，實時計算采用Flink，離線和實時數倉分層是統(tǒng)一的，從下到上分別是ODS層、DWD層、DWS層和APP層。
• 數據服務層：包括兩部分，一部分是數據工具層的存儲，另一部分是數據標準服務，我們標準化、統(tǒng)一化了數據輸出。
• 數據應用層：包括內部數據應用和外部數據應用。

02 數倉建設演進

接下來給大家介紹傳媒的數倉建設的演進歷程。

1. 從1.0到2.0

2015年之前，當時的背景是我們公司業(yè)務還處在一個門戶資訊的階段，這個時候的內容形式比較單一，大多是以新聞文章、圖文為主，數據的豐富度比較低，數據量級也很小，數據需求以面向公司整體的運營的數據報表為主。當時沒有專業(yè)的數據團隊，所有的數據需求都統(tǒng)一是平臺組去支撐。

隨著公司業(yè)務發(fā)展，我們從門戶資訊向泛資訊轉型，內容載體不再只是圖文文章，陸續(xù)引入了視頻、直播等新的載體。內容生產方也不僅是編輯老師，而是增加了PGC、UGC，內容生產更加多元化，同時也衍生出了很多平臺，數據需求常常得不到及時響應。另一方面，之前的數據統(tǒng)計邏輯大多在APP層，數據口徑不統(tǒng)一，對數、問題排查的成本極高。

我們開啟了數倉2.0，從零到一去搭建數據團隊，數倉建模采用維度建模的方法，自下而上進行數據建設，以高效支持業(yè)務需求為目的。我們也取得了如下的成果，確定了一個清晰的數據分層，確定了面向業(yè)務過程的數倉主題后使得影響范圍是可控的，數據輸出產品化，衍生了傳媒數據報表門戶、內容運營平臺等數據產品，較好地支持了定制化的數據產品需求，也較好的支持了業(yè)務的精細化運營。

2. 從2.0到3.0

我們在今年初開啟了數倉3.0，針對臨時數據需求，開始進行面向分析主題的一個寬表建設，再加寬表模型產品化輸出，和業(yè)務方定期宣講我們的寬表模型以及自助取出工具使用，讓業(yè)務方直接在產品層面界面化的探索，獲取自己想要的數據。我們還對數倉層級進行了簡化，將原來的六個層級，在邏輯層面簡化為了標準的四層，并在ODS層引入了視圖，將數據解耦。

03 數據管治體系

1. 開展數據管治的背景

傳媒業(yè)務快速發(fā)展，數據團隊承接了大量的數據需求，同時在資源成本、數據質量以及研發(fā)效率上面臨了很多痛點問題：

• 成本：資源使用負載高，資源使用不可控，為了資源最大化使用，所有離線任務都是提交到一個隊列上，沒有限制，一個不規(guī)范的任務占用大量資源，影響核心報表產出的情況在所難免。
• 質量：由于資源使用負載高和不可控，導致數據SLA不穩(wěn)定，并且數據質量建設體系缺失。
• 效率：資源的限制也限制了研發(fā)效率，使得數據需求交付周期長。

綜合以上問題，我們確定數據治理是非常必要的。

2. 數據管理框架

數據治理建設圍繞DAMA數據管理指南展開，分為十個模塊，整體是以元數據驅動數據治理。本次將重點介紹在數據建模與設計、元數據管理、數據資產管理和數據成本管理方面的實踐。

①數據建模與設計

數據的循環(huán)流轉包括兩部分：第一部分是數據化運營，也就是用數據，讓客戶快速獲取想要的數據；第二部分是運營數據，也就是養(yǎng)數據、管數據，主要包括收集數據、數據分層、面向主題建設，不斷改進數據模型、提升數據質量，讓數據變得更加易用。

基于數據的循環(huán)流轉，我們規(guī)范了數據的研發(fā)流程。從用數據到養(yǎng)數據，再到用數據，形成了數據應用的閉環(huán)。

②元數據管理?

隨著數據產生速度的加快，元數據成為數據遷移和集成中不可或缺的一部分。隨著存儲能力的提升，元數據管理的作用也越來越重要。我們參考了DAMA數據管理指南，確定了元數據的語境關系圖，描述了元素據體系建設落地流程：確定元數據管理的目標-元數據的實施-從技術出發(fā)實現(xiàn)對元數據解析和影響分析。

• 元數據管理之元數據構成?

我們將元數據體系分為四塊：業(yè)務元數據、技術元數據、過程元數據和安全元數據。

• 元數據管理之數據地圖

?

第一塊是數倉表導引，基于數據的使用頻率以及業(yè)務的重要性，將數倉每個主題域下的一些核心的數據表對外開放，大家可以對數倉產出的所有的數據有個全局性的了解。

第二塊是數據洞察，當前只是初步實現(xiàn)了幫助用戶找數據、用數據的功能。

③數據資產管理

第一步，定義數據資產等級，分為L1-L4四個等級。第一塊是l4等級，是具有全局影響的一個數據資產，像項目的管理層日報等；第二塊是l3等級，是具有局部影響的數據資產，主要包括支撐業(yè)務的決策分析，就某個核心業(yè)務線獨有的一些核心指標和核心維度；第三塊是l2等級，是具有一般影響的數據資產，這塊兒出現(xiàn)問題幾乎不會帶來影響，或者帶來的影響非常小。最后一塊是l1等級，這塊是具有未知影響的一個數據資產。有了數據資產等級的定點，然后接下來就是如何去落地去執(zhí)行了。

?

第二步，落地執(zhí)行：數據是從業(yè)務系統(tǒng)中產生的，然后經過同步工具進入到數倉，最后再通過同步工具輸出到數據產品中進行消費。不同的數據產品劃分等級，再根據數據的血緣關系打上資產等級標簽，不同等級采取相應保障措施。核心資產的占比會控制在30%以內，同時會有準入準出的一個嚴格的審核流程。通過數據資產等級體系，確定了四個資產等級，36個核心數據報表，153個核心的數據生產任務。

④數據成本管理?

資源成本優(yōu)化分三塊：存儲成本治理、計算成本治理、資源成本運營體系。

• 存儲成本治理

通過存儲使用監(jiān)控、僵尸文件管理、生命周期管理、存儲格式壓縮和數據模型優(yōu)化的舉措，近幾年數據的物理存儲降低25%，當前周期內數據存儲的占用值處在穩(wěn)定階段。

• 計算成本治理?

搭建計算成本的監(jiān)控體系，設計相應維度和指標。

?

通過僵尸任務治理、郵件任務遷移等策略執(zhí)行，今年2月以來CPU使用率逐步降低且趨于穩(wěn)定。資源空閑下來，數據使用方可以及時獲取數據，調整運營策略。

• 資源成本運營體系?

建設了資源成本運營體系，分為事前、事中、事后。

事前對資源消耗場景進行了拆解，確定了每個場景的資源使用方，制定了《離線數據研發(fā)規(guī)范》等，并定期組織串講。事前主要保障大家對研發(fā)規(guī)范的認知對齊，減少不規(guī)范數據的提交。

?

事中主要是對數據任務的上限審核。目前是主要圍繞數據任務占用計算資源、存儲資源、SQL代碼規(guī)范以及調度信息設置四塊進行審核，避免不規(guī)范的任務上線，從而影響核心報表的一個數據產出。

事后的資源治理，一是對資源成本治理進行分類：計算成本治理主要包括無效任務的治理、超長任務的優(yōu)化，以此提高資源的使用率；存儲成本治理上主要包括冷熱數據的管理、數據模型的優(yōu)化、數據生命周期的管理等；數據采集上主要包括日志上下游的應用監(jiān)控、無效買點的清理下線。二是在計算資源方面，根據CPU和內存的資源消耗統(tǒng)計了資源使用任務的排行榜，定期去優(yōu)化計算資源占用top的數據任務和存儲資源。

小結：從資源視角看，通過存儲治理策略，近一年數據存儲減負25%，通過計算治理策略，CPU占用率降低了25%，通過建立資源成本的保障體系，資源使用穩(wěn)定、流程合理。從業(yè)務視角看，部分數據報表產出從12：00提升到10：00前，產出時間穩(wěn)定，運營、編輯、分析師、產品人員可以在上午處理數據需求。

04 數據管治展望

?

結合DAMA的數據管理成熟度評估以及傳媒業(yè)務的實際情況，我們認為數據治理主要有四個階段。

第一階段是初始階段，大家使用有限的工具集進行通用的數據管理，很少或者根本沒有治理活動，然后數據處理過程中的角色和責任在各個部門中是分開定義的，數據質量問題也是普遍存在的，基礎設施的支持也處于業(yè)務的單元級別。

第二階段是可重復級別。這個階段有一致的工具集或和角色來支持數據治理流程的執(zhí)行，開始使用集中化的工具去展開數據治理活動。在這個階段是主要是解決一個或者幾個非常關鍵的問題，在治理實施的過程中，大多還是依靠人為手動處理問題，組織也開始關注數據質量的問題。

第三階段是管理級，引入了可擴展的數據管理流程并且將它制度化。從數據生產的鏈路、整體的視角去集中規(guī)劃數據治理的一些相關功能。這個時候組織開始關注管理與數據相關的風險，并且確定數據管理評價，可量化的一些指標體系。

最后階段是優(yōu)化級，從前面的三個級別中獲取的一些經驗積累，然后結合強大的元數據體系，使得數據治理活動自動化，并且是高度可預測的。

網易傳媒2021年從零到一去開展數據治理，主要解決了資源使用負載高、不可控的痛點，搭建了數據資產的等級體系和資源成本的保障、運營體系，使得數據生產可長期穩(wěn)定可控。接下來希望依賴完善的元數據體系，實現(xiàn)數據治理活動的標準化、自動化。

05 Q&A

Q：數據鏈路監(jiān)控需要監(jiān)控整個卡夫卡的集群還是監(jiān)控寫入和讀取的數據就可以了？上升到數據質量是怎么做的？

A：我們會對卡夫卡、MySQL以及Oracle過來的數據進行數據一致性的監(jiān)控，監(jiān)控范圍包括接入數倉后的數據量和原來數據的數據量是不是一致，我們會根據資產等級體系對核心數據進行監(jiān)控保障數據整體質量。

Q：數據治理中數據量化比較難，有沒有好的方法或者一些實踐？

A：我們在做數據治理推動的時候，一個是治理可以對業(yè)務帶來哪些價值，明確了治理效果才能推動落地執(zhí)行。第二是元數據的覆蓋度和準確性。

Q：傳媒的數據治理的數據量多少？用到什么框架？

A：涉及到數據表的元數據大約4000張，數據報告超過1200，還有一些不能衡量的元數據。我們這邊參考DAMA數據管理知識體系，整體上以元數據驅動整個治理工作的展開。

Q：傳媒血緣體系如何實現(xiàn)的，是否需要人工介入，準確度有多少？

A：我們這邊的血緣體系主要包括兩塊，一塊是數據表的血緣關系，通過Hive的插件掃描SQL的代碼實現(xiàn)。第二塊是數據表對應的數據任務的血緣關系，主要靠大家在猛犸的離線開發(fā)建立任務。兩塊都會結合，以數據任務的血緣關系為準。