B 站標簽系統落地實踐

作者：袁敏 2024-02-28 07:50:36

大數據

本次分享題目為標簽系統在 B 站的落地實踐。B 站標簽系統建立于 2021 年初。當時立項的背景為，業務側人均取數的需求越來越多，希望能夠加速數據取用的效率，標簽系統內部立項建設啟動。

一、演進歷程

首先簡要介紹一下 B 站標簽系統的演進歷程。

1. 2021 年標簽系統立項

B 站標簽系統建立于 2021 年初。當時立項的背景為，業務側人均取數的需求越來越多，希望能夠加速數據取用的效率，標簽系統內部立項建設啟動。

在最初的版本中形成了基礎的標簽圈群的能力，以開放 API 的方式對外提供服務，基本上能夠滿足當時的業務需求。

隨著越來越多的標簽接入需求，以及業務側越來越高的人群圈選頻率，系統逐步面臨各種問題：

所有明細數據進入 ClickHouse，通過物化視圖的方式做 BitMap 計算，通過分頁查詢的方式做人群數據的導出；另外，以 API 的方式對外提供服務，前端用戶可能自定義輸入非常復雜的 SQL，以上操作都會大量消耗ClickHouse 計算資源，導致其單引擎部署的計算負載面臨的穩定性壓力越來越大，集群擴展性不佳。
隨著對接的業務方定制化需求越來越多，導致 API 存在多套體系，整體維護成本較高，也很難持續迭代優化。
為了提升業務圈選響應速度，只要有用戶圈選需求進入，系統會立即提交ClickHouse 計算任務，缺乏任務并發度的管控。

2. 2022 年系統重構升級

針對 2021 系統上線后面臨的問題進行點狀優化，并通過平臺化的方式對接更多業務場景。

穩定性方面：引入多存算引擎的支持，在人群計算上支持任務隊列的調度，并重新定義了圈選 DSL。
場景拓展方面：實現了實時判定能力，對接 C 端業務服務。

3. 2023 年系統化建設賦能業務

更加系統化地建設標簽系統，在業務側更好地打通數據平臺和業務應用：

上下游收斂縮短數據鏈路
標簽人群治理與數據質量保障
人群效果回收與標簽體系完善

二、系統架構與實踐

1. 標簽系統整體架構

系統整體架構從下到上可以分為三個層級：依次為標簽生產、人群圈選和人群應用。

數據來源：依托于大數據平臺，各種業務數據例如 DB 數據、埋點行為數據、AB 實驗分流用戶數據等均可接入標簽平臺，通過 Spark 、Trino 以及Clickhouse 計算引擎實現上層標簽生產及人群圈選。
標簽生產：支持數據源表接入、標簽元信息管理、標簽構建、標簽治理。
人群圈選：支持人群元信息管理、人群規則圈選、人群計算調度、生命周期管理。
人群應用：支持數據批量下載、在線實時判定、畫像分析。
業務應用：包括推送平臺、活動和任務平臺、用戶洞察、用戶增長等。

2. 數據流轉鏈路

數據流轉鏈路是整個標簽系統整體架構的核心，標簽系統的主要作用是把各種類型的原始數據快速生產成人群，最終對接業務側各種場景的使用。

業務數據，包括 DB 數據，以及日志和埋點上報等數據。

一方面，業務數據通過大數據的數據集成能力入倉得到 Hive 表和 Iceberg 表，再通過標簽構建，出倉進入到 ClickHouse。這是離線的鏈路。

另一方面，移動端的埋點數據也是依托大數據的能力，會直接進入到ClickHouse。

整體上，標簽數據進入 ClickHouse 之后，就可以進行人群圈選。根據業務側應用場景，將標簽和人群數據分發到不同的存儲。批量推送數據需從ClickHouse 推送至 B 站自研分布式對象存儲系統 BOSS 后提供 API 接口訪問；實時判定點查數據是從 ClickHouse 推送至 Redis 后提供 API 接口訪問；北極星行為分群數據直接從 ClickHouse 提供畫像分析能力。

接下來詳細介紹一下標簽生產、人群圈選和在線服務三部分。

3. 標簽生產

在講解標簽構建之前，先來介紹一下 B 站當前的標簽體系情況。

整體目標為讓業務能夠快速靈活地接入標簽。

建設思路：對于事實屬性類標簽，例如性別、年齡、城市等人口屬性、位置屬性標簽，由平臺自建，作為公共標簽對外提供；對于統計類、規則類或模型類標簽，即業務強相關的標簽，與業務部門合作建設。
組織結構分為三級：一級，標簽類目；二級，具體標簽；三級，標簽枚舉。
標簽分類標準：根據后續圈選操作不同分為離散與連續類型。離散標簽：枚舉型，如性別；連續標簽：數值型，如播放時長。
標簽權限管理：基于業務域去做歸屬和隔離，用戶只能使用具有授權的標簽。
標簽接入流程：為滿足業務取數便捷性要求，支持用戶平臺化自助錄入數據源，完成標簽和字段綁定、觸發審批流程。評估和審批分三個環節，各環節負責人分別是業務域負責人（關注標簽體系是否完整、合理）、業務域數倉負責人（關注標簽數據源表及上游模型是否規范）、標簽服務負責人（DQC 規則配置）。
業務域：包括基礎域、B 端創作者、大會員、直播、游戲、漫畫等。

