導(dǎo)讀：

本篇是首屆網(wǎng)易數(shù)據(jù)治理大賽一等獎的作品分享，來自于網(wǎng)易傳媒大數(shù)據(jù)團(tuán)隊。傳媒的數(shù)據(jù)管治實踐解決了資源使用負(fù)載高、不可控的痛點，搭建了數(shù)據(jù)資產(chǎn)登記和成本運營體系，保障了數(shù)據(jù)生產(chǎn)長期穩(wěn)定，為自動化數(shù)據(jù)治理提供了一個很好的落地方案。

今天給大家推薦的是來自網(wǎng)易傳媒大數(shù)據(jù)團(tuán)隊的《網(wǎng)易傳媒數(shù)據(jù)管治建設(shè)實踐》。本篇從四個部分向大家展開介紹，第一部分是傳媒的業(yè)務(wù)介紹，第二部分是數(shù)倉建設(shè)演進(jìn)，第三部分是數(shù)據(jù)管治體系，最后再介紹對數(shù)據(jù)治理體系化建設(shè)的一些展望。

1

業(yè)務(wù)介紹

1.1 業(yè)務(wù)介紹

首先介紹下傳媒的業(yè)務(wù)，網(wǎng)易是從新聞門戶起家，從門戶網(wǎng)站到新聞客戶端，我們的目標(biāo)是讓用戶在短時間內(nèi)，去中心化的獲取內(nèi)容信息。整體的業(yè)務(wù)流程是，內(nèi)容生產(chǎn)者生產(chǎn)內(nèi)容、平臺分發(fā)、用戶消費。

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

1.2 數(shù)據(jù)架構(gòu)

我們的數(shù)據(jù)架構(gòu)體系，整體可分為4層，從下到上分別是數(shù)據(jù)接入層、數(shù)據(jù)計算層、數(shù)據(jù)服務(wù)層、數(shù)據(jù)應(yīng)用層。

數(shù)據(jù)接入層：將業(yè)務(wù)數(shù)據(jù)庫的數(shù)據(jù)（內(nèi)容生產(chǎn)數(shù)據(jù)、用戶信息、網(wǎng)易號信息等）、公司數(shù)據(jù)（用戶畫像、渠道數(shù)據(jù)等）、客戶端日志、服務(wù)端日志等結(jié)構(gòu)化和半結(jié)構(gòu)化的數(shù)據(jù)，統(tǒng)一接入數(shù)倉。

數(shù)據(jù)計算層：目前是Lambda架構(gòu)，離線計算和實時計算分離。離線側(cè)技術(shù)選型主要是Spark on Hive。實時側(cè)技術(shù)選型主要是Flink。離線和實時數(shù)倉分層統(tǒng)一，從下到上分為ODS層、DWD層、DWS層和APP層。

數(shù)據(jù)服務(wù)層：數(shù)據(jù)服務(wù)層包括2部分，一部分是工具層的數(shù)據(jù)存儲，主要包括：有數(shù)MPP數(shù)據(jù)庫、ClickHouse、HBase、MySQL、Redis等，把數(shù)據(jù)計算層產(chǎn)生的面向分析主題建設(shè)的寬表明細(xì)和匯總數(shù)據(jù)、維度主數(shù)據(jù)等數(shù)據(jù)集輸出到對應(yīng)的數(shù)據(jù)容器存儲。另一部分是數(shù)據(jù)標(biāo)準(zhǔn)服務(wù)，我們會把數(shù)據(jù)庫中的數(shù)據(jù)，通過統(tǒng)一的API接口平臺對外提供，滿足各類取數(shù)需求。在數(shù)據(jù)服務(wù)層，標(biāo)準(zhǔn)化、統(tǒng)一化了數(shù)據(jù)輸出。

