B站大數(shù)據(jù)平臺元數(shù)據(jù)業(yè)務(wù)分享

背景介紹

元數(shù)據(jù)是數(shù)據(jù)平臺的衍生數(shù)據(jù)，比如調(diào)度任務(wù)信息，離線hive表，實時topic，字段信息，存儲信息，質(zhì)量信息，熱度信息等。在數(shù)據(jù)平臺建設(shè)初期，這類數(shù)據(jù)主要散落于各種平臺子系統(tǒng)的數(shù)據(jù)庫中，例如HiveMetaStore,調(diào)度系統(tǒng)db等，在這個時期數(shù)據(jù)平臺主要以服務(wù)業(yè)務(wù)數(shù)據(jù)需求為主，平臺也以管理表，寫ETL，配置調(diào)度這類功能性需求作為重點，對于這些散落元數(shù)據(jù)的收集與統(tǒng)一管理并沒有太過強烈的訴求。

隨著數(shù)據(jù)平臺業(yè)務(wù)規(guī)模的增長，平臺會沉淀大量的數(shù)據(jù)表，調(diào)度任務(wù)等元數(shù)據(jù)。由于前期快速的業(yè)務(wù)發(fā)展產(chǎn)生大量數(shù)據(jù)管理成本，存儲計算成本。此時會逐步產(chǎn)生諸如模型規(guī)范治理、模型變更影響，指標(biāo)異動定位，重復(fù)建設(shè)治理等需求場景。基于這些場景需求，此時數(shù)據(jù)平臺僅提供數(shù)據(jù)開發(fā)相關(guān)的功能便難以滿足業(yè)務(wù)需求，需要建設(shè)以數(shù)據(jù)地圖（找數(shù)），血緣地圖（定位數(shù)據(jù)鏈路），影響分析工具，資產(chǎn)看板，治理工具等一系列偏向于事后的信息查詢、治理相關(guān)產(chǎn)品工具。

由于先前元數(shù)據(jù)的散落，導(dǎo)致系統(tǒng)間數(shù)據(jù)相互耦合，邊界不清楚，無法以全局視角觀察分析平臺數(shù)據(jù)資產(chǎn)，無法串聯(lián)數(shù)據(jù)之間的生產(chǎn)加工關(guān)系。于是建設(shè)起完善可靠的元數(shù)據(jù)服務(wù)成為后續(xù)滿足數(shù)據(jù)發(fā)現(xiàn)，數(shù)據(jù)治理業(yè)務(wù)的關(guān)鍵。

元數(shù)據(jù)基建

背景&目標(biāo)

B站的數(shù)據(jù)平臺元數(shù)據(jù)建設(shè)之初，由于對元數(shù)據(jù)的業(yè)務(wù)理解不夠深入，人力投入有限，實現(xiàn)方案采用的是針對特定需求深度定制化。比如需要某類Hive表的字段信息，那么就針對這個場景，設(shè)計一批hive表與字段的元數(shù)據(jù)表，通過直連HMS拉全量數(shù)據(jù)，定制業(yè)務(wù)邏輯消費HMS的Binlog進行變更同步，再通過暴露一批查詢表字段的HTTP接口，提供給需求方進行查詢。

基于這種模式，雖然短期也能滿足需求，但是暴露出了兩個大問題：1. 靈活性差，實現(xiàn)非常定制，難以支持頻繁出現(xiàn)的邊界場景，只能再針對新需求做排期開發(fā)，嚴(yán)重拖慢業(yè)務(wù)迭代速度 2. 開發(fā)維護成本高，大量定制的采集邏輯、異構(gòu)的元數(shù)據(jù)表、支持各種業(yè)務(wù)場景的接口，在有限的人力資源上難以支撐，還要隨時面對元數(shù)據(jù)模型變更的問題，采集質(zhì)量的問題。

在這種狀態(tài)下，也出現(xiàn)了一些必然結(jié)果，由于無法快速支持業(yè)務(wù)需求，需求方通常會自建離線元數(shù)據(jù)來跑通業(yè)務(wù)，產(chǎn)生了重復(fù)建設(shè)和后期治理的問題。由于開發(fā)維護成本高，支持元數(shù)據(jù)業(yè)務(wù)的同學(xué)疲于應(yīng)對各種需求，壓力大，還要兼顧各類線上的元數(shù)據(jù)質(zhì)量問題排查運維。

