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

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

01傳媒業(yè)務介紹

1. 業(yè)務介紹

?

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

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

2. 數(shù)據(jù)架構

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

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

02 數(shù)倉建設演進

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

1. 從1.0到2.0

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

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

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

2. 從2.0到3.0

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

03 數(shù)據(jù)管治體系

1. 開展數(shù)據(jù)管治的背景

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

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

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

2. 數(shù)據(jù)管理框架

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

①數(shù)據(jù)建模與設計

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

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

②元數(shù)據(jù)管理?

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

• 元數(shù)據(jù)管理之元數(shù)據(jù)構成?

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

• 元數(shù)據(jù)管理之數(shù)據(jù)地圖

?

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

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

③數(shù)據(jù)資產(chǎn)管理

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

?

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

④數(shù)據(jù)成本管理?

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

• 存儲成本治理

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

• 計算成本治理?

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

?

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

• 資源成本運營體系?

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

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

?

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

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

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

04 數(shù)據(jù)管治展望

?

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

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

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

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

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

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

05 Q&A

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

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

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

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

Q：傳媒的數(shù)據(jù)治理的數(shù)據(jù)量多少？用到什么框架？

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

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

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