外賣排序系統(tǒng)特征生產(chǎn)框架

海文 ·2016-12-09 19:28

背景

圖1 外賣排序系統(tǒng)框架

外賣的排序策略是由機器學(xué)習(xí)模型驅(qū)動的，模型迭代效率制約著策略優(yōu)化效果。如上圖所示，在排序系統(tǒng)里，特征是最為基礎(chǔ)的部分：有了特征之后，我們離線訓(xùn)練出模型，然后將特征和模型一起推送給線上排序服務(wù)使用。特征生產(chǎn)Pipeline對于策略迭代的效率起著至關(guān)重要的作用。經(jīng)過實踐中的積累和提煉，我們整理出一套通用的特征生產(chǎn)框架，大大節(jié)省開發(fā)量，提高策略迭代效率。

外賣排序系統(tǒng)使用GBDT（Gradient Boosting Decision Tree）樹模型，比較復(fù)雜。受限于計算能力，除了上下文特征（如時間、地域、終端類型、距離等）之外，目前使用的主要是一些寬泛的統(tǒng)計特征，比如商家銷量、商家單均價、用戶的品類偏好等。這些特征的生產(chǎn)流程包括：離線的統(tǒng)計、離線到在線的同步、在線的加載等。

圖2 特征生產(chǎn)流程

如上圖，目前外賣排序的特征生產(chǎn)流程主要有：

特征統(tǒng)計：基于基礎(chǔ)數(shù)據(jù)表（如曝光表、點擊表、訂單表等），統(tǒng)計若干時段內(nèi)特定維度的總量、分布等，如商家月均銷量、用戶不同品類下單占比。統(tǒng)計結(jié)果存儲于Hive表。這部分工作，簡單的可基于ETL，復(fù)雜的可基于Spark。產(chǎn)出的特征可供離線訓(xùn)練和線上預(yù)測，本文主要圍繞線上展開。

特征推送：Hive表里的數(shù)據(jù)需要存入KV，以便線上實時使用。這一步，首先要將Hive表里的記錄映射成POJO類（稱為Domain類），然后將其序列化，最后將序列化串存入KV。這部分工作比較單一，基于MapReduce實現(xiàn)。

特征獲取：在線服務(wù)根據(jù)需求，從KV中取出數(shù)據(jù)，并反序列化為Domain對象。

特征加載：針對模型所需特征列表，取得對應(yīng)的Domain對象。這步通過調(diào)用特征獲取實現(xiàn)。

前兩步為離線操作，后兩步為在線操作。特征同步由離線推送和在線獲取共同完成。離線生產(chǎn)流程是一個周期性的Pipeline，目前是以天為周期。

為此，我們設(shè)計了一套通用的框架，基于此框架，只需要簡單的配置和少量代碼開發(fā)，就可以新增一組特征。下文將詳細介紹框架的各個部分。

特征統(tǒng)計

排序模型用到的特征大部分是統(tǒng)計特征。有些特征比較簡單，如商家的月均銷量、商家單均價等，可用ETL統(tǒng)計(GROUP BY + SUM/AVG)；有些特征稍微復(fù)雜，如用戶的品類偏好（在不同品類上的占比）、用戶的下單額分布（不同金額區(qū)段的占比），用ETL就比較繁瑣。針對后一種情況，我們開發(fā)了一套Spark程序來統(tǒng)計。我們發(fā)現(xiàn)，這種統(tǒng)計需求可以規(guī)約成一種范式：針對某些統(tǒng)計對象（用戶、商家）的一些維度（品類、下單額），基于某些度量值（點擊、下單）做統(tǒng)計（比例/總和）。

同一對象，可統(tǒng)計不同維度；同一維度，有不同的度量角度；同一度量角度，有不同的統(tǒng)計方式。如下圖：

圖3 特征統(tǒng)計范式

例如，對于用戶點擊品類偏好、用戶下單品類偏好、用戶下單額分布、用戶下單總額等特征，可做范式分解：

圖4 特征統(tǒng)計范式示例

其中，

• 統(tǒng)計對象、統(tǒng)計維度、度量值對應(yīng)于Hive表中的字段（維度一般來自維度表，度量值一般來自事實表，主要是曝光、點擊、下單）。為了增加靈活性，我們還允許對原始Hive字段做加工，加工后的值作為統(tǒng)計維度、度量值（加工的接口我們分別稱為維度算子和度量算子）。

• 統(tǒng)計量基于度量值做的一些聚合操作，如累加、求均值、拼接、求占比、算分位點（分布）。前兩者輸出一個數(shù)值，后三者輸出形如"Key1:Value1,Key2:Value2"的KeyValue列表。