所以，體系化建設(shè)元數(shù)據(jù)的目標(biāo)之一就是統(tǒng)一元數(shù)據(jù)。即以統(tǒng)一的元數(shù)據(jù)模型，統(tǒng)一的采集方式，統(tǒng)一的存儲方式，統(tǒng)一的查詢方式支撐上層元數(shù)據(jù)業(yè)務(wù)需求。

系統(tǒng)總覽

統(tǒng)一元數(shù)據(jù)-模型

元數(shù)據(jù)模型需要滿足3點要求：

我們在這部分借鑒了業(yè)界的一些通用方案，以標(biāo)識協(xié)議URN+實體+關(guān)系進行了統(tǒng)一元數(shù)據(jù)模型的構(gòu)建。

統(tǒng)一標(biāo)識協(xié)議URN

URN = 協(xié)議域 + 業(yè)務(wù)域 + 資源類型 + 唯一資源ID

每個域之間以「:」進行分隔。

其中協(xié)議域全局固定為urn；對于數(shù)據(jù)平臺內(nèi)部的資源業(yè)務(wù)域統(tǒng)一為datacenter；資產(chǎn)類型為協(xié)商約定，由此文檔統(tǒng)一管理；唯一資源ID則由各個資產(chǎn)的定義方自行約定。

基于URN協(xié)議，我們已經(jīng)約定了16類的資源類型，以下列舉幾類作為示例：

這里針對最重點的資產(chǎn) - 表的URN定義展開討論一下，我們認(rèn)知中的表，可以來源于平臺內(nèi)部，比如最常見的Hive，ClickHouse表等，也可以來源于平臺外部，比如業(yè)務(wù)的Mysql，TiDB，還有一些是針對類似KV結(jié)構(gòu)映射出的邏輯表。

由于在血緣場景中，我們需要打通這些跨域類型的數(shù)據(jù)表的關(guān)系，所以需要站在全局的視角對他們進行統(tǒng)一標(biāo)識。我們采取的方案，使用了tab作為這些數(shù)據(jù)表統(tǒng)一類型，再以源.庫.表三段式作為唯一資源ID對各類數(shù)據(jù)源的進行表述，引申到字段同理，是以源.庫.表.字段四段式進行表述。

需要注意的是，如果要使用這種表達方式，必須滿足一個前提：具備統(tǒng)一的數(shù)據(jù)源管理，保障相同來源的數(shù)據(jù)源名稱唯一且不發(fā)生變更，比如使用同一個mysql集群下的數(shù)據(jù)庫中的表，必須在全部業(yè)務(wù)流程中，收斂為使用同一個數(shù)據(jù)源。這里會涉及到了關(guān)于數(shù)據(jù)源命名規(guī)范的問題，不多做展開。

實體關(guān)系模型

上圖的模型中大部分還是比較好理解的，但有以下兩個概念特別講解一下。

實體的Aspcet

在通常的理解中，一個實體的全部信息應(yīng)該來源于一個系統(tǒng)，這樣當(dāng)進行一類資源的采集時，我們只需要找那個系統(tǒng)去同步，但實際會存在一些特殊情況。比如，一張Hive表，它的基礎(chǔ)屬性都存于HMS之中，但是圍繞著Hive表，會建設(shè)很多衍生服務(wù)，這些服務(wù)會單獨管理一些衍生的業(yè)務(wù)屬性，例如Hive表的生命周期、安全等級等。

針對同一個實體，它的屬性來源分散的情況，我們借鑒了Linkedin開源元數(shù)據(jù)平臺DataHub中的設(shè)計，引入Aspcet(切面)概念，對來源不同的屬性進行區(qū)分。Aspcet在模型中的作用，更重要的是用在元數(shù)據(jù)采集時，這部分會在后面采集內(nèi)容說明。

關(guān)系的BuilderURN

在維護關(guān)系數(shù)據(jù)時，我們常會遇到一個問題，關(guān)系是由誰來構(gòu)建的。比如離線的表級血緣中，血緣關(guān)系通過調(diào)度任務(wù)來構(gòu)建，此時血緣的生命周期也應(yīng)該跟隨相應(yīng)的任務(wù)。針對類似場景，我們在關(guān)系模型中加入了builderURN作為抽象，也就是構(gòu)建關(guān)系的實體URN，這樣我們將任務(wù)的URN置于builderURN屬性中，而不是作為輸入輸出中的一個點。這樣做有幾點好處：

