大家好，很高興能和大家一起參加第四范式的技術(shù)日，做關(guān)于OpenMLDB 在 Akulaku 數(shù)據(jù)驅(qū)動中應(yīng)用實踐的分享。

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

場景需求和架構(gòu)設(shè)計

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

場景需求

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

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

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

對于內(nèi)部的數(shù)據(jù)部門來說，因為大數(shù)據(jù)工具的頻繁迭代，員工的學(xué)習(xí)成本很大。比如說 Spark 對批量計算友好，F(xiàn)link 對流式計算友好。但是為了每一種計算模式都單獨學(xué)一個工具，并且根據(jù)工具迭代跟進學(xué)習(xí)，還可能要適應(yīng)改造去大幅改造現(xiàn)有系統(tǒng)，會導(dǎo)致從每一個員工到整個部門都難以獲得沉淀，且非常痛苦。

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

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

架構(gòu)設(shè)計

設(shè)計需求

那以上種種情景下，Akulaku 的架構(gòu)設(shè)計必須滿足下面兩個目標。

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

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

經(jīng)過大量的二次開發(fā)和以上兩個目標的篩選，我們明確了 Akulaku 數(shù)據(jù)架構(gòu)中工具需要支持五種條件：

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

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

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

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

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

設(shè)計實現(xiàn)

最終成型的特征和數(shù)據(jù)計算架構(gòu)如上圖。

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

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

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

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

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

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

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

應(yīng)用細節(jié)和使用案例

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

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

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

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

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

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

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

應(yīng)用思考和建議

應(yīng)用思考

接下來的內(nèi)容想介紹一下 OpenMLDB 的應(yīng)用思考。

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

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

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

比如說以 OpenMLDB 的三種實現(xiàn)模式來說，我們會選擇使用特定的模式去實現(xiàn)盡可能恰當(dāng)?shù)哪切┨卣?。比如說 Rocksdb 的版本，我們就會做通用的指標計算的工具。

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

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

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

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

使用細節(jié)

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

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

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

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

建議和展望

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

使用建議

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

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

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

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

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

迭代展望

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

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

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

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

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

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

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

謝謝大家。