雪球演算法專案基於一流的通訊社群場景，提供資訊流推薦和搜尋的工程落地能力。 面對多個細分服務的接入，功能需求和實驗迭代速度都在加快，但目前的線上服務只能通過編碼來接入功能需求，迭代速度嚴重受限於工程編碼和除錯能力，需要不斷更新上線服務， 這給系統的穩定性帶來了極大的挑戰。因此，目前的工程架構無法滿足演算法實驗的快速演進，如何抽象特徵分層，做好模型和特徵依賴，構建一套全流程特徵管理機制，方便特徵上線下線，無需修改即可完成模型迭代是演算法工程團隊亟待解決的問題。
我們充分研究了業界特徵管理平台的設計方案，並基於雪球的演算法需求和技術架構，打造了UGC-Model-SLED雪球模型特徵實驗平台，統一管理特徵的生命週期，構建模型特徵依賴，打通實驗平台，降低工程維護成本， 並賦能演算法的快速迭代能力，很好地支撐業務需求。在相關系統的實戰中，還創新性地提出了一種特徵日誌實現方案，實現了工程化和資料一致性的平衡。
以連線人與資產，讓財富滾雪球越滾越大為使命，雪球是投資界的領軍人物。 作為資訊流內容平台，面對使用者不同的個性化需求，雪球社群服務與演算法團隊的工作就是智慧型分發、精準搜尋海量新聞資訊、討論、公告等內容，讓使用者輕鬆獲取所需內容和知識，促進社群生態健康發展。 內容的智慧型分發離不開模型的排序和估計，估計的準確性不僅取決於複雜模型和演算法的調優，更需要特徵工程快速迭代的支援。
隨著雪球日常活動的拓展和業務拓展，演算法能力不斷賦能各種新場景，功能數量也越來越多，社群服務專案面臨的挑戰和壓力也越來越大。 面對海量資料資源，需要實現特徵的快速迭代、特徵的高效計算、工程效能的平衡。 在此背景下，如何快速支援特徵迭代，是演算法工程團隊亟待解決的問題。
特徵是資料，特別是演算法在模型中使用的資料。 典型的功能生命週期如下圖所示：
特徵由資料來源生成，在離線或近線階段使用 Spark Flink 等資料處理平台生成，並儲存在 HDFS for Redis 中。 線上要素服務載入要素資料，對外提供資料查詢服務。 線上推薦和搜尋服務查詢模型**鏈結中對應的特徵資料，並進一步對特徵進行變換（特徵交叉、特徵離散化等），然後輸入模型**分數。
可以看出，功能的生命週期涵蓋線下和線上，涉及的環節和部門很多，在研發階段容易出現特徵不一致的現象。 此外，這些功能還具有以下特點：1有各種特徵，如特徵語義、資料型別、轉換方法等;2.功能復用率高，功能需要在不同專案之間復用 3.特徵數量大，專案耗時長，平均使用者每次推薦請求需要處理20W的特徵資料。
基於以上特點，應該用什麼樣的思路來接入和管理特徵，縮短特徵迭代週期，滿足快速演算法實驗的需求，保證線上工程的穩定性，是我們需要解決的問題。
行業內對特徵平台的研究非常廣泛，如微信的featurekv儲存系統專注於解決特徵資料快速同步的問題，騰訊的廣告特徵工程專注於解決機器習平台中的pre-trainer問題，美團的特徵平台專注於從樣品製作到線上服務的鏈路級解決方案， 而雪球的特徵平台則專注於模型線上部分的特徵依賴和特徵生命週期管理以及引擎級優化平台解決方案。本文將分享在搭建雪球模型功能平台過程中的一些思考和優化思路，希望對大家有所幫助或啟發。
如下圖所示，假設業務有ABC的三個特徵需求，線上特徵組裝部分需要開發特徵A、b、C的呼叫，並完成初步的改造。 採集完所有特徵後，進一步完成特徵交集的工作（如計算符號維度中使用者與帖子的匹配度），然後對特徵的離散值進行變換，併發送到模型端進行估計和評分。
*在電話會議的上述部分，如果對新功能有需求，工科學生需要繼續開發**以新增新功能。
隨著業務的發展，演算法不斷新增功能，功能迭代面臨以下問題：
功能復用：功能復用難度大，需要在不同服務的排序階段對功能進行複製和重新組合。
特徵管理：沒有特徵管理，特徵分層不清晰，特徵編碼結構隨意。
功能迭代：功能迭代速度受制於工程編碼和除錯能力以及線上服務發布速度。
特徵呼叫：並非所有模型都需要所有特徵，但所有特徵仍然需要線上獲取，造成浪費。
離線特點：缺乏離線機制導致服務臃腫，維護成本高，對專案耗時指標影響較大。
針對舊框架的不足，社群服務團隊於2024年著手搭建新的模型特徵平台，主要通過平台化的思路解決模型管理、特徵分層、生命週期管理等問題。 模型特徵平台整體架構如下：
圖中橙色部分是模型特徵平台的主要元件，分別是模型特徵平台管理模組和Web UI（ugc-model-sled-snownight）和模型特徵平台的線上引擎模組（ugc-model-sled）。
模型特徵平台管理模組是Web UI的後端部分，負責模型、特徵、配置等元資料的管理和維護，並將相關資料儲存在資料庫中。 模型特徵平台管理模組的核心部分是模型特徵依賴和特徵層次體系的構建。 稍後將對此進行詳細說明。
模型特徵平台的線上模組是線上引擎的重要組成部分，負責實驗接入、特徵組裝和提取，並請求模型服務進行評分，以及線上特徵的實現。 線上模組依靠管理模組的模型特徵配置來完成模型選擇和特徵組裝邏輯，作為通用引擎模組，這部分的架構盡可能抽象，變化不大。 同時，這部分涉及大量的IO，效能問題也需要特別注意。
接下來，我們將描述架構各個部分的解決方案和遇到的問題。
模型是演算法落地的核心模組，隨著業務線的不斷拓展，需要線上支援大量的模型實驗，模型型別、模型輸出模式、模型對特徵的依賴性不同，管理模組需要對模型進行統一管理。 同時，模型的上線和下線需要一套自動化工具來支援。
模型管理分為模型元資料管理和線上模型管理套件兩部分。
模型元資料管理主要解決模型註冊和統一管理的問題。 模型的主要元資料包括：模型名稱、模型版本、模型型別、模型輸出定義和特徵組。 這裡的模型名稱和模型版本可以唯一地確定模型，模型型別用於將模型與TensorFlow或XGB區分開來，模型輸出用於相容具有多個輸出的多工習模型。 特徵組是模型需要依賴的特徵集合（稍後在特徵分層中討論），以便線上引擎可以部分拉取相應的特徵。 對於不再依賴的功能，可以很容易地追溯到離線行。
線上模型管理套件主要解決生產環境中模型集群中的模型上線下線問題。 將演算法訓練的模型以檔案的形式上傳到集群中，然後向外界提供服務。 在舊框架下，需要手動操作，雖然有輔助指令碼工具，但服務集群之間經常出現模型不一致的情況，給專案故障排除帶來了很大的麻煩。 因此，開發了一種線上模型工具，通過對模型的集中控制，不僅實現了最佳集群的一致性，還節省了人力。
線上模型管理套件的架構如下圖所示，包括前端Web、模型線上和離線服務，以及整合到模型集群中的worker模組。 該演算法可以通過 WebUI 或 API 指定任務，然後模型的線上和離線服務通過任務下發與 worker 進行互動，完成模型的載入、刪除、檢視等操作。 同時預留API介面，方便與後續機器學習習平台平滑對接。
特徵管理系統以特徵分層為核心理論，特徵分層的主要任務是抽象特徵形態，梳理出各特徵形態的分層。 在 Snowball 模型特徵平台中，特徵根據生成和轉換方式分為原始資料層、派生特徵層和模型特徵層。
原始資料層是用於拼接特徵**的資料，它是非交叉資料，可以理解為描述實體的各種標記資料。 它可以是使用者的性別和年齡等靜態資料，也可以是離線或實時生成的動態資料，例如使用者關鍵字偏好、帖子關鍵字、帖子點選率等。 原始資料廣泛儲存在大資料、帖子、NLP等各種資料中，各種資料提供對公共特徵介面的訪問。
除了指定資料ID、資料來源和資料型別外，原始資料元資料管理的乙個重要欄位是資料主體（user、post、**來描述此功能是哪個實體，線上服務可以通過該欄位自動提取實體的金鑰來查詢資料。
派生要素圖層是原始資料（包括相交資料）的變換，被理解為模型所需的要素。 派生特徵解決了演算法需要對原始資料進行一些轉換和交集的問題。 這些操作之所以比離線更經濟，是為了節省計算資源，比如在關鍵詞維度上計算使用者和召回帖子的匹配度，解決方案是線上計算，離線層無法計算笛卡爾乘積的資料。
派生特徵是模型與原始資料之間的橋梁層，是模型所依賴的特徵，可以手動讀取。
此外，線上特徵落地是衍生特徵，不僅方便離線檢視特徵資料，還可以靈活地對衍生特徵進行轉換，做一些特徵實驗。
除了指定特徵 ID 和資料型別外，派生特徵元資料管理的乙個重要欄位是指定對原始資料的依賴關係，以便線上服務可以通過模型派生特徵>原始資料的依賴關係來組裝資料>。
模型特徵由衍生特徵進行變換，並基於一組模式化運算元完成關聯變換。 模型特徵是指模型輸入層的特徵，主要做一些特徵預處理工作，如一熱和資料歸一化，即離散資料（也增加了對連續特徵的支援），也可以指定離散特徵的交集。
由於模型要素圖層與模型緊密繫結，只需一組運算元配置即可完成從派生特徵到模型特徵的轉換，因此模型要素圖層的配置隱藏在模型中，模型要素圖層的配置僅依賴於為模型指定運算元配置檔案。 這簡化為原始和派生特徵的管理。
讓我們用使用者的 Intimacy 和 Post Discussion 標籤來解釋上述分層的含義，如下圖所示。
基於上述特徵分層理論，特徵管理模組分別構造原始資料元資料表和派生特徵元資料表，並提供前端介面和API介面，方便註冊。
模型特徵平台的引擎模組為線上部分，承擔各搜尋推薦業務的評分請求流量，完成將原有特徵拉取到模型特徵轉換，最後請求模型**集群進行評分的工作。
根據模型管理和特徵管理的架構，線上引擎部分的工作流程如下：
首先，根據實驗系統獲取模型ID，對依賴的原始資料集進行回溯，完成原始資料查詢後，將上游資料合併形成原始資料集; 然後，將派生的特徵和模型特徵轉換後，傳送到模型估計層進行估計。
功能分級管理帶來了友好的維護能力，但也給線上工程帶來了新的挑戰。 在舊框架中，可以對某些功能進行一些功能級別的優化，而不僅僅是多個功能的聚合等。 功能拉取和呼叫階段是高度 I/O 密集型服務，需要針對大量 GRPC 呼叫進行優化。 特徵轉換和計算階段是 CPU 密集型的，需要針對計算進行優化。
顧名思義，聚合查詢就是在 grpc 請求中完成可以批量請求的資料。 這裡，根據下游服務的特點，我們先根據資料來源對原始資料進行分組，然後根據資料主體進行分組，將屬於同一資料主體的原始特徵採集請求一次性傳送到資料來源。
在特徵壓縮模型的灰度啟動階段，需要使用原有服務的所有上游特徵，平均每個使用者請求需要上傳20w+的原始資料，給網路傳輸帶來極大的消耗。 在對比了各種壓縮方案和資料協議的效能後，採用自定義的protobuf+snappy壓縮方法解決了網路傳輸問題。
非同步呼叫原始資料是一種典型的I/O密集型業務模式，具有grPC裂變率高、請求時間長（P99可達100 ms）等特點。 初始階段採用多執行緒+同步呼叫模式，為原始資料呼叫建立執行緒池，主線程將任務提交到執行緒池執行，主線程和原特徵呼叫執行緒同步等待，造成執行緒浪費，無法承擔高QPS。 這裡的優化點是去掉了原來的資料呼叫執行緒池，只由主線程發起多個 grpc 非同步呼叫，然後進入等待狀態，通過 ** 函式的機制喚醒主線程繼續工作。 在這種情況下，只有主線程在同步等待，這是一種半非同步呼叫。 雖然我們也可以將其製作成完全非同步的形式，但由於底層服務框架的限制和**的可讀性，選擇主線程的同步等待方式是更好的解決方案。
快取優化快取和JVM分代**的存在是天然矛盾的，這在《人工智慧特徵系統中的資料訪問技術》一文中得到了闡述。 不受歡迎的資料繼續進入老年，觸發全GC。 這裡模型特徵拼接模組不設定快取，也是基於對這個問題的考慮，在高QPS的特徵快取模組中盡量使用堆外快取。
該演算法需要將線上特徵作為**日誌登陸，並離線進行模型訓練或資料分析。 一般來說，要登陸的特徵（logfeature）不一定是當前請求中模型需要的特徵（model feature），而只是最終推薦要返回的項的特徵。 傳統的方法是在特徵準備階段獲取logfeature，先快取，等待推薦結果加入，但這種資料量非常大，命中率很低（推薦結果數和評分項數），這一直是工程中的難題。
在此場景中，我們認為可以非同步重新獲取特徵，即在返回推薦時，重新呼叫線上引擎以登陸特徵。 將模型評分和特徵登陸解耦，以降低工程複雜性。 但是，這裡新的問題是特徵一致性和遍歷，即特徵準備階段的特徵和最後非同步落地的特徵，可能存在特徵遍歷的問題。
深入分析這兩個階段：特徵準備和非同步日誌丟棄階段，其實只有評分和混合的區別，一般在100-200ms之間，在這麼短的時間內，使用者不可能有新的行為，專案的特徵變化可以忽略不計，應該不存在特徵遍歷的問題。 用這個想法開發的特徵日誌上線後，經過反覆的模型訓練驗證，發現落地樣本訓練的模型AUC正常，線上效能可用，從業務角度解決了工程問題。
新平台抽象了特徵分層，顯式管理模型和特徵依賴關係，構建了一套全流程特徵管理機制，方便特徵上線下線，無需修改即可完成模型迭代，與舊框架相比，大大提高了特徵迭代速度，保證了專案的穩定性。
模型特徵平台專案旨在利用基於平台的工具，為演算法模型、模型、實驗相關業務賦能，解決線上工程中的特徵演化、模型迭代、實驗跟蹤分析等問題，提高演算法實驗迭代效率。 經過近一年的演進，已經形成了模型特徵管理和線上引擎兩大功能模組。
在特徵管理方面，我們充分調研了行業內的特徵管理經驗，結合雪球自有的演算法體系和資料的三端業務架構，創新性地提出了原始資料、衍生特徵和模型特徵的三層特徵分層理論，並線上應用，便於演算法介入特徵生產等生命週期的子階段， 提取和轉換，大大簡化了特徵管理成本，支援200+特徵的訪問和驗證。
在模型迭代方面，我們開發了離散特徵模型、多目標多輸出等異構模型的配置接入，可支援MMOE、FM等複雜業務模型。 同時，為了簡化演算法模型的上線，開發了線上模型管理套件，讓演算法學生可以線上和離線檢視線上模型版本和操作模型，目前已支援50+模型的迭代演進。
在新平台的引入下，各部門的角色和分工也更加清晰，如下圖所示：在新平台下，演算法更加注重特徵定義和模型訓練與估計，資料負責特徵的生產和服務，系統通過該平台為演算法模型的實現提供平台解決方案。
模型特徵平台目前在原始資料採集階段需要時間，可以進一步優化模型特徵平台的特徵分層，未來可以接入XGB等各種模型。