大家好，很高興能和大家一起參加第四范式的技術日，做關于OpenMLDB 在 Akulaku 數據驅動中應用實踐的分享。

我是來自 Akulaku 的馬宇翔。對于 OpenMLDB 來說，我們算是一個早期的關注方，也是對它提供的解決方案存有濃厚興趣的企業方，所以今天我非常希望通過和大家分享我們的使用體驗，來拋磚引玉。

場景需求和架構設計

Akulaku 的數據架構如圖所示。在特征計算層，有一些第三方和自研的底層工具；在模型計算層，做了一些開放架構式的整合，盡可能地構成了一個易擴增且不依賴于某種特定工具的計算模式框架。這兩層負責支持智能應用，比如說把行為動作、地理位置、設備指紋，也有銀行的一些反洗錢、設備風控，以及基于用戶體驗的智能客服、智能投顧。這些智能應用基于相同的數據驅動底座技術棧來提供服務，在設計滿足上述條件的方案時我們發現了OpenMLDB。

場景需求

作為Akulaku的數據部門，我們平時會面臨各自來自上下游的訴求。

下游業務方會要求我們盡可能支持各種各樣的功能，并且要求實時使用。我們常見的數據應用方會需要同時使用離線計算、異步實時計算和硬實時計算以滿足決策需要。這些關鍵事件的決策不能出錯，同時決策的穩定性也要有所保障。

對于上游的訴求。比如說運維部門作為資源提供方，存在成本上的訴求，整個計算體系的資源希望盡可能的少。這里的少，更多也是滿足業務前提下的少，也就是要做到全局最優。要求我們做精細化，可是精細化會帶來復雜度的提升，復雜度的提升又會降低穩定性。上下游的訴求存在互斥，對于我們來說是一個挑戰。

對于內部的數據部門來說，因為大數據工具的頻繁迭代，員工的學習成本很大。比如說 Spark 對批量計算友好，Flink 對流式計算友好。但是為了每一種計算模式都單獨學一個工具，并且根據工具迭代跟進學習，還可能要適應改造去大幅改造現有系統，會導致從每一個員工到整個部門都難以獲得沉淀，且非常痛苦。

在易用性這邊，我們的使用方是希望整個平臺的設施足夠簡單方便普及。既要處處可用，還要使用方式比較簡單，不然各類型的服務角色比如說開發者的訴求、分析師的訴求和算法工程師就不太一樣，很難都得到滿足。

其次重要的是可靠性，如果系統部署困難、三天兩崩，出現問題無法自查，測試時間過長都會給我們帶來很大的影響。所以以上的這些問題，我們必須逐一避免或減少。

架構設計

設計需求

那以上種種情景下，Akulaku 的架構設計必須滿足下面兩個目標。

首先我們需要同時做一個適用于 OLAP 和 OLTP 的一些高效融合計算的方案，它需要同時實現 AI 和 BI 的數據執行，必須保證 AI 和 BI 在整個的生產線上盡可能地使用同一份數據去運行，而不是分別跑出兩個中間結果，然后再得出不一樣的結論，這個有很高的風險。

其次使用的工具需要兼容其他的工具，擁有良好的生態。如果沒有良好的生態，我們也很難把它放置在整個的架構里。

經過大量的二次開發和以上兩個目標的篩選，我們明確了 Akulaku 數據架構中工具需要支持五種條件：

第一，流批一體。它的批處理和實時處理應該是一個相同的代碼能執行，而且執行出來的底層也應該是相同的邏輯。

第二，高性能。因為在線上的大并發和線下大吞吐量的任務都需要做一個支撐。

第三，場景無關。場景無關的這種特性，我們需要它具備一份數據可以處處使用，然后通過一些篩選，或者是說加窗口的方式去改變它的條件。而不是說它每換一個場景，我們都要重新去做一遍全量計算，或者全量數據導入導出。

第四，語義支持。語義支持更多是因為我們的流式計算有很多的新的語義，就是像 Flink 每次版本迭代，都會根據具體的大家提的使用需求去迭代一些新的語義。那么對于這些語義，希望我們的工具也能得到一定的支持，它能做一些比較復雜的實時計算場景。

第五，工具高效。首先我們需要搭建計算框架的組件，它本身是能沉淀我們一些上線的流水線和線下分析的數據邏輯的這些能力。便于我們后續對它做一些迭代。

