作者 | 盧冕，第四正規化開源機器學習資料庫 OpenMLDB PMC core member

譯者 | 王強

策劃 | 劉燕

在機器學習從開發到上線的閉環中，實時特徵計算是其中的重要一環，用於完成資料的實時特徵加工。由於其高時效性需求，資料科學家完成特徵指令碼離線開發以後，往往還需要工程化團隊透過大量的最佳化才能完成上線。另一方面，由於存在離線開發和工程化上線兩個流程，線上線下計算一致性驗證成為一個必要步驟，並且會耗費大量的時間和人力。

本文將從以上兩個痛點出發，描述實時特徵計算系統架構的最佳化目標 - 開發即上線，以及針對此最佳化目標的架構設計原則。最後，將會基於開源實時特徵計算解決方案 OpenMLDB，具體描述其在實踐中的架構設計和最佳化。

1。 背景介紹

1。1 機器學習閉環

今天，機器學習應用已經在各行各業積累了廣泛的應用落地案例。歸納來說，機器學習從開發到上線的全生命週期閉環可以用下圖（Figure-1）概括性描述。

Figure-1： 機器學習閉環

從 Figure-1 可以看到，從橫向維度，機器學習全流程被劃分成

離線開發

和

線上服務

兩個相輔相成的流程。從縱向維度，資訊價值承載的形式會經歷從資料、特徵、再到模型的轉換過程。

資料：原始的資料資訊，比如交易的流水資訊，包含金額、時間、商戶名稱等。

特徵：基於原始資料所生產計算的表達能力更為豐富的資訊，有利於產出後續質量更高的模型，比如某客戶在過去三個月內的消費平均金額等特徵。本文即針對特徵計算的工程化問題詳細展開討論。

模型：透過隱含的上萬甚至上億條基於特徵生成的資料規則，從超高維度上來描述資料本質的規律，包含了基於資料預測行為的能力。今天，對於資料和模型，已經有了充分的討論和事實上的工業界標準處理方式。但是對於特徵，今天工業界還並沒有形成統一的方法論和處理工具。這主要因為，在人工智慧開始應用落地的初期，大家的關注點都在基於深度學習的感知類應用上，此類應用的特徵工程流程相對標準。但今天，決策類場景（如風控、個性化推薦等）在大量企業級應用落地。

對於決策類場景，特徵工程的處理邏輯相對靈活和複雜，因此在這一塊目前尚未形成標準化的方法論和工具。這也正是本文所要聚焦的領域，透過從設計方法論和架構設計實踐的闡述，讓大家深刻理解實時特徵計算系統及其典型使用流程。

1。2 實時特徵計算

本文主要關注具有非常強時效性的實時特徵計算，其查詢計算的端到端延遲一般設定在幾十毫秒的量級。實時特徵的常見計算模式，是當事件發生時，基於從當前時間點往前推移的一個時間點，形成一個時間視窗，進行視窗內的相關聚合計算。

如下圖 Figure-2 列舉了一個典型的風控領域的實時特徵計算場景，其產生了十天、一個小時、五分鐘三個時間視窗，基於視窗進行了不同的聚合計算。

Figure-2： 風控領域的典型實時特徵計算舉例

實時特徵計算今天已經在越來越多的場景中體現出其重要性，其本質在於抓住最新時間段內的資料特徵，為快速決策提供有力支撐。本文主要針對實時特徵計算，來進行相關設計理念和架構的闡述。

2。 線上線下計算一致性架構

2。1。 痛點：兩套開發流程

和線上線下計算一致性校驗

今天，在沒有一套合適的方法論和工具鏈的情況下，如果需要開發上線一套實時特徵計算邏輯，主要包含三個步驟，即離線特徵指令碼開發、線上特徵程式碼重構、以及線上線下計算邏輯一致性校驗。其三者的關係如下圖 Figure-3 所示。

Figure-3： 在缺少合適的工具情況下的實時特徵計算從開發到上線全流程

這三個步驟主要完成的任務以及參與者見下方表格 Table-1。從 Table-1 中可以看到幾個關鍵資訊：

由於資料科學家一般習慣使用 Python 等資料分析工具進行特徵指令碼開發，其開發的模型一般無法符合實時特徵計算的上線需求，如低延遲、高吞吐、高可用等效能和運維指標均無法滿足。

由於資料科學家和工程化團隊是兩個團隊、兩條工具鏈、兩套系統的開發，因此兩套系統之間的計算一致性校驗就變得必不可少而且非常重要。

