一、特征生產

特征生產在推薦廣告、風控、記憶學習等領域都有廣泛的應用，特征平臺的特征生產功能是要降低特征工程的復雜度，將特征工程中常見的功能固定下來，通過配置的方式實現特征生產。后續還會推出支持跨平臺功能，比如同一套特征定義可以在 MaxCompute、Flink 等多個平臺運行，盡可能減少用戶的工作量，提升一致性。

1. 特征平臺介紹

特征生產是特征平臺的一個子功能，特征平臺 FeatureStore 是阿里云 PAI 平臺下的特征管理工具和共享平臺，用于組織、存儲和管理機器學習及訓練中使用的特征數據，通過特征平臺可以方便地向多人、多團隊共享特征，保證離在線的一致性，提供高效的特征訪問。

如上圖所示是特征平臺的整體鏈路，特征平臺包含在線和離線兩條鏈路，離線鏈路可以注冊實體、注冊特征視圖、存儲某個具體的特征，可以和具體的表關聯起來；注冊完特征視圖之后，可以構建模型，訓練模型；在訓練之前，可以用特征生產的功能來生成更豐富的特征，訓練完后可以導出模型，把模型部署到線上服務，就可以進行推理模型。線上推理時 user 側的實時特征可以放在在線的存儲引擎，目前平臺支持的存儲引擎主要包括 Hologres、OTS、GraphCompute，還有自建的存儲引擎 FeatureDB。還可以支持 item 側的實時特征，item 側的特征如果是離線特征可以放到服務內存里，取特征更快，基本上在幾毫秒之內就可以完成，而實時特征可以通過輪詢的方式取，比如可以從 feature DB 每隔固定幾秒輪詢到內存里面，這樣不會對在線服務造成很大的壓力；整個鏈路是收到請求之后讀取用戶特征，然后打分。

特征平臺除了支持離線鏈路，還支持實時鏈路，比如從消息隊列 DataHub，接到 Flink 計算,做特征的統計和計算等特征工程，然后寫到在線存儲引擎（Hologres、OTS、GraphCompute，FeatureDB 等）里面，這是在線的鏈路。離線鏈路可以通過大數據平臺 MaxCompute 來存儲數據，同時可以把數據表同步到在線存儲引擎里。特征平臺也提供了很多的 SDK，有 Go、C + +、Java，Python 的 SDK。Java、Go 的 SDK 在 GitHub 是開源的可以直接獲取到。Python SDK 可以做數據分析，比如讀特征、特征提取、特征生產等，特征生產是 Feature Store Python SDK 里面支持的功能。

上圖所示是特征平臺的頁面，目前已經在人工智能 PAI 產品頁面下開放，特征平臺包含幾個頁面：特征實體、特征視圖、label 表，模型特征、任務中心。比如在推薦系統中，特征實體是 user 和 item 側的特征，可以注冊為 user 和 item。特征視圖包含離線特征視圖、在線特征視圖、實時特征視圖、序列特征視圖，可以根據不同的功能來管理特征。Label 表是訓練時指定的 label。模型特征可以指定構建樣本表的特征，在線和離線只需要指定模型特征，就可以自動分析出你要使用的特征，進行特征的加載，不需要指定需要用多少張特征表，比如你用了 10 張特征表，只需要指定一個模型特征，就可以自動分析出特征表中你要使用的特征。任務中心包括數據同步，從離線同步到在線，可以保證特征一致性，還有樣本表的導出，比如訓練的時候，我們使用樣本來訓練，構建樣本表的過程任務可以自動完成，比如涉及離線表的 join，序列表的 join，還有實時表的 join。

2. 特征生產

為什么需要特征生產？