另外，統(tǒng)計通常是在一定時間窗口內(nèi)進行的，由于不同時期的數(shù)據(jù)價值不同（新數(shù)據(jù)比老數(shù)據(jù)更有價值），我們引入了時間衰減，對老數(shù)據(jù)降權(quán)。

基于以上考慮，整個統(tǒng)計流程可以分解為（基于Spark）：

圖5 特征統(tǒng)計流程

按統(tǒng)計對象字段做聚合（GROUP BY）。統(tǒng)計對象字段由配置給定。對于外賣排序主要為uuid、poi_id。這一步可能會有數(shù)據(jù)傾斜，需要更多優(yōu)化。

計算維度。支持維度算子，可以對原始維度字段做處理，如對金額字段做分段處理，以分段后的金額作為維度。

按統(tǒng)計維度聚合（GROUP BY）。這是在對象聚合的基礎(chǔ)上做的二次聚合。維度字段由配置給定，可以有多個字段，表示交叉特征統(tǒng)計，如不同時段的品類偏好，維度字段為：時段、品類。

時間衰減并累加。衰減各個時間的度量值，并把所有時間的度量值累加，作為加權(quán)后的度量值。時間字段和度量字段由配置給定。時間字段主要為日期，度量字段主要為曝光、點擊、下單。經(jīng)過維度聚合后，度量值都在特定維度值對應(yīng)的記錄集上做累加，每個維度對應(yīng)一個度量值，維度和度量值是一個KeyValue的映射關(guān)系。

計算度量值。度量字段也可以通過度量算子做進一步處理，算子得到的結(jié)果作為度量值。也可以有多個字段，如點擊和曝光字段，配合除法算子，可以得到點擊率作為度量值。

計算統(tǒng)計量。經(jīng)過對象和維度聚合后，對象、維度、度量值建立了二級映射關(guān)系：對象維度度量值，相當于一個二維Map：Map<對象, Map<維度, 度量值>>。統(tǒng)計量是對Map<維度, 度量值>做一個聚合操作。每個統(tǒng)計量對應(yīng)輸出Hive表中的一個字段。現(xiàn)在主要支持如下幾種算子：

• 累加：對該維度的所有度量值求和；

• 求均值：該維度所有取值情況對應(yīng)的度量值的均值；

• 拼接：把Map<維度, 度量值>序列化為"Key1:Value1, Key2:Value2"形式，以便以字符串的形式存儲于一個輸出字段內(nèi)。為了防止序列化串太長，可通過配置設(shè)定只保留度量值最大的top N；

• 求占比：該維度所有取值情況對應(yīng)的度量值占度量值總和的比重，即Map<維度, 度量值/Sum(度量值)>。然后再做拼接輸出；

• 算分位點：有時候想直到某些維度的分布情況，比如用戶下單金額的分布以考察用戶的消費能力。分位點可以作為分布的一種簡單而有效的表示方法。該算子輸出每個分位點的維度值，形如"分位點1:維度值1, 分位點2:維度值2"。此時，度量值只是用來算比值。

維度算子、度量算子、統(tǒng)計算子都可以通過擴展接口的方式實現(xiàn)自定義。

如下是統(tǒng)計用戶點擊品類偏好、用戶下單品類偏好、用戶下單額分布的配置文件和Hive表示例([Toml]^[1]格式)

圖6 特征統(tǒng)計配置示例

相對于ETL，這套Spark統(tǒng)計框架更為簡單清晰，還可以同時統(tǒng)計多個相關(guān)的特征。通過簡單的配置就可以實現(xiàn)特征的統(tǒng)計，開發(fā)量比較小。

特征同步

離線統(tǒng)計得到的特征存儲在Hive表中，出于性能的考慮，不能在線上直接訪問。我們需要把特征從Hive中推送到更為高效的KV數(shù)據(jù)庫中，線上服務(wù)再從KV中獲取。整個同步過程可以分為如下步驟：

圖7 特征推送流程

ORM：將Hive表中的每行記錄映射為Domain對象（類似于[Hibernate]^[2]的功能）

序列化：將Domain對象序列化，然后存儲到KV中。一個Domain類包含一組相關(guān)的、可同時在一個任務(wù)中統(tǒng)計的特征數(shù)據(jù)。每個Domain對象都有一個key值來作為自己唯一的標志—實現(xiàn)key()接口。同時，由于不同類型的Domain都會存儲在一起，我們還需要為每種類型的Domain設(shè)定一個Key值前綴prefix以示區(qū)別。因此，KV中的Key是Domain.prefix + Domain.key，Value是序列化串。我們支持json和protostuff兩種序列化方式。

反序列化：在線服務(wù)根據(jù)key和Domain.prefix從KV中得到序列化串，并反序列化為Domain對象。

前兩步為離線操作，第三步為在線操作（在預(yù)測代碼中被調(diào)用）。

