OpenMLDB 最新版本、架構設計與落地案例分享

歡迎大家來到第四正規化技術日，今天我分享的主題是《開源機器學習資料庫 OpenMLDB：提供線上線下一致的生產特徵平臺》，我是來自第四正規化的資深架構師，OpenMLDB PMC 盧冕。

感恩貢獻者

正好是 OpenMLDB 開源大概一週年左右，所以我今天先趁這個機會來感謝一下我們 OpenMLDB 社群貢獻者。

左下的曲線圖是 OpenMLDB 開源一週年以來的社群貢獻者的增長曲線圖，我們可以看到到今天為止 OpenMLDB 一共有一百多位貢獻者，開源貢獻者數量呈現一個比較平穩的上漲趨勢。左邊的頭像以及右邊的詞雲圖其實是我們 OpenMLDB Github 社群上貢獻者的頭像以及 Github ID。

今天，趁此機會我在這裡感謝百位 OpenMLDB 社群的貢獻者。如果沒有這些社群貢獻者，OpenMLDB 社群不會取得這樣茁壯的成長。

發展歷程

接著，我也借這個機會來回顧一下 OpenMLDB 的發展歷程，OpenMLDB 是在去年 6 月份正式開源。所以到今天為止，OpenMLDB 作為一個開源專案成長了一年多，在開源社群它還是一個非常年輕的專案。

但是在開源前，OpenMLDB 已經跟隨第四正規化的商業化平臺“先知”在很多客戶中得到部署，落地超過一百多個場景。其實早在 2017年 OpenMLDB 就開始了程式碼技術的累積，所以雖然 OpenMLDB 才開源一週年，但是已經擁有四五年的技術積累。

開源以後，OpenMLDB 也取得了很多成績。首先自開源到今天它一共迭代了六個版本，每個版本都有不同的新功能加入。

在去年 8 月份，基於 OpenMLDB 的優化創新論文在國際頂級的資料庫學術會議 VLDB 上發表。

去年 9 月份我們有第一個開源企業使用者 Akulaku，這是一家以印尼為主要市場的線上金融公司。

在過去一年裡，我們通過社群收穫到了非常多的使用者反饋。來自 Akulaku、京東科技，以及一些傳統行業的企業使用者都給了 OpenMLDB 很多關注和支援，他們的意見對我們來說非常寶貴。

關於 OpenMLDB

OpenMLDB 在端到端的機器學習流程當中提供了一個線上線下一致性的實時特徵計算平臺。

上圖顯示一個典型的機器學習的全流程，包括從離線開發一直到線上服務以及其他資訊載體從資料到特徵到模型的一個流動變化過程，而OpenMLDB 專注於中間的這一特徵平臺部分，給上下游去提供實時的特徵計算能力。

OpenMLDB 需求場景

那為什麼 OpenMLDB 會強調毫秒級實時特徵計算的重要性？因為我們看到今天只有這種毫秒級的硬實時計算才能夠真正滿足 AI 的需求，能夠最大化地實現實時決策業務效果。

剛剛所說的實時計算主要有兩方面的維度，一方面是我們需要使用最新鮮的實時的資料，比如過去一分鐘或者幾分鐘訪問點選的這個模式；另一個方面的實時計算是需要在非常短的時間去做實時響應。

我們今天看到在市面上確實也是有很多做批量計算和流式計算的計算框架，但它們都沒有真正滿足 AI 硬實時毫秒級的需求。與之對應的是毫秒級的需求非常常見，在諸如 AI 的無人車、反欺詐場景等應用中都有迫切的需要，比方說右側表格列舉的某銀行事中反欺詐場景需要二十毫秒非常高速地的實時特徵計算來業務需求。

OpenMLDB 架構設計

當沒有 OpenMLDB 時，想 開發一個 滿 足實時計算，同時 滿足線上線下一 致性的 系統 ，應該如何做呢？ 我們 看到 很多 企業 的流程 是這樣的：

首先他們會有一套離線開發的流程，就是資料科學家用他們特定的演算法的知識去構建一個離線特徵計算的指令碼，資料科學家的任務是去構建一個模型精度能夠達到業務實踐需求的指令碼，他們通常會用 Python 或者 SparkSQL 來完成，而這個指令碼是不能直接實時上線，做到實時計算的。

所以這個時候一般會有工程化團隊介入，把資料科學家的離線特徵計算指令碼轉化成用 Database 或者 C++ 等高效能的方式去滿足線上低延遲、高併發以及高可用的工程化需求。在這個流程當中，做完離線開發的線上服務後還有一個非常重要的工作叫做計算邏輯的一致性校驗，它往往會耗費大量的人力去做溝通，去做反覆地迭代、測試、開發。

