在推薦系統(tǒng)中，有效刻畫用戶偏好的特征是提升模型效果的重要因素。特征采集的意義在于保證模型訓練和預測這兩個相對獨立的步驟中特征的一致性，防止特征漂移[1][2]現(xiàn)象損失模型的效果。本文提出了一套適用于Hulu推薦系統(tǒng)的特征采集系統(tǒng)，用于幫助算法工程師構造更好的訓練數(shù)據(jù)集，提高模型實際落地的效果。

在Hulu的推薦系統(tǒng)中，一種典型的推薦模型離線訓練在線預測的工作流如圖1所示：

圖1：Model Engineer Workflow in Hulu

上圖中下半部分是離線構造模型的工作流：內容在用戶界面上的展現(xiàn)、點擊、播放等事件會被記錄到數(shù)據(jù)倉庫中，經過上游團隊的數(shù)據(jù)處理工作得到用戶事實表，推薦團隊再從事實表中提取內容展現(xiàn)給用戶時的特征和標簽，構成訓練數(shù)據(jù)集。每日生成的數(shù)據(jù)集經過訓練得到模型快照。

上半部分是在線模型預測的工作流：在線推薦服務收到用戶的請求之后，先請求依賴的相關服務得到用戶行為等原始數(shù)據(jù)，再通過在線特征提取邏輯得到該用戶和一些內容在此時的特征，再經過一個模型推理模塊計算該用戶對每個內容的預測得分。

在上面的流程中，離線特征提取是為了還原在線推薦使用的用戶和內容特征。理論上，內容對用戶的同一次展現(xiàn)，在線預測和離線訓練使用的特征應該完全相等， 但實際上，模型離線訓練和在線預測在工程實踐中使用的特征存在不一致現(xiàn)象，即發(fā)生了訓練-預測之間的特征漂移。漂移現(xiàn)象出現(xiàn)的原因可以總結為以下三個方面：

??? 1. 數(shù)據(jù)源：離線特征的數(shù)據(jù)源是數(shù)倉中的用戶事實表，在線特征的數(shù)據(jù)源是其他在線服務。

例如用戶在一年內保存和刪除的電視連續(xù)劇列表特征，由于數(shù)據(jù)源的差異(在線數(shù)據(jù)源是其他團隊基于播放器上報的心跳事件的行為服務, 離線數(shù)據(jù)源是另外一個團隊基于客戶端埋點的行為明細表)， 離線數(shù)據(jù)源中的連續(xù)劇列表比同一個用戶通過在線服務得到的連續(xù)劇少。實際系統(tǒng)中這個特征離線在線提取出的兩個列表的Jaccard距離[3]為0.28 。

??? 2. 執(zhí)行時間：離線和在線執(zhí)行時間不同，不能保證獲取到的數(shù)據(jù)源版本相同。

比如用戶興趣偏好特征由每日定時計算最新的版本，然后將離線計算結果同步到在線緩存，在線使用緩存中最新版本的用戶興趣偏好特征。雖然離線和在線的數(shù)據(jù)源相同，但是離線數(shù)據(jù)集生成的執(zhí)行時間和在線讀取緩存的時間不相同，導致在線服務可能使用了還未同步的舊版本特征，而訓練數(shù)據(jù)集使用了最新版本特征。

??? 3. 代碼邏輯：離線和在線特征提取邏輯由不同開發(fā)人員獨立開發(fā)。

離線特征提取代碼是算法工程師基于Spark開發(fā)的批量提取邏輯(離線高吞吐需求)，而在線特征提取代碼是開發(fā)工程師使用基于Java Service開發(fā)的單點提取邏輯(在線低延遲需求)。因為開發(fā)人員不同，在實現(xiàn)過程中難以保證兩部分特征提取邏輯完全相同。

一個相關的例子是某個時間相關的Context特征在離線提取的邏輯中時間運算的單位是毫秒，而在線提取的邏輯中時間運算的單位是秒，最終導致這個特征離線在線的絕對值差異達到78%。

圖2：特征漂移原因