離線標簽構建：

引入 Iceberg 支持多存算引擎的實時查詢性能優勢，解決集群負載問題；支持多計算引擎接入，解決集群擴展性差問題。
通過自定義分 shard 模式讀寫，避免使用 ClickHouse 分布式表聚合計算影響性能。

標簽構建流程為，所需數據源元信息從 Hive 表接入 Iceberg，連續型標簽不再出倉，直接基于 Iceberg 對接實時查詢，離散型標簽再通過 Spark 計算出倉至 ClickHouse。標簽數據主要包括標簽 BitMap、分區 logdata 和 version。

整個構建流程通過標簽系統進行管理，同時在標簽系統中還有對元信息的管理。

再來介紹一下自定義分 shard 的過程。Hive 表和 Iceberg 表數據進入到標簽構建，根據用戶 id 和 Spark 任務數 hash，得到 n*m 份數據，其中 n 為 ClickHouse 的 shard 數，m 是根據數據量級定義的并發數。之后根據 task id 和 shard 數再次 hash，確定每份 BigMap 數據寫到哪里。這樣做一方面可以保證構建的速度，另一方面也可以保證一個 id 落到一個 shard 上，后續所有計算、讀寫都僅用 local 表即可，從而減少表的聚合計算。

標簽生產另外一個重要來源是埋點數據。北極星作為 B 站的埋點分析管理平臺，負責管理除以上 DB 數據之外的埋點行為數據，用戶可以根據選擇特定埋點行為條件去圈選出具有某一行為特征的人群，以標簽的形式同步到標簽系統。

整體流程為，選擇埋點行為條件，北極星平臺將其翻譯為 ClickHouse SQL，對表查詢得到 BitMap，再分 shard 寫入標簽表。整個流程已在系統層面打通，以提升效率。

4. 人群圈選

標簽平臺支持通過以下 5 種方式創建人群：基于規則和行為的標簽圈群、本地文件 csv 導入用戶 id、從 Hive 表接入、大數據平臺查詢獲取的 http 鏈接、同步 DMP 人群包；

人群使用場景包括：批量導出、人群判定、畫像分析。批量導出場景下打開人群導出，數據存儲至 BOSS 后提供文件下載鏈接；實時判定等在線服務場景下，打開數據寫入線上集群，寫入至 Redis 后業務側通過 API 進行實時點查；畫像分析則兩者都無需開啟。

人群創建的方式決定了人群數據的來源，人群應用的方式則決定了人群數據的存儲；

人群更新方式包括：非例行和例行。非例行表示立即執行計算，例行則會根據圈群規則獲取上游依賴的標簽、人群當日是否更新，等待依賴更新后提交計算。

人群規則確定后，相應請求的 DSL 發送服務端，針對 DSL 配置做 DAG 任務拆解，任務分配到相應隊列后處理運算。

規則圈選 DSL 支持的操作運算符如上圖所示。

多層級可擴展的 DSL 結構，目前是采用三層結構，在業務實踐中幾乎可以滿足所有場景需求。根據DSL 描述翻譯成 Iceberg/ClickHouse 各自節點對應的SQL。

另外，也會進行一些優化。例如 Iceberg 查詢優化，假設 A1、A2 均為連續標簽，它們來自同一張 Iceberg 表，那么就把這兩個標簽在模型表的層面做合并計算，最終只會生成一個 Iceberg 任務。

5. 在線服務

在線服務滿足 SLA 標準：

在安全性上支持高并發、高可用，各業務獨立限流；在擴展性上支持無狀態計算，各業務存儲隔離；在滿足安全性和水平擴展性的基礎上，做到服務全生命周期功能覆蓋，包括人群生成灌庫、黑白名單、流量控制、版本切換、人群下線等。

在較大數據量下人群數據通過 Spark 寫入 Redis。根據人群元信息將數據寫入不同 Redis 集群，進行存儲隔離。當前在 Redis 層面采用了 KKV 的存儲結構。版本控制方面，保留 5 個數據版本，版本更新邏輯為，當前人群 id 版本和當前版本做邏輯與，再去拼接下一個版本。

因為對接 C 端業務，所以要求比較嚴謹，人群灰度包括流量控制、人群替換和快速回滾。流量控制的場景為，比如一個新功能對某個人群開放，而人群策略不確定是否合理，這時就需要灰度放流，在此過程中觀察用戶反饋。人群替換的場景為，比如人群策略變更，但對接服務中人群id 不方便修改，這時就可以另外要一個人群來進行替換。數據構建是偏離線的，有一定時間差，如果數據出現問題可以快速回滾到上一個版本。

這三個功能都是基于分流表實現的。