首頁 > 科技週邊 > 人工智慧 > VLDB 2023獎項公佈,清華、第四範式、NUS聯合論文獲最佳工業界論文獎

VLDB 2023獎項公佈,清華、第四範式、NUS聯合論文獲最佳工業界論文獎

王林
發布: 2023-09-14 10:01:01
轉載
688 人瀏覽過

VLDB 2023國際會議已在加拿大溫哥華成功舉辦。 VLDB會議是資料庫領域歷史悠久的三大頂尖會議之一,其全稱為國際大型資料庫會議。每屆會議都集中展示了當前資料庫研究的前沿方向、工業界的最新技術以及各國的研發水平,吸引了全球頂尖研究機構的投稿

VLDB 2023奖项公布,清华、第四范式、NUS联合论文获最佳工业界论文奖

該會議對系統創新性、完整性、實驗設計等方面都有極高的要求。 VLDB 的論文接受率整體較低,約18%,只有貢獻很大的論文才有可能被錄用。今年的競爭更加激烈。根據官方數據顯示,今年VLDB 共有9篇論文獲得了最佳論文獎項,其中包括史丹佛大學、卡內基美隆大學、微軟研究院、VMware 研究院、Meta 等全球知名大學、研究機構和科技巨頭的身影

其中由第四範式、清華大學以及新加坡國立大學聯合完成的"FEBench: A Benchmark for Real-Time Relational Data Feature Extraction" 論文,獲得了最佳工業界論文Runner Up 獎項。

VLDB 2023奖项公布,清华、第四范式、NUS联合论文获最佳工业界论文奖

這篇論文是由第四範式、清華大學和新加坡國立大學合作完成的。論文提出了一個基於工業界真實場景累積的即時特徵計算測試基準,用於評估基於機器學習的即時決策系統

VLDB 2023奖项公布,清华、第四范式、NUS联合论文获最佳工业界论文奖

  • 請點擊以下連結查看論文:https://github.com/decis-bench/febench/blob/main/report/febench.pdf

  • ##計畫網址:https://github.com /decis-bench/febench 需要重寫的內容是:專案網址為https://github.com/decis-bench/febench

專案背景

基於人工智慧的決策系統在許多行業場景中已廣泛應用。其中,許多場景涉及基於即時數據的計算,例如金融業的反詐騙和零售業的即時線上推薦。機器學習驅動的即時決策系統通常包括兩個主要計算環節:特徵和模型。由於業務邏輯的多樣性以及線上低延遲和高並發的需求,特徵計算往往成為整個決策系統的瓶頸。因此,需要進行大量的工程實踐來建立一個可用、穩定和高效的即時特徵計算平台。下圖1展示了一個常見的反詐騙應用程式的即時特徵計算場景。透過基於原始的刷卡流水記錄表格進行特徵計算,產生新的特徵(例如最近10秒內的最大/最小/平均刷卡金額等特徵),然後將其輸入到下游模型進行即時推理

VLDB 2023奖项公布,清华、第四范式、NUS联合论文获最佳工业界论文奖

重寫後的內容:圖1. 即時特徵運算在反詐騙應用程式中的應用程式

一般而言,即時特徵運算平台需要滿足以下兩個基本要求:

  • 線上線下一致性:由於機器學習應用一般會分為線上和線上兩個流程,即基於歷史資料的訓練和基於即時數據的推理。因此確保線上線下的特徵計算邏輯一致性,對於確保線上線下最終業務效果一致至關重要。

  • 線上服務的高效率:線上服務針對即時資料和運算,滿足低延遲、高並發、高可用等需求。

VLDB 2023奖项公布,清华、第四范式、NUS联合论文获最佳工业界论文奖

圖2. 即時特徵計算平台架構及工作流程

如上圖2 列舉了一個常見的即時特徵計算平台的架構。簡單來說主要包含了離線計算引擎和線上計算引擎,其中的關鍵點是確保離線和線上計算引擎的計算邏輯一致性。目前市面上有許多特徵平台可以滿足上述要求,構成一個完整的即時特徵運算平台,包括通用系統如 Flink,或專用系統如 OpenMLDB、Tecton、Feast 等。但是,目前工業界缺少一個面向即時特徵的專用基準來對這類系統的性能進行嚴謹科學的評估。針對該需求,本論文作者建構了 FEBench,一個即時特徵計算基準測試,用於評估特徵計算平台的性能,分析系統的整體延遲、長尾延遲和並發性能等。