實際經驗中，特征漂移大部分由數(shù)據(jù)源導致，小部分由代碼邏輯不匹配和執(zhí)行時間不同導致。在Hulu廣泛使用的模型離線訓練在線預測場景下，由于每個特征漂移的原因不一，漂移程度也不盡相同，所以要想直接正面解決模型中特征的漂移問題非常困難。為了衡量已有特征的漂移程度和解決特征漂移問題，Hulu的推薦工程師提出了服務端特征采集系統(tǒng)(Server Side Feature Logging，簡稱特征采集系統(tǒng))。

目前工業(yè)界對特征漂移問題提出的解決思路主要分為兩類：Fact Logging[4] 和 Feature Logging[5]。Fact Logging解決特征漂移問題的思路是將數(shù)據(jù)源的每個版本記錄下來，且離線和在線特征提取共享部分代碼。Feature Logging的思路則是將在線提取出來的特征記錄下來, 屏蔽離線提取特征的流程。Fact Logging消除了離線在線之間數(shù)據(jù)源差異和部分代碼差異，從而消除了大部分特征漂移。Fact Logging的缺點是需要先使用Point-in-time join[6]找到正確版本的數(shù)據(jù)源，再執(zhí)行特征提取邏輯, 對離線任務的性能是一大挑戰(zhàn)。另一方面是 Fact Logging 適用于用戶行為相關的特征，但不支持其他類型的特征，如召回模型分數(shù)之類的運行時Context特征。Feature Logging直接采集線上用于模型預測的特征，端到端地完全解決特征漂移問題，但因為Feature Logging沒有離線特征提取，只能慢慢積累在線特征，帶來的問題是不支持Backfill時間點在開始采集之前的數(shù)據(jù)集，因此特征迭代時間成本高。這兩種方式的對比如下表1所示。

表1：特征漂移解決思路對比

基于Hulu推薦系統(tǒng)中的特征工程現(xiàn)狀，我們最終決定采用如圖3所示的Feature Logging技術方案。Hulu原有的離線數(shù)據(jù)集構造工作流具備離線特征提取的能力，如果能結合原有離線提取的特征和在線采集的特征，就可以彌補Feature Logging在模型特征迭代方面的短板。

圖3：特征漂移解決思路

圖4：特征采集系統(tǒng)

加入特征采集之后的推薦系統(tǒng)如圖4所示，其中加粗的部分是特征采集系統(tǒng)的四個組件，分別位于推薦系統(tǒng)中在線服務、流式處理、離線大數(shù)據(jù)處理三個環(huán)節(jié)：

????● Feature Encoder：將在線特征編碼為二進制數(shù)據(jù)發(fā)送到流平臺。

????● Data Integration: 將流平臺中無格式的二進制特征數(shù)據(jù)持久化到離線數(shù)倉中。

????● Feature Consistency Check(FCC) & Dataset Builder: 兩類使用采集的在線特征的離線任務。

Feature Encoder是一個內嵌到在線服務中的異步組件; Data Integration是一個獨立且持續(xù)運行的流式任務；FCC計算采集下來的在線特征和原有離線生成的特征之間的特征漂移指標。Dataset Builder把上游離線任務生成的標簽信息和采集下來的在線特征關聯(lián)起來，生成模型訓練數(shù)據(jù)集。因為Dataset Builder生成的數(shù)據(jù)集的特征來源于在線預測使用的特征，讓模型訓練使用的特征與模型在線預測使用的特征對齊，所以徹底消除了離線和在線環(huán)境之間的特征漂移。

這三個組件中，Data Integration是業(yè)務完全無關的組件，在線服務中的Feature Encoder和離線的FCC & Dataset Builder需要對接業(yè)務，目前，Feature Encoder和FCC & Dataset Builder已經能兼容線上所有類型的特征，只需要編寫業(yè)務相關的配置文件即可完成對應模型的特征采集和使用需求。

圖5：原有離線訓練數(shù)據(jù)集構建流程

圖6：基于特征采集的離線訓練數(shù)據(jù)集構建流程

