B站大數據平臺元數據業務分享

背景介紹

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

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

由于先前元數據的散落，導致系統間數據相互耦合，邊界不清楚，無法以全局視角觀察分析平臺數據資產，無法串聯數據之間的生產加工關系。于是建設起完善可靠的元數據服務成為后續滿足數據發現，數據治理業務的關鍵。

元數據基建

背景&目標

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

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

在這種狀態下，也出現了一些必然結果，由于無法快速支持業務需求，需求方通常會自建離線元數據來跑通業務，產生了重復建設和后期治理的問題。由于開發維護成本高，支持元數據業務的同學疲于應對各種需求，壓力大，還要兼顧各類線上的元數據質量問題排查運維。

所以，體系化建設元數據的目標之一就是統一元數據。即以統一的元數據模型，統一的采集方式，統一的存儲方式，統一的查詢方式支撐上層元數據業務需求。

系統總覽

統一元數據-模型

元數據模型需要滿足3點要求：

我們在這部分借鑒了業界的一些通用方案，以標識協議URN+實體+關系進行了統一元數據模型的構建。

統一標識協議URN

URN = 協議域 + 業務域 + 資源類型 + 唯一資源ID

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

其中協議域全局固定為urn；對于數據平臺內部的資源業務域統一為datacenter；資產類型為協商約定，由此文檔統一管理；唯一資源ID則由各個資產的定義方自行約定。

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

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

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

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

實體關系模型

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

實體的Aspcet

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

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

關系的BuilderURN

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

統一元數據-采集

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

采集方式選型

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

1. 批拉取

采集側進行調度觸發拉取，業務側支持按業務偏移量進行增量查詢。優點：采集配置可控，易監控和運維。缺點：業務側需要配合進行定制取數邏輯開發，對業務數據的存儲更新方式有一定要求。

2. 批上報

業務側自行調度，按業務偏移量增量查詢后自主上報，采集側被動做消費。優點：整體采集邏輯簡單，開發成本低。缺點：無法控制采集配置（頻率、間隔），采集問題難監控、難定位，難運維。

3. 埋點上報

業務側將上報埋點到數據變更流程中。優點：實時性強，對業務數據的存儲更新方式無特定要求。缺點：采集問題難監控、難定位，幾乎無法運維。

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

業務邏輯誰來維護

為了解藕業務，降低元數據去理解業務含義，維護業務變更等等成本，我們約定統一由數據源頭業務負責維護數據模型到統一元數據模型的轉換邏輯，也就是說，無論是自助上報，還是接口拉取，我們都會以統一的元數據模型來進行數據交換，避免產生業務邏輯處理各類異構數據。

采集質量保障

采集質量保障是非常重要的一環，直接關系到后續元數據上層業務能否有效開展。在采集質量方面，我們踩過很多坑，比如業務側硬刪數據、業務側數據事務落庫問題、業務側上報bug、消息中間件不穩定等導致最終數據不一致，且缺少有效的數據監控，定位處理成本非常的高。

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

統一元數據-存儲

TIDB - 元數據DB，承載采集到的實體關系數據，作為元數據業務的中心存儲。

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

HugeGraph - 關系搜索DB，數據從TIDB的關系表同步，提供圖結構下的深度遍歷，路徑選擇，成環處理等能力。

統一元數據-查詢

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

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

通用查詢接口的設計中，我們實現了兩個重要的功能降低使用成本，提高靈活度 1. 類SQL查詢 2. 關聯查詢

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

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

由于實際場景中有大量的關聯查詢需求，而我們的數據存儲模型是類似于雪花模型的結構，為了降低多次查詢的復雜性，我們用特殊的字段設計和查詢語法支持了一次查詢時的額外多層關聯查詢。

{ "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" }}

目前，通用元數據查詢已經全面應用在數據地圖、影響分析、指標取數服務等業務應用場景上面，存量的定制查詢也在逐步遷移。

血緣建設

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

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

1. 提升覆蓋

提升元數據的覆蓋需要兩個前提，一是數據生產或使用的鏈路收斂、系統數據可采集；二是參與數據生產使用的系統，需要有統一的數據定義。

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

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

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

2. 細化粒度

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

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

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

事前+靜態同解析表級血緣的思路一樣，但是解析的準確性很差，處理不了類似于select *等不明確寫明字段的情況。事前+動態是在任務注冊時，通過調用Hive引擎的動態解析能力，產出LineageLog日志，用于字段級血緣解析，這種方法是可行的，優點是獲取血緣的時效性比較高，缺點是需要感知生產任務的注冊變更主動發起解析，如果生產系統不夠收斂，實現的成本較大。事后+動態是在任務實際執行時，經過Hive引擎的動態解析過程后，自動拋出LineageLog，進行字段級血緣解析，這種方案也是可行的，優缺點和事前+動態相反，時效性較低，但是只需要被動采集日志，不用感知任務變化。我們采用的是方案3，當然，在實際情況中，我們還需要面臨Hive之外的引擎適配，比如Spark、Presto執行，但思路相類似，都需要引擎側的支持。

行級血緣只在非常特殊的場景存在需求，比如埋點鏈路追蹤，可以通過其他定制化手段加以解決，統一的行級血緣暫時無法實現。

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

現狀總結&當前規模

元數據應用-數據地圖

找數

找數是數據運營中的關鍵環節，也是數據地圖要解決的核心問題。我們將地圖模塊分為基礎搜索、分類查詢、熱度推薦三部分。

基礎搜索重點解決用戶主動找數的場景，其中涉及數據模型的搜索召回策略、排序策略。我們將表名、描述信息、責任人、字段、標簽等字段作為模型召回字段，通過關鍵詞匹配度、模型熱度、模型質量、模型推薦標以及適當的權重分配，進行排序控制，最終展現用戶需要的搜索結果。

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

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

理解數

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

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

數據畫像，目前支持的功能主要是樣例數據和數據探查，用以展示表數據的內容，并具備一些基礎統計分析能力。

元數據應用-血緣地圖

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

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

元數據應用-影響分析

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

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

未來規劃

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

B站大數據平臺元數據業務分享