建站
咨詢
售后
建站咨詢
新聞中心
大家好，很高興能和大家一起參加第四范式的技術(shù)日，做關(guān)于OpenMLDB 在 Akulaku 數(shù)據(jù)驅(qū)動(dòng)中應(yīng)用實(shí)踐的分享。
創(chuàng)新互聯(lián)建站主打移動(dòng)網(wǎng)站、成都網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)、網(wǎng)站改版、網(wǎng)絡(luò)推廣、網(wǎng)站維護(hù)、空間域名、等互聯(lián)網(wǎng)信息服務(wù)，為各行業(yè)提供服務(wù)。在技術(shù)實(shí)力的保障下，我們?yōu)榭蛻舫兄Z穩(wěn)定，放心的服務(wù)，根據(jù)網(wǎng)站的內(nèi)容與功能再?zèng)Q定采用什么樣的設(shè)計(jì)。最后，要實(shí)現(xiàn)符合網(wǎng)站需求的內(nèi)容、功能與設(shè)計(jì)，我們還會(huì)規(guī)劃穩(wěn)定安全的技術(shù)方案做保障。
我是來(lái)自 Akulaku 的馬宇翔。對(duì)于 OpenMLDB 來(lái)說(shuō)，我們算是一個(gè)早期的關(guān)注方，也是對(duì)它提供的解決方案存有濃厚興趣的企業(yè)方，所以今天我非常希望通過(guò)和大家分享我們的使用體驗(yàn)，來(lái)拋磚引玉。
場(chǎng)景需求和架構(gòu)設(shè)計(jì)
Akulaku 的數(shù)據(jù)架構(gòu)如圖所示。在特征計(jì)算層，有一些第三方和自研的底層工具；在模型計(jì)算層，做了一些開放架構(gòu)式的整合，盡可能地構(gòu)成了一個(gè)易擴(kuò)增且不依賴于某種特定工具的計(jì)算模式框架。這兩層負(fù)責(zé)支持智能應(yīng)用，比如說(shuō)把行為動(dòng)作、地理位置、設(shè)備指紋，也有銀行的一些反洗錢、設(shè)備風(fēng)控，以及基于用戶體驗(yàn)的智能客服、智能投顧。這些智能應(yīng)用基于相同的數(shù)據(jù)驅(qū)動(dòng)底座技術(shù)棧來(lái)提供服務(wù)，在設(shè)計(jì)滿足上述條件的方案時(shí)我們發(fā)現(xiàn)了OpenMLDB。
場(chǎng)景需求
作為Akulaku的數(shù)據(jù)部門，我們平時(shí)會(huì)面臨各自來(lái)自上下游的訴求。
下游業(yè)務(wù)方會(huì)要求我們盡可能支持各種各樣的功能，并且要求實(shí)時(shí)使用。我們常見的數(shù)據(jù)應(yīng)用方會(huì)需要同時(shí)使用離線計(jì)算、異步實(shí)時(shí)計(jì)算和硬實(shí)時(shí)計(jì)算以滿足決策需要。這些關(guān)鍵事件的決策不能出錯(cuò)，同時(shí)決策的穩(wěn)定性也要有所保障。
對(duì)于上游的訴求。比如說(shuō)運(yùn)維部門作為資源提供方，存在成本上的訴求，整個(gè)計(jì)算體系的資源希望盡可能的少。這里的少，更多也是滿足業(yè)務(wù)前提下的少，也就是要做到全局最優(yōu)。要求我們做精細(xì)化，可是精細(xì)化會(huì)帶來(lái)復(fù)雜度的提升，復(fù)雜度的提升又會(huì)降低穩(wěn)定性。上下游的訴求存在互斥，對(duì)于我們來(lái)說(shuō)是一個(gè)挑戰(zhàn)。
對(duì)于內(nèi)部的數(shù)據(jù)部門來(lái)說(shuō)，因?yàn)榇髷?shù)據(jù)工具的頻繁迭代，員工的學(xué)習(xí)成本很大。比如說(shuō) Spark 對(duì)批量計(jì)算友好，F(xiàn)link 對(duì)流式計(jì)算友好。但是為了每一種計(jì)算模式都單獨(dú)學(xué)一個(gè)工具，并且根據(jù)工具迭代跟進(jìn)學(xué)習(xí)，還可能要適應(yīng)改造去大幅改造現(xiàn)有系統(tǒng)，會(huì)導(dǎo)致從每一個(gè)員工到整個(gè)部門都難以獲得沉淀，且非常痛苦。
在易用性這邊，我們的使用方是希望整個(gè)平臺(tái)的設(shè)施足夠簡(jiǎn)單方便普及。既要處處可用，還要使用方式比較簡(jiǎn)單，不然各類型的服務(wù)角色比如說(shuō)開發(fā)者的訴求、分析師的訴求和算法工程師就不太一樣，很難都得到滿足。
其次重要的是可靠性，如果系統(tǒng)部署困難、三天兩崩，出現(xiàn)問(wèn)題無(wú)法自查，測(cè)試時(shí)間過(guò)長(zhǎng)都會(huì)給我們帶來(lái)很大的影響。所以以上的這些問(wèn)題，我們必須逐一避免或減少。
架構(gòu)設(shè)計(jì)
設(shè)計(jì)需求
那以上種種情景下，Akulaku 的架構(gòu)設(shè)計(jì)必須滿足下面兩個(gè)目標(biāo)。
首先我們需要同時(shí)做一個(gè)適用于 OLAP 和 OLTP 的一些高效融合計(jì)算的方案，它需要同時(shí)實(shí)現(xiàn) AI 和 BI 的數(shù)據(jù)執(zhí)行，必須保證 AI 和 BI 在整個(gè)的生產(chǎn)線上盡可能地使用同一份數(shù)據(jù)去運(yùn)行，而不是分別跑出兩個(gè)中間結(jié)果，然后再得出不一樣的結(jié)論，這個(gè)有很高的風(fēng)險(xiǎn)。
其次使用的工具需要兼容其他的工具，擁有良好的生態(tài)。如果沒(méi)有良好的生態(tài)，我們也很難把它放置在整個(gè)的架構(gòu)里。
經(jīng)過(guò)大量的二次開發(fā)和以上兩個(gè)目標(biāo)的篩選，我們明確了 Akulaku 數(shù)據(jù)架構(gòu)中工具需要支持五種條件：
第一，流批一體。它的批處理和實(shí)時(shí)處理應(yīng)該是一個(gè)相同的代碼能執(zhí)行，而且執(zhí)行出來(lái)的底層也應(yīng)該是相同的邏輯。
第二，高性能。因?yàn)樵诰€上的大并發(fā)和線下大吞吐量的任務(wù)都需要做一個(gè)支撐。
第三，場(chǎng)景無(wú)關(guān)。場(chǎng)景無(wú)關(guān)的這種特性，我們需要它具備一份數(shù)據(jù)可以處處使用，然后通過(guò)一些篩選，或者是說(shuō)加窗口的方式去改變它的條件。而不是說(shuō)它每換一個(gè)場(chǎng)景，我們都要重新去做一遍全量計(jì)算，或者全量數(shù)據(jù)導(dǎo)入導(dǎo)出。
第四，語(yǔ)義支持。語(yǔ)義支持更多是因?yàn)槲覀兊牧魇接?jì)算有很多的新的語(yǔ)義，就是像 Flink 每次版本迭代，都會(huì)根據(jù)具體的大家提的使用需求去迭代一些新的語(yǔ)義。那么對(duì)于這些語(yǔ)義，希望我們的工具也能得到一定的支持，它能做一些比較復(fù)雜的實(shí)時(shí)計(jì)算場(chǎng)景。
第五，工具高效。首先我們需要搭建計(jì)算框架的組件，它本身是能沉淀我們一些上線的流水線和線下分析的數(shù)據(jù)邏輯的這些能力。便于我們后續(xù)對(duì)它做一些迭代。
設(shè)計(jì)實(shí)現(xiàn)
最終成型的特征和數(shù)據(jù)計(jì)算架構(gòu)如上圖。
首先我們數(shù)據(jù)源可能會(huì)來(lái)自 HDFS、Kafka，還有其他服務(wù)語(yǔ)言的 SDK，或是 Nebula 這種比較特殊的圖計(jì)算工具?；谶@些不同的數(shù)據(jù)源，我們?cè)谥虚g做了流批一體化，最后主要選擇了 OpenMLDB 不同的模式去實(shí)現(xiàn)這一套的功能，再通過(guò)中間件去屏蔽掉流批一體化的不同組件對(duì)于一個(gè)邏輯的不同實(shí)現(xiàn)，保證接下來(lái)的融合計(jì)算組件能得到很好的降低復(fù)雜度的程度。
在 Akulaku，接近50%的、使用量最大的一部分指標(biāo)對(duì)實(shí)時(shí)性的要求較低，比如運(yùn)營(yíng)人員或者管理人員需要的數(shù)據(jù)指標(biāo)或是一些對(duì)實(shí)時(shí)性要求比較差的特殊模型，可能會(huì)使用性能或性價(jià)比相對(duì)較高、更加普適的 Rocksdb 模式去做。
接下來(lái)，如果對(duì)于生產(chǎn)要求，準(zhǔn)確性以及性能、計(jì)算速度要求比較高的批處理，我們就會(huì)使用背后基于 Spark FE 的 OpenMLDB 離線模式，它的性能比 Spark 要好很多倍。
如果有一些硬實(shí)時(shí)的計(jì)算，就會(huì)采用 OpenMLDB 的在線模式去做，可以做到大并發(fā)下面保持在幾十毫秒級(jí)這個(gè)水平，基本上是滿足 200 毫秒硬實(shí)時(shí)的門檻。
其他的一些補(bǔ)充，例如 Clickhouse 或者數(shù)據(jù)湖的組件，就會(huì)在指標(biāo)市場(chǎng)或更多的數(shù)據(jù)大盤上做一些支持，這兒就不贅述了。
在融合計(jì)算方面，我們主要基于 Ray 來(lái)完成的，F(xiàn)link 是我們之前的方案，但是目前是在Ray上去做全盤過(guò)渡。
數(shù)據(jù)應(yīng)用層，首先就是因?yàn)镺penMLDB的離線、在線一體化，所以我們可以很輕易地去把 MLOPs 做到持續(xù)交付到持續(xù)部署中間這一步的測(cè)試自動(dòng)化，可以簡(jiǎn)化非常多步驟，因?yàn)榇a是一致的。有了 OpenMLDB 之后，我們就可以比較輕松地去做 AutoML，其他的一些指標(biāo)市場(chǎng)和低代碼分析，完成一些更精細(xì)化的BI的應(yīng)用。
應(yīng)用細(xì)節(jié)和使用案例
為什么最后選擇把 OpenMLDB 選擇放在我們的核心位置？
第一，天然地支持流批一體。流批一體是 OpenMLBD 的一個(gè)核心，或說(shuō)主打功能，也是我們最剛需的功能。
第二，高性能。實(shí)測(cè) OpenMLDB 的性能時(shí)，如果從 Kafka 寫入數(shù)據(jù)最大可以做到 1 萬(wàn)的并發(fā)，當(dāng)然這是一個(gè)三節(jié)點(diǎn)的集群，可能更多節(jié)點(diǎn)的集群會(huì)有更好的效果，也就是說(shuō)OpenMLDB 的性能還有擴(kuò)展空間。在離線部分，OpenMLDB 性能超過(guò) Spark 數(shù)倍，基本上能滿足常規(guī)的一些使用。在實(shí)時(shí)計(jì)算部分，我們可以輕松地做到接近 200 的 qps，還可以保持 99%的 70 毫秒內(nèi)的計(jì)算。所以可以說(shuō)，OpenMLDB 是一個(gè)非常優(yōu)秀的線上和線下的計(jì)算工具，也是一個(gè)非常優(yōu)秀的可以同時(shí)滿足線上計(jì)算和線下計(jì)算的分析數(shù)據(jù)庫(kù)。
第三，場(chǎng)景無(wú)關(guān)。這個(gè)特性，它是可以在內(nèi)存做一個(gè)持久化，以及我們可以選擇使用持久化內(nèi)存版本，來(lái)確保我們數(shù)據(jù)在非常極端的情況下還是能夠得到恢復(fù)。通過(guò)這種方案，我們就可以在一次地把數(shù)據(jù)寫入之后，然后不停地通過(guò)SQL去控制計(jì)算力度，來(lái)確保我們可以不停地復(fù)用這些數(shù)據(jù)。
其次就是它自己也支持?jǐn)?shù)據(jù)過(guò)期。數(shù)據(jù)過(guò)期功能，就是說(shuō)可以把一些我們?cè)O(shè)定好的，過(guò)了多久不會(huì)使用的數(shù)據(jù)自動(dòng)給干掉，那就會(huì)省很多的一些空間，然后提高我們的存儲(chǔ)有效性。而且它還支持Rocksdb的版本，然后去做到降本增效的效果。
第四，語(yǔ)義支持。它支持了常見的流式場(chǎng)景需求，而且可以和批式的語(yǔ)法使用相同的一些算子。同時(shí)它也支持 UDF 或者 UDAF 一些特征工程的函數(shù)擴(kuò)展。這些擴(kuò)展方式對(duì)我們來(lái)說(shuō)還是很實(shí)用的，因?yàn)槟憧梢园岩恍┨囟ǖ倪壿嫹盅b成函數(shù)使用。
第五，工具高效。我們目前是使用一些像 Airflow之 類的工具去把整個(gè)的腳本做一些流水線的固化，然后這個(gè)固化擱置呢，OpenMLDB 在里面只需要配置一些類似 SQL 腳本就可以完成了，這個(gè)方式是比較便于實(shí)現(xiàn) MLOPs。同時(shí)OpenMLDB 也在打造和很多第三方工具的使用生態(tài)，去確保我們可以更便利地和其他工具打通。
應(yīng)用思考和建議
應(yīng)用思考
接下來(lái)的內(nèi)容想介紹一下 OpenMLDB 的應(yīng)用思考。
第一是關(guān)于標(biāo)準(zhǔn) SQL，我們是否一定要有一個(gè)滿足標(biāo)準(zhǔn) SQL 的工具呢？我們思考的結(jié)果是：其實(shí)也不那么必要。因?yàn)闃?biāo)準(zhǔn) SQL 語(yǔ)法更多的本質(zhì)目的是為了支持我們的邏輯一致性，但對(duì)于邏輯一致性，我們還是有其他的方案可以去實(shí)現(xiàn)的。比如大家如果是調(diào)用一些非標(biāo)的方法或者說(shuō)還未支持的方法，我們就必須調(diào)用自我實(shí)現(xiàn)的一些功能或者使用軟件工程的一些設(shè)計(jì)模式去解決掉這些分裝，或者解決掉多層復(fù)用的一些問(wèn)題。
這種方式，可以為我們換來(lái)超越標(biāo)準(zhǔn)SQL工具更多效率吧，這個(gè)效率其實(shí)是我們目前更為需要的一個(gè)東西。以我們自己的時(shí)間來(lái)說(shuō)，現(xiàn)在是一些復(fù)雜到可能數(shù)百行 SQL 盤活挖掘類型的任務(wù)，都是可以通過(guò)這種方案去解決掉的，它的擴(kuò)展空間還是非常大。
第二就是關(guān)于質(zhì)量和效能的平衡。質(zhì)量和效能，一般來(lái)說(shuō)我們希望它同時(shí)提升，但是更多時(shí)候它們也會(huì)有一些沖突。比如說(shuō)每當(dāng)提高復(fù)雜度，那質(zhì)量就會(huì)下降，但是提高復(fù)雜度可以精細(xì)化整個(gè)產(chǎn)品的一個(gè)效能。這些時(shí)候，我們就會(huì)選擇做一些錯(cuò)位對(duì)齊。
比如說(shuō)以 OpenMLDB 的三種實(shí)現(xiàn)模式來(lái)說(shuō)，我們會(huì)選擇使用特定的模式去實(shí)現(xiàn)盡可能恰當(dāng)?shù)哪切┨卣?。比如說(shuō) Rocksdb 的版本，我們就會(huì)做通用的指標(biāo)計(jì)算的工具。
在線計(jì)算的版本，我們就會(huì)用來(lái)做一個(gè)線上實(shí)時(shí)模型特征計(jì)算的工具。離線版本，我們就會(huì)用來(lái)做一些 T+1 的一些非常大批量數(shù)據(jù)的計(jì)算工具。就是說(shuō)，每種方案我其實(shí)都是可以以特定的數(shù)據(jù)或者說(shuō)場(chǎng)景盡可能最優(yōu)匹配。
這種方式我們還運(yùn)用到一些預(yù)計(jì)算、及時(shí)計(jì)算、軟加載或者窗口劃分之類的方案中，進(jìn)一步去優(yōu)化它的質(zhì)量和效能的平衡。
第三是在業(yè)務(wù)和技術(shù)上面，我們也需要做一些取舍。對(duì)技術(shù)來(lái)說(shuō)，希望我們的技術(shù)不產(chǎn)生任何的一些技術(shù)債，然后不停地去向上迭代。針對(duì)業(yè)務(wù)來(lái)說(shuō)，它需要的其實(shí)就是你的功能的完整實(shí)現(xiàn)以及上線時(shí)間。
關(guān)于這一點(diǎn)，我們是之前做了一些低代碼的工具去完成這個(gè)事情。如果是一個(gè)標(biāo)準(zhǔn)的低代碼工具，那它可能更多節(jié)省的時(shí)間是業(yè)務(wù)人員“拖拉拽”的時(shí)間，這個(gè)其實(shí)并不是業(yè)務(wù)真正想要的。他們更想要的其實(shí)是縮短上線時(shí)間，這個(gè)上線時(shí)間的減少就需要看你使用的工具能否直接從持續(xù)交付進(jìn)展到持續(xù)部署，這一點(diǎn)就是 OpenMLDB 在這兒起到的作用。就是我在這邊“拖拉拽”完成的一套低代碼工具背后實(shí)現(xiàn)生成的SQL，我就可以直接應(yīng)用在線上的版本去做部署。
使用細(xì)節(jié)
接下來(lái)，就是想介紹一些具體的使用細(xì)節(jié)，其實(shí)更多是一些 tips，可能會(huì)對(duì)大家使用這個(gè)工具的時(shí)候有一定的幫助。
首先就是在建表環(huán)節(jié)，我們可能會(huì)提供多種的索引定義方式。主流的方式就是使用 INDEX 里面 Key 的關(guān)鍵字，另外一種就是使用時(shí)間窗口里面的 TS 關(guān)鍵字，時(shí)間窗口的這種關(guān)鍵字就是用于所有基于時(shí)間的流式數(shù)據(jù)。使用 Key 關(guān)鍵字的，需要我們自己把這個(gè)事件進(jìn)行序列化，然后定義其中可以幫助你良好地把序列拆分開的一些字段用來(lái)做一個(gè)關(guān)鍵字。如果定義非常成功，就會(huì)讓我們使用這個(gè)工具的效果得到一個(gè)極大的提升。首先是邏輯會(huì)得到簡(jiǎn)化，其次就是性能也會(huì)提升很多。OpenMLDB 目前支持的時(shí)間字段就是兩種數(shù)據(jù)類型，這個(gè)也是需要注意到的。
接下來(lái)在查詢部分，當(dāng)我們查詢一條數(shù)據(jù)的時(shí)候，并不需要完整地把一個(gè)非常龐大的業(yè)務(wù) SQL 傳進(jìn)去。我們更多的是可以說(shuō)，只用到我關(guān)心的、所用到的字段和時(shí)間戳。其他不重要的可以使用一些替代值它給占位，有了這個(gè)占位之后，OpenMLDB 是已經(jīng)可以正常工作。
其次就是金融場(chǎng)景尤其常見的，不使用當(dāng)前行去計(jì)算一定時(shí)間窗口內(nèi)的數(shù)據(jù)。Akulaku 使用的解決方案是，我們排除掉當(dāng)前這個(gè)字典里面所在的毫秒時(shí)間戳里面的第一個(gè)字段，然后通過(guò)這種方式去把排除當(dāng)前行的操作解決掉。那么里面其他的字段，因?yàn)槭且粋€(gè)非時(shí)間戳，而且不是我們用到的字段，所以就是一個(gè)不重要的無(wú)所謂的數(shù)據(jù)，可以隨便的去做一些占位。這些操作是可以比較簡(jiǎn)化排除當(dāng)前行這個(gè)問(wèn)題的實(shí)現(xiàn)，不需要做一些非常復(fù)雜的邏輯。
建議和展望
最后想和大家介紹一下，我們最后使用下來(lái)的一些建議，以及對(duì) OpenMLDB 產(chǎn)品未來(lái)迭代的展望。
使用建議
關(guān)于這一塊相對(duì)比較經(jīng)典的使用建議的話，首先就是如果我們的邏輯它很復(fù)雜，那會(huì)導(dǎo)致線上驗(yàn)證和線下生效，這兩個(gè)事沒(méi)辦法在很短的時(shí)間內(nèi)判斷出邏輯是否一致，或者說(shuō)最后跑出來(lái)的結(jié)果能不能是一個(gè)數(shù)。對(duì)這種方式，我們就會(huì)建議使用 OpenMLDB 來(lái)去完成，因?yàn)樗翘烊幌麥邕@種問(wèn)題。
其次就是說(shuō)，如果我們參與計(jì)算的數(shù)據(jù)可以按照時(shí)間或者某個(gè)索引非常完美地去切片、做窗口，那我們也是建議使用這個(gè)工具。因?yàn)樗男阅軙?huì)非常的高，那我們的性價(jià)比和效率就會(huì)提升到一個(gè)非常可觀的一個(gè)程度。
第三部分就是說(shuō)，如果我們邏輯的開發(fā)人員不是那么關(guān)心大數(shù)據(jù)領(lǐng)域和高性能領(lǐng)域的一些問(wèn)題，甚至說(shuō)包括 SQL 優(yōu)化也不是很想考慮的話。那我們也建議使用這個(gè)工具來(lái)去做這個(gè)邏輯的開發(fā)。
就目前來(lái)說(shuō)，就我們使用下來(lái) OpenMLDB 本身的性能、底層的優(yōu)化已經(jīng)做得很到位了。關(guān)于 SQL 語(yǔ)義這塊特別影響性能的實(shí)現(xiàn)，比如說(shuō)多表聯(lián)做這種，它是直接不支持的，那么也就是不會(huì)讓邏輯開發(fā)人員寫出來(lái)一些非常低性能的代碼，可能會(huì)造成系統(tǒng)血崩之類的問(wèn)題。
其次就是我們建議要使用好 OpenMLDB，我們希望企業(yè)內(nèi)部還是需要有比較清晰的數(shù)據(jù)治理的能力。不然的話，可能我在第一步的過(guò)程中，就是導(dǎo)入OpenMLDB 里面的數(shù)據(jù)可能就會(huì)相對(duì)比較亂。它更多也不是一個(gè)在內(nèi)部做數(shù)據(jù)清洗的一個(gè)工具。如果要用好 OpenMLDB 的強(qiáng)項(xiàng)——計(jì)算，那我們最好是把一個(gè)盡可能清晰的，需要用它算的數(shù)據(jù)輸入進(jìn)去，然后可以直接執(zhí)行后面的相應(yīng)邏輯，而不是一直收到報(bào)錯(cuò)。
迭代展望
接下來(lái)就是我們認(rèn)為OpenMLDB后面還會(huì)支持的一些功能，然后以便于更加方便我們的一些使用。
第一，就是目前看起來(lái)它是有在做一些進(jìn)一步的支持異構(gòu)資源，去降低存儲(chǔ)成本之類的事情。這個(gè)操作后續(xù)的衍生，我們認(rèn)為就會(huì)去做一些更進(jìn)一步的精細(xì)化的使用配置。同樣的一個(gè)表里面，甚至可以支持某些字段的計(jì)算，例如需要用內(nèi)存版本某些字段的計(jì)算，用 Rocksdb 去做就可以了。這種方式，可以讓資源的精細(xì)化管理做到一個(gè)相對(duì)比較極致的水平。只要所謂的成本和產(chǎn)出的 ROI 能達(dá)到更高的話，那 OpenMLDB 的應(yīng)用場(chǎng)景其實(shí)就會(huì)更寬。
第二，目前它的數(shù)據(jù) IO 和 SDK 支持來(lái)看，它后面還有很多可以支持的一些工作。比如說(shuō)目前的離線數(shù)據(jù)導(dǎo)入，我們一般是使用 HDFS 或者 CSV。那還有比較新的一些數(shù)據(jù)或者說(shuō)離線的數(shù)據(jù)湖，或者說(shuō)在線的一些連接器，那都是它后續(xù)可以做一些實(shí)現(xiàn)的。
其次就是關(guān)于 SDK 的支持，我們目前在 Java SDK 和 Python SDK 使用上面，如果相對(duì)于其他一些更成熟的數(shù)據(jù)工具，我們希望能有一種像是支持 Python 多線程?；蛘邔?duì) Java 來(lái)說(shuō)，可能就是它的生成文件形式可以更友好，或者說(shuō)它可以直接有一個(gè)非常明顯的開關(guān)功能，都可以幫助我們更好地去便利使用 OpenMLDB。
第三，我們期待有更多來(lái)自社區(qū)的文檔貢獻(xiàn)，比如說(shuō) OpenMLDB 有很多的寶藏功能，比如說(shuō) UDF 函數(shù)的一些實(shí)現(xiàn)，或者是關(guān)于在線和離線兩種不同模式底層的數(shù)據(jù)如何做一致性之類的設(shè)計(jì)能夠給還未入門或者說(shuō)剛?cè)腴T的開發(fā)者一個(gè)更加充足的介紹，那我相信它的轉(zhuǎn)化和使用量也會(huì)得到更迅速的一個(gè)增長(zhǎng)。
第四，我們認(rèn)為 OpenMLDB 可以有一個(gè)更友好的 SRE 支持的設(shè)計(jì)，比如說(shuō)關(guān)于數(shù)據(jù)過(guò)期是一個(gè)非常好的功能。但是如果是生產(chǎn)環(huán)境下的話，出了一些問(wèn)題就不太好回溯，也不太好去做進(jìn)一步的迭代。那這個(gè)時(shí)候，如果我們可以有一個(gè)選項(xiàng)是把它做一個(gè)異步轉(zhuǎn)存，再或者后面再補(bǔ)充一些定時(shí)刪除，對(duì)于 SRE 這邊的排查問(wèn)題或者說(shuō)后續(xù)的功能迭代都會(huì)更友好一些。當(dāng)然也包括比如說(shuō)現(xiàn)在命令行日志更細(xì)的分級(jí)，或者在整個(gè)數(shù)據(jù)庫(kù)級(jí)別做一些管理權(quán)限的一些支持。這些都是作為SRE可能會(huì)關(guān)心到的一些訴求。
關(guān)于整個(gè)OpenMLDB，我們這邊的一些建議和使用實(shí)踐就到這里了。同時(shí)也非常期望能看到更多的企業(yè)來(lái)去使用它，通過(guò)共同的“踩坑”和“填坑”把 OpenMLDB 做成一個(gè)更好的工具。
謝謝大家。
當(dāng)前名稱：如何選擇架構(gòu)中的底層工具？
當(dāng)前URL：http://www.5511xx.com/article/cddspdi.html