統(tǒng)一元數(shù)據(jù)-采集

元數(shù)據(jù)的采集部分主要涉及幾點問題，其中包含技術(shù)問題，也包含職責(zé)分工邊界的問題。

采集方式選型

對采集方式的選擇，一般會比較幾種方案：

1. 批拉取

采集側(cè)進行調(diào)度觸發(fā)拉取，業(yè)務(wù)側(cè)支持按業(yè)務(wù)偏移量進行增量查詢。優(yōu)點：采集配置可控，易監(jiān)控和運維。缺點：業(yè)務(wù)側(cè)需要配合進行定制取數(shù)邏輯開發(fā)，對業(yè)務(wù)數(shù)據(jù)的存儲更新方式有一定要求。

2. 批上報

業(yè)務(wù)側(cè)自行調(diào)度，按業(yè)務(wù)偏移量增量查詢后自主上報，采集側(cè)被動做消費。優(yōu)點：整體采集邏輯簡單，開發(fā)成本低。缺點：無法控制采集配置（頻率、間隔），采集問題難監(jiān)控、難定位，難運維。

3. 埋點上報

業(yè)務(wù)側(cè)將上報埋點到數(shù)據(jù)變更流程中。優(yōu)點：實時性強，對業(yè)務(wù)數(shù)據(jù)的存儲更新方式無特定要求。缺點：采集問題難監(jiān)控、難定位，幾乎無法運維。

這里我們選型是1和3，權(quán)重傾向于可控采集和采集質(zhì)量保障，對于需要強保障質(zhì)量的類型，我們主推采用1的方式做采集。對于一些非核心數(shù)據(jù)，或者存儲更新不規(guī)范，無法批量取數(shù)的場景，也可以選用3的方式由業(yè)務(wù)自行上報。

業(yè)務(wù)邏輯誰來維護

為了解藕業(yè)務(wù)，降低元數(shù)據(jù)去理解業(yè)務(wù)含義，維護業(yè)務(wù)變更等等成本，我們約定統(tǒng)一由數(shù)據(jù)源頭業(yè)務(wù)負(fù)責(zé)維護數(shù)據(jù)模型到統(tǒng)一元數(shù)據(jù)模型的轉(zhuǎn)換邏輯，也就是說，無論是自助上報，還是接口拉取，我們都會以統(tǒng)一的元數(shù)據(jù)模型來進行數(shù)據(jù)交換，避免產(chǎn)生業(yè)務(wù)邏輯處理各類異構(gòu)數(shù)據(jù)。

采集質(zhì)量保障

采集質(zhì)量保障是非常重要的一環(huán)，直接關(guān)系到后續(xù)元數(shù)據(jù)上層業(yè)務(wù)能否有效開展。在采集質(zhì)量方面，我們踩過很多坑，比如業(yè)務(wù)側(cè)硬刪數(shù)據(jù)、業(yè)務(wù)側(cè)數(shù)據(jù)事務(wù)落庫問題、業(yè)務(wù)側(cè)上報bug、消息中間件不穩(wěn)定等導(dǎo)致最終數(shù)據(jù)不一致，且缺少有效的數(shù)據(jù)監(jiān)控，定位處理成本非常的高。

基于這些問題，我們建設(shè)落地了成元數(shù)據(jù)質(zhì)量保障機制，核心思路是以單批次檢查和全局兜底檢查作為質(zhì)量問題的發(fā)現(xiàn)定位手段，以業(yè)務(wù)實現(xiàn)規(guī)范取數(shù)接口支持了采集全量拉取、采集增量拉取、運維補數(shù)拉取和運維靶向拉取，作為問題處理手段。最終做到自動化的完成采集質(zhì)量問題發(fā)現(xiàn)、定位、處理整套運維動作。

統(tǒng)一元數(shù)據(jù)-存儲

TIDB - 元數(shù)據(jù)DB，承載采集到的實體關(guān)系數(shù)據(jù)，作為元數(shù)據(jù)業(yè)務(wù)的中心存儲。

