嘉賓：盧冕

整理：墨色

2022年8月6日-7日，??AISummit 全球人工智能技術大會???如期舉辦。在會上，OpenMLDB 研發負責人第四范式系統架構師盧冕帶來了主題演講《開源機器學習數據庫OpenMLDB：線上線下一致的生產級特征平臺》，從人工智能工程化落地的數據和特征挑戰、OpenMLDB線上線下一致的生產級特征計算平臺、OpenMLDB v0.5：性能、成本、易用性增強，三個方面進行了分享。

現將演講內容整理如下，希望對各位有所啟發。

人工智能工程化落地的數據和特征挑戰

如今，據統計，在人工智能落地過程中有95%的時間都是花費在數據上。雖然市面上有諸如MySQL之類各種各樣的數據工具，但它們遠遠沒有解決人工智能落地的難題。因此，先來了解一下數據問題。

如果大家有參與過一些機器學習的應用開發，應該對MLOps印象深刻，如下圖所示：

其實，當下對MLOps并沒有嚴格的學術定義，整體上可將其分成離線開發和線上服務兩個流程。每個流程中信息的載體，從數據、特征，到模型，會經歷三種不同的載體，從離線開發流程一直走到線上服務流程。

接下來我們聚焦中間特征流程這一部分，了解到底是如何解決所面臨的挑戰的。

應用背景：決策類場景基于時序數據的特征工程

人工智能發展到現在主要有兩種應用分類，一類是感知類，比如大家熟悉的人臉識別等都是感知類的AI應用，基本上會基于DNN算法進行。另一類是決策類的AI場景，比如淘寶購物的個性化推薦。此外還有一些像風控場景、反欺詐場景等都是AI在決策類中使用非常廣泛的應用場景。

因此，我們現在講的應用背景主要是針對這種決策類場景，最大的一個特點在于它的數據是一個二維表格的結構化數據，并且還是一個時序數據。如下圖所示，用戶交易表上有一個“trans_time”，代表了每一條記錄所發生的時間點，連起來就是一個時序數據。基于時序數據的特征工程，最常見的一種處理方式就是基于時間窗口的聚合函數。例如針對用戶一天內的交易總額等，這是決策類場景中特征工程常見的操作。

業務場景：滿足生產級上線需求的實時推薦系統

當下，我們為什么要使用OpenMLDB？一個非常大的背景是要用真正的硬實時計算去滿足AI需求。

什么是硬實時計算？它有兩層含義，一層是指要用最新鮮的實時數據來達到最大的決策業務效果。比方要用過去10秒或1分鐘內用戶的點擊行為來做決策業務，而不是過去一年或前年的數據。

另外很重要的一點是，做實時計算，用戶一旦發出行為請求就需要在短時間內甚至是毫秒級去進行特征計算。

當前市面上有很多做批量計算/流式計算的產品，但還沒有達到毫秒級的硬實時計算需求。

例如，如下圖所示做一個滿足生產級上線需求的實時推薦系統，用戶小李做一個關鍵詞為“洗衣機”的搜索，他需要在系統中把原始請求數據以及用戶、商品、交易等信息數據合起來進行實時特征計算，然后產生一些更有意義的特征，即所謂的特征工程，產生特征的過程。比如系統會產生“過去三個月內某一年齡段顧客購買的前三暢銷洗衣機”，這一類特征不需要強時效性，是基于較長歷史數據進行計算的。但是，系統可能也會需要一些強時效性的數據，比如“過去一小時內/半小時內的瀏覽記錄”等，系統得到新計算出來的特征后會給到模型進行推理。而這樣的系統特征平臺的需求主要有兩個，一個是正確性，即線上線下特征計算一致性；另一個是高效性，即特征實時計算，延遲<20ms。

特征計算開發到上線全生命周期

在沒有OpenMLDB方法論之前，大家主要使用如下圖所示的流程進行特征計算開發。

首先要做一個場景，數據科學家會使用Python/SparkSQL工具做離線特征抽取。數據科學家的KPI就是去做符合精度的業務需求模型，當模型質量達標后任務也就完成了。而特征腳本上線以后所面臨的工程化挑戰，如低延遲、高并發、高可用等并不是科學家的管轄范疇。

為了讓數據科學家寫的Python腳本上線，需要工程化團隊介入，他們要做的就是把數據科學家所做的離線腳本進行重構、優化，使用C++/Database做實時特征抽取服務。這滿足了低延遲、高并發、高可用的一系列工程化的需求，從而使特征腳本真正上線去做線上服務。

這一流程非常昂貴，需要兩組技能團隊的介入，而且他們所使用的工具不一樣。兩組流程走下來，還需要做計算邏輯的一致性校驗，即數據科學家所開發的特征腳本的計算邏輯要與最后實時特征抽取上線的邏輯完全一致。這一需求看似明確、簡單，但在一致性校驗過程當中會引入大量的溝通成本、測試成本以及迭代開發成本。根據以往經驗，項目越大則一致性校驗需要的時間越長，成本非常大。

一般來說，在一致性校驗過程中線上線下不一致的原因主要在于開發工具不一致，比如科學家用的是Python，工程化團隊用的是數據庫，工具能力有差異就可能會出現功能的妥協、不一致；還有就是對數據的定義、算法的定義，以及認知有差距等。    

總而言之，基于傳統兩套流程的開發成本非常高昂，需要兩組不同技能站的開發人員、兩套系統的開發和運營，中間還要添加堆砌的校驗、核對等。

而OpenMLDB提供了一個低成本開源解決方案。

OpenMLDB：線上線下一致的生產級特征計算平臺