數(shù)據(jù)應(yīng)用層：一塊兒是內(nèi)部業(yè)務(wù)數(shù)據(jù)應(yīng)用，主要包括有數(shù)BI自助取數(shù)工具，管理層日報、推薦數(shù)字化、編輯考核等數(shù)據(jù)產(chǎn)品；另一塊兒是外部團(tuán)隊數(shù)據(jù)應(yīng)用，主要包括算法特征底層數(shù)據(jù)、新聞熱榜APP端數(shù)據(jù)、網(wǎng)易號薪資結(jié)算系統(tǒng)數(shù)據(jù)支持等。

2

數(shù)倉建設(shè)演進(jìn)

2.1 數(shù)倉1.0~2.0

數(shù)倉1.0，也就是15年之前。當(dāng)時的背景是，公司業(yè)務(wù)還處在門戶資訊的階段，內(nèi)容形式單一，以文章、圖文為主，數(shù)據(jù)豐富度低、數(shù)據(jù)量級小。數(shù)據(jù)需求以面向公司整體運營的數(shù)據(jù)報表為主。當(dāng)時沒有數(shù)據(jù)團(tuán)隊，所有數(shù)據(jù)需求統(tǒng)一由平臺組支撐。

隨著公司業(yè)務(wù)發(fā)展，從門戶向泛資訊轉(zhuǎn)型的過程中，內(nèi)容載體不僅僅是文章、圖文，陸續(xù)引入了視頻、直播等新的載體；內(nèi)容生產(chǎn)方也不僅僅是編輯老師，又引入了PGC 和 UGC，內(nèi)容生產(chǎn)多元化。平臺運營也朝著精細(xì)化發(fā)展，逐步衍生出了內(nèi)容運營平臺、編輯考核平臺等平臺，數(shù)據(jù)需求得不到及時響應(yīng)。另一方面，數(shù)據(jù)統(tǒng)計邏輯也大多在app層，沒有在底層統(tǒng)一收口，導(dǎo)致數(shù)據(jù)口徑不統(tǒng)一，對數(shù)、問題排查成本極高。

由此，我們開啟了數(shù)倉2.0，從0到1搭建數(shù)據(jù)團(tuán)隊。數(shù)倉建模，采用維度建模的方法，自下而上進(jìn)行數(shù)據(jù)建設(shè)，以高效支持業(yè)務(wù)需求為目的。取得如下效果，確定了清晰的數(shù)據(jù)分層，面向業(yè)務(wù)過程的數(shù)倉主題；統(tǒng)計邏輯，底層標(biāo)簽化，影響范圍可控。數(shù)據(jù)輸出產(chǎn)品化，衍生了傳媒數(shù)據(jù)報表門戶、內(nèi)容數(shù)據(jù)運營平臺等數(shù)據(jù)產(chǎn)品，較好的支持了定制化的數(shù)據(jù)產(chǎn)品，支持了業(yè)務(wù)的精細(xì)化運營。

2.2 數(shù)倉2.0~3.0

隨著業(yè)務(wù)團(tuán)隊擴(kuò)張，新的業(yè)務(wù)功能在不斷探索，我們承接了大量的臨時跑數(shù)需求，業(yè)務(wù)方需要快速看到數(shù)據(jù)效果，來驗證假設(shè)。大量的臨時取數(shù)需求提到數(shù)倉后，需求交付效率大大降低，這是其中的一個問題。

另外一個問題是，隨著個性化推薦場景的上線，我們先后接入了召回、排序、下發(fā)全鏈路日志以及用戶畫像等數(shù)據(jù)，一開始需求簡單，直接引用推薦的數(shù)據(jù)表產(chǎn)出數(shù)據(jù)報告。隨著需求增多，導(dǎo)致大量的推薦側(cè)的數(shù)據(jù)表，直接擴(kuò)張到了app層數(shù)據(jù)使用。上游推薦數(shù)據(jù)一修改，導(dǎo)致我們這邊數(shù)據(jù)改動工作量極大。

基于以上問題，我們在今年年初，開啟了數(shù)倉3.0。

