本文整理自 OpenMLDB PMC 盧冕 在 OpenMLDB Meetup No.6 中的分享——《開源機器學習資料庫 OpenMLDB：線上線下一緻的生産級特征平台》。
非常感謝大家來參加此次 OpenMLDB 第六次 Meetup。我叫盧冕，是 OpenMLDB 的研發負責人，也是第四範式的系統架構師。
今天由我來給大家整體介紹 OpenMLDB 的定位和特性，回顧最近一個月來 release 的内容和 OpenMLDB 研發進展。
我的分享主要分為三部分。
- 第一部分介紹目前人工智能工程化落地所面臨的資料和特征挑戰
- 第二部分講解我們目前如何通過 OpenMLDB 這個線上線下一緻的生産級特征平台來解決這些挑戰
- 第三部分帶領大家回顧 OpenMLDB 的發展曆程，以及 OpenMLDB 下一版本的 Roadmap。
Tips：目前我們正在規劃 OpenMLDB v0.7.0，已有一個初步的 roadmap（還在調整修改中）。如果大家對 OpenMLDB 有期待和需求或是對于參與開發某一個 feature 非常感興趣，我們歡迎大家和我們進行詳細地交流，也會把來自開源社群的需求放在讨論排期比較高優的位置。
交流通道：https://github.com/4paradigm/OpenMLDB/issues/2547
人工智能工程化落地所面臨的資料和特征挑戰
資料挑戰
在如今人工智能落地的過程當中，其實我們把大部分時間都花費在資料治理上。
今天市面上已經有非常多的資料治理工具，如 MySQL、HDFS 等。但從 AI 落地的角度考慮，這些工具未能完全解決我們 AI 落地中的一些工程化問題。接下來就來具體介紹 AI 工程化落地面臨的挑戰，以及 OpenMLDB 的解決思路。
毫秒級實時特征計算需求廣闊
在此之前，先說明一個非常重要的背景知識：OpenMLDB 所面向的應用場景是機器學習的決策類場景，而且是時效性要求非常強的決策場景，是以它需要具備毫秒級的資料和特征處理能力。
可能大家都知道我們的目前接觸到的 AI 應用可以分為兩類。
- 一類是感覺類，例如 CV、人臉識别、NLP，它們都是屬于感覺類的應用。
- 另一類是 OpenMLDB 所關注的決策類的 AI 應用，主要面向于商業場景，像是防控、風控、反欺詐、個性化推薦等等。決策類的 AI 應用一般針對結構化的資料。
那為什麼我們需要實時的機器學習去做決策呢？
其實，所謂實時機器學習決策，可以從兩個次元上去了解。
- 一個次元是我們需要實時的資料。當我們需要對目前行為的發生做出判斷，必須通過十秒甚至更短時的實時資料才能獲得更準确的判斷。
- 另一個次元是我們需要實時的計算，隻有在非常短的時間内把計算結果反映出來，才能做到業務要求下的快速響應。
針對此類需要實時資料和實時計算的場景，我們現實生活中已經有了非常豐富的需求場景。AI 無人車、量化交易、銀行的風控和事中反欺詐等都需要基于實時資料的快速實時計算。
在今天的市面上，我們也能看到很多機器學習的通用大資料處理架構，如 Spark、Flink，甚至是 Python，但是這些架構都不能達到毫秒級的實時計算響應速度。以 OpenMLDB 企業客戶為例，在他們的銀行反欺詐場景中，需要系統的響應時間控制在 20毫秒以内。若響應時間過長，反欺詐機制可能失效，導緻大量損失。是以市場還是非常需要有一款具備毫秒級實時資料和特征處理能力的工具，為機器學習場景決策提供更強有力的支援。
OpenMLDB 最具優勢的應用場景正是實時的機器學習決策。
機器學習應用開發上線全流程
接下來讓我們進入到另一個重要的背景知識——機器學習應用從離線開發到上線全流程是怎樣的。
整個需求會分為離線和線上兩個部分。
在離線開發環節，資料科學家會不斷探索開發特征腳本和模型，使它們能夠達到最終的精度要求。
線上上服務環節，要将服務上線，真正做到線上的實時預測以及實時特征計算。OpenMLDB 關注的是其中的特征部分，而不涉及後續的模型。
在這裡，我們可以通過下面的事中反欺詐交易的案例幫助大家了解實時特征計算場景。
假設圖中有一位使用者做了刷卡的行為動作。我們可以得到刷卡金額、刷卡時間、卡号這些消費記錄，也是最原始的資料。我們的反欺詐系統會通過一張曆史交易表，查詢到做了消費行為的卡号，進而得到一系列的曆史資料。
因為我們是做事中反欺詐的，是以目前的資料也能為判斷提供依據，它也會虛拟地暴露到表格當中和交易記錄等曆史資料共同形成所有的原始交易資訊，提供給特征抽取。
在右側圖表中還可以觀察到一個非常重要的特征，就是資訊的時間戳。所有原始資訊都是基于時序排列的。這裡經常需要做的特征計算模式，就是基于視窗的聚合模式。
在例子裡，我們可以劃定兩個視窗，一個是十秒的視窗，即從目前交易的時間點向前十秒的時間點劃一個時間視窗；另一個是三小時的視窗。基于這兩個時間視窗，我們可以做一些特征抽取，比方說過去十秒或三小時的刷卡次數、最大刷卡金額、最小刷卡金額以及平均每次刷卡金額。那麼通過計算我們得到了一些有效的特征資訊，這些特征資訊會提供給後面的模型推理環節使用。
這個就是 OpenMLDB 面向的實時特征計算場景中的典型案利。通過這個案例，我們可以看到兩個非常值得關注的工程化需求。
- 第一點，線上線下的一緻性。簡單來說就是線上服務的效果需與資料科學家離線開發的效果一緻。
- 第二點，低延遲、高并發、高可用的工程化需求。
接下來我會展開講解這兩點需求。
特征計算開發上線全生命周期
上圖可以展示出特征計算開發，從開發到上線的生命周期。
首先會由資料科學家進入項目體系，他會根據經驗使用 Python、SparkSQL 做離線特征計算。當離線特征計算的輸出結果可以滿足業務需求時，資料科學家生産滿足業務精度的特征腳本和模型的任務就完成了。
但因為離線的特征腳本和模型不能滿足低延遲、高并發、高可用的線上工程化需求。此時會有工程化團隊介入。他們會使用一些高性能、高可用的工具，像 Database、C++ 把離線特征計算腳本轉換成成實時特征計算的程式應用，滿足生産需求後真正做上線服務。
那這個流程當中呢，其實我們有看到兩組開發人員以及兩套工具鍊。最重要的是中間還有一個環節，叫做計算邏輯一緻性校驗。這個環節需要保證的資料科學家和工程化團隊開發腳本的計算邏輯、資料定義是一模一樣的。
聽上去這是一個直接且簡單的需求，但在真正的工程化落地實踐中，一緻性校驗往往要投入大量的時間精力。我們不僅需要這個工程化團隊完成性能優化，還要不斷地溝通對齊、去兩邊對齊、疊代測試，保證計算邏輯的一緻性。根據我們以往的業務經驗，這個環節很可能會成為整個項目周期的瓶頸，耗費幾個月甚至一年以上的時間，計算其投入成本，是非常高昂的。
線上線下不一緻原因
而線上線下不一緻的原因也是多樣的，它可能受到工具能力不一緻的影響，也可能是需求溝通認知差導緻的。美國一家線上銀行的工程師就曾寫部落格述說過這種需求認知的差異，他在文章裡提到自己對賬戶餘額的定義與其他同僚預設的賬戶餘額定義以及處理方式不一緻，導緻了線上線下的不一緻。
特征平台工程化解決方案
為了解決該痛點，頭部企業會花費上千小時自研建構資料與特征平台，來解決諸如線上線下一緻性、資料穿越、特征回填、高并發低延遲等工程挑戰；其他中小企業則需要采購高昂的 SaaS 工具和資料治理服務。OpenMLDB 選擇為大家提供開源的、低成本、高效率、企業級的解決方案。
OpenMLDB：線上線下一緻的生産級特征平台
OpenMLDB 誕生背景
OpenMLDB 是去年6月開源的，但是其中的技術累積已經超過了四五年的時間。在第四範式的商業産品中，OpenMLDB 的前身是嵌入在 MLOps 産品中的特征平台，過去我們叫它 RTIDB 或 FEDB，已經跟随第四範式的商業化産品在100多個場景得到應用落地。
OpenMLDB 如何解決之前提到的兩個問題呢？讓我們往下看。
在 OpenMLDB 架構中有兩套處理引擎。
- 一套用于離線開發，處理離線資料。它是我們基于 Spark 做了源代碼級别優化後的産物，專門提供給資料科學家做離線探索，面向批處理模式。
- 另一套面向工程化，是針對生産級線上服務研發的實時 SQL 引擎，是由我們研發團隊完全從零到一、自主搭建的。它是針對時序資料，也針對特征工程優化的一個分布式時序資料庫。
除了兩套引擎外，架構中還有一個非常重要的一緻性執行計劃生成器。它保證了線上線下兩套引擎生産的執行計劃在計算邏輯上完全一緻。
配套這樣一套架構，OpenMLDB 對外暴露的唯一程式設計語言是 SQL。使用者隻需要把 SQL 寫好就能通過一緻性執行計劃生成器去生成線上和線下的執行計劃，同時天然保證這兩套執行計劃對資料定義、計算邏輯定義是完全一緻的。
這個架構能幫助我們達到**“開發即上線”**的終極目标。
資料科學家完成離線特征開發後，隻需一行 deploy 指令，就能直接把計算邏輯從離線批處理的引擎切換到線上實時引擎。再去把這個實時資料接入，就能完成離線開發到上線的流程。這樣做不再需要工程化團隊的介入，也不需要兩個團隊兩套裝置的對齊溝通，不再需要反複的一緻性校驗，是以能大大降低 AI 工程化落地的成本。
OpenMLDB 參與的開發上線全流程
具體流程如上圖。
- step 1：在離線開發模式，資料科學家導入離線資料用于特征探索開發（注意：OpenMLDB 離線引擎支援硬拷貝和軟拷貝。在軟拷貝模式下隻需要給出 HDFS 路徑，不做實際的資料拷貝）
- step 2：使用 OpenMLDB 提供的基于 Spark 改進的離線引擎在 HDFS 檔案上做離線特征抽取，在這個階段内資料科學家還會和模型訓練互動，不斷對特征抽取腳本進行調優。
- step 3：調試特征腳本至滿意狀态就可以把 SQL 上線，同時這也意味着計算邏輯上線。
- step 4：此時，切換 OpenMLDB 到線上模式。準備冷啟動需要的資料，比如特征抽取邏輯需要過去三個月的時間視窗資料，那我們需要把從上線時間點開始倒退三個月前的所有資料導入。
- step 5：準備實時資料接入，随着現實時間的推移，最近三個月的視窗資料是不斷變動的，資料視窗在不斷前移，是以需要把實時資料接入。這裡可以通過 OpenMLDB 提供的 SDK 去寫入，也可以通過我們這個提供的 connectors，像 Kafka Connector，Pulsar Connector，RocketMQ Connector 等把實時資料直接入。
- step 6：接下來就可以進入實時特征計算，使用者發送實時請求，OpenMLDB 會基于最新的視窗資料，進行特征計算，并傳回結果。
線上上引擎中，OpenMLDB 有一個真正資料存儲引擎，同時我們支援 TTL（一個資料過期的概念）。如果我們需要三個月的資料，那麼當資料庫中的存儲大于三個月會自動淘汰過期的資料。
基于計算邏輯加資料呢，我們的實時特征服務就已經準備好了。OpenMLDB 此時可以服務線上的實時請求，并把實時特征送出去提供給後面的模型推理。
OpenMLDB 核心問題與核心特性
總結上述内容，OpenMLDB 解決了線上線下特征計算不一緻的核心問題，提供了毫秒級實時特征計算的核心特性。
OpenMLDB 應用場景和使用方式
因為我們發現在社群當中存在很多不同的使用方式，是以在這裡為大家列舉展示一下 OpenMLDB 的使用方式。
我們最推薦的使用方式當然是剛才示範的從離線開發到實時上線的完整流程？這樣能保證線上線下一緻性。不過取決于場景需求，社群裡也有許多不同的使用方式，可以給大家提供參考。
比如某些使用者已有離線特征腳本了，但之前使用的線上引擎達不到性能需求，是以隻用了 OpenMLDB 的線上引擎。
同理，也存在一些使用者不需要去做線上的實時預估隻需要跑批，就可以單獨使用 OpenMLDB 的離線部分。
今天我們看到在開源社群中這三種方式都有出現。
再為大家簡單介紹一下産品特性吧。
OpenMLDB 産品特性一：線上線下一緻性執行引擎
第一個是線上線下一緻性執行引擎可以天然保證線上線下的一緻性，這點我們不重複介紹了。
OpenMLDB 産品特性二：高性能線上特征計算引擎
第二個重要特性是我們這個高性能線上特征計算引擎。圖中展示了我們實時引擎的主要子產品，這裡想傳達的主要資訊是 OpenMLDB 是一個分布式、高性能、可擴充、高可用的架構。在設計中我們用 Zookeeper 管理原資料，用 Nameserver 保證 Tablet 的管理和故障的轉移。而 Tablets 是我們整個資料庫存儲和執行的最小機關，其中包含了儲存引擎和執行引擎。
OpenMLDB 的存儲引擎是預設使用基于記憶體的存儲模式，以此保證線上服務的高性能。當然我們也有設定 Binlog 機制和備份機制，保護資料，幫助持久化。基于記憶體的存儲模式帶來高性能的同時也會帶來比較高的成本，是以我們也為對性能要求不敏感的使用者提供了成本更低的磁盤存儲模式。
在實時特征計算引擎中，我們最核心的優化是雙層跳表結構和預聚合技術。其中最顯著的優化是 OpenMLDB 内部使用了雙層跳表結構。雙層跳表結構可以幫助我們快速地找到相應資料給，保證線上計算的高性能。另外一個核心優化技術是預聚合技術。簡單來說是針對資料量巨大的視窗，我們會提前計算部分結果，便于在實時計算時降低延遲。
左側條形圖是 OpenMLDB 與兩個記憶體型商業資料庫的性能對比圖，可以看到在時序特征持續抽取的 workload 下 OpenMLDB 還是有比較明顯的優勢。
左側折線圖是我們使用預聚合技術後的性能提升表現，當視窗的資料量級達到幾百萬時，預聚合技術可以使延遲從秒級降至十毫秒以内。
性能測試報告：https://openmldb.feishu.cn/wiki/wikcnZRB9VRkqgD1vDFu1F9AaTh
OpenMLDB 産品特性三：面向特征計算的優化的離線計算引擎
第三個特性和離線引擎有關。首先，我們在 Spark 的基礎上做了文法的擴充。其次，OpenMLDB 把一些執行計劃也做了優化修改。然後最終我們達成的這個目的也是為了讓這個Spark能夠更友善的去做特征計算，而且能達到一個更高的一個效率。
OpenMLDB 産品特性四：針對特征工程的SQL擴充
第四個特性是 OpenMLDB 針對特征工程做了 SQL 的擴充——Last Join 和 Window Union。
Last Join文法能夠在左表比對到右表多條記錄時隻取其中一條，一般是會取最新的一條。這種情況通常是右表為某物體不斷更新的資訊狀态，我們隻需要最新的狀态過來做拼表，做最後的特征計算，這種場景其實在機器學習中非常常見。
如果 Last Join 是一個簡單的拼表，那 Window Union 其實就是一個相對複雜的拼表。Window Union 的設計針對另一種機器學習常見場景。在我們的現實應用中資料一般會出現在多表裡面。Window Union 不是簡單的取一條資料過來拼表，而是通過左表資訊找到右表的對應記錄然後再用。如果我們使用标準的 SQL 去實作上述要求也能夠寫出來，但會寫的相當複雜，執行效率也對應下降。
OpenMLDB 産品特性五：企業級特性支援
第五個特性是 OpenMLDB 提供企業級的特性支援，包括高可用、擴縮容、平滑更新、企業級監控以及雙機房保障。現在我們也在開發多租戶還有雲原生等企業級特性。
OpenMLDB 産品特性六：以SQL為核心的開發管理體驗
最後的特性讓我們用一個 OpenMLDB CLI 界面展示。如果使用過 MySQL，你肯定會對 CLI 有印象。OpenMLDB 作為一個資料庫産品，也提供了一個類似的 CLI，使用者可以在這裡非常友善地完成整套流程，實作離線開發。
OpenMLDB 上下遊生态
作為一個開源軟體，開源生态建設也必不可少。OpenMLDB 也在上下遊生态方面做了不少努力。
- 上遊的資料生态部分，因為在生産環境的使用情況，我們更專注線上資料的生态合作。對接Kafka、Pulsar、RocketMQ，我們都有開發相應的 Connector。在離線部分，OpenMLDB 目前主要讀取HDFS上的資料，我們也在計劃對接Hive、Cassandra，争取能做到把這兩個工具中的離線資料直接導入。
- 下遊的模型部分，OpenMLDB 還是松耦合的實作方式。因為我們輸出的格式比較标準，下遊模型可以直接讀取使用。
- 在生産這一子產品，OpenMLDB 也和Airflow、DolphinScheduler、Bzyer做了緊耦合，能夠直接在上述工具中調用 OpenMLDB 的算子。
- 在監控這一子產品，OpenMLDB 也和Prometheus做了對接。
OpenMLDB 應用案例
在特征介紹後，讓我們用一個客戶案例幫大家更具體地了解 OpenMLDB 的應用。
Akulaku 是 OpenMLDB 第一個深度使用企業使用者，是一家出海東南亞的線上金融公司。在 Akulaku 的應用中 OpenMLDB 的使用場景也大部分是和金融有關。
在圖上的架構中，線上部分的設計中 OpenMLDB 被放置在模型計算層，在離線部分 OpenMLDB 位于特征計算層，通過這樣的架構保障了線上線下特征計算的一緻性并且完成了線上服務。
Akulaku 的應用場景和需解決的痛點與 OpenMLDB 非常比對。Akulaku 的線上部署需要達到低延遲并發并且高時效性的要求，需要盡可能新鮮資料來反映實時的變更。線下分析也需要滿足高吞吐的需求，同時要保證線上線下的邏輯完全一緻。
使用 OpenMLDB 後，在一天内需要處理大概 10億 條訂單資料的 Akulaku，能夠将視窗計算延遲大大降低，達到 4毫秒 的級别。
History & Roadmap
OpenMLDB 發展曆程
接下來的時間我們會簡單介紹 OpenMLDB 目前的發展狀态和未來的規劃。
開源至今，OpenMLDB 已經經曆了一年多時間的疊代，從 0.1.0 更新到了 0.6.0，第七個版本預計會在今年11月或者12月和大家見面。
在成長的過程中，我們收到了非常多來自社群小夥伴的回報，也吸引了一批使用者的使用。Akulaku、京東科技、華為、37手遊的同學都有深入參與到 OpenMLDB 的成長中，非常感謝合作夥伴帶給我們社群的建議及回報。
OpenMLDB 近期優化
過去一個月中，OpenMLDB 主要釋出了一個大版本、兩個小版本。其實我們做了兩件非常重要的事情。
第一是是我們引入了一個資料庫狀态智能診斷工具以及一個自動化的 log 收集工具。在社群的讨論交流中我們發現 OpenMLDB 的狀态診斷以及 log 解析存在不足，經常會耗費大量人力去排查叢集狀态。是以我們在 0.6.0 版本裡引入了智能診斷工具。希望在存在問題是能為社群使用者提供初始資訊、調整建議，甚至是直接解決。
第二是完成了 OpenMLDB 和 Airflow 的整合。大家可以在非常流行的編排工具 Airflow 中直接調用我們的 OpenMLDB 算子。
另外，我們也做了 SQL 的文法增強。提供了更多事後決策的功能，支援 EXCLUDE CURRENT_ROW。
在 0.6.1 版本中，我們主要是做了一些修複，進一步提升了離線引擎的性能和穩定性，增加了 Oneflow 的整合案例。
在上周釋出的 0.6.2 版本中，OpenMLDB 能夠支援離線引擎的獨立運作，對這個日志輸入格式做了優化，減少一些意義不大的無效資訊出現。
OpenMLDB v0.7 Roadmap
現狀我們已經在規劃 0.7.0 版本的過程中了，目前大緻拟定了三個方向。
第一，增強 OpenMLDB 的 SQL 能力，特别是增強預聚合能力。因為我們看到部分使用者的特征抽取文法邏輯非常複雜，是以雖然我們提供了 UDF 支援，但是接下來依然會在 SQL 的原生能力上去做增強。
第二個重要方向是，我們會 提升 OpenMLDB 的穩定性。比如我們可能會通過一些手段完成記憶體資源的隔離。以前造成 OpenMLDB 不穩定的最大的問題是記憶體消耗過度，而使用者沒有感覺。一旦過度消耗，就可能會被 OS 給殺掉。是以在下一個版本中，我們會計劃引入記憶體資源隔離的手段來避免服務的完全中斷。
第三，在 易用性上做更多優化。之前會有社群使用者抱怨運維指令過于複雜。針對這些聲音，我們會對運維指令做一些簡化優化。OpenMLDB 0.7.0 版本也會嘗試在阿裡雲市場提供一個開箱即用的服務。歡迎大家持續關注。
OpenMLDB 歡迎你的加入
今天的介紹到這裡就結束了。最後也非常歡迎大家加入 OpenMLDB 社群，可以掃描二維碼入群了解更多相關内容或和我們做深入交流。
相關連結
OpenMLDB 官網：https://openmldb.ai/