根據大量工程化落地案例，一致性校驗由於需要牽涉到團隊溝通、需求對齊、反覆測試確認等，其花費的人力成本往往是三個步驟間最高的。

Table 1： 在缺少合適工具情況下的實時特徵計算從開發到上線的主要步驟

造成線上線下計算邏輯不一致的原因有很多種，比如：

工具能力不對等

。現在，Python 是大部分資料科學家的首選工具；相反，工程化團隊一般會首先嚐試使用一些高效能資料庫去翻譯 Python 指令碼。因此兩個工具在表達能力上並不對等。當 SQL 的表達能力無法滿足需求時，就可能會出現計算邏輯上的妥協或者使用 C/C++ 等高效能程式語言去補充相關能力。

需求溝通的認知差

。資料科學家以及工程化團隊對於資料的定義和處理方式的認知可能會不一致。美國的一家線上銀行 Varo Bank 描述了一個他們在沒有合適工具的情況下，實時特徵上線時碰到的一個不一致場景（具體可以參照他們工程化團隊的部落格 Feature Store： Challenges and Considerations）。在上線環境中，工程化團隊很自然的認為“賬戶餘額”的定義應該就是實時的賬戶裡的餘額；但對於資料科學家來說，透過離線的資料去構建“實時賬戶餘額”其實是一件相當複雜的事情，因此資料科學家使用了一個更加簡單的定義，即昨天結束的時候的賬戶的餘額。很明顯，兩者對於賬戶餘額的認知差，直接造成了線上線下計算邏輯的不一致性。線上線下計算邏輯一致性校驗的必要性，以及所需要花費的巨大人力成本，使我們有必要重新審視特徵計算從開發到上線的全流程。需要一套更為合理的生命週期方法論，以及相應的架構設計，來高效支撐今天急速增長的機器學習落地場景數量和規模。

2。2。 目標：開發即上線

我們已經認識到，線上線下計算一致性校驗是整個系統實現和實施的瓶頸。那麼理想中，如果需要改進整體流程，我們期望有一套開發即上線的高效流程。其如下圖 Figure-4 所示。

在此套最佳化過的流程中，資料科學家的指令碼可以即刻部署上線，而不需要再經過二次程式碼重構，也不需要額外的線上線下一致性校驗。如果基於此流程的方法論可以實現，將會極大地提高實時特徵從開發到上線的整體流程，其人力成本也將會從過去的一共 8 人 月大幅縮短到 1 人 月。

Figure-4： 實時特徵計算開發週期的最佳化目標：開發即上線流程

2。3。 技術需求

如果為了達到開發即上線的最佳化目標，同時要保證實時計算的高效能，可以總結出整套架構需要滿足如下的技術需求：

需求一：線上實時特徵計算的低延遲、高併發

。如果我們期望在最佳化後的流程中（Figure-4），資料科學家的指令碼可以直接上線，那麼我們必須要非常小心的處理好線上計算的一系列工程化問題。其最主要的需求是滿足低延遲、高併發的實時計算需求；此外，如可靠性、可擴充套件性、災備、運維等問題亦是在企業生產環境中實際落地需要特別關注的特性。很顯然，如果僅僅依靠資料科學教使用 Python 寫的特徵計算指令碼來直接上線，是不能滿足這些條件的。

需求二：線上線下統一的程式設計介面

。為了降低整體開發到上線的成本，我們期望在對外使用者的視角來看，整個系統需要一個統一的對外程式設計介面，而不是如 Table-1 中所示，對外暴露了兩套不同的程式設計介面。基於統一的程式設計介面，那麼不再需要透過程式碼重構來進行指令碼上線。

需求三：線上線下計算一致性保證

。我們的最佳化目標是不再需要額外的高成本的線上線下一致性校驗。那麼，如何在系統內部保證好線上線下的計算一致性，是必須要解決的問題。

2。4。 抽象架構

Figure-5： 開發即上線的實時特徵平臺的抽象架構

為了滿足在章節 2。3 裡提到的三個技術需求，我們構建出瞭如上 Figure-5 的抽象架構。可以看到，在這個抽象架構圖裡有三大模組，分別對應去解決我們所面臨的的技術挑戰。

以下表格列出了模組的功能要點以及所解決的技術需求。

Table-2： 實時特徵計算平臺架構的核心模組和功能

3。OpenMLDB 的架構設計實踐

基於如上分析的 Figure-5 的抽象架構，以及 Table-2 所列舉的核心模組功能，我們在此介紹一下 OpenMLDB 的架構實踐。

