技术博客|第13期:Server Side Logging:Hulu推荐系统中的特征漂移问题解决方法
在推薦系統中，有效刻畫用戶偏好的特征是提升模型效果的重要因素。特征采集的意義在于保證模型訓練和預測這兩個相對獨立的步驟中特征的一致性，防止特征漂移[1][2]現象損失模型的效果。本文提出了一套適用于Hulu推薦系統的特征采集系統，用于幫助算法工程師構造更好的訓練數據集，提高模型實際落地的效果。
在Hulu的推薦系統中，一種典型的推薦模型離線訓練在線預測的工作流如圖1所示：
圖1：Model Engineer Workflow in Hulu
上圖中下半部分是離線構造模型的工作流：內容在用戶界面上的展現、點擊、播放等事件會被記錄到數據倉庫中，經過上游團隊的數據處理工作得到用戶事實表，推薦團隊再從事實表中提取內容展現給用戶時的特征和標簽，構成訓練數據集。每日生成的數據集經過訓練得到模型快照。
上半部分是在線模型預測的工作流：在線推薦服務收到用戶的請求之后，先請求依賴的相關服務得到用戶行為等原始數據，再通過在線特征提取邏輯得到該用戶和一些內容在此時的特征，再經過一個模型推理模塊計算該用戶對每個內容的預測得分。
在上面的流程中，離線特征提取是為了還原在線推薦使用的用戶和內容特征。理論上，內容對用戶的同一次展現，在線預測和離線訓練使用的特征應該完全相等， 但實際上，模型離線訓練和在線預測在工程實踐中使用的特征存在不一致現象，即發生了訓練-預測之間的特征漂移。漂移現象出現的原因可以總結為以下三個方面：
??? 1. 數據源：離線特征的數據源是數倉中的用戶事實表，在線特征的數據源是其他在線服務。
例如用戶在一年內保存和刪除的電視連續劇列表特征，由于數據源的差異(在線數據源是其他團隊基于播放器上報的心跳事件的行為服務, 離線數據源是另外一個團隊基于客戶端埋點的行為明細表)， 離線數據源中的連續劇列表比同一個用戶通過在線服務得到的連續劇少。實際系統中這個特征離線在線提取出的兩個列表的Jaccard距離[3]為0.28 。
??? 2. 執行時間：離線和在線執行時間不同，不能保證獲取到的數據源版本相同。
比如用戶興趣偏好特征由每日定時計算最新的版本，然后將離線計算結果同步到在線緩存，在線使用緩存中最新版本的用戶興趣偏好特征。雖然離線和在線的數據源相同，但是離線數據集生成的執行時間和在線讀取緩存的時間不相同，導致在線服務可能使用了還未同步的舊版本特征，而訓練數據集使用了最新版本特征。
??? 3. 代碼邏輯：離線和在線特征提取邏輯由不同開發人員獨立開發。
離線特征提取代碼是算法工程師基于Spark開發的批量提取邏輯(離線高吞吐需求)，而在線特征提取代碼是開發工程師使用基于Java Service開發的單點提取邏輯(在線低延遲需求)。因為開發人員不同，在實現過程中難以保證兩部分特征提取邏輯完全相同。
一個相關的例子是某個時間相關的Context特征在離線提取的邏輯中時間運算的單位是毫秒，而在線提取的邏輯中時間運算的單位是秒，最終導致這個特征離線在線的絕對值差異達到78%。
圖2：特征漂移原因
實際經驗中，特征漂移大部分由數據源導致，小部分由代碼邏輯不匹配和執行時間不同導致。在Hulu廣泛使用的模型離線訓練在線預測場景下，由于每個特征漂移的原因不一，漂移程度也不盡相同，所以要想直接正面解決模型中特征的漂移問題非常困難。為了衡量已有特征的漂移程度和解決特征漂移問題，Hulu的推薦工程師提出了服務端特征采集系統(Server Side Feature Logging，簡稱特征采集系統)。
目前工業界對特征漂移問題提出的解決思路主要分為兩類：Fact Logging[4] 和 Feature Logging[5]。Fact Logging解決特征漂移問題的思路是將數據源的每個版本記錄下來，且離線和在線特征提取共享部分代碼。Feature Logging的思路則是將在線提取出來的特征記錄下來, 屏蔽離線提取特征的流程。Fact Logging消除了離線在線之間數據源差異和部分代碼差異，從而消除了大部分特征漂移。Fact Logging的缺點是需要先使用Point-in-time join[6]找到正確版本的數據源，再執行特征提取邏輯, 對離線任務的性能是一大挑戰。另一方面是 Fact Logging 適用于用戶行為相關的特征，但不支持其他類型的特征，如召回模型分數之類的運行時Context特征。Feature Logging直接采集線上用于模型預測的特征，端到端地完全解決特征漂移問題，但因為Feature Logging沒有離線特征提取，只能慢慢積累在線特征，帶來的問題是不支持Backfill時間點在開始采集之前的數據集，因此特征迭代時間成本高。這兩種方式的對比如下表1所示。
表1：特征漂移解決思路對比
基于Hulu推薦系統中的特征工程現狀，我們最終決定采用如圖3所示的Feature Logging技術方案。Hulu原有的離線數據集構造工作流具備離線特征提取的能力，如果能結合原有離線提取的特征和在線采集的特征，就可以彌補Feature Logging在模型特征迭代方面的短板。
圖3：特征漂移解決思路
圖4：特征采集系統
加入特征采集之后的推薦系統如圖4所示，其中加粗的部分是特征采集系統的四個組件，分別位于推薦系統中在線服務、流式處理、離線大數據處理三個環節：
????● Feature Encoder：將在線特征編碼為二進制數據發送到流平臺。
????● Data Integration: 將流平臺中無格式的二進制特征數據持久化到離線數倉中。
????● Feature Consistency Check(FCC) & Dataset Builder: 兩類使用采集的在線特征的離線任務。
Feature Encoder是一個內嵌到在線服務中的異步組件; Data Integration是一個獨立且持續運行的流式任務；FCC計算采集下來的在線特征和原有離線生成的特征之間的特征漂移指標。Dataset Builder把上游離線任務生成的標簽信息和采集下來的在線特征關聯起來，生成模型訓練數據集。因為Dataset Builder生成的數據集的特征來源于在線預測使用的特征，讓模型訓練使用的特征與模型在線預測使用的特征對齊，所以徹底消除了離線和在線環境之間的特征漂移。
這三個組件中，Data Integration是業務完全無關的組件，在線服務中的Feature Encoder和離線的FCC & Dataset Builder需要對接業務，目前，Feature Encoder和FCC & Dataset Builder已經能兼容線上所有類型的特征，只需要編寫業務相關的配置文件即可完成對應模型的特征采集和使用需求。
圖5：原有離線訓練數據集構建流程
圖6：基于特征采集的離線訓練數據集構建流程
在引入特征采集之后，離線訓練數據集的構建過程從圖5演變為圖6。在圖6中，如果同一個特征即存在在線采集的數據，又存在離線提取的數據，Dataset Builder默認優先使用在線采集的數據。因此圖5中的離線特征提取過程在圖6中變為可選步驟，不僅解決了特征漂移問題，還節省了離線特征提取所消耗的資源和時間。
本節介紹了Hulu推薦工程中的特征采集系統的設計思路，在實際接入業務的過程中，系統還遇到了很多靈活性、高性能、高可用性等方面的挑戰和需求，下一部分我們將著重介紹一下這些挑戰以及我們的解決思路。
圖7：特征采集系統的挑戰和解決
為了支持算法工程師快速驗證新開發特征的有效性，Dataset Builder生成數據集的部分特征可能還是通過離線計算得到，故而Dataset Builder需要既支持使用在線特征，也支持使用離線特征生。
算法工程師在離線確認新開發特征的有效性之后，新特征會被上線到在線特征提取模塊，特征采集需要自動采集新提取的特征，并在離線環節自動切換到新采集的在線特征。這對特征采集系統提出了從采集到使用的端到端靈活性挑戰。
下面將從三個方面說明系統在靈活性方面的解決思路。
Feature Encoder采集入口和離線數倉都使用了動態數據類型Map將一次在線請求響應過程中提取的多個feature保存下來，而經過流處理部分是一個格式無關的組件。由于Map是一個動態的數據結構，因此一個新增的在線特征會被自動存儲到離線數據倉庫，數據格式無需任何改動。
離線的Dataset Builder設計了一套特征選擇機制：對于數據集中的一個特征，默認優先使用這個特征的在線采集數據，如果沒有采集到這個特征，則選擇使用該特征離線計算的結果。除了默認的在線優先規則，也可以配置一些特征直接使用離線生成的數據。在特征選擇機制下，一個特征的數據來源從離線計算切換到在線采集變得自然順暢，而且，還可以通過參數避開有問題的并且被采集下來的在線特征。
Dataset Builder將標簽當作離線計算的特征，支持多目標模型的訓練數據集生成，比如同時考慮點擊率和觀看時長的推薦模型。用戶僅需要添加一個單獨的YAML配置文件，就可以定義一個數據集生成任務，在采集特征和離線特征之間選擇想要的特征，生成符合預期的數據集。
為了縮短基于采集特征的特征迭代周期，我們設計出一套綜合了FCC、Dataset Builder、離線特征提取的迭代方案。
假設一個天級更新的模型的訓練數據集是30天，如圖8所示是基于特征采集新開發特征的過程：
??? 1. 在T-10d之前，算法工程師離線提取特征，并驗證新開發的特征對模型指標是否有提升。
??? 2. 在T-10d天，在線邏輯提取通過驗證的特征，使用Server Side Logging自動采集到離線。
??? 3. 在T-9d天，使用FCC對T-10d到T-9d這段時間內的新開發特征檢測離線和在線偏移指標。
??? 4. 如果第3步中FCC認為該特征離線漂移可接受(比如偏移指標小于5%)，則可以使用特征選擇機制，數據集中該特征在T-10d之前的數據來源于離線計算，T-10d之后來源于在線采集。這樣生成的數據集訓練的模型可以在T-9d即可進行線上實驗，不影響特征迭代周期。隨著時間推移，在線采集的部分在數據集中占的比例越來越高。當時間推移到T+20d，訓練數據集中的這個特征全部由在線采集得到。由FCC保證特征順滑地從離線切換到在線。
? ? 5. 如果第3步中FCC認為該特征離線在線差異很大，則需要等到T+20d使用完全由采集特征生成的數據集重新評估該特征對模型的影響。否則在離線在線特征漂移程度很大的情況下進行實驗，實驗可能有效果不及預期的風險，浪費算法工程師的人力。
圖8：基于特征采集的特征迭代過程
在目前Hulu推薦模型訓練數據集的標簽生成過程中，正負樣本有不同的采樣比例，而在特征采集階段，系統不能預知用戶對在線特征預測得到的推薦內容是否點擊播放， 即不知道采集的特征關聯上的訓練數據是正樣本還是負樣本。因此每個請求都需要記錄在線提取的特征，這樣可以支持最大正樣本100%采樣率。因此，特征采集系統面臨巨大的數據量。
數據壓縮旨在減小特征采集流量對在線服務、流式處理、離線存儲三個環節機器資源的網絡帶寬和存儲開銷， 提升采集系統能支撐的最大數據量。
Feature Encoder對特征按照特征值的類型進行分類（如整形值、浮點數、字符串等），將特征分到多個Map中，再使用Avro序列化框架編碼這些Map。由于每個Map的值類型相同，因此Avro序列化時能進好地壓縮數據。此外，數據傳輸過程和存儲都開啟了壓縮選項。在Hulu的場景下，Avro編碼的特征可以比Json節省70%的傳輸開銷，而Kafka開啟壓縮選項之后，能再節省80%傳輸開銷。
數據集成使用基于流式Flink代替批處理的Spark，在同樣的計算資源消耗下，能將更大的數據量從在線采集到離線，縮短數據落盤的周期。
FCC & Dataset Builder在離線主要處理采集的在線特征和離線生成的標簽數據，具有海量、傾斜、不對稱的特點。離線環境下的FCC和Dataset Builder任務，使用了列剪裁、Join優化、Window優化、布隆過濾器等多種優化手段，采集系統生成數據集相比原有離線提取特征的方式可以減少50%的資源消耗并且更快地生成訓練數據集。
特征采集的所有部分都實現為可以橫向擴容的組件。在現有機器資源無法服務需要采集的特征規模時，可以直接增加機器資源承接更重的特征采集需求。
Feature Encoder從推薦服務中源源不斷采集到特征，Data Integration也需要穩定、正常運行，將流平臺中的數據盡快寫入到離線，確保將特征數據在流平臺的Retention時間內持久化。在實際經驗中，這部分在特征采集整個環節中最消耗運維人員的精力，如離線數倉短暫不可用，或流處理任務中的認證信息過期，都可能導致特征數據同步中斷。
采集系統的可用性主要體現在Data Integration部分。這部分實現為一個內部自研的通用數據集成工具“Ribbon”。Ribbon基于Flink框架，特性是格式無關，功能之一是將流中的二進制Avro數據自動持久化到離線數倉中。Ribbon利用Flink的CheckPoint機制，完成特征數據從在線到離線的精確一次持久化，并且Ribbon使用了Flink任務自身的自動重啟和Flink平臺的自動重啟功能，雙重確保同步任務的持續運行。由此得到的高可用特性，使得運維人員幾乎不需要花費時間精力就能保證特征采集的正常運行。
目前，FCC已經對多個Hulu的推薦模型進行了檢測，得到了每個模型在線和離線特征之間的漂移報告。針對報告中的數個漂移明顯的特征，FCC幫助工程師解決了一些實現邏輯中的問題。多次實驗證明，使用Dataset Builder基于在線特征構造的數據集，替換離線提取特征構造的數據集，一般都能讓訓練出來的模型取得更好的用戶指標效果。另一方面，使用采集的在線特征帶來了工程上的好處：由于避免了離線特征提取過程，減少了離線數據集生成過程的資源和時間消耗。
這一套特征采集系統已經支持了Hulu主頁上的直播、電影、連續劇推薦場景的推薦特征，高效地承接了高峰期萬級別RPS的在線特征和每日TB級別離線特征數據的使用需求，而且我們還在不斷拓寬應用場景，提高模型落地的效果。
在Hulu的推薦系統中，除了用戶請求驅動的在線推薦，還有基于用戶事件觸發的近線推薦，應用在召回、UI排序等場景。近線場景觸發的推薦結果并不會立即返回給用戶，而是存在緩存中，等到用戶下一次在線請求時取出緩存中的預推薦結果給用戶。特征采集系統已經采集了近線場景的特征，支持了近線場景模型的FCC，但是因為近線推薦結果并不直接返回給用戶，所以近線場景下采集到的特征難以關聯到用戶的行為，生成無漂移的近線推薦模型數據集需要處理更大的數據量。
特征采集使得Hulu的推薦系統中有了流式的特征數據，再結合內容展現之后的用戶反饋信號，就能通過雙流Join生成流式的訓練數據集，從而加速原有模型的更新頻率，提高推薦用戶參與指標。
針對Hulu推薦模型離線訓練在線預測中的特征漂移問題，我們提出了一套適用于Hulu的特征采集系統， 用于衡量和解決特征漂移問題，特征形成了從在線提取、采集到離線、構造數據集、訓練模型、在線預測的閉環。
系統考慮到算法工程師特征實驗、迭代、上線運行需求，支持高效的特征迭代，對數據集在時間維度上的問題給出了解決方案。在工程實踐上，系統緩和了同一特征信息在服務技術棧和大數據技術棧之間的數據表示和使用方法之間的固有差異，具有靈活性、性能、高可用性等優點。
Hulu中特征采集系統的應用也離不開整個Hulu背景下的機器學習工程體系，訓練數據集在用戶和特征這兩個維度上的高質量仍然需要在線特征提取，離線標簽構造這兩個組件的密切配合。
[1]What is training-serving skew and how does it impact? ?models deployed in production.?
https://cloud.google.com/blog/topics/developers-practitioners/monitor-models-training-serving-skew-vertex-ai
[2]What is data drift?
https://docs.microsoft.com/en-us/azure/machine-learning/how-to-monitor-datasets?tabs=python#what-is-data-drift
[3]Jaccard_index
https://en.wikipedia.org/wiki/Jaccard_index
[4]Netflix: Evolution of ML Fact Store
https://netflixtechblog.com/evolution-of-ml-fact-store-5941d3231762
[5]Tecton: apply() Highlight: How Feature Logging Enables Real-Time ML
https://www.tecton.ai/blog/feature-logging-enables-real-time-ml/
[6]Point-in-time joins
https://docs.feast.dev/getting-started/concepts/point-in-time-joins#:~:text=Point%2Din%2Dtime%20joins%20%2D%20Feast&text=Copied!,specific%20point%20in%20the%20past.
Jing Zhou， Hulu機器學習平臺高級開發工程師
內容發現部門 (Content Discovery Org.) 是迪士尼流媒體核心研發部門，主攻Hulu、Disney+、Star+等迪士尼流媒體產品線的三大業務方向：搜索、個性化推薦、內容推廣。在每個業務方向上都和人工智能技術深度融合，涉及AI平臺的搭建、前沿算法的研究、以及工程系統的集成，致力于為迪士尼流媒體用戶提供最佳的視頻觀看體驗。
自成立伊始，該部門始終將內容的精準傳遞作為首要業務目標，深入結合工程、算法和數據，利用人才優勢與人工智能基礎解決業務問題。
感興趣的同學發送簡歷至：bjindustry@disney.com（煩請標注申請職位+姓名）
現誠招高級開發工程師 - 機器學習平臺大數據方向
點擊閱讀原文，查看職位詳細信息，歡迎投遞！
↓↓↓
總結
以上是生活随笔為你收集整理的技术博客|第13期:Server Side Logging:Hulu推荐系统中的特征漂移问题解决方法的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 闪存驱动器_什么是闪存驱动器？
- 下一篇： 【EXLIBRIS】随笔记 012