在引入特征采集之后，離線訓練數(shù)據(jù)集的構建過程從圖5演變?yōu)閳D6。在圖6中，如果同一個特征即存在在線采集的數(shù)據(jù)，又存在離線提取的數(shù)據(jù)，Dataset Builder默認優(yōu)先使用在線采集的數(shù)據(jù)。因此圖5中的離線特征提取過程在圖6中變?yōu)榭蛇x步驟，不僅解決了特征漂移問題，還節(jié)省了離線特征提取所消耗的資源和時間。

本節(jié)介紹了Hulu推薦工程中的特征采集系統(tǒng)的設計思路，在實際接入業(yè)務的過程中，系統(tǒng)還遇到了很多靈活性、高性能、高可用性等方面的挑戰(zhàn)和需求，下一部分我們將著重介紹一下這些挑戰(zhàn)以及我們的解決思路。

圖7：特征采集系統(tǒng)的挑戰(zhàn)和解決

為了支持算法工程師快速驗證新開發(fā)特征的有效性，Dataset Builder生成數(shù)據(jù)集的部分特征可能還是通過離線計算得到，故而Dataset Builder需要既支持使用在線特征，也支持使用離線特征生。

算法工程師在離線確認新開發(fā)特征的有效性之后，新特征會被上線到在線特征提取模塊，特征采集需要自動采集新提取的特征，并在離線環(huán)節(jié)自動切換到新采集的在線特征。這對特征采集系統(tǒng)提出了從采集到使用的端到端靈活性挑戰(zhàn)。

下面將從三個方面說明系統(tǒng)在靈活性方面的解決思路。

Feature Encoder采集入口和離線數(shù)倉都使用了動態(tài)數(shù)據(jù)類型Map將一次在線請求響應過程中提取的多個feature保存下來，而經過流處理部分是一個格式無關的組件。由于Map是一個動態(tài)的數(shù)據(jù)結構，因此一個新增的在線特征會被自動存儲到離線數(shù)據(jù)倉庫，數(shù)據(jù)格式無需任何改動。

離線的Dataset Builder設計了一套特征選擇機制：對于數(shù)據(jù)集中的一個特征，默認優(yōu)先使用這個特征的在線采集數(shù)據(jù)，如果沒有采集到這個特征，則選擇使用該特征離線計算的結果。除了默認的在線優(yōu)先規(guī)則，也可以配置一些特征直接使用離線生成的數(shù)據(jù)。在特征選擇機制下，一個特征的數(shù)據(jù)來源從離線計算切換到在線采集變得自然順暢，而且，還可以通過參數(shù)避開有問題的并且被采集下來的在線特征。

Dataset Builder將標簽當作離線計算的特征，支持多目標模型的訓練數(shù)據(jù)集生成，比如同時考慮點擊率和觀看時長的推薦模型。用戶僅需要添加一個單獨的YAML配置文件，就可以定義一個數(shù)據(jù)集生成任務，在采集特征和離線特征之間選擇想要的特征，生成符合預期的數(shù)據(jù)集。

為了縮短基于采集特征的特征迭代周期，我們設計出一套綜合了FCC、Dataset Builder、離線特征提取的迭代方案。

假設一個天級更新的模型的訓練數(shù)據(jù)集是30天，如圖8所示是基于特征采集新開發(fā)特征的過程：

??? 1. 在T-10d之前，算法工程師離線提取特征，并驗證新開發(fā)的特征對模型指標是否有提升。

??? 2. 在T-10d天，在線邏輯提取通過驗證的特征，使用Server Side Logging自動采集到離線。

??? 3. 在T-9d天，使用FCC對T-10d到T-9d這段時間內的新開發(fā)特征檢測離線和在線偏移指標。

??? 4. 如果第3步中FCC認為該特征離線漂移可接受(比如偏移指標小于5%)，則可以使用特征選擇機制，數(shù)據(jù)集中該特征在T-10d之前的數(shù)據(jù)來源于離線計算，T-10d之后來源于在線采集。這樣生成的數(shù)據(jù)集訓練的模型可以在T-9d即可進行線上實驗，不影響特征迭代周期。隨著時間推移，在線采集的部分在數(shù)據(jù)集中占的比例越來越高。當時間推移到T+20d，訓練數(shù)據(jù)集中的這個特征全部由在線采集得到。由FCC保證特征順滑地從離線切換到在線。