針對臨時數(shù)據(jù)需求，我們開始進(jìn)行面向分析主題的寬表建設(shè)，再將我們的寬表模型產(chǎn)品化輸出，和業(yè)務(wù)方定期宣講我們的寬表模型以及自助取數(shù)工具使用，讓業(yè)務(wù)方同學(xué)直接在產(chǎn)品層面探索、獲取想要的數(shù)據(jù)，至此臨時取數(shù)需求通過自助取數(shù)工具，開始收斂。

針對外部團(tuán)隊數(shù)據(jù)，在我們數(shù)倉側(cè)app層泛濫使用的情況，在ods層，我們采用視圖將數(shù)據(jù)解耦，統(tǒng)計口徑底層標(biāo)簽化，數(shù)據(jù)影響范圍達(dá)到可控。

另外我們還對數(shù)倉層級做了簡化，將之前的6個分層，簡化為了標(biāo)準(zhǔn)的4層。同時還確定了面向分析的主題、面向應(yīng)用的主題。在數(shù)倉層級劃分和數(shù)倉主題劃分上，通過不斷宣講，保證了認(rèn)知對齊。通過指標(biāo)系統(tǒng)、數(shù)據(jù)模型設(shè)計中心，在工具層面保障規(guī)范的落地執(zhí)行。

3

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

3.1 數(shù)據(jù)管治背景介紹

在數(shù)倉演進(jìn)的過程中，我們也遇到了數(shù)據(jù)資產(chǎn)難梳理、計算存儲資源超限使用等問題，針對這些問題，介紹一下我們數(shù)據(jù)治理做的一些工作。

首先介紹下傳媒這邊開展數(shù)據(jù)治理建設(shè)的背景，傳媒大數(shù)據(jù)團(tuán)隊是15年開始組建，近6年的時間，在數(shù)據(jù)規(guī)模上，我們線上調(diào)度的離線任務(wù)流達(dá)到4000+，數(shù)據(jù)報表個數(shù)1200+，服務(wù)的用戶數(shù)340+，數(shù)據(jù)系統(tǒng)個數(shù)13個。

隨著傳媒業(yè)務(wù)快速發(fā)展擴(kuò)張，數(shù)據(jù)團(tuán)隊也承接了大量的數(shù)據(jù)需求，同時在資源成本、數(shù)據(jù)質(zhì)量以及研發(fā)效率也面臨了很多痛點問題。

資源成本上有2痛點，第一塊是資源使用負(fù)載高，比如：計算資源凌晨4~12點 cpu使用率是100% ，因為計算資源上午是打滿的，數(shù)倉RD、分析師只能等到下午才能去做一些數(shù)據(jù)源探查、臨時跑數(shù)的一些需求，這塊兒受限于資源配額限制，工作效率也是大打折扣。另外一個問題是，資源使用不可控。因為歷史原因再加上為了資源的最大化使用，數(shù)倉、分析師等所有使用離線開發(fā)功能的團(tuán)隊，大家所有的離線開發(fā)任務(wù)都是提交到一個計算隊列上的，并且大家提交任務(wù)是沒有限制的，一個占用資源大且不規(guī)范的任務(wù)提交上線后，影響核心報表的數(shù)據(jù)產(chǎn)出，是在所難免的。

數(shù)據(jù)質(zhì)量層面，資源使用負(fù)載高、不可控，也使得數(shù)據(jù)SLA產(chǎn)出不穩(wěn)定。資源負(fù)載高、數(shù)據(jù)質(zhì)量不穩(wěn)定，也必然降低了研發(fā)效率，進(jìn)而導(dǎo)致數(shù)據(jù)交付周期長，業(yè)務(wù)滿意度低。

從數(shù)據(jù)規(guī)模、資源成本、數(shù)據(jù)質(zhì)量、研發(fā)效率這4個方面，我們對關(guān)鍵問題進(jìn)行了歸納梳理，也確定了開展數(shù)據(jù)治理是必要的。