設計實現

最終成型的特征和數據計算架構如上圖。

首先我們數據源可能會來自 HDFS、Kafka，還有其他服務語言的 SDK，或是 Nebula 這種比較特殊的圖計算工具。基于這些不同的數據源，我們在中間做了流批一體化，最后主要選擇了 OpenMLDB 不同的模式去實現這一套的功能，再通過中間件去屏蔽掉流批一體化的不同組件對于一個邏輯的不同實現，保證接下來的融合計算組件能得到很好的降低復雜度的程度。

在 Akulaku，接近50%的、使用量最大的一部分指標對實時性的要求較低，比如運營人員或者管理人員需要的數據指標或是一些對實時性要求比較差的特殊模型，可能會使用性能或性價比相對較高、更加普適的 Rocksdb 模式去做。

接下來，如果對于生產要求，準確性以及性能、計算速度要求比較高的批處理，我們就會使用背后基于 Spark FE 的 OpenMLDB 離線模式，它的性能比 Spark 要好很多倍。

如果有一些硬實時的計算，就會采用 OpenMLDB 的在線模式去做，可以做到大并發下面保持在幾十毫秒級這個水平，基本上是滿足 200 毫秒硬實時的門檻。

其他的一些補充，例如 Clickhouse 或者數據湖的組件，就會在指標市場或更多的數據大盤上做一些支持，這兒就不贅述了。

在融合計算方面，我們主要基于 Ray 來完成的，Flink 是我們之前的方案，但是目前是在Ray上去做全盤過渡。

數據應用層，首先就是因為OpenMLDB的離線、在線一體化，所以我們可以很輕易地去把 MLOPs 做到持續交付到持續部署中間這一步的測試自動化，可以簡化非常多步驟，因為代碼是一致的。有了 OpenMLDB 之后，我們就可以比較輕松地去做 AutoML，其他的一些指標市場和低代碼分析，完成一些更精細化的BI的應用。

應用細節和使用案例

為什么最后選擇把 OpenMLDB 選擇放在我們的核心位置？

第一，天然地支持流批一體。流批一體是 OpenMLBD 的一個核心，或說主打功能，也是我們最剛需的功能。

第二，高性能。實測 OpenMLDB 的性能時，如果從 Kafka 寫入數據最大可以做到 1 萬的并發，當然這是一個三節點的集群，可能更多節點的集群會有更好的效果，也就是說OpenMLDB 的性能還有擴展空間。在離線部分，OpenMLDB 性能超過 Spark 數倍，基本上能滿足常規的一些使用。在實時計算部分，我們可以輕松地做到接近 200 的 qps，還可以保持 99%的 70 毫秒內的計算。所以可以說，OpenMLDB 是一個非常優秀的線上和線下的計算工具，也是一個非常優秀的可以同時滿足線上計算和線下計算的分析數據庫。

第三，場景無關。這個特性，它是可以在內存做一個持久化，以及我們可以選擇使用持久化內存版本，來確保我們數據在非常極端的情況下還是能夠得到恢復。通過這種方案，我們就可以在一次地把數據寫入之后，然后不停地通過SQL去控制計算力度，來確保我們可以不停地復用這些數據。

其次就是它自己也支持數據過期。數據過期功能，就是說可以把一些我們設定好的，過了多久不會使用的數據自動給干掉，那就會省很多的一些空間，然后提高我們的存儲有效性。而且它還支持Rocksdb的版本，然后去做到降本增效的效果。

第四，語義支持。它支持了常見的流式場景需求，而且可以和批式的語法使用相同的一些算子。同時它也支持 UDF 或者 UDAF 一些特征工程的函數擴展。這些擴展方式對我們來說還是很實用的，因為你可以把一些特定的邏輯分裝成函數使用。

第五，工具高效。我們目前是使用一些像 Airflow之 類的工具去把整個的腳本做一些流水線的固化，然后這個固化擱置呢，OpenMLDB 在里面只需要配置一些類似 SQL 腳本就可以完成了，這個方式是比較便于實現 MLOPs。同時OpenMLDB 也在打造和很多第三方工具的使用生態，去確保我們可以更便利地和其他工具打通。

應用思考和建議

應用思考

接下來的內容想介紹一下 OpenMLDB 的應用思考。

