數(shù)據(jù)資產(chǎn)治理：元數(shù)據(jù)采集那點事

數(shù)據(jù)資產(chǎn)治理：元數(shù)據(jù)采集那點事

一、介紹

數(shù)據(jù)資產(chǎn)治理的前提要有數(shù)據(jù)。它要求數(shù)據(jù)類型全、量大，并盡可能多地

覆蓋數(shù)據(jù)流轉(zhuǎn)的各個環(huán)節(jié)。元數(shù)據(jù)采集就變得尤其重要，它是數(shù)據(jù)資產(chǎn)治理的

核心底座。

在早期的采集系統(tǒng)，我們主要面向數(shù)倉，通過"API直連方式"采集

Hive/Mysql表的元數(shù)據(jù)。隨著業(yè)務(wù)的快速發(fā)展，數(shù)據(jù)運營、成本治理的需求越

來越強烈。元數(shù)據(jù)需要覆蓋到數(shù)據(jù)全鏈路，包括離線計算平臺、實時計算平臺、

內(nèi)部工具，任務(wù)元數(shù)據(jù)等。采集元數(shù)據(jù)的過程中，我們遇到以下困難：

?數(shù)據(jù)類別多

需要采集組件的基礎(chǔ)元數(shù)據(jù)、趨勢數(shù)據(jù)、資源數(shù)據(jù)、任務(wù)數(shù)據(jù)和血緣數(shù)

據(jù)。

?平臺組件多

大數(shù)據(jù)平臺組件：Hive/Hbase/Kafka/Druid/Flume/Flink/Prest。，內(nèi)

部工具：BI報表系統(tǒng)/指標庫/OneService等。

?采集周期長

接入新的數(shù)據(jù)類型周期長，需要經(jīng)過需求評審、開發(fā)、測試、聯(lián)調(diào)、數(shù)

據(jù)核對、上線。

?接入效率低，采集穩(wěn)定性

接入每種數(shù)據(jù)類型需要和業(yè)務(wù)方對接，效率不高，采集過程出現(xiàn)異常中

斷，不能及時感知到。

本文主要從元數(shù)據(jù)的含義、提取、采集、監(jiān)控告警幾個方面，介紹我們做的

一些事情。

二、元數(shù)據(jù)

2.1什么是元數(shù)據(jù)

什么是元數(shù)據(jù)？元數(shù)據(jù)是“用來描述數(shù)據(jù)的數(shù)據(jù)"。舉個例子：我拿手機拍攝了

一張照片，查看照片的詳情，如下所示信息：

照片信息

文件名:IMG_20201217_114115

時間:2020年12月17號11:30:01

分辨率：4608X2592

文件大小：2.69MB

相機制造商：OnePlus

相機型號：ONEPLUSA5000

閃光燈：未使用閃光燈

焦距：4.10mm

白平衡：自動

光圈：f/1.7

曝光時間：1/50

ISO:1250

這些就是數(shù)碼照片的元數(shù)據(jù)，用來描述一張圖片。在資產(chǎn)治理平臺中，我們

采集Hive組件的元數(shù)據(jù)包含：表名稱、字段列表、責任人、任務(wù)調(diào)度信息等。

收集全鏈路的數(shù)據(jù)（各類元數(shù)據(jù)），可以幫助數(shù)據(jù)平臺回答：我們有哪些數(shù)據(jù)？

有多少人在使用？數(shù)據(jù)存儲是多少？如何查找這些數(shù)據(jù)？數(shù)據(jù)的流轉(zhuǎn)是怎么樣

的？結(jié)合血緣關(guān)系進行問題溯源和影響分析。

2.2采集了哪些元數(shù)據(jù)

如下圖所示，是一張數(shù)據(jù)的流轉(zhuǎn)圖，我們主要采集了各個平臺組件的：

示息：數(shù)據(jù)坡路圖馥曙羽嚴治理

?基礎(chǔ)元數(shù)據(jù)

表名稱、備注、字段列表、責任人、業(yè)務(wù)域、表所在集群、項目等信息。

.趨勢數(shù)據(jù)

表的大小、行數(shù)、文件數(shù)、分區(qū)數(shù)、任務(wù)調(diào)度時長、產(chǎn)出時間等信息。