3.2 數(shù)據(jù)管理框架

接下來，介紹下傳媒這邊是如何開展數(shù)據(jù)治理的，我們的數(shù)據(jù)治理建設(shè)，是圍繞DAMA數(shù)據(jù)管理指南展開，主要包括元數(shù)據(jù)、數(shù)據(jù)建模和設(shè)計、數(shù)據(jù)成本管理、數(shù)據(jù)資產(chǎn)管理、數(shù)據(jù)質(zhì)量等10大模塊。整上以元數(shù)據(jù)驅(qū)動數(shù)據(jù)治理。接下來，重點介紹下數(shù)據(jù)研發(fā)流程、元數(shù)據(jù)建設(shè)、數(shù)據(jù)資產(chǎn)管理和數(shù)據(jù)成本管理在傳媒這邊的建設(shè)實踐。

3.3 數(shù)據(jù)研發(fā)流程

這里先介紹下數(shù)據(jù)的循環(huán)流轉(zhuǎn)，包括2部分。第一部分是數(shù)據(jù)化運營，也就是用數(shù)據(jù)，這個階段主要是讓用戶快速獲取想用的數(shù)據(jù)，判斷、解決問題。第二部分是運營數(shù)據(jù)，也就是養(yǎng)數(shù)據(jù)、管數(shù)據(jù)，這塊兒主要完成收集數(shù)據(jù)，數(shù)據(jù)分層，面向主題建設(shè)，不斷改善數(shù)據(jù)模型以及數(shù)據(jù)質(zhì)量，讓數(shù)據(jù)易用。

基于數(shù)據(jù)的循環(huán)流轉(zhuǎn)，我們規(guī)范化了數(shù)據(jù)研發(fā)流程，主要包括，業(yè)務(wù)方(產(chǎn)品、運營同學(xué)等) 提出數(shù)據(jù)需求給到數(shù)據(jù)PM，數(shù)據(jù)PM接到需求后，分析需求，之后與數(shù)據(jù)RD、數(shù)據(jù)需求方三方確認(rèn)可行后，數(shù)據(jù)PM產(chǎn)出數(shù)據(jù)PRD。數(shù)據(jù)同學(xué)接收到數(shù)據(jù)PRD后，開始數(shù)據(jù)源探查，產(chǎn)出數(shù)據(jù)探查文檔，數(shù)據(jù)探查可行后，進(jìn)行數(shù)倉模型設(shè)計以及評審，評審?fù)ㄟ^后將PRD的指標(biāo)錄入指標(biāo)系統(tǒng)，之后開始進(jìn)行數(shù)據(jù)開發(fā)、數(shù)據(jù)自測，將數(shù)據(jù)表交付數(shù)據(jù)PM進(jìn)行測試，測試通過后，數(shù)據(jù)RD在DQC配置數(shù)據(jù)質(zhì)量監(jiān)控，任務(wù)上線，進(jìn)行數(shù)據(jù)SLA評估，核心數(shù)據(jù)報表加入基線運維保障，最后交付需求方。

以上是我們數(shù)據(jù)側(cè)的整個數(shù)據(jù)研發(fā)流程，從用數(shù)據(jù)到養(yǎng)數(shù)據(jù)，再到用數(shù)據(jù)，在一套規(guī)范的流程體系內(nèi)運轉(zhuǎn)，衍生了數(shù)據(jù)應(yīng)用的閉環(huán)，解決了數(shù)倉RD直接對接需求方，帶來的數(shù)據(jù)需求煙囪式開發(fā)以及維度指標(biāo)規(guī)范不一致等問題。

3.4 元數(shù)據(jù)體系建設(shè)

接下來和大家介紹下我們的元數(shù)據(jù)體系建設(shè)。元數(shù)據(jù)組成我們分為4塊：

第一塊是業(yè)務(wù)元數(shù)據(jù)(主要包括：數(shù)據(jù)需求管理、維度/指標(biāo)管理、數(shù)據(jù)報告管理)；