ES - 查詢搜索DB，數(shù)據(jù)從TIDB的實體表同步，提供元數(shù)據(jù)檢索能力，提供跨源跨表join，分詞查詢，權(quán)重控制，自定義詞包等能力。

HugeGraph - 關(guān)系搜索DB，數(shù)據(jù)從TIDB的關(guān)系表同步，提供圖結(jié)構(gòu)下的深度遍歷，路徑選擇，成環(huán)處理等能力。

統(tǒng)一元數(shù)據(jù)-查詢

在元數(shù)據(jù)查詢的場景中，有非常多的定制需求，不僅要滿足上層應(yīng)用對元數(shù)據(jù)的查詢，也要滿足來自用戶和數(shù)據(jù)治理層面的突發(fā)需求。所以在元數(shù)據(jù)查詢能力建設(shè)上，既需要具備通用性，支持各種靈活的查詢情況場景，又需要具備可復(fù)用性，避免重復(fù)建設(shè)導(dǎo)致維護成本的上升。

因此我們采用了通用元數(shù)據(jù)查詢的設(shè)計思路，查詢底層依賴上面Tidb、ES、圖數(shù)據(jù)庫的搜索能力。通用查詢主要設(shè)計了兩個核心接口，通用實體查詢和通用關(guān)系查詢，并逐步將上層應(yīng)用查詢使用進行收斂。

通用查詢接口的設(shè)計中，我們實現(xiàn)了兩個重要的功能降低使用成本，提高靈活度 1. 類SQL查詢 2. 關(guān)聯(lián)查詢

為了使用上的便捷性，我們定制了一個SQLParser的實現(xiàn)，適配SQL的WHERE條件邏輯中 AND、OR、LIKE、IN、=、!= 等算子和組合拼接，最后在內(nèi)部將其轉(zhuǎn)換為各個引擎定制的DSL發(fā)起查詢請求。

{ "page": 1, "size": 20, "where": "entity_type = 1 and sec_type = 3 and properties.tabName like '%r_ai.ods.recindexing.archive.test%'"}

由于實際場景中有大量的關(guān)聯(lián)查詢需求，而我們的數(shù)據(jù)存儲模型是類似于雪花模型的結(jié)構(gòu)，為了降低多次查詢的復(fù)雜性，我們用特殊的字段設(shè)計和查詢語法支持了一次查詢時的額外多層關(guān)聯(lián)查詢。

{ "page": 1, "size": 500, "where": "entity_type = 7", "extraProperties": { "t1": "*:$.pgUrn.text_pageName", "t2": "7:$.pgUrn.text_userName", "t3": "7:$.pgUrn", "t4": "*:$.pgUrn.bizCtime", "t5": "*:$.dsUrn.sql", "t6": "guanyuanCard:$.dsUrn.datasetStatus" }}

目前，通用元數(shù)據(jù)查詢已經(jīng)全面應(yīng)用在數(shù)據(jù)地圖、影響分析、指標(biāo)取數(shù)服務(wù)等業(yè)務(wù)應(yīng)用場景上面，存量的定制查詢也在逐步遷移。

血緣建設(shè)

數(shù)據(jù)血緣是元數(shù)據(jù)基建中非常比較重點的方向，甚至可以說，元數(shù)據(jù)建設(shè)的收益中，30%~50%是血緣建設(shè)。描述好數(shù)據(jù)的來龍去脈，能充分解釋一份數(shù)據(jù)從哪里來到哪里去，是后續(xù)開展數(shù)據(jù)運維、數(shù)據(jù)治理工作的關(guān)鍵。

我們將血緣建設(shè)主要分成三個主攻方向：提升覆蓋、細(xì)化粒度、保障準(zhǔn)確性。其中第三點保障準(zhǔn)確性目前相對較難，我們也還處于探索階段，所以重點圍繞前兩個方向來講。

1. 提升覆蓋

提升元數(shù)據(jù)的覆蓋需要兩個前提，一是數(shù)據(jù)生產(chǎn)或使用的鏈路收斂、系統(tǒng)數(shù)據(jù)可采集；二是參與數(shù)據(jù)生產(chǎn)使用的系統(tǒng)，需要有統(tǒng)一的數(shù)據(jù)定義。