• 捕捉時間趨勢，比如在用戶行為數據中，最近一段時間的行為可能對當前的狀態有比較大的影響，用戶最近幾天的點擊率可能比一個月之前的點擊率更能反映當前的興趣偏好。
• 降低噪音。原始數據中可能包含大量的噪音，我們通過統計變換，或者聚合操作可以減少噪音的影響。比如簡單的點擊次數可能受廣告位的隨機影響比較大，但是一段時間內的平均點擊率則更穩定。
• 豐富特征。通過特征工程可以生成新的特征，增強模型的表達能力。比如除了閱讀數特征，還可以引入閱讀增長率、平均閱讀時長，為模型提供更多的信息，可以讓模型更好地擬合標簽。
• 提高模型性能。通過引入一些統計特征，可以顯著提高模型的預測性能，因為這些特征更穩定，在多天或更長的窗口上進行統計特征，更能準確地反映潛在的模式。
• 增強解釋性。統計特征更加易于解釋和理解，使得問題的診斷和分析更為方便，比如可通過查看一些長期和短期的統計數據推斷某些行為的變化趨勢和原因。
• 數據壓縮。在某些情況下，統計特征可以有效地減少數據的維度，比如用過去一年的平均值代替每日的數據，從而簡化模型的復雜度。

面對不同的大數據平臺，通常會根據不同大數據平臺的文檔，去寫特征生產的語句，然后執行不同的特征生產邏輯。

但是如果換一個大數據平臺，又要根據另外一個大數據平臺來寫特征生產語句，難以復用，這就會帶來一些問題：

• 特征生產的實現過程比較復雜，有可能每實現一步，就要進行一些校驗，然后判斷邏輯實現是否正確，還需要寫一些冗長的語句，會耗費較多時間。
• 計算過程難以優化，需要對大數據平臺進行比較深入的了解，閱讀文檔，需要使用哪些關鍵字、哪些功能，也是非常耗時的。
• 線上線下不一致現象頻出，在推薦廣告、風控或者其它一些場景中都經常出現。

我們做特征生產功能，就是為了解決上述問題，實現以下功能：

• 同一套特征生產定義。
• 根據定義生產出各種特征。
• 特征生產出來是一個執行過程，支持本地進行調試，也適配各個大數據平臺運行，如果從大數據平臺 a 切換到 b 大數據平臺，不需要整個的定義過程，只需要改其中的某個參數，指定大數據平臺就可以。比如從 MaxCompute，到 Flink，特征生產定義都是同一套，可以在多個平臺運行，還包括 Spark。
• 保證在線和離線的一致性。
• 優化計算過程，節省計算資源。通過引入中間表，做中間結果的存儲可以極大地節省計算時間。如果在大數據平臺訓練，其計算也會節省一些費用，計算時間也會更短。
• 統計特征的實時更新。

上圖所示是特征生產的整體鏈路，開始是特征定義的部分，針對不同的大數據平臺可以有相同的定義，就可以不用因為切換大數據平臺而修改特征定義，便于各個平臺的移植，特征定義完成之后有編譯的過程，根據指定的不同的大數據平臺進行分別的編譯，編譯完之后的執行過程就可以在對應的大數據平臺上運行。

特征定義對于新手比較友好。如果熟悉 Python 的話，有 Python 的定義方式，比較簡單直接；還支持 JSON 的定義。Python 定義會轉成自動 JSON 的定義，通過唯一的輸入，就能有一個固定的輸出，不受各個平臺的限制也不受語言的限制。

上圖所示左邊是 Python 的特征定義，比如定義 TableTtransform，指定字段表變換的名稱、去重字段和排序字段等，還做 ComboTransform，把兩個特征連接起來。還能對特征做一些處理，比如對 play time 特征除以 10 這些操作都可以在一個特征生產鏈路里面執行。最后會自動生成右邊的 JSON 格式，包含輸入原表，特征處理（表變換、特征變換等）操作，輸出結果表；通過這樣唯一的定義，就可以生成整個的執行過程，在不同的大數據平臺運行。

整個編譯的過程根據不同的平臺來分別實現，我們盡可能針對平臺的特性做對應的優化。平臺 command 命令也放在包里面，用戶就可以指定同一個執行的命令，在不同大數據平臺運行。

上圖所示是連接不同變換的編譯過程，是一個 pipeline 的形式，可以進行表變換、特征變換，可以指定多個表變換，也可以指定很多的特征變換，不同的特征變換之間利用了 SQL 的公域表達式，比如左邊是一個 SQL，看起來很復雜，但轉變成右邊的一個語句的形式，看起來會更簡單直接，在每一個語句實現的時候，只需要關心本身的輸入和變換過程，不需要關心前一個和后一個變化是什么。當這個變換完成之后輸出出來，程序就可以根據本次變換的輸出，和下一個變換的過程，再進行下一個語句的實現，整個過程以流水線的形式來執行，可以定義任意的變換，最后拿到結果。