? ? 5. 如果第3步中FCC認為該特征離線在線差異很大，則需要等到T+20d使用完全由采集特征生成的數(shù)據(jù)集重新評估該特征對模型的影響。否則在離線在線特征漂移程度很大的情況下進行實驗，實驗可能有效果不及預期的風險，浪費算法工程師的人力。

圖8：基于特征采集的特征迭代過程

在目前Hulu推薦模型訓練數(shù)據(jù)集的標簽生成過程中，正負樣本有不同的采樣比例，而在特征采集階段，系統(tǒng)不能預知用戶對在線特征預測得到的推薦內容是否點擊播放， 即不知道采集的特征關聯(lián)上的訓練數(shù)據(jù)是正樣本還是負樣本。因此每個請求都需要記錄在線提取的特征，這樣可以支持最大正樣本100%采樣率。因此，特征采集系統(tǒng)面臨巨大的數(shù)據(jù)量。

數(shù)據(jù)壓縮旨在減小特征采集流量對在線服務、流式處理、離線存儲三個環(huán)節(jié)機器資源的網(wǎng)絡帶寬和存儲開銷， 提升采集系統(tǒng)能支撐的最大數(shù)據(jù)量。

Feature Encoder對特征按照特征值的類型進行分類（如整形值、浮點數(shù)、字符串等），將特征分到多個Map中，再使用Avro序列化框架編碼這些Map。由于每個Map的值類型相同，因此Avro序列化時能進好地壓縮數(shù)據(jù)。此外，數(shù)據(jù)傳輸過程和存儲都開啟了壓縮選項。在Hulu的場景下，Avro編碼的特征可以比Json節(jié)省70%的傳輸開銷，而Kafka開啟壓縮選項之后，能再節(jié)省80%傳輸開銷。

數(shù)據(jù)集成使用基于流式Flink代替批處理的Spark，在同樣的計算資源消耗下，能將更大的數(shù)據(jù)量從在線采集到離線，縮短數(shù)據(jù)落盤的周期。

FCC & Dataset Builder在離線主要處理采集的在線特征和離線生成的標簽數(shù)據(jù)，具有海量、傾斜、不對稱的特點。離線環(huán)境下的FCC和Dataset Builder任務，使用了列剪裁、Join優(yōu)化、Window優(yōu)化、布隆過濾器等多種優(yōu)化手段，采集系統(tǒng)生成數(shù)據(jù)集相比原有離線提取特征的方式可以減少50%的資源消耗并且更快地生成訓練數(shù)據(jù)集。

特征采集的所有部分都實現(xiàn)為可以橫向擴容的組件。在現(xiàn)有機器資源無法服務需要采集的特征規(guī)模時，可以直接增加機器資源承接更重的特征采集需求。

Feature Encoder從推薦服務中源源不斷采集到特征，Data Integration也需要穩(wěn)定、正常運行，將流平臺中的數(shù)據(jù)盡快寫入到離線，確保將特征數(shù)據(jù)在流平臺的Retention時間內持久化。在實際經驗中，這部分在特征采集整個環(huán)節(jié)中最消耗運維人員的精力，如離線數(shù)倉短暫不可用，或流處理任務中的認證信息過期，都可能導致特征數(shù)據(jù)同步中斷。

采集系統(tǒng)的可用性主要體現(xiàn)在Data Integration部分。這部分實現(xiàn)為一個內部自研的通用數(shù)據(jù)集成工具“Ribbon”。Ribbon基于Flink框架，特性是格式無關，功能之一是將流中的二進制Avro數(shù)據(jù)自動持久化到離線數(shù)倉中。Ribbon利用Flink的CheckPoint機制，完成特征數(shù)據(jù)從在線到離線的精確一次持久化，并且Ribbon使用了Flink任務自身的自動重啟和Flink平臺的自動重啟功能，雙重確保同步任務的持續(xù)運行。由此得到的高可用特性，使得運維人員幾乎不需要花費時間精力就能保證特征采集的正常運行。