我們針對Hive開發(fā)了一套ORM庫（見圖8），主要基于Java反射，除了支持基本類型(int/long/float/double/String等)，還支持POJO類型和集合類型(List/Map)。因為ETL不支持json拼接，為了兼容基于ETL統(tǒng)計的特征數(shù)據(jù)，我們的POJO以及集合類型是基于自定義的規(guī)范做編解碼。針對Spark統(tǒng)計的特征數(shù)據(jù)，后續(xù)我們可以支持json格式的編解碼。

圖8 Hive ORM示意

特征序列化和反序列我們統(tǒng)一封裝為通用的KvService：負責(zé)序列化與反序列，以及讀寫KV。如下圖：

圖9 KvService

對于新特征，只需要定義一個Domain類，并實現(xiàn)接口key()即可，KvService自動完成Key值的拼接（以Domain的類名作為Key的prefix），序列化和反序列化，讀寫KV。

我們通過周期性的離線MapReduce任務(wù)，讀取Hive表的記錄，并調(diào)用KvService的put接口，將特征數(shù)據(jù)推送到KV中。由于KvService能夠統(tǒng)一處理各種Domain類型，MapReduce任務(wù)也是通用的，無需為每個特征單獨開發(fā)。

對于特征同步，只需要開發(fā)Domain類，并做少量配置，開發(fā)量也很小。目前，我們?yōu)榱舜a的可讀性，采用Domain這種強類型的方式來定義特征，如果可以弱化這種需求的話，還可以做更多的框架優(yōu)化，省去Domain類開發(fā)這部分工作。

特征加載

通過前面幾步，我們已經(jīng)準備好特征數(shù)據(jù)，并存儲于KV中。線上有諸多模型在運行，不同模型需要不同的特征數(shù)據(jù)。特征加載這一步主要解決怎么高效便捷地為模型提供相應(yīng)的特征數(shù)據(jù)。

離線得到的只是一些原始特征，在線還可能需要基于原始特征做更多的處理，得到高階特征。比如離線得到了商家和用戶的下單金額分布，在線我們可能需要基于這兩個分布計算一個匹配度，以表征該商家是否在用戶消費能力的承受范圍之內(nèi)。

我們把在線特征抽象為一個特征算子：FeatureOperator。類似的，一個特征算子包含了一組相關(guān)的在線特征，且可能依賴一組相關(guān)的離線特征。它除了封裝了在線特征的計算過程，還通過兩個Java Annotation聲明該特征算子產(chǎn)出的特征清單(@Features)和所需要的數(shù)據(jù)清單(@Fetchers)。所有的數(shù)據(jù)獲取都是由DataFetcher調(diào)用KvService的get接口實現(xiàn)，拿到的Domain對象統(tǒng)一存儲在DataPortal對象中以便后續(xù)使用。

服務(wù)啟動時，會自動掃描所有的FeatureOperator的Annotation（@Features、@Fetchers），拿到對應(yīng)的特征清單和數(shù)據(jù)清單，從而建立起映射關(guān)系：FeatureFeatureOperatorDataFetcher。而每個模型通過配置文件給定其所需要的特征清單，這樣就建立起模型到特征的映射關(guān)系（如圖9）：

Model → Feature → FeatureOperator → DataFetcher

不同的在線特征可能會依賴相同的離線特征，也就是FeatureOperatorDataFetcher是多對多的關(guān)系。為了避免重復(fù)從KV讀取相同的數(shù)據(jù)以造成性能浪費，離線特征的獲取和在線特征的抽取被劃分成兩步：先匯總所有離線特征需求，統(tǒng)一獲取離線特征；得到離線特征后，再進行在線特征的抽取。這樣，我們也可以在離線特征加載階段采用并發(fā)以減少網(wǎng)絡(luò)IO延時。整個流程如圖10所示：

圖10 模型和特征數(shù)據(jù)的映射關(guān)系



圖11 特征加載流程

對于新特征，我們需要實現(xiàn)對應(yīng)的FeatureOperator、DataFetcher。DataFetcher主要封裝了Domain和DataPortal的關(guān)系。類似的，如果我們不需要以強類型的方式來保證代碼的業(yè)務(wù)可讀性，也可以通過優(yōu)化框架省去DataFetcher和DataPortal的定制開發(fā)。

總結(jié)

我們在合理抽象特征生產(chǎn)過程的各個環(huán)節(jié)后，設(shè)計了一套較為通用的框架，只需要少量的代碼開發(fā)（主要是自定義一些算子）以及一些配置，就可以很方便地生產(chǎn)一組特征，有效地提高了策略迭代效率。

總結(jié)

以上是生活随笔為你收集整理的外卖排序系统特征生产框架的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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