根據第四正規化以前的經驗，如果基於這套流程，中間的一致性校驗可能會花費數月的時間導致 AI 場景的落地成本劇增。

這個問題，OpenMLDB是怎麼解決的呢？右邊這張圖顯示了 OpenMLDB 比較簡要的關鍵架構。

我們可以看到首先 OpenMLDB 對外暴露了一個唯一的一個程式語言就 SQL。

OpenMLDB 內部還有兩套處理引擎，一套專門負責批處理的引擎，是基於 Spark 做了原始碼級別優化、針對特徵計算場景提升效能的引擎。第二套是實時 SQL 引擎，是 OpenMLDB 團隊自研的時序資料庫，也是整個 OpenMLDB 保證毫秒級實時特徵計算的核心引擎。

基於這兩個離線引擎和線上引擎之間，我們會有一個一致性的執行計劃生成器，保證它們生成的執行計劃是一致的，天然保障了線上線下的一致性。

基於這麼一套引擎系統，我們可以達到最終開發即上線的目的。資料科學家使用批處理的 SQL 引擎，去寫批處理的特徵計算指令碼做離線的開發，開發後可以通過一個命令直接把 SQL 指令碼一鍵上線，此時整個 OpenMLDB 的計算模式就會從線下切換到線上，這個時候我們再去接入這個實時資料，就能完成開發上線。

所以大家看到基於這麼一套引擎，我們在整個流程當中只需要資料科學家把 SQL 指令碼寫好，通過一鍵上線就能做到上線服務，不再需要工程化團隊優化，也不再需要人為完成邏輯校驗，可以節省大量的 AI 落地成本。所以簡單回顧一下 OpenMLDB 的核心特性就是做一個線上線下的特徵計算一致去提供一個非常高效的毫秒級的實時特徵計算能力。

OpenMLDB 作為一個開源軟體，也做了很多上下游生態的整合。OpenMLDB 內部的離線引擎本身就是基於 Spark，而線上引擎方面我們提供了兩種模式，一種是基於記憶體的引擎這種能提供毫秒級計算的模式，另外一種模式面向對於成本比較敏感的使用者，他們可以使用基於 RockDB 基於第三方儲存引擎的這麼一種模式，達到降低成本的效果。

對於上游來說，OpenMLDB 也對接了很多線上的資料來源，像 Kafka，像 Pulsar，能夠更加方便把實時資料記錄。離線的資料來源目前主要是  HDFS、 S3，後面也會做進一步擴充套件。對於下游來說，模型這一塊目前主要是一個鬆耦合的對接方式，主要還是輸出一些標準檔案格式，使它們可以被後面 ModelOps 的軟體所讀取。

在部署和監控這一塊，我們其實也做了很多第三方軟體整合，比如在部署這一塊我們跟 Airflow、Dolphinscheduler、Byzer 做了一些整合，監控也基於 Prometheus 和 Grafana 去做。

這裡可以給大家簡單看一下 OpenMLDB 和 Dolphinscheduler 整合介面，可以看到在這裡的話我們已經把 OpenMLDB 作為一個運算元整合在 Dolphinscheduler  裡面，大家可以通過拖拉拽做非常簡單的配置，比如任務的優先順序，線上線下模式。這裡就有一個非常典型的指令碼，通過拖拉拽的形式，我們就可以方便地搭建 AI 整個流程。這張圖顯示了一個非常典型的流程，就是通過建立表匯入資料，做離線特徵抽取，我們去做模型的訓練，這個時候會有一步驗證的流程，如果模型訓練成功就會直接切換到模型部署，否則就會輸出一個報告。基於 Dolphinscheduler 加 OpenMLDB 就可以非常方便地做到這 一個非常典型的從訓練到部署的 一個流程。

最新升級

客戶案例

最後要和大家著重介紹的是 OpenMLDB 過去一年來落地的客戶案例。

Akulaku

首先要提到我們第一個社群使用者——Akulaku，這是一家主攻印尼市場的線上金融科技公司。

Akulaku 在整體架構裡構建了一個智慧計算平臺，可以看到在它的智慧計算平臺裡最上層是智慧應用，大部分應用都與風控、反欺詐有關，而下面兩層是 Akulaku 的底層技術架構層，OpenMLDB 的線引擎部署在模型計算層，離線引擎部署在特徵計算層，提供特徵計算。

