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

本期作者

圖片

沈汪洋

嗶哩嗶哩資深開發工程師 

負責 B 站數據平臺工具側元數據、數據運營、數據管理等業務方向，專注於元數據採集、血緣應用、數據地圖、建模工具、治理工具等工具或產品功能的落地和推廣。

背景介紹

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

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

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

元數據基建

背景 & 目標

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

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

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

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

系統總覽

圖片

統一元數據 - 模型

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

  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. 方便生命週期管理：當任務被下線時，我們可以快速查詢到由該任務構建的關係，級聯進行刪除操作。

統一元數據 - 採集

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

採集方式選型

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

  1. 批拉取

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

  1. 批上報

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

  1. 埋點上報

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

這裏我們選型是 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 執行，但思路相類似，都需要引擎側的支持。

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

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

現狀總結 & 當前規模

  1. 目前元數據基建已經建設成熟，擁有基於統一模型的元數據採集、存儲、查詢、監控、運維的一站式能力。目前建立 10 + 元數據採集上報方，接入實體類型 16 種，關係類型 10 種，其中 Hive 正式表數量 6W+，各類任務數量 11W+。

  2. 表級血緣覆蓋從數據入倉到出倉全鏈路，打通離線表與實時表血緣，表級血緣覆蓋平臺正規調度任務產出的所有表字段。

  3. 元數據通用查詢每日支撐各類業務查詢 PV2.5W 次，支撐上層 數據地圖、影響分析、血緣地圖、取數服務、基線分析 等重要平臺應用。

元數據應用 - 數據地圖

找數

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

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

圖片

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

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

圖片

理解數

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

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

圖片

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

圖片

元數據應用 - 血緣地圖

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

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

圖片

元數據應用 - 影響分析

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

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

圖片

圖片

未來規劃

  1. 元數據質量保障，目前已經落地一套保障機制，但目前接入保障的場景還比較少，需要長期推廣和推動存量上報遷移，形成質量評估的體系。

  2. 元數據字典，隨着越來越多元數據類型的接入，沉澱了各類元數據的業務屬性，要形成基於通用查詢的完全自助查詢，需要通過建立元數據字典，解決元數據模型和字段業務含義的理解問題。

  3. 數據運營體系，隨着功能的拓展，平臺功能已經覆蓋到用戶方方面面的需求。但平臺建設，除了建工具之外，還有需要建流程，建機制。目前在找數用數場景中，最核心的痛點就是模型質量不高，模型分類不準不全，下游使用存在數據口徑問題，數據質量問題、數據使用問題。我們需要建立數據運營機制，從數據供給側建立成本指標和產出指標，數據消費側打通數據使用鏈路血緣，建立收益指標，利用地圖的能力保障數據生產消費兩端的信息暢通。

  4. 數據治理，在數據平臺的建設中，由於各種歷史原因，普遍存在大量重複建設，不規範的行爲動作，導致數據成本，人力成本的多餘消耗。隨着降本增效成爲業務重心，我們需要從工具層面開展數據治理建設，利用已經完善的元數據基建能力，規模化治理流程，擴大治理範圍，提升治理效率。

嗶哩嗶哩技術 提供 B 站相關技術的介紹和講解

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/yC-TowHcw2zboXb_QgqEGQ

猜你喜歡