?資源數(shù)據(jù)

集群的吞吐量、QPS、調(diào)度任務(wù)消耗Cpu、內(nèi)存大小等信息。

?血緣數(shù)據(jù)

表/字段級別的上下游依賴關(guān)系、任務(wù)的輸入輸出表依賴關(guān)系。

?任務(wù)數(shù)據(jù)

離線/實時計算任務(wù)的名稱、責任人、deadline告警時間、腳本、任務(wù)

配置等信息。

截至目前為止，采集到的平臺組件覆蓋了整個數(shù)據(jù)的鏈路。覆蓋數(shù)據(jù)類型10

種+,基礎(chǔ)元數(shù)據(jù)的數(shù)量主要包括：

10w+o

?離線平臺組件

Hive/Mysql0

?實時平臺

Flume/Kafka/Hbase/Kylin/Es/Presto/Spark/Flink等。

?內(nèi)部工具

BI報表系統(tǒng)、指標庫系統(tǒng)、OneService,測試QA系統(tǒng)。

三、元數(shù)據(jù)提取

如何從眾多平臺組件提取元數(shù)據(jù)呢？大致有這幾個方面：

?訪問Metastore獲取基礎(chǔ)元數(shù)據(jù)

一般的平臺組件會把元數(shù)據(jù)存儲在Mysql等關(guān)系型數(shù)據(jù)庫中，通過訪

問Metastore獲取基礎(chǔ)的元數(shù)據(jù)。

?獲取組件集群資源數(shù)據(jù)

平臺組件本身會提供Metrics和Alarm的監(jiān)控服務(wù)，定期請求服務(wù)，

把數(shù)據(jù)流入到Hbase/Opentsdb等存儲。通過訪問存儲并對指標數(shù)據(jù)

進行匯總統(tǒng)計，獲取集群或任務(wù)的資源數(shù)據(jù)。

?獲取平臺組件業(yè)務(wù)指標

數(shù)據(jù)中臺內(nèi)部有各種平臺，比如KP（Kafka基礎(chǔ)平臺）、RP（Flink實

時計算平臺）、RDS（管理Mysql的工具平臺）、DP（數(shù)據(jù)研發(fā)平臺）。

通過這些平臺自身提供的服務(wù)獲取基礎(chǔ)元數(shù)據(jù)、業(yè)務(wù)監(jiān)控指標、集群

QPS、吞吐量等數(shù)據(jù)。

?獲取血緣數(shù)據(jù)用戶在DP平臺、RP平臺上開發(fā)計算任務(wù)，我們可以及

時的獲取發(fā)布的任務(wù)列表、任務(wù)的配置信息、SQL腳本等信息。

a.計算任務(wù)通過解析任務(wù)的輸入/輸出依賴配置，獲取血緣關(guān)系。

b.SQL類型任務(wù)通過"SqlParser"（使用ANTLR4系統(tǒng)實現(xiàn)的sql改寫

工具）工具解析SQL腳本獲取表/字段級別的血緣關(guān)系。

3.1離線平臺

主要是采集Hive/RDS表的元數(shù)據(jù)。

Hive組件的元數(shù)據(jù)存儲在Metastore,通過JDBC的方式訪問Mysql獲取

庫表的元數(shù)據(jù)。根據(jù)Hive表信息組裝成HDFS地址，通過FileSystemAPI獲

取文件的狀態(tài)、文件數(shù)、文件大小、數(shù)據(jù)更新時間等趨勢數(shù)據(jù)。RDS平臺提供了

對Mysql服務(wù)的管理，通過平臺提供的服務(wù)接口獲取表的元數(shù)據(jù)、趨勢數(shù)據(jù)、

訪問情況等信息。

3.2實時平臺

主要是Flume/Hbase/Kafka等組件的元數(shù)據(jù)。舉個例子:我們通過訪問KP

平臺落盤的工單數(shù)據(jù)，獲取topic的基礎(chǔ)元數(shù)據(jù)信息，定時消費topic獲取抽樣

數(shù)據(jù)，解析出字段列表。平臺本身提供集群狀態(tài)和業(yè)務(wù)監(jiān)控指標，通過平臺服務(wù)

獲取集群資源的使用情況。