Akulaku 的需求跟 OpenMLDB 的特性非常吻合，在線上時需要做低延遲、高時效性的計算儘可能反映實時資料的變更，所以需要 OpenMLDB 使用實時資料去做實時的計算；線下它則要去做高吞吐的資料分析，最重要的保證線上線下部署的邏輯完全一致。這個與OpenMLDB 提供的線上線下一致性相契合，所以 Akulaku 最終使用 OpenMLDB 的解決方案，使用 SQL 作為離線和線上的橋樑，實現了一天內處理近 10 億條定單資料的需要，能做到及時的更新，去做時間視窗實時滑動計算，達到4毫秒的延遲。

某銀行——事中反欺詐

第二個案例有關某銀行事中交易的風控系統。OpenMLDB 在風控系統架構中銜接了實時特徵計算和批處理的特徵計算，把兩邊的線上模組和自學習模組做了連線，保證兩邊線上線下的一致性。

在這個案例裡，銀行方對特徵計算模組的效能要求非常高，為了應對如今有數目繁多的欺詐手段，他們需要非常快速地做出高效的實時響應，銀行的需求是要在 20 毫秒內走完特徵計算流程。然而不管是基於行方傳統的規則系統，還是客戶自研的系統，都無法達到這一個嚴苛的要求，最後他們使用 OpenMLDB 的方案，依託分散式可擴充套件的線上預估能力，能夠最終達到小於 20 毫秒的實時特徵計算。

某國家級科研機構——計算海量資料特徵

第三個案例是某國家級的科研單位使用 OpenMLDB 在 IOT 場景裡做資料的處理。

在某科研單位的應用場景裡，多個裝置的實時資料流是通過 Pulsar 匯入到 OpenMLDB，OpenMLDB 以線上資料庫的模式去做實時線上計算，同時在應用模組裡面會不斷請求實時計算一場波形的資料。因為資料來自三萬個檢測裝置，每個裝置又會每秒產生一百個資料點，所以客戶的需求是資料寫入需要達到 QPS 三百萬的數級。在應用側，查詢計算每十秒就會發送不同裝置的資料，請求進行多個視窗的邊緣計算，所以計算請求的效能要求大概是 QPS 3000。基於OpenMLDB 的方案，我們只需要使用一臺伺服器就可以在不考慮高可用的情況下滿足資料儲存佔用記憶體 50GP，一臺伺服器就可以滿足整體的容量和智慧需求，去提供實時 IOT 的資料處理和計算能力。

某金融服務機構——智慧運維場景

這張圖顯示的是某金融服務機構的智慧運維場景。

在這個案例中有很多業務系統的監控指標。客戶是通過 Kafka 把資料灌到一個實時資料特徵平臺，在特徵計算平臺裡面做模型推理，再把這個預測結果放到規則決策的系統裡，最後決定決策結果是否要報警給運維人員。

行方原來的方案是基於整體做了特徵計算，隨著業務的擴充套件，他們希望實現業務的十倍擴容，在原來的方案裡面實現十倍擴容，機器也需要實現十倍增長，成本非常高的，所以最後他們使用了基於 OpenMLDB 的升級方案。升級方案是把 OpenMLDB 作為特徵計算平臺替代原來的 Redis 方案，升級之後 CPU 的資源消耗和記憶體使用上都有 2 到 3 倍的優化，進而實現擴容成本 50% 的下降，就是說只需要做五倍的機器擴容就可以實現業務的十倍擴容目標，大大降低了資源成本。

某網際網路科技公司——實時風控場景

接下來的案例來自於某網際網路科技公司。

該公司的需求場景也是實時風控場景。客戶原先的實時風控場景同樣使用了基於 Redis 方案，輔助一些自研指令碼來完成實時特徵計算。但是隨著業務升級，客戶發現原來這套方案在實時計算的反應速度上無法達到需求，計算延遲較高，於是客戶選擇使用 OpenMLDB 的升級方案，最終使用 OpenMLDB 去替代 Redis，資源利用率獲得顯著提升，實現了毫秒級實時特徵計算，輕鬆滿足了他們的業務需求。

慕尚集團——智慧營銷平臺

最後一個落地案例來自於 OpenMLDB 和慕尚集團的深度合作。慕尚集團是一家中國領先的、由新零售模式驅動的休閒時尚服飾和多品牌運營公司，2019年已經在港交所上市。

隨著業務的擴充套件，慕尚集團對數字化轉型產生非常迫切的需求，而以前的營銷平臺是基於專家規則打造的，需要改造。結合慕尚集團的業務與需求，第四正規化使用了 AutoX ＋OpenMLDB 共同構建了新的智慧營銷平臺，並基於新營銷平臺搭建衍生出了適應多種場景 AI 應用，比如個性化推薦應用、廣告精準投放應用、客戶流失預警應用等等。

最後我們也歡迎大家加入OpenMLDB的開源社群，和我們在技術方面或者案例方面做更多的互動交流。

謝謝大家，我今天的分享就到這裡。