第二塊是技術(shù)元數(shù)據(jù)(主要包括：源數(shù)據(jù)管理、表模型管理等)；

第三塊是過程元數(shù)據(jù)(主要包括：任務(wù)生產(chǎn)信息、數(shù)據(jù)使用信息等)；

最后一塊兒是安全元數(shù)據(jù)(主要包括：安全密級、安全審計等)。

基于以上，我們具象了一張數(shù)據(jù)表的元數(shù)據(jù)構(gòu)成，主要包括表的模型分層、數(shù)據(jù)表安全密級、生命周期、任務(wù)信息、數(shù)據(jù)任務(wù)owner、血緣關(guān)系、表存儲大小、表的訪問熱度等信息。

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

有了元數(shù)據(jù)，接下來我們開始了數(shù)據(jù)資產(chǎn)管理體系建設(shè)。首先是數(shù)據(jù)資產(chǎn)等級定義，對齊了有數(shù)的任務(wù)優(yōu)先級，主要包括4個等級：

第一是L4等級，具有全局影響的數(shù)據(jù)資產(chǎn)；

第二是L3等級，具有局部影響的數(shù)據(jù)資產(chǎn)，主要包括支撐業(yè)務(wù)決策分析，某個核心業(yè)務(wù)線獨有的核心指標(biāo)和核心維度；

第三是L2等級，具有一般影響的數(shù)據(jù)資產(chǎn)，出現(xiàn)問題幾乎不會帶來影響或者帶來的影響極小；

第四是L1等級，具有未知影響的數(shù)據(jù)資產(chǎn)，這些數(shù)據(jù)資產(chǎn)，不能明確說出數(shù)據(jù)的應(yīng)用場景。

我們將L4、L3定義為核心數(shù)據(jù)，我們會將該等級對應(yīng)的數(shù)據(jù)任務(wù)也納入到基線值班運維，保障數(shù)據(jù)SLA。為了保證分級的ROI，核心資產(chǎn)的占比會控制30%內(nèi)，同時會有準(zhǔn)入準(zhǔn)出的審核流程。

以上數(shù)據(jù)資產(chǎn)等級的標(biāo)準(zhǔn)以及數(shù)據(jù)內(nèi)容，由分析師、數(shù)倉、數(shù)據(jù)PM三方組成的數(shù)據(jù)管理虛擬小組統(tǒng)一審核歸納。

有了數(shù)據(jù)資產(chǎn)等級的定義，接下來就是如何落地了。我們的數(shù)倉有近4000張數(shù)據(jù)表，如何給每一份數(shù)據(jù)都打上一個等級標(biāo)簽?zāi)兀?

數(shù)據(jù)是從業(yè)務(wù)系統(tǒng)中產(chǎn)生的，經(jīng)過同步工具進(jìn)入到數(shù)倉，在數(shù)倉中進(jìn)行ETL后，再通過同步工具輸出到數(shù)據(jù)產(chǎn)品中進(jìn)行消費。可以得出結(jié)論，在數(shù)據(jù)產(chǎn)品中使用的都是經(jīng)過數(shù)倉加工后的產(chǎn)出表。

可以通過不同的數(shù)據(jù)產(chǎn)品劃分?jǐn)?shù)據(jù)資產(chǎn)等級，再依靠數(shù)據(jù)任務(wù)的血緣關(guān)系，就可以將整個消費鏈路打上等級標(biāo)簽。針對不同的等級，采取不同的數(shù)據(jù)保障措施。比如L4、L3等級，定義為核心數(shù)據(jù)，我們會將該等級對應(yīng)的數(shù)據(jù)任務(wù)納入到基線值班運維，保障數(shù)據(jù)SLA。