3.3內(nèi)部工具

主要是BI報表系統(tǒng)（一張BI報表查詢的Hive表、Mysql表關(guān)系\指標庫

（指標關(guān)聯(lián)的Hive表和字段關(guān)系XOneService服務(wù)（接口訪問哪些庫表的關(guān)

系數(shù)據(jù)）的血緣數(shù)據(jù)。這些內(nèi)部系統(tǒng)在產(chǎn)品不斷迭代中積累了很多元數(shù)據(jù)。在不

考慮元數(shù)據(jù)時效性的情況下，我們一般同步這些系統(tǒng)的數(shù)據(jù)到Hive庫，經(jīng)過離

線處理得到元數(shù)據(jù)。

3.4任務(wù)元數(shù)據(jù)

元數(shù)據(jù)任務(wù)主要是DP離線任務(wù)、Flink計算服務(wù)、Flume任務(wù)。這些計算

任務(wù)都有落盤，通過Binlog同步或離線同步的方式獲取任務(wù)列表，得到任務(wù)的

元數(shù)據(jù)。

四、數(shù)據(jù)采集

經(jīng)過元數(shù)據(jù)提取，我們可以獲取數(shù)據(jù)全鏈路中各個平臺組件的元數(shù)據(jù)。數(shù)據(jù)

采集指的是把這些元數(shù)據(jù)入庫到數(shù)據(jù)資產(chǎn)管理系統(tǒng)的數(shù)據(jù)庫中。

4.1采集方式

采集數(shù)據(jù)主要有3種方式，下方表格列出了3種方式的優(yōu)缺點：

采集方式描述優(yōu)點缺點適用場景舉例

API直連請求組件提供無侵入強依賴API服有現(xiàn)成的API采集

的API服務(wù)獲快速接入務(wù)服務(wù)RDS/Druid元

取到元數(shù)據(jù)并滿足采集需求數(shù)據(jù)

入庫解析不同API

返回的數(shù)據(jù)格

式

離線采集同步組件的元無侵入數(shù)據(jù)時效性元數(shù)據(jù)提取復采集內(nèi)部工具

數(shù)據(jù)到Hive庫T+1雜，數(shù)據(jù)的時BI報表系統(tǒng)，

表，進行數(shù)據(jù)效性低指標庫系統(tǒng)的

離線處理得到元數(shù)據(jù)

元數(shù)據(jù)并完成

入庫

采集SDK業(yè)務(wù)方通過采快速接入有侵入性有獨立的平臺采集實時平臺

集SDK主動上解耦系統(tǒng)組件的元數(shù)據(jù)

報元數(shù)據(jù)到時效性高時效性高

Kafka

一般情況我們推薦業(yè)務(wù)方使用采集SDK。主動上報元數(shù)據(jù)，在接入時只需要

關(guān)注上報的數(shù)據(jù)格式、SDK的初始化，就能快速完成上報工作。

4.2采集SDK設(shè)計

采集SDK支持上報基礎(chǔ)元數(shù)據(jù)、趨勢數(shù)據(jù)、血緣數(shù)據(jù)，主要包括客戶端SDK

和采集服務(wù)端兩部分?？蛻舳薙DK主要實現(xiàn)了通用上報模型的定義和上報功能,

采集服務(wù)端主要實現(xiàn)了不同的適配器，完成數(shù)據(jù)的統(tǒng)一入庫。

4.2.1架構(gòu)

FlinkDruidKafka

采集

監(jiān)控

告警

數(shù)據(jù)

校驗

數(shù)據(jù)

鑒權(quán)

pull

采集SDK客戶端