編譯過程中內部變換優化分為兩個方面：

• 優化用戶使用功能。支持定義多個根據不同的 group key 進行連接, 還有考慮如何讓用戶使用起來更方便等相關優化。
• 優化計算過程。特征的產出需要非常多的時間，通過存儲一些中間表，把中間的結果存儲下來，可以節省資源，提高運行效率。

下面介紹兩個有代表性的優化的例子：AggregationTransform和 WindowTransform。

AggregationTransform,根據某個聚合做統計，比如 user_sum_click_count_3d，計算某個用戶最近三天點擊過所有物品的總點擊數，如上圖所示左邊是一個行為寬表，有請求 ID、用戶 ID、行為、物品 ID、物品歷史總點擊數和時間分區，做近三天點擊數特征聚合統計，得到 u1 用戶 50 次，u2 用戶 50 次，這是 AggregationTransform 的計算內容。

AggregationTransform 實際定義的過程比較復雜，但是用戶只需要通過一個簡單的定義就可以實現復雜的計算,以下是一些功能的優化：

• 支持同窗口的自動歸并，不同窗口自動連接，比如點擊數可能會定義 1 天、3 天、7 天、15 天、30 天、45 天，甚至是 60 天、90 天等長時間窗口的統計。還能定義很多別的特征，比如點贊的統計、評論的統計，使用的過程中可能會做特征變換，在變換的過程中，對于同窗口會自動的歸并,不同窗口會自動地做連接，比如用 left join，把 1 天、3 天、7 天、15 天、30 天等窗口 join 起來。
• 同一個 group key 一起計算，不同的分組關鍵字自動連接，與不同窗口類似，不同的 group key 不需要放在多個 SQL 中實現，只需要放在一個 pipeline 流程里面即可實現自動連接。
• 類型的自動推導。用戶不需要指定輸出類型，會根據輸入特征的類型和聚合函數，做類型的自動推導，極大方便用戶使用的門檻。
  
• 內置自動擴展函數，支持特征變換自動擴展，只需要根據擴展函數輸入要做的特征的一些統計，就能生成成百上千個特征，如上圖左側單個特征示例，單個特征定義比較簡單，指定聚合函數、判斷條件和 group key、窗口，就可以進行單個特征清晰地定義，但是如果要添加多個特征，單個特征地加比較麻煩，就可以用自動擴展函數生成成百上千個特征，比如上圖右側示例指定了要做輸入的一些統計，可以生成 96 個特征，這個函數用戶可以根據自己的場景來進行一些修改，生成出適配自己使用場景的函數。

WindowTransform 用于計算不同實體的交叉統一特征，如上圖示例 user_kv_category_click_sum_3d 是計算用戶最近三天點擊過的不同類目的所有物品的總點擊數，是一個 KV 特征，輸出不同實體的交叉統計特征 map，線上要排序打分需要取到 item 和 user 特征，通過 uid 和 item 類目進行特征查找，比如 u1 和 item 類目 1 取出來就是 30。根據上圖所示的歷史行為寬表去做的匯總統計，得到右邊的 kv 特征表，存儲到在線的存儲引擎里面。線上取特征時，做一個 lookup 查找，根據 k 來查找對應的 value，然后再做模型的推理；如果是離線的話再去做模型的訓練。

WindowTransform 也做了一些功能上和計算過程上的優化，還有一些計算過程的優化：

• 類型自動推導。
• 支持不同的分組關鍵字的自動連接。
  
• 統計不同窗口特征的時候計算量很大，比較浪費計算資源，我們引入了中間臨時表，將每天的計算過程臨時存儲下來，當計算新的一天時，只需要匯總結果即可。這個過程的優化大幅縮短了計算時間，提高計算效率。比如對 n 天的樣本統計，計算完?次后，下?次不需要再重新計算 n 天，只需計算第 n + 1 天，然后匯總。執行的過程還支持第一次執行自動補全中間臨時表數據。
• 內置自動擴展函數，支持特征的自動變換擴展。

WindowTransform 同樣也支持單個特征的定義和自動擴展。

特征生產功能支持很多變換，包括表變換、特征變換、JoinTransform、ComboTransform、CustomTransform、AggregationTransform、WindowTransform。