技術原理

FEBench 的基準建構主要包括三個方面的工作:資料集收集、查詢產生的內容需要進行改寫和重寫內容時,需要選擇適當的模板

資料集蒐集

研究團隊總共收集了118 個可以用於即時特徵計算場景的資料集,這些資料集來自Kaggle,Tianchi,UCI ML,KiltHub 等公開數據網站以及第四範式內部可公開數據,涵蓋了工業界的典型使用場景,如金融、零售、醫療、製造、交通等行業場景。研究小組進一步依照表格數量及資料集大小將收集到的資料集進行了歸類,如下圖 3 所示。

VLDB 2023奖项公布,清华、第四范式、NUS联合论文获最佳工业界论文奖

重寫內容:FEBench中資料集的表格數量和資料集大小的圖表如下:

##查詢產生的內容需要進行改寫

由於資料集數量較大,為每一個資料集人工產生特徵抽取的計算邏輯工作量十分巨大,因此研究人員利用瞭如AutoCross(參考論文: AutoCross: Automatic Feature Crossing for Tabular Data in Real-World Applications) 等自動機器學習技術,來為收集到的資料集自動化產生查詢。 FEBench 的特徵選擇和查詢產生的內容需要進行改寫過程包括以下四個步驟(如下圖4 所示):

  • 透過識別資料集中的主表(儲存串流數據)和輔助表(例如靜態/ 可追加/ 快照表),進行初始化。隨後,分析主表和輔助表中具有相似名稱或鍵關係的列,並枚舉列之間的一對一 / 一對多關係,這些關係對應不同的特徵操作模式。

  • 將列關係對應到特徵運算子。

  • 在提取所有候選特徵後,利用 Beam 搜尋演算法迭代生成有效的特徵集。

  • 選擇的特徵被轉換為語意上等效的 SQL 查詢。

VLDB 2023奖项公布,清华、第四范式、NUS联合论文获最佳工业界论文奖

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

重寫內容時,需要選擇適當的模板

在產生每個資料集的查詢後,研究人員進一步使用聚類演算法來選擇代表性的查詢作為查詢模板,以減少對相似任務的重複測試。針對收集到的118個資料集和特徵查詢,使用DBSCAN演算法對這些查詢進行聚類,具體步驟如下:

  • 將每個查詢的特徵劃分為五個部分:輸出列數、查詢運算子總數、複雜運算子的出現頻率、巢狀子查詢層數以及時間視窗中最大元組的數量。由於特徵工程查詢通常涉及時間窗口,查詢複雜性不受批次資料規模的影響,因此資料集大小沒有作為聚類特徵之一。

  • 使用邏輯迴歸模型來評估查詢特徵與查詢執行特性之間的關係,將特徵作為模型的輸入,將特徵查詢的執行時間作為模型的輸出。透過使用每個特徵的迴歸權重作為其聚類權重,來考慮不同特徵對聚類結果的重要性

  • 基於加權查詢特徵,使用DBSCAN 演算法將特徵查詢劃分為多個聚類。

以下圖表顯示了118個資料集在各個考量指標下的分佈。圖(a)顯示了統計性質的指標,包括輸出列數、查詢操作符總數和嵌套子查詢層數;圖(b)顯示了與查詢執行時間相關性最高的指標,包括聚合操作個數、嵌套子查詢層數與時間視窗個數

VLDB 2023奖项公布,清华、第四范式、NUS联合论文获最佳工业界论文奖

圖5. 118 個特徵查詢透過聚類分析得到6 個集群,產生查詢模板(Q0 -5)

最終,根據聚類結果,將118 個特徵查詢分為6 個集群。對於每個集群,選擇質心附近的查詢作為候選模板。此外,考慮到不同應用場景下的人工智慧應用可能有不同的特徵工程需求,圍繞每個叢集的質心,嘗試選擇來自不同場景的查詢,以更好地覆蓋不同的特徵工程場景。最終,從 118 個特徵查詢中選擇了 6 個查詢模板,適用於不同場景,包括交通、醫療保健、能源、銷售,以及金融交易。這 6 個查詢模板最終構成了 FEBench 最為核心的資料集和查詢,用於進行即時特徵計算平台的效能測試。