鏈路收斂意味著分母數(shù)量確定，提升覆蓋不會變成一個無法預(yù)期、無限投入的工作。比如在B站內(nèi)部，參與數(shù)據(jù)生產(chǎn)的系統(tǒng)，統(tǒng)一到了平臺調(diào)度平臺、流計算平臺、數(shù)據(jù)集成平臺、埋點平臺幾個有限系統(tǒng)中，我們根據(jù)這些系統(tǒng)中的要素去定制血緣解析和采集策略，將數(shù)據(jù)進行打通，即可覆蓋離線、實時、出入倉等關(guān)鍵步驟的血緣，但往往還會存在一些由業(yè)務(wù)定制的野生調(diào)度系統(tǒng)，野生運行腳本等跑數(shù)情況，這些場景一般伴隨著缺少歸屬人，生產(chǎn)模式雜亂，缺失生命周期等問題，正常不應(yīng)該納入到血緣鏈路中，最好盡快的收口治理掉。

統(tǒng)一的數(shù)據(jù)定義，可以參考上面統(tǒng)一資源表達式URN，需要推動各個系統(tǒng)達成共識。尤其對于涉及出入倉的系統(tǒng)，對數(shù)據(jù)源的統(tǒng)一管理，全面接入是對出入倉數(shù)據(jù)統(tǒng)一定義的關(guān)鍵點。

目前我們在血緣的覆蓋度建設(shè)上面比較完善，目前已經(jīng)較為完整的覆蓋了離線鏈路、實時鏈路、出入倉表、數(shù)據(jù)報表等等。

2. 細(xì)化粒度

血緣的粒度由大至小分別是表級 → 字段級 (分區(qū)級) → 行級，血緣粒度越小，進行數(shù)據(jù)鏈路上下游定位的精度越高，但采集解析存儲的難度越大。

表級血緣是非常基礎(chǔ)的能力，一般使用類似Antlr等開源的SQL解析器進行ETLSQL靜態(tài)解析，結(jié)果也比較精準(zhǔn)。一般的離線調(diào)度、實時計算平臺都會自建這類scan能力，難點是對于非SQL的ETL任務(wù)，比如MRJar、SparkJar類型的任務(wù)，解析原生代碼的難度很大而且結(jié)果很大概率會不準(zhǔn)，一般會盡量收斂在重要的鏈路使用，或者擴充功能，由用戶手動維護這類任務(wù)的輸入輸出表。對于出入倉的表血緣，一般則是功能化選擇入倉表、出倉表，可以直接獲得血緣。

字段級血緣隨著平臺建設(shè)的深入和治理工作的開展，越來越趨于重要，因為從表粒度定位上下游的精度太粗，比如在字段變更影響分析時，通過表血緣會篩出很多實際無依賴表，需要再耗費很多人力去看代碼篩選。實現(xiàn)字段級血緣，有三種可選方案：a. 事前+靜態(tài) b. 事前+動態(tài) c. 事后+動態(tài)。

事前+靜態(tài)同解析表級血緣的思路一樣，但是解析的準(zhǔn)確性很差，處理不了類似于select *等不明確寫明字段的情況。事前+動態(tài)是在任務(wù)注冊時，通過調(diào)用Hive引擎的動態(tài)解析能力，產(chǎn)出LineageLog日志，用于字段級血緣解析，這種方法是可行的，優(yōu)點是獲取血緣的時效性比較高，缺點是需要感知生產(chǎn)任務(wù)的注冊變更主動發(fā)起解析，如果生產(chǎn)系統(tǒng)不夠收斂，實現(xiàn)的成本較大。事后+動態(tài)是在任務(wù)實際執(zhí)行時，經(jīng)過Hive引擎的動態(tài)解析過程后，自動拋出LineageLog，進行字段級血緣解析，這種方案也是可行的，優(yōu)缺點和事前+動態(tài)相反，時效性較低，但是只需要被動采集日志，不用感知任務(wù)變化。我們采用的是方案3，當(dāng)然，在實際情況中，我們還需要面臨Hive之外的引擎適配，比如Spark、Presto執(zhí)行，但思路相類似，都需要引擎?zhèn)鹊闹С帧?br />
行級血緣只在非常特殊的場景存在需求，比如埋點鏈路追蹤，可以通過其他定制化手段加以解決，統(tǒng)一的行級血緣暫時無法實現(xiàn)。