OpenMLDB （https：//github。com/4paradigm/OpenMLDB） 是一款開源機器學習資料庫，主要面向特徵計算場景構建高效解決方案。

OpenMLDB 的架構設計上秉承了 Figure-5 所列的抽象架構，透過基於現有開源軟體最佳化或者自研，來實現具體的功能。其具象化以後的架構如下圖 Figure-6 所示。

Figure-6： OpenMLDB 整體架構

從架構圖 Figure-6 上可以看到，OpenMLDB 有幾個關鍵模組，說明如下：

SQL（+）

：OpenMLDB 對外暴露 SQL 作為統一的使用介面。由於標準 SQL 並沒有對特徵計算相關的操作做最佳化（如時序視窗相關操作），因此其在標準 SQL 的基礎上做了功能擴充套件，支援了更多對於特徵計算友好的語法功能。

一致性執行計劃生成器

：這是保障線上線下計算邏輯一致性的核心模組。裡面主要包含了 SQL 語法樹解析以及基於 LLVM 的執行計劃生成模組。其中，統一的執行計劃生成模組，對於給定的 SQL，可以翻譯成針對線上和線下分別最佳化的不同的執行計劃，但是同時保證兩者的計算一致性。

分散式批處理 SQL 引擎 Spark（+）

：對於面向離線開發的批處理 SQL 引擎，OpenMLDB 基於 Spark 進行了原始碼級別的二次最佳化開發，高效支援 SQL 中對於特徵計算的擴充套件語法。注意，由於批處理引擎實質上並沒有任何資料的儲存需求，所以這裡在邏輯上並不包含一個專用的儲存引擎，只需從離線資料來源上去讀取資料進行計算即可。

分散式時序資料庫：核心的實時計算功能主要由儲存引擎和實時 SQL 引擎這兩個核心模組承載，共同組成了一個分散式的高效能時序資料庫。其中，SQL 引擎為開發團隊自研的基於 C++ 編寫的高效能核心；資料儲存引擎主要為了儲存特徵計算所需要的最新的視窗資料（即 Figure-2 中的物料資料）。注意，此處的時序資料庫有一個數據生存週期的概念（TTL， Time-To-Live），假設我們的特徵計算邏輯只需要最近三個月的資料，那麼超過三個月的舊資料會自動被清除。儲存引擎有兩種選擇：

一是，開發團隊自研的記憶體儲存引擎（built-in）：OpenMLDB 為了最佳化線上處理的延遲和吞吐，預設採用了基於記憶體的儲存方案，構建了雙層跳錶（double-layered skip list）的索引結構。此種資料結構特別適合快速找到某個 key 下面的一個按照時間戳排序的資料。此種記憶體索引結構在時序資料的查詢延遲上可以達到毫秒級別 ［1］，並且效能遠好於商業版的記憶體資料庫；二是，基於 RocksDB 的外存儲存引擎：如果使用者對於效能不太敏感，但是希望降低記憶體用成本，使用者亦可以選擇基於 RocksDB 的外存儲存引擎。透過以上核心元件的串聯，OpenMLDB 可以實現開發即上線的最終最佳化目標。

下圖 Figure-7 總結了 OpenMLDB 從離線開發到部署上線的整體使用流程。對照 Figure-4 所對應的最佳化流程目標，我們可以發現，透過 OpenMLDB，從特徵開發到上線，很好地踐行了開發即上線的核心思想。

Figure-7： OpenMLDB 使用流程

關於 OpenMLDB 的詳細資訊可以參考以下內容：

官網：https：//openmldb。ai/

GitHub： https：//github。com/4paradigm/OpenMLDB

Docs： https：//openmldb。ai/docs/zh/

4。 總結

本文總結了構建實時特徵計算平臺所面臨的工程化挑戰，以及工業界所期望的從離線開發到上線的最佳化目標。基於目標，展開描述了架構設計的方法論和原則。最後介紹了從最佳化目標出發，基於設計方法論實踐的開源解決方案 OpenMLDB 的整體架構。

參考

：

［1］ Cheng Chen， Jun Yang， Mian Lu， Taize Wang， Zhao Zheng， Yuqiang Chen， Wenyuan Dai， Bingsheng He， Weng-Fai Wong， Guoan Wu， Yuping Zhao， and Andy Rudoff。

Optimizing in-memory database engine for AI-powered on-line decision augmentation using persistent memory

。 International Conference on Very Large Data Bases （VLDB） 2021。

開啟App看更多精彩內容