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

背景介紹

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

隨著數(shù)據(jù)平臺(tái)業(yè)務(wù)規(guī)模的增長(zhǎng)，平臺(tái)會(huì)沉淀大量的數(shù)據(jù)表，調(diào)度任務(wù)等元數(shù)據(jù)。由于前期快速的業(yè)務(wù)發(fā)展產(chǎn)生大量數(shù)據(jù)管理成本，存儲(chǔ)計(jì)算成本。此時(shí)會(huì)逐步產(chǎn)生諸如模型規(guī)范治理、模型變更影響，指標(biāo)異動(dòng)定位，重復(fù)建設(shè)治理等需求場(chǎng)景。基于這些場(chǎng)景需求，此時(shí)數(shù)據(jù)平臺(tái)僅提供數(shù)據(jù)開(kāi)發(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ù)相互耦合，邊界不清楚，無(wú)法以全局視角觀察分析平臺(tái)數(shù)據(jù)資產(chǎn)，無(wú)法串聯(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ù)平臺(tái)元數(shù)據(jù)建設(shè)之初，由于對(duì)元數(shù)據(jù)的業(yè)務(wù)理解不夠深入，人力投入有限，實(shí)現(xiàn)方案采用的是針對(duì)特定需求深度定制化。比如需要某類Hive表的字段信息，那么就針對(duì)這個(gè)場(chǎng)景，設(shè)計(jì)一批hive表與字段的元數(shù)據(jù)表，通過(guò)直連HMS拉全量數(shù)據(jù)，定制業(yè)務(wù)邏輯消費(fèi)HMS的Binlog進(jìn)行變更同步，再通過(guò)暴露一批查詢表字段的HTTP接口，提供給需求方進(jìn)行查詢。

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

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

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

系統(tǒng)總覽

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

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

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

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

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

每個(gè)域之間以「:」進(jìn)行分隔。

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

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

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

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

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

實(shí)體關(guān)系模型

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

實(shí)體的Aspcet

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

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

關(guān)系的BuilderURN

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

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

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

采集方式選型

對(duì)采集方式的選擇，一般會(huì)比較幾種方案：

1. 批拉取

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

2. 批上報(bào)

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

3. 埋點(diǎn)上報(bào)

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

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

業(yè)務(wù)邏輯誰(shuí)來(lái)維護(hù)

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

采集質(zhì)量保障

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

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

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

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

ES - 查詢搜索DB，數(shù)據(jù)從TIDB的實(shí)體表同步，提供元數(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ù)查詢的場(chǎng)景中，有非常多的定制需求，不僅要滿足上層應(yīng)用對(duì)元數(shù)據(jù)的查詢，也要滿足來(lái)自用戶和數(shù)據(jù)治理層面的突發(fā)需求。所以在元數(shù)據(jù)查詢能力建設(shè)上，既需要具備通用性，支持各種靈活的查詢情況場(chǎng)景，又需要具備可復(fù)用性，避免重復(fù)建設(shè)導(dǎo)致維護(hù)成本的上升。

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

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

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

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

由于實(shí)際場(chǎng)景中有大量的關(guān)聯(lián)查詢需求，而我們的數(shù)據(jù)存儲(chǔ)模型是類似于雪花模型的結(jié)構(gòu)，為了降低多次查詢的復(fù)雜性，我們用特殊的字段設(shè)計(jì)和查詢語(yǔ)法支持了一次查詢時(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)用場(chǎng)景上面，存量的定制查詢也在逐步遷移。

血緣建設(shè)

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

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

1. 提升覆蓋

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

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

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

目前我們?cè)谘壍母采w度建設(shè)上面比較完善，目前已經(jīng)較為完整的覆蓋了離線鏈路、實(shí)時(shí)鏈路、出入倉(cāng)表、數(shù)據(jù)報(bào)表等等。

2. 細(xì)化粒度

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

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

字段級(jí)血緣隨著平臺(tái)建設(shè)的深入和治理工作的開(kāi)展，越來(lái)越趨于重要，因?yàn)閺谋砹６榷ㄎ簧舷掠蔚木忍郑热缭谧侄巫兏绊懛治鰰r(shí)，通過(guò)表血緣會(huì)篩出很多實(shí)際無(wú)依賴表，需要再耗費(fèi)很多人力去看代碼篩選。實(shí)現(xiàn)字段級(jí)血緣，有三種可選方案：a. 事前+靜態(tài) b. 事前+動(dòng)態(tài) c. 事后+動(dòng)態(tài)。

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

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

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

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

找數(shù)

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

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

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

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

理解數(shù)

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

模型畫(huà)像，我們從以下幾個(gè)方面對(duì)表的信息進(jìn)行了刻畫(huà)：

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

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

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

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

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

影響分析主要使用場(chǎng)景有兩個(gè)：

所以在這個(gè)產(chǎn)品定位下，影響分析的核心能力就是支持血緣深層遍歷，數(shù)據(jù)匯總統(tǒng)計(jì)，我們?cè)诖斯δ苌鲜状沃С至俗侄窝墶Ｔ谶@個(gè)場(chǎng)景中，我們依然要面對(duì)數(shù)據(jù)類型多的問(wèn)題，初此之外，還要面對(duì)深層遍歷時(shí)長(zhǎng)耗時(shí)的交互處理，超大數(shù)據(jù)量(過(guò)百層，百萬(wàn)級(jí)實(shí)體)結(jié)果處理，已經(jīng)超大數(shù)據(jù)對(duì)服務(wù)資源占用的影響。針對(duì)這幾種情況，我們的處理方式是：

未來(lái)規(guī)劃

欧美日韩午夜_五月天激情综合_国产精品久久久久一区二区三区_色女人av_国产福利av_欧美日韩中

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