通過數(shù)據(jù)資產(chǎn)等級體系，我們確定了4個資產(chǎn)等級，36個核心數(shù)據(jù)報表，153個核心數(shù)據(jù)生產(chǎn)任務(wù)，同時也保障了核心數(shù)據(jù)資產(chǎn)的數(shù)據(jù)質(zhì)量。

3.6 數(shù)據(jù)成本管理

對于如何進(jìn)行資源成本優(yōu)化，主要包括存儲成本治理、計算成本治理以及資源成本的運營體系。

在存儲成本治理上，我們通過僵尸文件清理，數(shù)據(jù)生命周期管理，存儲壓縮以及多個同粒度數(shù)據(jù)模型歸并優(yōu)化，近1年時間內(nèi)，數(shù)據(jù)存儲減負(fù)25%，且當(dāng)前周期內(nèi)存儲占用處在穩(wěn)定值。

在計算成本治理上，首先搭建了計算成本監(jiān)控體系，分析維度包括了日期維度、使用場景、角色等維度，指標(biāo)上包括規(guī)模類的指標(biāo)，如:當(dāng)日運行任務(wù)數(shù)，當(dāng)日消耗cpu總核數(shù)等；新增類指標(biāo)，如:近7天新增的任務(wù)數(shù)量等；最后是排行榜，如：計算資源按任務(wù)按負(fù)責(zé)人使用排行榜。

通過hive mr 到 hive on spark的遷移、計算資源占用top的任務(wù)優(yōu)化、僵尸任務(wù)下線以及不規(guī)范任務(wù)遷移優(yōu)化等策略的執(zhí)行，從今年2月至今，cpu使用率逐步降低并趨于穩(wěn)定，整體降低35%。資源空閑下來了，數(shù)倉RD、分析師上午就能跑一些臨時查數(shù)需求了。另外部分核心數(shù)據(jù)報表從12點產(chǎn)出提升到了7點前，產(chǎn)品、運營、編輯等數(shù)據(jù)使用方，可以及時的獲取數(shù)據(jù)，調(diào)整運營策略。

針對以上成本治理策略，我們建設(shè)了資源成本治理的運營體系，主要分為前、中、后。

事前，我們制定了《離線數(shù)據(jù)研發(fā)規(guī)范》、《數(shù)據(jù)抽取規(guī)范》等研發(fā)規(guī)范以及《SQL任務(wù)優(yōu)化指南》，定期會在團(tuán)隊內(nèi)組織串講，同時也會把常用的SQL優(yōu)化方法以及注意事項，定期和分析師團(tuán)隊分享，主要是保障大家研發(fā)規(guī)范的認(rèn)知對齊，從而減少不規(guī)范數(shù)據(jù)任務(wù)的提交。

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

舉一個我們使用過程中的真實案例，一位數(shù)據(jù)RD，需要開發(fā)一張app層的數(shù)據(jù)表，來配置對應(yīng)的數(shù)據(jù)報表。這位同學(xué)按照我們的研發(fā)流程進(jìn)行數(shù)據(jù)表設(shè)計、開發(fā)、測試，最后提交了一個離線數(shù)據(jù)任務(wù)到對應(yīng)的審核同學(xué)，審核同學(xué)看到該任務(wù)測試執(zhí)行，消耗的cpu core 大于1.5萬核，運行時長超過1小時，review了下代碼，發(fā)現(xiàn)SQL中依賴的用戶曝光日志表重復(fù)引用了10余次，導(dǎo)致數(shù)據(jù)被重復(fù)掃描計算。審核人員將工單駁回，告知相關(guān)同學(xué)優(yōu)化方式。優(yōu)化后，任務(wù)的計算資源使用是1600左右的 cpu core，資源節(jié)省近10倍，同時運行時長也縮減到25min。通過事中對資源使用的審核機制，阻斷了65+占用資源大且不規(guī)范任務(wù)的提交。