二、組件化建模

組件化建模是 EasyRec 算法框架的一個新功能，EasyRec 框架是一個訓練框架，已經在 GitHub 開源，它支持 20 多種行業的經典模型，可以和多種數據源對接，支持大規模分布式訓練評估，支持自動超參搜索、知識蒸餾等功能?？蚣芾锇苏倩啬Ｐ汀⑴判蚰Ｐ?，多目標模型，重排模型。這個框架的優勢在于它支持多個平臺，只需要指定一個 config 就可以在各個平臺上運行和訓練模型。支持多種經典模型，如果模型不滿足要求，通過組件化建模就可以根據自己的需求用組件來搭建自己所需模型。并且提供了豐富的組件，常用模型都可以通過組件化的形式像搭積木一樣搭建出來，當組件不滿足要求時，也支持自定義組件。

組件化靈活搭建模型，可以做到所思即所得，通過搭積木的方式來搭建想要的模型結構，組件間無縫銜接，還可以復用組件，做到一次開發就能使用多種模型，通過配置的方式即可生成新的模型。過去開發一個新的公共模塊到現有模型中，需要修改模型的代碼才能用上新特性，過程繁瑣。組件化之后，可以快速地通過配置的方式來搭建新的模型，極大提高了實驗的迭代效率，想法可以得到快速地驗證。

上圖示例是組件化流程示例，有 backbone 網絡和一些 blocks，整體組成一個 DAG 圖。組件化的目標是不需要新的模型，只需要新的組件。新的模型由已有的組件通過拼接形成，各個組件只需要專注于實現自身的功能和單一的任務即可。組件化的 EasyRec 網絡，可以通過一個可配置的主干網絡作為核心部件,主干網絡是由多個模塊組成的一個 DAG 圖構成，輸出到頂部的 MLP 層，然后到最終的預測層。

上圖所示具體的案例是比較常用的模型 Wide&Deep 網絡。主干的網絡由很多 block 組成，圖中左邊是原來的一個示例，更改比較麻煩，中間部分是用組件化升級之后，通過幾個組件來拼接來生成想要的模型，一個 block 輸入可以關聯一個 feature group 或者 keras layer 對象，實現了一個可復用的子模塊網絡。

上圖所示是 DCN 模型的示例，用了一個 recurrent 組件，實現循環調用某個模塊多次的效果,另外還加了一個 MLP 模塊，如果想嘗試其它組件的效果也可以加到這里面。

上圖示例是組件化升級之前實現的 DLRM 模型，模型代碼都是固定的，使用這個模型時只能修改輸入層特征，和一些 DN 層的改變，其它特殊模塊改變不了。

而升級用組件化搭建 DLRM 網絡只需要實現一個 dot block，案例中的 dot block 第一個輸入是一個 Tensor，第二個輸入是一個 list，第一個輸入會插入到 list 當中，形成一個更大的 list 作為 block 輸入。我們還有數值 embedding 組件，效果非常好，也可以很方便地加入模型結構中，組件化具有很強的靈活性和可擴展性。

支持豐富的組件，包括 MLP、Highway、Gate 等可以實際使用體驗其功能，還有一些特征交叉的組件，包括二階交叉、二階內積交叉、雙線性等。

我們還支持一些特征重要度學習的組件，序列特征編碼組件（DIN 和 BST)，多目標學習的組件 MMoE。

當現有組件沒有辦法滿足使用要求的時候，支持自定義組件。自定義組件實現初始化和 call 函數即可。因為代碼是開源的，根據已實現組件可以參考開源代碼是怎么實現的，可以直接模仿開源代碼去實現。

特征平臺的特征?產 Notebook 已在 PAI-DSW Gallery 發布，可以直接運行 Notebook 進行體驗。EasyRec 代碼是開源的，通過上圖 GitHub 地址可以體驗，有問題可以加群溝通交流咨詢。

三、Q&A

Q1：這個特征工程的產品是在云上可以體驗的嗎？

A1：是可以體驗的，在阿里云 PAI-DSW Gallery 已經發布，它是一個 Notebook，只需要 Notebook 就可以實現整個特征變換過程。我們還提供了示例表，模擬真實場景的一些示例，包括行為表、用戶表和物品表，通過這些表可以直接體驗產品功能。另外還提供了最佳實踐的文檔，還可直接加群，群公告里面有相關地址，使用過程當中如果有什么問題都可以在群里提問。