第一是關于標準 SQL，我們是否一定要有一個滿足標準 SQL 的工具呢？我們思考的結果是：其實也不那么必要。因為標準 SQL 語法更多的本質目的是為了支持我們的邏輯一致性，但對于邏輯一致性，我們還是有其他的方案可以去實現的。比如大家如果是調用一些非標的方法或者說還未支持的方法，我們就必須調用自我實現的一些功能或者使用軟件工程的一些設計模式去解決掉這些分裝，或者解決掉多層復用的一些問題。

這種方式，可以為我們換來超越標準SQL工具更多效率吧，這個效率其實是我們目前更為需要的一個東西。以我們自己的時間來說，現在是一些復雜到可能數百行 SQL 盤活挖掘類型的任務，都是可以通過這種方案去解決掉的，它的擴展空間還是非常大。

第二就是關于質量和效能的平衡。質量和效能，一般來說我們希望它同時提升，但是更多時候它們也會有一些沖突。比如說每當提高復雜度，那質量就會下降，但是提高復雜度可以精細化整個產品的一個效能。這些時候，我們就會選擇做一些錯位對齊。

比如說以 OpenMLDB 的三種實現模式來說，我們會選擇使用特定的模式去實現盡可能恰當的那些特征。比如說 Rocksdb 的版本，我們就會做通用的指標計算的工具。

在線計算的版本，我們就會用來做一個線上實時模型特征計算的工具。離線版本，我們就會用來做一些 T+1 的一些非常大批量數據的計算工具。就是說，每種方案我其實都是可以以特定的數據或者說場景盡可能最優匹配。

這種方式我們還運用到一些預計算、及時計算、軟加載或者窗口劃分之類的方案中，進一步去優化它的質量和效能的平衡。

第三是在業務和技術上面，我們也需要做一些取舍。對技術來說，希望我們的技術不產生任何的一些技術債，然后不停地去向上迭代。針對業務來說，它需要的其實就是你的功能的完整實現以及上線時間。

關于這一點，我們是之前做了一些低代碼的工具去完成這個事情。如果是一個標準的低代碼工具，那它可能更多節省的時間是業務人員“拖拉拽”的時間，這個其實并不是業務真正想要的。他們更想要的其實是縮短上線時間，這個上線時間的減少就需要看你使用的工具能否直接從持續交付進展到持續部署，這一點就是 OpenMLDB 在這兒起到的作用。就是我在這邊“拖拉拽”完成的一套低代碼工具背后實現生成的SQL，我就可以直接應用在線上的版本去做部署。

使用細節

接下來，就是想介紹一些具體的使用細節，其實更多是一些 tips，可能會對大家使用這個工具的時候有一定的幫助。

首先就是在建表環節，我們可能會提供多種的索引定義方式。主流的方式就是使用 INDEX 里面 Key 的關鍵字，另外一種就是使用時間窗口里面的 TS 關鍵字，時間窗口的這種關鍵字就是用于所有基于時間的流式數據。使用 Key 關鍵字的，需要我們自己把這個事件進行序列化，然后定義其中可以幫助你良好地把序列拆分開的一些字段用來做一個關鍵字。如果定義非常成功，就會讓我們使用這個工具的效果得到一個極大的提升。首先是邏輯會得到簡化，其次就是性能也會提升很多。OpenMLDB 目前支持的時間字段就是兩種數據類型，這個也是需要注意到的。

接下來在查詢部分，當我們查詢一條數據的時候，并不需要完整地把一個非常龐大的業務 SQL 傳進去。我們更多的是可以說，只用到我關心的、所用到的字段和時間戳。其他不重要的可以使用一些替代值它給占位，有了這個占位之后，OpenMLDB 是已經可以正常工作。

其次就是金融場景尤其常見的，不使用當前行去計算一定時間窗口內的數據。Akulaku 使用的解決方案是，我們排除掉當前這個字典里面所在的毫秒時間戳里面的第一個字段，然后通過這種方式去把排除當前行的操作解決掉。那么里面其他的字段，因為是一個非時間戳，而且不是我們用到的字段，所以就是一個不重要的無所謂的數據，可以隨便的去做一些占位。這些操作是可以比較簡化排除當前行這個問題的實現，不需要做一些非常復雜的邏輯。

建議和展望

最后想和大家介紹一下，我們最后使用下來的一些建議，以及對 OpenMLDB 產品未來迭代的展望。