去年6月，OpenMLDB正式開源，是開源社區中的年輕項目，但已經在100多個場景中落地應用，覆蓋超過300多個節點。

OpenMLDB是一個開源機器學習數據庫，最主要功能是提供一個線上線下一致的特征平臺。那么OpenMLDB是如何滿足高性能和正確性的需求的？

如上圖所示，首先OpenMLDB使用的唯一編程語言就是SQL，不再有兩套工具鏈，不管是數據科學家還是開發人員，都使用SQL表述特征。

其次，在OpenMLDB內部分出兩套引擎，一套是“批處理SQL引擎”，基于Spark++進行源代碼級別的優化，提供了更高性能的計算方式，并做了語法擴充；另外一套是“實時SQL引擎”，這一套是我們團隊自研的資源時序數據庫，默認是一個基于內存的存儲引擎的時序數據庫。基于“實時SQL引擎”，我們才可以達到線上高效的毫秒級實時計算，同時也保證高可用、低延遲、高并發。

在這兩套引擎之間還有一個重要的“一致性執行計劃生成器”，目的是保證線上線下執行計劃邏輯的一致性。有了它可以天然保證線上線下一致性而不再需要人工進行校對。

總而言之，基于此架構，我們的最終目的是達成“開發即上線”的優化目標，主要包括三個步驟：線下SQL特征腳本開發；一鍵部署上線；接入實時請求數據流。

可以看出，相較于之前兩套流程、兩套工具鏈、兩套開發人員的投入，這一套引擎最大的優勢是節省了大量工程化成本，即只要數據科學家用SQL開發特征腳本，不再需要工程化團隊做第二輪優化，便可直接上線，也不再需要中間的線上線下一致性校驗的人工操作，省下了大量時間和成本。

下圖展示了OpenMLDB從離線開發到線上服務的完整流程：

總體來看，OpenMLDB解決了一個核心問題——機器學習線上線下一致性；提供了一個核心特性——毫秒級實時特征計算。這兩點是OpenMLDB所提供的最核心價值。

因為OpenMLDB有線上線下兩套引擎，所以應用方式也不盡相同。下圖展示了我們的推薦方式，可供參考：

接下來介紹一下OpenMLDB中的一些核心組件或特性：

特性一，線上線下一致性執行引擎，基于統一的底層計算函數，邏輯計劃到物理計劃的線上線下執行模式自適應調整，從而使得線上線下一致性得到天然保證。

特性二，高性能在線特征計算引擎，包括高性能雙層跳表內存索引數據結構；實時計算+預聚合技術的混合優化策略；提供內存/磁盤兩種存儲引擎，滿足不同性能和成本需求。

特性三，面向特征計算的優化的離線計算引擎，包括多窗口并行計算優化；數據傾斜計算優化；SQL語法擴展；針對特征計算優化的Spark發行版等。這些都使得在性能方面相較社區版大幅提升。 

特性四，針對特征工程的SQL擴展。之前提到我們使用SQL做特征定義，但其實SQL并不是為特征計算設計的，所以在研究大量案例、累積使用經驗以后，發現有必要對SQL語法做一些擴展，讓它更好處理特征計算的場景。這里有兩個比較重要的擴展，一個是LAST JOIN，另一個是比較常用的WINDOW UNION，具體如下圖所示：

特性五，企業級特性支持。OpenMLDB作為一個分布式數據庫，具有高可用、可無縫擴縮容、可平滑升級等特點，已經在很多企業案例中落地應用。

特性六，以SQL為核心的開發和管理，OpenMLDB還是一個數據庫的管理，它與傳統數據庫較為相似，比如提供了CLI，那OpenMLDB就可以在整個CLI中實現整套流程，從離線特征計算、SQL方案上線到線上請求等，可以提供一個基于SQL和CLI的全流程開發體驗。

另外，OpenMLDB目前已經開源，關于其上下游生態的擴展，如下圖所示：

OpenMLDB v0.5.0：性能、成本、易用性增強

接下來，介紹一下OpenMLDB v0.5的一個新版本，我們在三方面做了一些增強。

首先看一下OpenMLDB的發展歷程。2021年6月，OpenMLDB開源，其實在這之前已經擁有了很多客戶，并且從2017年就已經開始做第一行代碼開發，技術的積累已有四五年的時間。   

在開源后一周年里，我們迭代了大概五個版本。相較于以往版本，v0.5.0具有以下幾個顯著特點：

性能升級，聚合技術能夠顯著提升長窗口性能。預聚合優化使得在長窗口查詢下，無論延遲還是吞吐，性能都提升了兩個數量級。

成本降低，從v0.5.0版本開始，在線引擎提供基于內存和外存的兩種引擎選擇。基于內存，低延遲、高并發；較高使用成本提供毫秒級延遲響應。基于外存，對性能較不敏感；低成本使用落地基于SSD的典型配置下成本可下降75%。兩種引擎上層業務代碼無感知，零成本切換。

易用性增強。我們在v0.5.0版本中引入了用戶自定義函數（UDF），這意味著如果SQL不能滿足你的特征抽取邏輯表達，支持用戶自定義函數，比如C/C++ UDF、UDF動態注冊等，方便用戶擴展計算邏輯，提升應用覆蓋范圍。

最后，感謝各位OpenMLDB開發者，從開源開始已經有接近100位貢獻者在我們社區做過代碼貢獻，同時，我們也歡迎更多的開發者可以加入社區，貢獻自己的力量，一起做更有意義的事情。

大會演講回放及PPT已上線，進入??官網??查看精彩內容。