B站大資料平臺元資料業務分享

本期作者

背景介紹

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

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

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

元資料基建

背景&目標

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

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

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

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

系統總覽

統一元資料-模型

統一標識協議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

統一元資料-採集

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

採集方式選型

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

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

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

血緣建設

現狀總結&當前規模

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

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

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

元資料應用-資料地圖

找數

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

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

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

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

理解數

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

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

• 基礎元資料（表名、欄位、分割槽、路徑、格式等）

• 業務元資料（歸屬資訊、安全等級、業務線、模型資訊、生命週期等）

• 生產元資料（產出任務、基線）4. 質量元資料（DQC任務）

• 衍生元資料（使用說明、自定義標籤、評分）

• 血緣元資訊（表血緣）

• 變更元資訊（變更記錄）

• 成本元資訊（表儲存佔用，分割槽儲存佔用，冷存週期，壓縮格式）

• 使用元資訊（使用熱度）

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

元資料應用-血緣地圖

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

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

元資料應用-影響分析

未來規劃

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

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

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

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