#需要重寫的內容是:基準評測(OpenMLDB與Flink)

在研究中,研究人員使用了FEBench來測試兩個典型的工業界系統,分別是Flink和OpenMLDB。 Flink是一個通用的批次和流處理一致性計算平台,而OpenMLDB則是一個專用的即時特徵計算平台。透過測試和分析,研究人員發現了這兩個系統各自的優缺點以及背後的原因。實驗結果顯示,由於架構設計的不同,Flink和OpenMLDB在效能上有差異。同時,這也說明了FEBench在分析目標系統能力上的重要性。總結來說,研究的主要結論如下

  • Flink 比 OpenMLDB 在延遲上慢兩個數量級(圖 6)。研究人員分析,其造成差距的主要原因在於兩者係統架構的不同實現方式,其中OpenMLDB 作為實時特徵計算的專用系統,包含了基於內存的雙層跳表等專門針對時序數據優化的數據結構,最終相比較於Flink,在特徵計算場景上有明顯的效能優勢。當然 Flink 作為一個通用系統,在可適用場景上比 OpenMLDB 更為廣泛。

VLDB 2023奖项公布,清华、第四范式、NUS联合论文获最佳工业界论文奖

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

  • OpenMLDB 表現出明顯的長尾延遲問題,而Flink 的尾延遲更穩定(圖7)。請注意,以下數字顯示均為歸一化到 OpenMLDB 和 Flink 各自的 TP-50 下的延遲效能,並不代表絕對效能的比較。 重寫為:OpenMLDB 在尾延遲方面有明顯的問題,而 Flink 的尾延遲更穩定(見圖7)。要注意的是,下面的數字是將延遲效能歸一化到OpenMLDB 和Flink 分別在TP-50 下的效能,而不是絕對效能的比較

VLDB 2023奖项公布,清华、第四范式、NUS联合论文获最佳工业界论文奖

VLDB 2023奖项公布,清华、第四范式、NUS联合论文获最佳工业界论文奖

  • #圖7. OpenMLDB 與Flink 的尾延遲比較(歸一化到各自的TP-50 延遲)

  • 研究人員對上述效能結果進行了更深入的分析:

VLDB 2023奖项公布,清华、第四范式、NUS联合论文获最佳工业界论文奖

根據執行時間進行拆解分析,微架構指標包括指令完成、錯誤分支預測、後端依賴和前端相依性等。不同查詢模板在微觀結構層面的效能瓶頸有所不同。如圖8所示,Q0-Q2的效能瓶頸主要在前端依賴,佔整個運作時間的45%以上。在這種情況下,執行的操作相對簡單,大部分時間花在處理使用者請求和特徵提取指令的切換。而對於Q3-Q5,後端依賴(如快取失效)和指令運作(包含更多複雜指令)成為更主要的因素。 OpenMLDB透過針對性最佳化使其在效能上更加出色

  • #圖8展示了OpenMLDB與Flink的微架構指標分析

  • 執行計畫分析:以Q0 為例,下圖9 比較了Flink 和OpenMLDB 的執行計畫差異。 Flink 中的計算運算子花費最多的時間,而 OpenMLDB 透過最佳化視窗處理和使用自訂聚合函數等最佳化技術減少了執行延遲。

### 第九張圖展示了OpenMLDB和Flink在執行計畫(Q0)的對比######## #如果使用者期望復現以上實驗結果,或在本地系統上進行基準測試(論文作者也鼓勵將測試結果在社區提交共享),可以訪問FEBench 的專案主頁,獲得更多資訊。 ############FEBench 專案:https://github.com/decis-bench/febench############Flink 專案:https://github.com /apache/flink############OpenMLDB 專案:https://github.com/4paradigm/OpenMLDB#########

以上是VLDB 2023獎項公佈,清華、第四範式、NUS聯合論文獲最佳工業界論文獎的詳細內容。更多資訊請關注PHP中文網其他相關文章!

相關標籤:
來源:jiqizhixin.com
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
最新問題
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板