目前我們的血緣粒度支持到字段級，但是字段級還存在不少的限制，比如某些系統(tǒng)生產(chǎn)的數(shù)據(jù)不支持字段級，報表血緣不支持字段級等等，此外，一直缺乏對字段級血緣的準(zhǔn)確性評估的有效手段，目前只能借助于類似于影響分析、字段屬性繼承等業(yè)務(wù)場景的用戶反饋。

現(xiàn)狀總結(jié)&當(dāng)前規(guī)模

元數(shù)據(jù)應(yīng)用-數(shù)據(jù)地圖

找數(shù)

找數(shù)是數(shù)據(jù)運營中的關(guān)鍵環(huán)節(jié)，也是數(shù)據(jù)地圖要解決的核心問題。我們將地圖模塊分為基礎(chǔ)搜索、分類查詢、熱度推薦三部分。

基礎(chǔ)搜索重點解決用戶主動找數(shù)的場景，其中涉及數(shù)據(jù)模型的搜索召回策略、排序策略。我們將表名、描述信息、責(zé)任人、字段、標(biāo)簽等字段作為模型召回字段，通過關(guān)鍵詞匹配度、模型熱度、模型質(zhì)量、模型推薦標(biāo) 以及適當(dāng)?shù)臋?quán)重分配，進行排序控制，最終展現(xiàn)用戶需要的搜索結(jié)果。

分類查詢、熱度推薦重點解決用戶被動找數(shù)的場景，首先需要對業(yè)務(wù)域、數(shù)據(jù)域和數(shù)據(jù)過程進行合理劃分，構(gòu)建完善可讀的數(shù)據(jù)目錄，用戶通過對目錄信息的瀏覽，可以定位到具體業(yè)務(wù)表。熱度推薦則是通過模型使用熱度，按照部門劃分進行排序，推薦出同部門用戶高頻使用、近期新增的表。

除了Hive表之外，數(shù)據(jù)地圖還提供了實時Topic、clickhouse表、Bi報表的搜索查詢，目前地圖搜索日查詢PV 4000+。

理解數(shù)

為了用戶找數(shù)后，理解模型數(shù)據(jù)的內(nèi)容，極大豐富了表詳情頁的功能，重點圍繞構(gòu)建表的模型畫像、數(shù)據(jù)畫像，這里面非常依賴元數(shù)據(jù)的基建能力進行采集和質(zhì)量校驗。

模型畫像，我們從以下幾個方面對表的信息進行了刻畫：

數(shù)據(jù)畫像，目前支持的功能主要是樣例數(shù)據(jù)和數(shù)據(jù)探查，用以展示表數(shù)據(jù)的內(nèi)容，并具備一些基礎(chǔ)統(tǒng)計分析能力。

元數(shù)據(jù)應(yīng)用-血緣地圖

血緣地圖需要滿足用戶探索數(shù)據(jù)血緣的需求，是血緣元數(shù)據(jù)最直接的產(chǎn)品化呈現(xiàn)，在產(chǎn)品設(shè)計實現(xiàn)的過程中，我們遇到了非常多的問題，也走了一些彎路，才探索出一套可用的形態(tài)。目前最終呈現(xiàn)的數(shù)據(jù)地圖，支持動態(tài)配置不同類型數(shù)據(jù)的展示信息，支持點的動態(tài)條件過濾、高亮。

目前血緣地圖中涉及的主要實體類型12種，關(guān)系構(gòu)建實體類型4種，日均使用PV 500+。

元數(shù)據(jù)應(yīng)用-影響分析

影響分析主要使用場景有兩個：

所以在這個產(chǎn)品定位下，影響分析的核心能力就是支持血緣深層遍歷，數(shù)據(jù)匯總統(tǒng)計，我們在此功能上首次支持了字段血緣。在這個場景中，我們依然要面對數(shù)據(jù)類型多的問題，初此之外，還要面對深層遍歷時長耗時的交互處理，超大數(shù)據(jù)量(過百層，百萬級實體)結(jié)果處理，已經(jīng)超大數(shù)據(jù)對服務(wù)資源占用的影響。針對這幾種情況，我們的處理方式是：

未來規(guī)劃

欧美深夜视频_国产精品99视频_国产精品网站一区_亚洲最大av网

B站大數(shù)據(jù)平臺元數(shù)據(jù)業(yè)務(wù)分享