數(shù)據(jù)庫領(lǐng)域的國際頂級學(xué)術(shù)會議 VLDB 2023 在加拿大溫哥華落幕。VLDB 會議全稱 International Conference on Very Large Data Bases，是數(shù)據(jù)庫領(lǐng)域歷史悠久的三大頂級會議 (SIGMOD、VLDB、ICDE) 之一，每屆會議集中展示了當(dāng)前數(shù)據(jù)庫研究的前沿方向、工業(yè)界的最新技術(shù)和各國的研發(fā)水平，吸引了全球頂級研究機構(gòu)投稿。

該會議對系統(tǒng)創(chuàng)新性、完整性、實驗設(shè)計等方面都要求極高，VLDB 的論文接受率總體較低（約 18%），必須是貢獻很大的論文才有機會被錄用。今年的競爭更為激烈。據(jù)官方顯示，今年 VLDB 共有 9 篇論文脫穎而出，獲得了最佳論文獎項，其中不乏斯坦福、CMU、微軟研究院、VMware 研究院、Meta 等全球知名高校、研究機構(gòu)、科技巨頭的身影。

其中由第四范式、清華大學(xué)以及新加坡國立大學(xué)聯(lián)合完成的 "FEBench: A Benchmark for Real-Time Relational Data Feature Extraction" 論文，獲得了最佳工業(yè)界論文 Runner Up 獎項。

該論文由第四范式、清華大學(xué)以及新加坡國立大學(xué)合作完成，提出了一個基于工業(yè)界真實場景積累的實時特征計算測試基準(zhǔn)，用于評測基于機器學(xué)習(xí)的實時決策系統(tǒng)。

• 論文地址：https://github.com/decis-bench/febench/blob/main/report/febench.pdf
• 項目地址：https://github.com/decis-bench/febench

項目背景

基于人工智能的決策系統(tǒng)目前已經(jīng)在很多行業(yè)場景實現(xiàn)了廣泛的應(yīng)用，其中大量的場景涉及到基于實時數(shù)據(jù)的計算，比如金融行業(yè)的反欺詐、零售行業(yè)的實時線上推薦等場景。機器學(xué)習(xí)驅(qū)動的實時決策系統(tǒng)一般會包含兩個最主要的計算環(huán)節(jié)，即特征和模型。其中，由于業(yè)務(wù)邏輯的多樣化和線上的低延遲、高并發(fā)的需求，特征計算往往成為整個決策系統(tǒng)的瓶頸，需要大量的工程化實踐來構(gòu)建一個生產(chǎn)環(huán)境可用、穩(wěn)定高效的實時特征計算平臺。如下圖 1 列舉了一個常見的反欺詐應(yīng)用的實時特征計算場景。基于原始的刷卡流水記錄表格進行特征計算，生成新的特征（包含如最近 10 秒內(nèi)最大 / 最小 / 平均刷卡金額等特征），進一步輸入下游模型，進行實時推理。

圖 1. 反欺詐應(yīng)用中的實時特征計算

一般來說，實時特征計算平臺需要滿足如下兩個基本要求：

• 線上線下一致性：由于機器學(xué)習(xí)應(yīng)用一般會分為線上和線上兩個流程，即基于歷史數(shù)據(jù)的訓(xùn)練和基于實時數(shù)據(jù)的推理。因此確保線上線下的特征計算邏輯一致性，對于保證線上線下最終業(yè)務(wù)效果一致至關(guān)重要。
• 線上服務(wù)的高效性：線上服務(wù)針對實時數(shù)據(jù)和計算，滿足低延遲、高并發(fā)、高可用等需求。

圖 2. 實時特征計算平臺架構(gòu)及工作流程

如上圖 2 列舉了一個常見的實時特征計算平臺的架構(gòu)。簡單來說主要包含了離線計算引擎和在線計算引擎，其中的關(guān)鍵點是保證離線和在線計算引擎的計算邏輯一致性。目前市面上有許多特征平臺可以滿足上述要求，構(gòu)成一個完整的實時特征計算平臺，包括通用系統(tǒng)如 Flink，或者專用系統(tǒng)如 OpenMLDB、Tecton、Feast 等。但是，目前工業(yè)界缺少一個面向?qū)崟r特征的專用基準(zhǔn)來對這類系統(tǒng)的性能進行嚴(yán)謹(jǐn)科學(xué)的評估。針對該需求，本篇論文作者構(gòu)建了 FEBench，一個實時特征計算基準(zhǔn)測試，用于評估特征計算平臺的性能，分析系統(tǒng)的整體延遲、長尾延遲和并發(fā)性能等。