定義了基礎(chǔ)元數(shù)據(jù)(MetaSchema\趨勢數(shù)據(jù)(TrendSchema\血緣數(shù)

據(jù)(的通用模型，支持擴展新的上報模型(

LineageSchema)XXXSchema)o

Reportservice實現(xiàn)了數(shù)據(jù)推送到Kafka的功能。

采集服務(wù)端

a.數(shù)據(jù)鑒權(quán)服務(wù)端消費kafka,獲取到數(shù)據(jù)后，對每條記錄的簽名進行認

證（取到記錄中的appld、appName、token信息，重新生成token

并比對值的過程X

b.統(tǒng)一入庫服務(wù)定義統(tǒng)一數(shù)據(jù)入庫模型，包括表基礎(chǔ)元數(shù)據(jù)、趨勢數(shù)據(jù)、

血緣數(shù)據(jù)、趨勢數(shù)據(jù)并實現(xiàn)不同數(shù)據(jù)類型入庫的服務(wù)。

c.數(shù)據(jù)適配器Bridge獲取kafka的數(shù)據(jù)，根據(jù)不同的數(shù)據(jù)類型轉(zhuǎn)換成

"統(tǒng)一入庫模型"，并觸發(fā)"統(tǒng)一入庫服務(wù)"完成數(shù)據(jù)的寫入。

4.2.2通用模型

采集的平臺組件多，我們參照Hive"表模型"的定義，抽象出了一套通用

的數(shù)據(jù)上報模型，保障了數(shù)據(jù)上報和數(shù)據(jù)存儲的擴展性。

?通用元數(shù)據(jù)模型主要包括接入方信息、表基礎(chǔ)信息、業(yè)務(wù)域信息、擴展

信息。

.通用趨勢模型主要包括表信息定義、趨勢指標定義、擴展信息。

?通用血緣模型一張血緣圖主要是由點、線組成的。點指的是表節(jié)點，邊

指的是任務(wù)節(jié)點；節(jié)點信息包括：節(jié)點名稱、節(jié)點類型、節(jié)點擴展信

息；表節(jié)點包括表基礎(chǔ)信息，可以唯一確定一張表，任務(wù)節(jié)點包括任

務(wù)的基礎(chǔ)信息。

通用血緣模型主要包含表血緣模型定義、表任務(wù)血緣模型定義，支持用戶單

獨上報表血緣、任務(wù)血緣。模型定義如下：

*表血緣模型定義

V

(5)Data

publicclassTableLineageSchema<TextendsTableNode>{

*當前節(jié)點

*/

privateTcurrent;

/**

*父節(jié)點

*/

privateList<T>parents;

/**

*子節(jié)點

*/

privateList<T>childs;

/**

*表級別血緣擴展信息,json對象，kv結(jié)構(gòu)

*/

privateStringextParam;

)

*表任務(wù)血緣定義

*

*/

@Data

publicclassJobLineageSchema<JobextendsJobNode,TableextendsTableNode>

(

/**

*彳甥節(jié)點艱

*/

privateJobtask;

/**

*輸入又攙列表

*/

privateList<Table>inputs;

/**

*輸出對象列表

*/

privateList<Table>outputs;

/**

*任務(wù)級別血緣擴展信息，json對象，kv結(jié)構(gòu)

*/

privateStringextParam;

)

每種模型定義留有擴展字段（約定json格式），不在定義中的指標可以放在

擴展字段，上報數(shù)據(jù)后，也會被存儲在元數(shù)據(jù)表的擴展字段中。接入新的類型,

指標定義差異性較大，通過擴展新的數(shù)據(jù)模型定義，完成元數(shù)據(jù)的上報。

4.2.3接入，校驗，限流

如何保障用戶上報的數(shù)據(jù)是安全的？我們設(shè)計了一組簽名：接入方Id

（appld1接入名稱（appName1接入標識（token工管理員填寫基礎(chǔ)的接

入方信息即可生成隨機的appld、token信息。業(yè)務(wù)方在初始化采集SDK時，

指定簽名信息，上報的每條數(shù)據(jù)會攜帶簽名。在采集服務(wù)端，會對每條數(shù)據(jù)進行

簽名認證，這樣保障了數(shù)據(jù)的安全性。采集SDK會對上報的每條數(shù)據(jù)執(zhí)行通用

規(guī)則，檢查數(shù)據(jù)的合法性，比如表名稱不為空、責任人有效性、表大小、趨勢數(shù)

據(jù)不能為負數(shù)等。檢杳出非法數(shù)據(jù)會過濾掉并觸發(fā)告警通知。在采集SDK服務(wù)

端，定時（每隔兩秒）消費Kafka一批數(shù)據(jù)，支持設(shè)置消費數(shù)據(jù)的時間間隔和拉

取條數(shù)，不會因為上報數(shù)據(jù)的流量波峰導致下游入庫壓力變大，起到了限流的作

用。

4.3觸發(fā)采集

我們支持了元數(shù)據(jù)的多種采集方式，如何觸發(fā)數(shù)據(jù)的采集呢？整體的思路是：

?增量采集變更的數(shù)據(jù)

?定期采集全量的數(shù)據(jù)

?實時采集SDK上報的數(shù)據(jù)

基于阿波羅配置系統(tǒng)（詳見：Apollo在有贊的實踐）和Linux系統(tǒng)的Crontab

功能，實現(xiàn)了任務(wù)的定時調(diào)度。數(shù)據(jù)采集任務(wù)配置在阿波羅上，變更配置后發(fā)布

阿波羅，實時同步配置信息到線上節(jié)點的Crontab文件中。

4.3.1增量任務(wù)，準實時

支持獲取組件最近變更的元數(shù)據(jù)酒己置增量任務(wù)才是升元數(shù)據(jù)采集的實時性。

比如增量采集Hive表元數(shù)據(jù)，每隔1分鐘查詢metastore獲取最近變更的元

數(shù)據(jù)列表，更新元數(shù)據(jù)。

4.3.2全量任務(wù)，兜底

增量采集可能存在丟數(shù)據(jù)的場景，每隔1天或多天全量采集一次，作為兜底

方案保障元數(shù)據(jù)的完整性。

4.3.3采集SDK,實時上報

采集SDK支持實時和全量上報模式，一般要求接入方數(shù)據(jù)變更后實時上報,

同時不定期全量上報一次。

4.4數(shù)據(jù)存儲，更新

數(shù)據(jù)采集后,要考慮如何存儲、元數(shù)據(jù)發(fā)生變更如何同步更新。我們對采集

過來的元數(shù)據(jù)進行分類歸一，抽象出"表模型"，分類存儲。

4.4.1數(shù)據(jù)存儲

我們評估了每種組件的元數(shù)據(jù)數(shù)量（總量10w+1預估數(shù)據(jù)可能的使用場

景，最終選擇Mysql存儲。為了滿足用戶的個性化查詢需求，構(gòu)建Es寬表。以

表粒度為主包括：表名稱、備注、責任人、字段列表、趨勢信息、業(yè)務(wù)域信息、

任務(wù)信息等。數(shù)據(jù)采集過程中同步更新Es表保障了元數(shù)據(jù)查詢的實時性，定期

（構(gòu)建離線模型表，每天同步更新Es表）全量更新一次，保障了元數(shù)據(jù)的完整

性。元數(shù)據(jù)中的表不是孤立存在的，一般有關(guān)聯(lián)的任務(wù)（離線任務(wù)，實時任務(wù)）

產(chǎn)出表，數(shù)據(jù)地圖中也會展示表和任務(wù)的流轉(zhuǎn)關(guān)系。那么在眾多的平臺組件中，

如何唯一的區(qū)分出一張表呢？我們是通過表所在的集群名稱、項目名稱、表類型

（來自哪個平臺組件1表名稱這幾個字段組合來唯一區(qū)分。數(shù)據(jù)分類儲存，最

終形成：基礎(chǔ)元數(shù)據(jù)表、趨勢數(shù)據(jù)表、任務(wù)元數(shù)據(jù)表、血緣數(shù)據(jù)表。

4.4.2數(shù)據(jù)更新

元數(shù)據(jù)表下線了，如何同步更新呢？

?全量采集，找差異全量采集時，獲取平臺組件的所有元數(shù)據(jù)，和資產(chǎn)數(shù)

據(jù)庫中的元數(shù)據(jù)表做全量比對，找出差異的表并設(shè)置下線。

?增量采集，走約定增量采集時，與接入方約定：已下線的表不上報，3

天未更新的元數(shù)據(jù)平臺會進行清理。

五、監(jiān)控預警

完成了數(shù)據(jù)的采集，是不是就大功告成了？答案是否定的。采集過程中數(shù)據(jù)

類型多、刪掉方式多樣、刪掉鏈路長，任何一個環(huán)節(jié)出現(xiàn)問題就會導致結(jié)果的不

準確。我們通過以下方式保障采集服務(wù)的穩(wěn)定性。

5.1采集鏈路監(jiān)控告警

5.1.1接口監(jiān)控

我們把系統(tǒng)所有的服務(wù)接口劃分為三個等級：核心、重要、一般，并支持注

解的方式打標接口和責任人，發(fā)生異常觸發(fā)不同程度的告警通知。核心服務(wù)異常

直接觸發(fā)電話告警，重要或一般服務(wù)異常觸發(fā)郵件告警。系統(tǒng)會存儲接口請求和

執(zhí)行的狀態(tài)刪掉，每天定時向接口服務(wù)的責任人發(fā)送服務(wù)日報。通過將元數(shù)據(jù)的

采集服務(wù)標記為核心和重要服務(wù)，對"API直連方式"的接口做到了異常感知。

如下所示，是服務(wù)接口的告警通知：

[Warning][prod][data-dict]-數(shù)據(jù)資產(chǎn)平臺告警

你負責的[元信息采集]模塊(backup為XXX)出現(xiàn)[重要]等級問題，方法

^iIcom.youzan.bigdata.crystal.controller.HiveMetaController.getHiveDb],異常信息:null

host:XXXXXX

處理地址：https://XXXX

如下所示，是服務(wù)接口的告警日報：

[Warning][prod][data-dict]-數(shù)據(jù)資產(chǎn)平臺告警

[shunfengche]今日問題匯總

請及時收斂今日問題，總問題數(shù)1個，出現(xiàn)2次

【核心】問題0個：

【重要】問題0個：

【一般】問題1個：

[數(shù)據(jù)采集]com.youzan.bigdata.crystal.controller.HiveMetaController.getHiveDb今日出現(xiàn)2次，

已存在5天，歷史出現(xiàn)8次

host:XXXXXX

處理典：https://XXXX

5.1.2采集過程監(jiān)控

針對每個元數(shù)據(jù)采集服務(wù)，采集過程發(fā)生異常則發(fā)送告警通知。如下所示，是采

集過程發(fā)生異常觸發(fā)的告警：

[Waming][prod][data-dict]-數(shù)據(jù)資產(chǎn)平臺告警

你負責的[元信息采集]模塊(backup為XXX)出現(xiàn)[一般]等級問題，方法

=S：[com.youzan.bigdata.crystal.asyncworker.work.AsyncAIIRdsDDLWorker.run],異常信息:/n

###Errorupdatingdatabase.Cause:

com.mysql.jdbc.exceptions.jdbc4.MySQLQueryInterruptedException:Queryexecutionwas

interrupted

5.1.3kafka消息積壓告警

消費kafka數(shù)據(jù)，通過kp平臺配置消息積壓告警，針對采集SDK服務(wù)做

到了異常感知。

5.2結(jié)果數(shù)據(jù)比對

主要是事后監(jiān)控預警，定時探查采集的元數(shù)據(jù)數(shù)量異常波動。對不同類型的

元數(shù)據(jù)，通過比較當日采集的數(shù)量和近7天歷史平均的數(shù)量，設(shè)定異常波動告警

閾值，超過閾值觸發(fā)告警通知。針對采集的元數(shù)據(jù)結(jié)果表，配置一些數(shù)據(jù)質(zhì)量探

查規(guī)則，定時執(zhí)行異常規(guī)則發(fā)現(xiàn)問題數(shù)據(jù)觸發(fā)告警通知。這樣保障了對結(jié)果數(shù)據(jù)

的異常感知。比如已定義的數(shù)據(jù)質(zhì)量規(guī)則：

?表責任人：離職人員或特殊責任人（表的責任人是叩p,admin等）數(shù)

量。

?血緣：無關(guān)聯(lián)的任務(wù)，無上下游的表數(shù)量。

?趨勢數(shù)據(jù)：表趨勢值非法（默認值-1）的數(shù)量。

.業(yè)務(wù)域：表所屬的業(yè)務(wù)域值為-1（非法值）的數(shù)量。

5.3項目迭代機制，采集問題收斂

經(jīng)過事前、事中、事后的監(jiān)控告警機制，能夠及時發(fā)現(xiàn)并感知采集異常。對

異常問題，我們一般以項目迭代的方式，發(fā)起"a，組織關(guān)聯(lián)人復盤。追溯根因，

討