最后是事后的資源治理，計算資源這塊兒，我們根據(jù)cpu和內(nèi)存資源消耗，統(tǒng)計了資源使用任務(wù)排行榜，定期優(yōu)化計算資源占用top的數(shù)據(jù)任務(wù)。存儲資源這塊兒，我們設(shè)置了表推薦下線相關(guān)規(guī)則,中間表近30天訪問次數(shù)、日均job引用次數(shù)等指標(biāo)為0，這些數(shù)據(jù)表會被定期推送給相關(guān)負(fù)責(zé)人，人工review后，再進(jìn)行數(shù)據(jù)表的下線清理。數(shù)據(jù)生命周期也是類似，沒有設(shè)置生命周期、且總存儲占用或者單日新增存儲占用較大的數(shù)據(jù)表，定期推送給表的負(fù)責(zé)人，人工review后，進(jìn)行數(shù)據(jù)生命周期的合理設(shè)置。

以上是我們傳媒這邊資源治理建設(shè)的介紹?？偨Y(jié)下來，從資源視角看，我們通過存儲治理策略，近1年時間內(nèi)，數(shù)據(jù)存儲減負(fù)25%。通過計算治理策略，我們的CPU使用率降低了35%。通過建立資源成本治理的運營體系，使得資源使用穩(wěn)定、流程化、合理化。從業(yè)務(wù)視角看，部分核心數(shù)據(jù)報表產(chǎn)出時間從中午12點提升到了7點前，報表產(chǎn)出時間穩(wěn)定，運營、編輯、分析師上班前就能看到報表數(shù)據(jù)。另外凌晨4點到中午12點，計算資源得到優(yōu)化后，數(shù)倉RD、分析師、產(chǎn)品上午就能跑一些數(shù)據(jù)源探查、臨時查數(shù)的需求。

數(shù)據(jù)研發(fā)流程規(guī)范、元數(shù)據(jù)建設(shè)、數(shù)據(jù)資產(chǎn)管理，是我們數(shù)據(jù)治理今年的重點工作，接下來介紹下，對數(shù)據(jù)治理的一些認(rèn)知以及展望。

4

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

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

1級初始/臨時。使用有限的工具集進(jìn)行通用的數(shù)據(jù)管理，很少或根本沒有治理活動。數(shù)據(jù)處理過程中，角色和責(zé)任在各部門中分開定義。數(shù)據(jù)質(zhì)量問題普遍存在，無法得到解決，基礎(chǔ)設(shè)施支持處于業(yè)務(wù)單元級別。

2級可重復(fù)。有一致的工具和角色定義來支持流程執(zhí)行。開始使用集中化的工具(如:網(wǎng)易這邊杭研的猛犸數(shù)據(jù)資產(chǎn)中心)展開數(shù)據(jù)治理活動，主要解決1個或幾個關(guān)鍵的問題。在治理實施過程中，大多靠人為手動處理問題。組織開始關(guān)注數(shù)據(jù)質(zhì)量問題。

3級已管理。引入可擴(kuò)展的數(shù)據(jù)管理流程并將其制度化。從數(shù)據(jù)生產(chǎn)全鏈路，整體視角集中規(guī)劃數(shù)據(jù)治理的相關(guān)功能。開始管理與數(shù)據(jù)相關(guān)的風(fēng)險。確定數(shù)據(jù)管理評價可量化的指標(biāo)體系。

4級優(yōu)化。從1~3級獲得的經(jīng)驗積累中，結(jié)合元數(shù)據(jù)體系，使得數(shù)據(jù)治理活動自動化并且是高度可預(yù)測的。

傳媒在今年從0到1開展數(shù)據(jù)治理，我們解決了資源使用負(fù)載高、不可控的痛點，搭建了數(shù)據(jù)資產(chǎn)等級體系、資源成本運營體系，保障了數(shù)據(jù)生產(chǎn)長期穩(wěn)定、可控。接下來是依賴完善的元數(shù)據(jù)體系，實現(xiàn)數(shù)據(jù)治理活動的標(biāo)準(zhǔn)化、自動化。