在機器學習的流程大體可以分成模型訓練和模型服務兩個階段。無論是訓練和服務階段，其實都需要進行特征工程相關的工作，這塊的技術挑戰(zhàn)就是如何保證訓練和預測過程中使用的特征是一致的。這個問題困擾了很多機器學習從業(yè)者，比較典型的場景就是推薦場景。在推薦業(yè)務中往往要用離線數據做特征工程然后輸入到算法中訓練生成推薦模型，在實際業(yè)務側也需要按照同樣的特征樣本拼接方式生成預測樣本，輸入給模型做實時預測并拿到推薦結果。

今天要介紹的Feast其實是一個特征管理工具，他通過一套封裝好的sdk保證了Model Serving和Model Training兩個場景下的特征一致性問題。

Feast架構介紹

看下Feast的架構圖，他可以接受Spark、Hive等數倉體系生成的Batch類數據，也可以將Log Service產出的數據通過Kafka構建成Streaming Feature與Batch數據結合構建特征。在Feast籃框內看到，針對Offline和Online的Feature提供了不同的方案，Offline Feature可以通過Feast SDK形成Training Features進行訓練，在Online Feature可以通過部署Feast Serving構建出來用于Inference。而且訓練和預測的特征是嚴格一致性保證的。接下來通過一個例子介紹下Feast是如何使用的。

Feast使用方式

1.特征表注冊

Feast中將特征構建的主key定義為Entity，Entity往往是多個表關聯的索引。可以用以下方法注冊：

driver_id = Entity(name="driver_id", description="Driver identifier", value_type=ValueType.INT64)

有了主key后，就可以注冊多張表的關聯關系。Feature Table可能由離線和在線的多種源構成，需要在里面描述清楚每種特征是如何構建出來的。

最終特征的拼接邏輯會生成yaml文件。

2.離在線特征區(qū)分

離在線的特征的構建是不同的，離線通常是聚合統計類特征，比如算比例之類的，在Feast里這種特征處理方式叫做driver statistics，如下圖：

在線特征更多的是單純的計算出現次數，如某件行為發(fā)生的次數，可以通過flink實時統計出來，叫做driver trips。

driver statistics和driver trips通常在注冊數據表來源的時候要體現。

定義好這些內容之后就可以具體的生產特征了。離線特征可以存儲在S3、本地等環(huán)境里。實時特征可以處理好并存儲到Redis里供實時調用。

3.時間窗定義

既然特征工程分離線處理的特征和在線處理的特征，那么離在線任務肯定會涉及到時間窗口一致性問題。比如一個表3個特征是離線的，2個特征是實時的，如果離線特征的生產時間窗總是比實時特征慢，會造成特征拼接不準確的問題。為了解決這個問題Feast提供了一個time-stamp功能。

系統會為每個Entity記錄一個time-stamp，客戶在使用的過程中可以根據time-stamp確定某個Feature Table是否可用。

Feast總結

經過整體的特征生成、特征表注冊、離線和在線配置就可以構建以上的特征生成系統，可以通過time-stamp功能去選擇要調用的Feature Table。

總結

以上是生活随笔為你收集整理的特征训练、预测一致性管理工具：开源项目Feast的全部內容，希望文章能夠幫你解決所遇到的問題。

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