技術(shù)原理

FEBench 基準(zhǔn)的構(gòu)建主要包含三部分工作：數(shù)據(jù)集搜集、查詢生成、以及模板選擇。

數(shù)據(jù)集搜集

研究團隊總共收集了 118 個可以用于實時特征計算場景的數(shù)據(jù)集，這些數(shù)據(jù)集來自 Kaggle，Tianchi，UCI ML，KiltHub 等公開數(shù)據(jù)網(wǎng)站以及第四范式內(nèi)部可公開數(shù)據(jù)，覆蓋了工業(yè)界的典型使用場景，如金融、零售、醫(yī)療、制造、交通等行業(yè)場景。研究小組進一步按照表格數(shù)量及數(shù)據(jù)集大小將收集到的數(shù)據(jù)集進行了歸類，如下圖 3 所示。

圖 3. FEBench 中數(shù)據(jù)集的表格數(shù)量及數(shù)據(jù)集大小

查詢生成

由于數(shù)據(jù)集數(shù)量較大，為每一個數(shù)據(jù)集人工生成特征抽取的計算邏輯工作量十分巨大，因此研究人員利用了如 AutoCross（參考論文：AutoCross: Automatic Feature Crossing for Tabular Data in Real-World Applications） 等自動機器學(xué)習(xí)技術(shù)，來為收集到的數(shù)據(jù)集自動化生成查詢。FEBench 的特征選擇和查詢生成過程包括以下四個步驟（如下圖 4 所示）：

• 通過識別數(shù)據(jù)集中的主表（存儲流式數(shù)據(jù)）和輔助表（例如靜態(tài) / 可追加 / 快照表），進行初始化。隨后，分析主表和輔助表中具有相似名稱或鍵關(guān)系的列，并枚舉列之間的一對一 / 一對多關(guān)系，這些關(guān)系對應(yīng)不同的特征操作模式。
• 將列關(guān)系映射到特征操作符。
• 在提取所有候選特征后，利用 Beam 搜索算法迭代生成有效的特征集。
• 選擇的特征被轉(zhuǎn)換為語義上等效的 SQL 查詢。

圖 4. FEBench 中查詢的生成流程

模板選擇

在為每一個數(shù)據(jù)集生成查詢以后，研究人員進一步使用聚類算法選取代表性的查詢作為查詢模板，來減少對相似任務(wù)的冗余測試。對于收集到的 118 個數(shù)據(jù)集和特征查詢，采用 DBSCAN 對這些查詢進行聚類，步驟如下：

• 將每個查詢的特征劃分為五個部分：輸出列數(shù)、查詢操作符總數(shù)、復(fù)雜運算符的出現(xiàn)頻率、嵌套子查詢層數(shù)以及時間窗口中最大元組的數(shù)量。由于特征工程查詢通常涉及時間窗口，查詢復(fù)雜性不受批處理數(shù)據(jù)規(guī)模的影響，因此數(shù)據(jù)集大小沒有作為聚類特征之一。
• 使用邏輯回歸模型評估查詢特征與查詢執(zhí)行特性的關(guān)系，特征作為模型輸入，特征查詢的執(zhí)行時間為模型輸出。使用每個特征的回歸權(quán)重作為其聚類權(quán)重，以考慮不同特征對聚類結(jié)果的重要性。
• 基于加權(quán)查詢特征，使用 DBSCAN 算法將特征查詢劃分為多個聚類。

如下圖 5 可視化了 118 個數(shù)據(jù)集在各個考量指標(biāo)下的分布。其中圖（a）展示了統(tǒng)計性質(zhì)的指標(biāo)，包括輸出列數(shù)，查詢操作符總數(shù)和嵌套子查詢層數(shù)；圖（b）展示了與查詢執(zhí)行時間相關(guān)性最高的指標(biāo)，包括聚合操作個數(shù)，嵌套子查詢層數(shù)和時間窗口個數(shù)。

圖 5. 118 個特征查詢通過聚類分析得到 6 個集群，生成查詢模板（Q0-5）