Q2：FeatureStore 的 SDK 和 EasyRecProcessor 的一些集成案例有開放嗎？

A2：FeatureStore SDK 目前是集成在 EasyRec Processor 里面，EasyRec Processor 可以直接在阿里云 ES 上運行，我們有文檔，直接搜索一下 EasyRec Processor，就可以在阿里云上搜到這篇文檔，就可以直接使用了，里面內置了 Feature Store SDK，我們做了非常多的優化，包括存儲優化、取特征優化，還支持了實時特征，只需要指定一些參數就可以運行。

Q3：有一些 transform，只是基線上有，線上沒有，如何知道哪些是線上，哪些是用于離線的？

A3：這是離線和在線特征不一致的問題。如果用特征平臺，注冊的時候特征視圖關聯的是一張表，但是我們會同時在離線和在線引擎里面構建同樣的兩張表，保證離線數據平臺和在線存儲的 schema 是一模一樣的，這樣可以保證一致性。上線過程中取特征只需要指定你的模型特征，就可以從離線和在線拉取特征，我們還會有一致性檢查工具可以排查出來，把在線的特征和離線的特征拿出來，然后做一個特征的對比，最后打分對比，如果打分一致，那就說明在線和離線是一致的，打分不一致的話，我們還會做特征的分析，判斷在線特征和離線特征哪里不一樣，可以通過差別來看哪個地方有問題。

Q4：EasyREC 有拖拽組件的形式給用戶用嗎？

A4：EasyRec目前還沒有拖拽的組件，但是目前 config 配置其實非常方便。直接復制一下樣例就可以跑起來。

Q5：特征量非常大，不論是離線訓練還是在線 serving，特征的生產到使用鏈路挺長的，那在咱們平臺能否看到哪些特征在用，哪些特征不在用等一些血緣關系，在特征治理場景還是比較有強訴求去看到這種信息的，平臺上是怎么去實現這部分功能？

A5：這個是一個非常重要的功能，EasyRec 里面有特征重要度的分析，通過組件進行訓練之后，可以分析出來哪些特征是重要的，哪些特征是不重要的，如果想做特征的裁剪，可以通過這一功能把那些重要的特征保留出來，把不重要的去掉，比如你之前有 1000 多個特征，然后做了特征重要度的分析，發現只需要保留前 200 個就可以，那你保留了前 200 個特征之后，在線上的時候，我們會自動分析你的模型，它用了 200 個特征，那就做這 200 個特征的加載，可以有效地減少特征的冗余。特征重要度和特征有沒有在用都可以分析出來。

Q6：在線存儲引擎里面去做特征抽取，在實際線上 serving 的過程中，它的吞吐和性能如何去優化？因為可能需要拉取大量的特征，從特征引擎里是非常大的傳輸量。

A6：特殊拉取到在線存儲引擎里面分為兩種情況，如果是離線特征，只是天級拉取調度，拉取的過程也非?？?，拉取的過程中，線上數據是可以正常取的，不會影響線上數據。如果是實時特征，毫秒級更新，它整個鏈路就不是從大數據平臺，一般是通過 Flink 實時計算數據流，然后寫入到存儲引擎里面，取的時候我們會通過服務，支持輪詢的方式，通過設置時間間隔來輪詢，如果線上要求非常精準，輪詢的時間可以設得短一點。如果想節省一些成本的話，把輪詢時間設得稍微長一點，這都是可以自動調整的。

Q7：如上所述 EasyREC 里面其實是做了一些特征的一些緩存是嗎?

A7：如果是離線特征的話，我們會直接通過大數據平臺拉到內存里面，不通過存儲引擎，可以給存儲引擎減少很多壓力。存儲引擎目前只存儲了 user 特征和一些實時特征，因為 user 特征非常大，不適合放在內存里面，還有一些實時特征，因為它是要實時去更新，它需要 Flink 往里面寫，靜態的 item 側的特征，可以直接從大數據平臺拉到內存里面。

Q8：如上所述做這種特征緩存的話，其實要做一些時效性上的權衡？

A8：對，是要做時效性的權衡。