目前，FCC已經對多個Hulu的推薦模型進行了檢測，得到了每個模型在線和離線特征之間的漂移報告。針對報告中的數(shù)個漂移明顯的特征，FCC幫助工程師解決了一些實現(xiàn)邏輯中的問題。多次實驗證明，使用Dataset Builder基于在線特征構造的數(shù)據(jù)集，替換離線提取特征構造的數(shù)據(jù)集，一般都能讓訓練出來的模型取得更好的用戶指標效果。另一方面，使用采集的在線特征帶來了工程上的好處：由于避免了離線特征提取過程，減少了離線數(shù)據(jù)集生成過程的資源和時間消耗。

這一套特征采集系統(tǒng)已經支持了Hulu主頁上的直播、電影、連續(xù)劇推薦場景的推薦特征，高效地承接了高峰期萬級別RPS的在線特征和每日TB級別離線特征數(shù)據(jù)的使用需求，而且我們還在不斷拓寬應用場景，提高模型落地的效果。

在Hulu的推薦系統(tǒng)中，除了用戶請求驅動的在線推薦，還有基于用戶事件觸發(fā)的近線推薦，應用在召回、UI排序等場景。近線場景觸發(fā)的推薦結果并不會立即返回給用戶，而是存在緩存中，等到用戶下一次在線請求時取出緩存中的預推薦結果給用戶。特征采集系統(tǒng)已經采集了近線場景的特征，支持了近線場景模型的FCC，但是因為近線推薦結果并不直接返回給用戶，所以近線場景下采集到的特征難以關聯(lián)到用戶的行為，生成無漂移的近線推薦模型數(shù)據(jù)集需要處理更大的數(shù)據(jù)量。

特征采集使得Hulu的推薦系統(tǒng)中有了流式的特征數(shù)據(jù)，再結合內容展現(xiàn)之后的用戶反饋信號，就能通過雙流Join生成流式的訓練數(shù)據(jù)集，從而加速原有模型的更新頻率，提高推薦用戶參與指標。

針對Hulu推薦模型離線訓練在線預測中的特征漂移問題，我們提出了一套適用于Hulu的特征采集系統(tǒng)， 用于衡量和解決特征漂移問題，特征形成了從在線提取、采集到離線、構造數(shù)據(jù)集、訓練模型、在線預測的閉環(huán)。

系統(tǒng)考慮到算法工程師特征實驗、迭代、上線運行需求，支持高效的特征迭代，對數(shù)據(jù)集在時間維度上的問題給出了解決方案。在工程實踐上，系統(tǒng)緩和了同一特征信息在服務技術棧和大數(shù)據(jù)技術棧之間的數(shù)據(jù)表示和使用方法之間的固有差異，具有靈活性、性能、高可用性等優(yōu)點。

Hulu中特征采集系統(tǒng)的應用也離不開整個Hulu背景下的機器學習工程體系，訓練數(shù)據(jù)集在用戶和特征這兩個維度上的高質量仍然需要在線特征提取，離線標簽構造這兩個組件的密切配合。

[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機器學習平臺高級開發(fā)工程師

內容發(fā)現(xiàn)部門 (Content Discovery Org.) 是迪士尼流媒體核心研發(fā)部門，主攻Hulu、Disney+、Star+等迪士尼流媒體產品線的三大業(yè)務方向：搜索、個性化推薦、內容推廣。在每個業(yè)務方向上都和人工智能技術深度融合，涉及AI平臺的搭建、前沿算法的研究、以及工程系統(tǒng)的集成，致力于為迪士尼流媒體用戶提供最佳的視頻觀看體驗。

自成立伊始，該部門始終將內容的精準傳遞作為首要業(yè)務目標，深入結合工程、算法和數(shù)據(jù)，利用人才優(yōu)勢與人工智能基礎解決業(yè)務問題。

感興趣的同學發(fā)送簡歷至：bjindustry@disney.com（煩請標注申請職位+姓名）

現(xiàn)誠招高級開發(fā)工程師 - 機器學習平臺大數(shù)據(jù)方向

點擊閱讀原文，查看職位詳細信息，歡迎投遞！

↓↓↓

總結

以上是生活随笔為你收集整理的技术博客|第13期:Server Side Logging:Hulu推荐系统中的特征漂移问题解决方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。