最終，根據(jù)聚類結(jié)果，將 118 個特征查詢分為 6 個集群。對于每個集群，選擇質(zhì)心附近的查詢作為候選模板。此外，考慮到不同應(yīng)用場景下的人工智能應(yīng)用可能有不同的特征工程需求，圍繞每個集群的質(zhì)心，嘗試選擇來自不同場景的查詢，以更好地覆蓋不同的特征工程場景。最終，從 118 個特征查詢中選擇了 6 個查詢模板，適用于不同場景，包括交通、醫(yī)療保健、能源、銷售，以及金融交易。這 6 個查詢模板最終構(gòu)成了 FEBench 最為核心的數(shù)據(jù)集和查詢，用于進行實時特征計算平臺的性能測試。

基準(zhǔn)評測（ OpenMLDB vs Flink）

研究人員在兩個典型的工業(yè)界系統(tǒng) Flink（通用的批處理和流處理一致性計算平臺）及 OpenMLDB（專用實時特征計算平臺）上部署了 FEBench 進行測試，并分析了兩個系統(tǒng)各自的優(yōu)缺點以及背后的原因。實驗展示了 Flink 和 OpenMLDB 由于架構(gòu)設(shè)計不同帶來的性能差異，并由此說明了 FEBench 分析目標(biāo)系統(tǒng)的能力。其評測的主要結(jié)論如下。

• Flink 比 OpenMLDB 在延遲上慢兩個數(shù)量級（圖 6）。研究人員分析，其造成差距的主要原因在于兩者系統(tǒng)架構(gòu)的不同實現(xiàn)方式，其中 OpenMLDB 作為實時特征計算的專用系統(tǒng)，包含了基于內(nèi)存的雙層跳表等專門針對時序數(shù)據(jù)優(yōu)化的數(shù)據(jù)結(jié)構(gòu)，最終相比較于 Flink，在特征計算場景上有明顯的性能優(yōu)勢。當(dāng)然 Flink 作為通用系統(tǒng)，在可適用場景上比 OpenMLDB 更為廣泛。

圖 6. OpenMLDB 與 Flink 的 TP-50 延遲對比

• OpenMLDB 表現(xiàn)出明顯的長尾延遲問題，而 Flink 的尾延遲更穩(wěn)定（圖 7）。注意，以下數(shù)字顯示均為歸一化到 OpenMLDB 和 Flink 各自的 TP-50 下的延遲性能，并不代表絕對性能的比較。

圖 7. OpenMLDB 與 Flink 的尾延遲對比（歸一化到各自的 TP-50 延遲）

研究人員對上述的性能結(jié)果進行了進一步的深入分析：

• 微架構(gòu)指標(biāo)分析：根據(jù)執(zhí)行時間進行拆解分析，包括指令完成、錯誤分支預(yù)測、后端依賴和前端依賴等指標(biāo)。不同查詢模板的性能瓶頸在微觀結(jié)構(gòu)層面上有所不同。如下圖 8 所示，Q0-Q2 的性能瓶頸主要在前端依賴，占整個運行時間的 45% 以上，這種情況下執(zhí)行的操作相對簡單，大部分時間花在處理用戶請求和特征提取指令的切換上面。而對于 Q3-Q5，后端依賴（緩存失效等）和指令運行（更多復(fù)雜指令）成為更主要的因素。OpenMLDB 的針對性優(yōu)化使得它在性能上更加出色。

圖 8. OpenMLDB 與 Flink 的微架構(gòu)指標(biāo)分析

• 執(zhí)行計劃分析：以 Q0 為例，下圖 9 比較了 Flink 和 OpenMLDB 的執(zhí)行計劃差異。Flink 中的計算運算符花費最多的時間，而 OpenMLDB 通過優(yōu)化窗口處理和使用自定義聚合函數(shù)等優(yōu)化技術(shù)減少了執(zhí)行延遲。

圖 9. OpenMLDB 與 Flink 的執(zhí)行計劃（Q0）對比

如果用戶期望復(fù)現(xiàn)以上實驗結(jié)果，或者在本地系統(tǒng)上進行基準(zhǔn)測試（論文作者也鼓勵將測試結(jié)果在社區(qū)提交共享），可以訪問 FEBench 的項目主頁，獲得更多信息。

• FEBench 項目：https://github.com/decis-bench/febench
• Flink 項目：https://github.com/apache/flink
• OpenMLDB 項目：https://github.com/4paradigm/OpenMLDB