使用建議

關于這一塊相對比較經典的使用建議的話，首先就是如果我們的邏輯它很復雜，那會導致線上驗證和線下生效，這兩個事沒辦法在很短的時間內判斷出邏輯是否一致，或者說最后跑出來的結果能不能是一個數。對這種方式，我們就會建議使用 OpenMLDB 來去完成，因為它是天然消滅這種問題。

其次就是說，如果我們參與計算的數據可以按照時間或者某個索引非常完美地去切片、做窗口，那我們也是建議使用這個工具。因為它的性能會非常的高，那我們的性價比和效率就會提升到一個非常可觀的一個程度。

第三部分就是說，如果我們邏輯的開發人員不是那么關心大數據領域和高性能領域的一些問題，甚至說包括 SQL 優化也不是很想考慮的話。那我們也建議使用這個工具來去做這個邏輯的開發。

就目前來說，就我們使用下來 OpenMLDB 本身的性能、底層的優化已經做得很到位了。關于 SQL 語義這塊特別影響性能的實現，比如說多表聯做這種，它是直接不支持的，那么也就是不會讓邏輯開發人員寫出來一些非常低性能的代碼，可能會造成系統血崩之類的問題。

其次就是我們建議要使用好 OpenMLDB，我們希望企業內部還是需要有比較清晰的數據治理的能力。不然的話，可能我在第一步的過程中，就是導入OpenMLDB 里面的數據可能就會相對比較亂。它更多也不是一個在內部做數據清洗的一個工具。如果要用好 OpenMLDB 的強項——計算，那我們最好是把一個盡可能清晰的，需要用它算的數據輸入進去，然后可以直接執行后面的相應邏輯，而不是一直收到報錯。

迭代展望

接下來就是我們認為OpenMLDB后面還會支持的一些功能，然后以便于更加方便我們的一些使用。

第一，就是目前看起來它是有在做一些進一步的支持異構資源，去降低存儲成本之類的事情。這個操作后續的衍生，我們認為就會去做一些更進一步的精細化的使用配置。同樣的一個表里面，甚至可以支持某些字段的計算，例如需要用內存版本某些字段的計算，用 Rocksdb 去做就可以了。這種方式，可以讓資源的精細化管理做到一個相對比較極致的水平。只要所謂的成本和產出的 ROI 能達到更高的話，那 OpenMLDB 的應用場景其實就會更寬。

第二，目前它的數據 IO 和 SDK 支持來看，它后面還有很多可以支持的一些工作。比如說目前的離線數據導入，我們一般是使用 HDFS 或者 CSV。那還有比較新的一些數據或者說離線的數據湖，或者說在線的一些連接器，那都是它后續可以做一些實現的。

其次就是關于 SDK 的支持，我們目前在 Java SDK 和 Python SDK 使用上面，如果相對于其他一些更成熟的數據工具，我們希望能有一種像是支持 Python 多線程。或者對 Java 來說，可能就是它的生成文件形式可以更友好，或者說它可以直接有一個非常明顯的開關功能，都可以幫助我們更好地去便利使用 OpenMLDB。

第三，我們期待有更多來自社區的文檔貢獻，比如說 OpenMLDB 有很多的寶藏功能，比如說 UDF 函數的一些實現，或者是關于在線和離線兩種不同模式底層的數據如何做一致性之類的設計能夠給還未入門或者說剛入門的開發者一個更加充足的介紹，那我相信它的轉化和使用量也會得到更迅速的一個增長。

第四，我們認為 OpenMLDB 可以有一個更友好的 SRE 支持的設計，比如說關于數據過期是一個非常好的功能。但是如果是生產環境下的話，出了一些問題就不太好回溯，也不太好去做進一步的迭代。那這個時候，如果我們可以有一個選項是把它做一個異步轉存，再或者后面再補充一些定時刪除，對于 SRE 這邊的排查問題或者說后續的功能迭代都會更友好一些。當然也包括比如說現在命令行日志更細的分級，或者在整個數據庫級別做一些管理權限的一些支持。這些都是作為SRE可能會關心到的一些訴求。

關于整個OpenMLDB，我們這邊的一些建議和使用實踐就到這里了。同時也非常期望能看到更多的企業來去使用它，通過共同的“踩坑”和“填坑”把 OpenMLDB 做成一個更好的工具。

謝謝大家。