基於實時流的廣告特徵平臺的建設與實踐
本期作者
李淵馳
嗶哩嗶哩資深開發工程師
背景介紹
作爲一個擁有龐大年輕用戶羣體和多元化內容資源的視頻平臺，B 站爲廣告主提供了豐富的投放場景。爲了實現更精準的廣告投放，B 站商業化技術團隊深入挖掘用戶、物料、場景等多方面的數據特徵，並構建精細化的目標受衆畫像。這些數據在經過特徵計算後會成爲模型訓練所需的訓練樣本，通過模型訓練得到能夠對廣告創意進行點擊率、轉化率預估的深度模型。當用戶進行訪問時，作爲廣告檢索引擎的一部分，在線 CTR 預估服務會使用深度模型，對候選集內的廣告創意逐個進行點擊率、轉化率預估，這些數值會在精選階段用來挑選出價值最高的廣告創意返回給用戶。模型預估的準確性直接決定了廣告檢索引擎的效果，爲了確保模型訓練和模型推理階段所使用的樣本數據的一致性，提供一個全面、穩定、高效的廣告特徵平臺顯得尤爲重要。
遇到的問題
模型訓練
模型訓練分爲離線訓練和實時訓練兩部分，在構建特徵平臺之前，特徵處理的主要流程如下圖所示。
離線訓練
離線訓練主要用於訓練以天爲單位的模型，通過處理前一天的日誌數據得到訓練樣本，分爲數據拼接、樣本生成、模型訓練三個階段：
- 數據拼接
將廣告引擎日誌和用戶行爲日誌進行拼接，寫入日誌消息隊列，進一步和離線 Hive 表和離線 Redis 庫中的預處理數據進行拼接，生成離線 Hive 表作爲離線視圖，最後將數據文件存儲至 HDFS。
- 樣本生成
使用 MapReduce 框架讀取並處理 HDFS 上的數據文件，使用 Python 腳本進行特徵計算，將生成的訓練樣本文件存儲至 HDFS。
- 模型訓練
模型訓練框架從 HDFS 讀取樣本文件，執行模型訓練任務。
實時訓練
實時訓練主要用於訓練以小時爲單位的模型，通過處理前一個小時的日誌數據得到訓練樣本，由於處理的數據量較小且時效性更高，實時訓練能夠得到更好的效果：
- 數據拼接
與離線訓練有所不同，實時訓練的過程中，在日誌消息與離線數據進行拼接後，將消息寫入新的消息隊列作爲實時視圖。
- 樣本生成
使用 Flink 流處理框架讀取消息隊列，使用 Java 實現的 UDF 來進行特徵計算，將生成的訓練樣本文件存儲至 HDFS。
- 模型訓練
模型訓練框架從 HDFS 讀取樣本文件，執行模型訓練任務。
模型推理
在線 CTR 預估服務，將使用深度模型對候選集中的廣告創意進行點擊率、轉化率預估，其中特徵處理的主要流程如下圖所示：
在線推理
在線服務部分，CTR 預估服務會將請求側數據和廣告側數據進行拼接，處理後生成推理樣本，與模型訓練類似，也分成數據拼接、樣本生成、模型推理三個階段：
- 數據拼接
廣告檢索引擎將請求側數據和從 BS 服務召回的廣告側數據發送至 CTR 預估服務，CTR 預估服務與在線詞表和在線 Redis 進行拼接。
- 樣本生成
CTR 預估服務使用 C++ 實現的特徵計算算子完成特徵處理，生成訓練樣本。
- 模型推理
CTR 預估服務使用深度模型對樣本進行推理，計算得到廣告創意的點擊率、轉化率預估值。
結合上述模型訓練和模型推理的執行流程，可以發現現有系統存在以下問題：
- 數據源分散
訓練時數據源來自於多個預處理結果，拼接成本較高。
- 數據不一致
訓練時數據和推理時數據的產出分別來自於兩組任務，任務間數據處理方式存在差異，產出版本也不統一。
- 計算不一致
在離線訓練、實時訓練、在線推理三個流程的特徵計算階段，分別需要使用 Python、Java、C++ 三種語言進行實現，代碼邏輯難以完全一致。
4) 排查問題成本較高
當需要排查模型訓練和模型推理的一致性問題時，離線無法獲取推理階段使用的完整特徵數據，難以快速準確定位問題。
架構設計
針對上述問題，我們希望能夠提供一個涵蓋模型訓練過程和模型推理過程的特徵平臺，確保模型訓練時和推理時樣本數據的一致性，從而提升模型預估的效果。同時考慮到模型訓練過程中，數據拼接階段的資源開銷，我們設計了一套基於在線服務側的實現方案，通過在線服務側上報特徵數據的方式，大幅簡化了模型訓練過程中的數據拼接工作。新的實現方案涵蓋了模型推理和模型訓練兩個部分，具體如圖所示：
模型推理
模型推理側的升級點主要是提供了競勝廣告的特徵數據上報能力，具體包括了：
- 獲取實時 Redis 數據上移至廣告檢索引擎
Redis 中主要存儲了實時的用戶側特徵數據，獲取數據的操作上移至廣告檢索引擎後，確保了發送至 CTR 預估服務和特徵上報服務的用戶側特徵是一致的
- 新增在線特徵上報服務
在線服務側新增了特徵上報服務，廣告檢索引擎在返回競勝的廣告創意前，會將該廣告側數據和請求側數據一起發送至特徵上報服務。該服務與 CTR 預估服務使用相同的代碼實現，並且加載了相同的在線詞表，在經過數據拼接階段後，會將拼接完成的信息作爲一條文本消息上報至消息隊列，其中包含了特徵計算階段所需的全部字段。
- 升級 C++ 特徵計算庫
通過進一步優化，將 CTR 預估服務中的特徵計算模塊升級成了特徵計算庫，主要進行了如下修改：
a. 新增序列化 / 反序列化功能，能夠對拼接後的用戶側和廣告側數據進行序列化 / 反序列化操作。
b. 移除 / 簡化第三方庫的依賴，儘可能降低 JNI 調用過程中的額外依賴。
模型訓練
模型訓練側的升級點主要是簡化了數據拼接，並且統一了模型訓練和推理的特徵計算實現，具體包括了：
- 簡化數據拼接
由於特徵上報日誌中已經包含了特徵計算的全部字段，因此新方案只需要拼接用戶行爲日誌和特徵上報日誌，將結果寫入消息隊列即可得到實時視圖，將結果寫入 Hive 表即可得到離線視圖。
- 統一離線訓練和實時訓練
在離線訓練的過程中，使用 Flink-Batch 的方式從離線視圖中獲取數據，後續操作與實時訓練相同，使用 UDF 生成訓練樣本，並將樣本數據寫至 HDFS。
- 使用 JNI 調用特徵計算庫
使用 JNI 技術實現了在 Flink 流處理框架中，通過 UDF 調用 C++ 特徵計算庫進行處理，統一了特徵計算的代碼實現。
實踐及收益
自特徵平臺上線以來，已有三個深度模型採用新方案進行訓練，在模型效果和訓練成本上均取得了顯著收益。
在模型效果方面，累計修復了 72% 的特徵一致性問題（其中 9% 的特徵嚴重不一致，diff 比例大於 10%），從而提高了模型預估的準確性。這使得效果廣告整體收入提升了 1.30%，同時在信息流、Story 和播放頁三個場景中，點擊率分別提升了 4.61%、1.36% 和 2.42%。
在訓練成本方面，大幅簡化了離線訓練和實時訓練過程中的數據拼接，降低了 Flink 硬件資源需求，使得模型訓練的 Flink 任務併發度下降了 79%。此外，通過對視圖模塊的重構，訓練任務流程變得更加清晰簡潔，進一步降低了模型迭代和問題排查的成本。
總結和展望
在商業技術部的工程團隊、數據團隊和算法團隊的緊密協作下，我們成功構建了一套實時流廣告特徵平臺。這一平臺克服了數據源分散、數據不一致、計算不一致以及排查問題成本較高等諸多挑戰。它爲離線訓練和實時訓練提供了一套統一的數據處理和特徵計算方案，簡化了數據拼接流程，提升了模型預估的準確性，並降低了訓練成本。
爲了持續優化廣告特徵平臺，各團隊將在未來的工作中加強溝通與協作，共同探討和研究平臺的優化方向。我們將致力於進一步提升模型性能，優化訓練和推理流程，併爲商業化業務的持續增長提供堅實的技術支持。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/SGBy9LqsUQnw0MDBPOnWFQ