摘要：本文整理自阿里云計(jì)算平臺(tái)事業(yè)部 OLAP 引擎開(kāi)發(fā)工程師焦明燁老師在8月3日 Streaming Lakehouse Meetup Online（Paimon x StarRocks，共話實(shí)時(shí)湖倉(cāng)架構(gòu)）上的分享。主要分為以下四個(gè)內(nèi)容：
- StarRocks數(shù)據(jù)湖能力介紹
- 使用阿里云EMR StarRocks構(gòu)建基于Paimon的極速實(shí)時(shí)湖倉(cāng)
- StarRocks + Paimon的最新進(jìn)展
- StarRocks + Paimon未來(lái)規(guī)劃
我的分享將分為以下四個(gè)部分。首先，會(huì)介紹一下 StarRocks 的數(shù)據(jù)湖能力，也就是回答為什么要用 StarRocks 來(lái)進(jìn)行數(shù)據(jù)湖分析這個(gè)問(wèn)題；接下來(lái)，簡(jiǎn)單講一下阿里云上的 EMR Serverless Serverless StarRocks 是什么樣的、該怎么用它來(lái)構(gòu)建 Paimon 湖倉(cāng)；然后介紹近期在 StarRocks 訪問(wèn) Paimon 這個(gè)方向，我們實(shí)現(xiàn)了哪些新功能、做了哪些優(yōu)化，分別起到什么樣的作用，會(huì)在哪些方面為使用者賦能；最后，我會(huì)將我們正在進(jìn)行中的工作提前透?jìng)€(gè)底，告訴大家哪些新特性將會(huì)在未來(lái)上線。
一、StarRocks數(shù)據(jù)湖能力介紹
StarRocks 從 3.x 版本開(kāi)始，一直在著力打造數(shù)據(jù)湖分析的新范式，期望能利用好自己在 Warehouse 上的優(yōu)勢(shì)，積極擁抱各種湖格式，在湖上為使用者提供不輸給數(shù)倉(cāng)的使用體驗(yàn)。StarRocks 社區(qū)有一個(gè)非常專業(yè)的 DLA Team，專門(mén)負(fù)責(zé)開(kāi)發(fā)和優(yōu)化 StarRocks 的數(shù)據(jù)湖場(chǎng)景，因此打造了一款非常優(yōu)秀的數(shù)據(jù)湖分析引擎。StarRocks 數(shù)據(jù)湖分析的特點(diǎn)，我總結(jié)了兩個(gè)關(guān)鍵詞，也就是極速統(tǒng)一和簡(jiǎn)單易用。
- 極速統(tǒng)一
StarRocks 作為一個(gè)向量化引擎，具備全面的向量化執(zhí)行能力；此外StarRocks擁有現(xiàn)代化的CBO，全面兼容多種湖格式，無(wú)論是 Hive Paimon 還是 Iceberg Hudi Delta Lake 等等，都可以使用 StarRocks 進(jìn)行查詢；不僅如此，StarRocks 還實(shí)現(xiàn)了 IO 合并，優(yōu)化對(duì)象存儲(chǔ)的讀取，綜合下來(lái)相對(duì) Trino 能給帶來(lái) 3 倍以上的性能提升。
- 簡(jiǎn)單易用
StarRocks 建立與數(shù)據(jù)湖的連接非常方便快捷，是能夠做到開(kāi)箱即用的；與此同時(shí)，StarRocks 能夠兼容 Trino 的語(yǔ)法、關(guān)鍵字、函數(shù)轉(zhuǎn)義等，遷移便利快速，具有九成以上的兼容度。最后，StarRocks 能夠通過(guò) Audit Log、Profile 等多種方式對(duì)執(zhí)行的查詢進(jìn)行分析和處理，方便業(yè)務(wù)側(cè)進(jìn)行治理和優(yōu)化。下面我會(huì)詳細(xì)介紹這兩個(gè)方面。
StarRocks 優(yōu)勢(shì)：極速統(tǒng)一
前面已經(jīng)說(shuō)過(guò)，StarRocks 具有自己在 Warehouse 上的諸多優(yōu)勢(shì)，因此希望也能將類似的體驗(yàn)帶給湖上用戶。先來(lái)看左邊這幅圖，StarRocks內(nèi)部有統(tǒng)一的 Catalog 機(jī)制，不論是 StarRocks 的內(nèi)表，多種格式的湖上外表，還是 JDBC 外表，在邏輯上都是這樣一個(gè) Catalog 的概念。也就是說(shuō)，StarRocks 單一引擎就能夠同時(shí)訪問(wèn)包括但不限于內(nèi)表、Paimon 為代表的湖上外表、MySQL 為代表的 JBBC 外表等多種數(shù)據(jù)源，并且能夠支持跨數(shù)據(jù)源的 Join。只要用戶需要，任意一個(gè)數(shù)據(jù)源的數(shù)據(jù)都可以寫(xiě)入 StarRocks 內(nèi)表，實(shí)現(xiàn)統(tǒng)一的數(shù)據(jù)加工和處理，非常方便。此外內(nèi)外表的數(shù)據(jù)訪問(wèn)還能夠通過(guò) StarRocks 的 RBAC 機(jī)制進(jìn)行統(tǒng)一的權(quán)限管理。當(dāng)然，如果還想使用湖上常用的權(quán)限管理方案比如 Ranger，StarRocks 也是支持的。上面就體現(xiàn)了 StarRocks “統(tǒng)一”的地方所在。那么極速體現(xiàn)在哪里呢？我們來(lái)看右邊這張圖。右圖的上半部分是 StarRocks 的架構(gòu)，可以看到 FE 的查詢優(yōu)化器、BE 的查詢執(zhí)行器與 IO 引擎等等等等，唯獨(dú)少了什么？少了存儲(chǔ)對(duì)吧。在這個(gè)場(chǎng)景下，湖就是 StarRocks 的存儲(chǔ)。也就是說(shuō)，我們可以理解為，StarRocks 做到了把數(shù)據(jù)留在 HDFS 或者對(duì)象存儲(chǔ)上，在讀取的時(shí)候從這些文件系統(tǒng)中獲取需要的數(shù)據(jù)，后續(xù)的查詢與分析過(guò)程都和內(nèi)表別無(wú)二致。作為一款實(shí)現(xiàn)的很優(yōu)秀的查向量化引擎，根據(jù)我們的實(shí)測(cè)，即使只替換查詢引擎將 Trino 換成 StarRocks，其他什么都不做，速度就能提高3倍。不僅如此，StarRocks 還提供了多種多樣的特性，來(lái)對(duì)查詢進(jìn)行加速，比如內(nèi)存和磁盤(pán)的兩級(jí) Data Cache 緩存，物化視圖等。也就是說(shuō)，對(duì)于需要經(jīng)常執(zhí)行的湖上熱數(shù)據(jù)的查詢，StarRocks 能夠做到更快。
StarRocks 優(yōu)勢(shì)：簡(jiǎn)單易用
我直接舉例子說(shuō)明吧。先來(lái)看上面的兩幅圖。如果有熟悉 Trino 的觀眾應(yīng)該知道 Trino 想要新建一個(gè)連接器是怎么做的，我們是不是需要按照一定規(guī)范寫(xiě)一個(gè) Properties 文件，把這個(gè)文件分發(fā)到包括 Cooridinator 和全部worker 在內(nèi)的所有節(jié)點(diǎn)，然后重啟整個(gè)集群？不僅如此，一旦有一個(gè)配置配錯(cuò)了，Trino 直接拒絕服務(wù)了，啟動(dòng)都起不來(lái)。也就是說(shuō)，Trino 的 Catalog 管理和配置校驗(yàn)是 Server 啟動(dòng)的時(shí)候做的,對(duì)系統(tǒng)維護(hù)者來(lái)說(shuō)是一個(gè)考驗(yàn)。雖然 Trino 最近也做了 Dynamic Catalog，但這個(gè)功能默認(rèn)是關(guān)的，還是 Static 的，Trino 的人說(shuō)他有安全問(wèn)題。并且，Trino 的 Catalog 是插件形式的，即使用了 Dynamic Catalog，只要之前用這個(gè) Catalog 執(zhí)行過(guò)查詢，就還是會(huì)出現(xiàn)資源釋放不掉的情況，這個(gè)體驗(yàn)顯然是非常不好的。StarRocks 這邊就不一樣，外表 Catalog 默認(rèn)就是動(dòng)態(tài)創(chuàng)建和配置的，可以做到開(kāi)箱即用，只要我們保證網(wǎng)絡(luò)是暢通的，就可以在客戶端通過(guò)寫(xiě)SQL的方式直接創(chuàng)建一個(gè)外表 Catalog，我們看到上面我創(chuàng)建了一個(gè) type 是 Paimon 的 Catalog，這個(gè) Catalog 和 Paimon 自己的那個(gè) Catalog 是一一對(duì)應(yīng)的，我設(shè)置了 type 是 DLF，然后配置了 DLF 的 ID，上面全部的操作和 show 出來(lái)這個(gè) Catalog 里面的全部數(shù)據(jù)庫(kù)，加起來(lái)總共花了還不到一秒，是非常簡(jiǎn)單易用的。StarRocks 也支持對(duì)查詢進(jìn)行分析，這里就以最常用的 profile 為例，看這幅小圖，我故意構(gòu)造了一個(gè)執(zhí)行可能會(huì)比較慢的情境，我們可以看到一個(gè)簡(jiǎn)單的 select count(1) 花了4秒，數(shù)據(jù)量也只有一萬(wàn)條，這顯然是不合理的。但是只要我們拿到這個(gè)查詢的 ID，并且開(kāi)啟了 profile 功能，我們就可以獲取這個(gè)查詢對(duì)應(yīng)的 profile。拿到 query id 的方式有很多，包括從系統(tǒng)表里查找、翻找 Audit LOG 等等，這里只是其中一個(gè)方式，就是調(diào)用函數(shù)查詢。右邊的圖就是這個(gè) profile 的文本，當(dāng)然 profile 很長(zhǎng)啊，通常會(huì)有成百上千行，這里只截取了一個(gè)開(kāi)頭，但從開(kāi)頭已經(jīng)可以看到 Analyze 這個(gè)步驟花了2.6秒，占總時(shí)間的一半還多了，時(shí)間都花在這了，我們就可以看看為什么 Analyze 要用這么久，從而優(yōu)化我們的查詢業(yè)務(wù)。
數(shù)據(jù)湖分析常見(jiàn)場(chǎng)景
聊完了 StarRocks 數(shù)據(jù)湖分析的特點(diǎn)，我們?cè)賮?lái)說(shuō)說(shuō)幾個(gè)常見(jiàn)的場(chǎng)景，我就挑了這四個(gè)，分別是數(shù)據(jù)湖分析加速、湖倉(cāng)分層建模、冷熱融合以及全鏈路 ELT。我會(huì)以 Paimon 為例，說(shuō)說(shuō)這些場(chǎng)景分別是干什么用的、怎么用。
場(chǎng)景一：數(shù)據(jù)湖分析加速
第一個(gè)場(chǎng)景是最基礎(chǔ)的數(shù)據(jù)湖分析加速場(chǎng)景。我們對(duì)比的基準(zhǔn)都是 Trino。Trino 也是一個(gè)非常優(yōu)秀的 MPP 查詢引擎，非常穩(wěn)定而高效。剛剛也提到過(guò) StarRocks 是能夠兼容 Trino 的語(yǔ)法函數(shù)和關(guān)鍵字的，也就是我們把 Trino的語(yǔ)法解析器包了起來(lái)，Trino 的 SQL 傳進(jìn)來(lái)以后被我們轉(zhuǎn)成了 StarRocks 能看懂的的 AST，后面的流程，包括生成執(zhí)行計(jì)劃和查詢這些就和 StarRocks 原生語(yǔ)法都一樣了。開(kāi)啟的方式也很簡(jiǎn)單，就是設(shè)置一個(gè) session 變量sql_dialect =“Trino” 只要開(kāi)啟了這個(gè)，StarRocks 一秒變身成 Trino。具體的使用案例可以看阿里云 EMR Serverless StarRocks 的文檔，里面有實(shí)際的演示，包括開(kāi)啟前怎么提示函數(shù)解析錯(cuò)誤查詢失敗，開(kāi)啟后怎么得到結(jié)果等等。根據(jù)我們多家用戶的生產(chǎn)環(huán)境實(shí)際測(cè)試，可以保證兼容度高達(dá) 90% 以上，大多數(shù)常見(jiàn)的場(chǎng)景是都能兼容的?？赡?Trino 有一些特殊的函數(shù)，比如正則什么的，StarRocks 這邊沒(méi)有，這些也還在適配，可能有一些已經(jīng)適配完成了。
可以看到，以 Trino 等引擎為基準(zhǔn)，StarRocks 什么都不做，直接平替就能帶來(lái)3倍的性能提升，如果更進(jìn)一步開(kāi)啟 Data Cache，在緩存盤(pán)足夠大、緩存能夠大量命中的前提下，提升更是來(lái)到了6倍。新版本的 Data Cache 也是先進(jìn)了很多，增加了主動(dòng)的緩存預(yù)熱功能，并且增加了多項(xiàng)可觀測(cè)性的指標(biāo)，這個(gè)功能之前是關(guān)的，現(xiàn)在也是默認(rèn)打開(kāi)了。如果覺(jué)得還是不夠快，還想要再進(jìn)一步的提升，就需要后面的一些場(chǎng)景用到的手段了，我這里列舉了一些，后面都會(huì)一一涉及到。
場(chǎng)景二：湖倉(cāng)分層建模
第二個(gè)場(chǎng)景是湖倉(cāng)分層建模。我們先來(lái)思考一個(gè)問(wèn)題，直接查湖和內(nèi)表相比，慢在哪里呢？我們前面說(shuō)過(guò)，查內(nèi)表和查湖邏輯上只有存儲(chǔ)是不一樣的，那么答案也就顯而易見(jiàn)，IO 會(huì)是天然的第一道瓶頸。因?yàn)槲覀冃枰褦?shù)據(jù)從遠(yuǎn)端，通常是對(duì)象存儲(chǔ)，拉取到查詢引擎本地。在讀數(shù)據(jù)的時(shí)候，經(jīng)常會(huì)遇到網(wǎng)絡(luò)帶寬打滿的情況，即使帶寬沒(méi)打滿，也會(huì)有各種各樣的IO問(wèn)題。有人說(shuō)，我把數(shù)據(jù)從湖導(dǎo)入到內(nèi)表不就可以了，但是其一，本地存儲(chǔ)是很昂貴的，遠(yuǎn)遠(yuǎn)比對(duì)象存儲(chǔ)要貴，因此 warehouse 中往往不能存放全量的數(shù)據(jù)；其二，導(dǎo)入畢竟是要花時(shí)間花資源的，也需要專人來(lái)維護(hù)，等到導(dǎo)入完成了，查到的是什么時(shí)候的數(shù)據(jù)就不好說(shuō)了，這就局限了使用的情境。于是， StarRocks 就打造了這樣一個(gè)場(chǎng)景，即湖倉(cāng)分層建模?？梢詮膱D上看到，StarRocks 可以用物化視圖的形式，對(duì)對(duì)象存儲(chǔ)中存放的湖上數(shù)據(jù)進(jìn)行分層。物化視圖就相當(dāng)于內(nèi)表，查物化視圖會(huì)比直接查湖快很多。并且，物化視圖是可以嵌套的，在物化視圖之上又能構(gòu)建一個(gè)物化視圖，每層物化視圖都是一次聚合，每一層應(yīng)對(duì)不同的場(chǎng)景，越往上的數(shù)據(jù)越精煉，所有數(shù)據(jù)都可以訪問(wèn)到。物化視圖可以做到在分區(qū)粒度刷新，比如我們以天為粒度刷新，刷新的成本也是比較可控的。這樣一來(lái)，每層之間的依賴關(guān)系的維護(hù)，數(shù)據(jù)的異步刷新，以上這些所有工作，都只需要StarRocks 一個(gè)引擎就可以完成了。這樣，業(yè)務(wù)側(cè)就可以查到實(shí)時(shí)與近實(shí)時(shí)的數(shù)據(jù)，并且速度也是非?？斓?。
場(chǎng)景三：冷熱融合
下一個(gè)場(chǎng)景叫做冷熱融合，這個(gè)場(chǎng)景也是依賴物化視圖的。我們實(shí)際業(yè)務(wù)中，數(shù)據(jù)可能是會(huì)有冷熱之分的，冷數(shù)據(jù)就是那些可能很久才會(huì)查一次的數(shù)據(jù)，熱數(shù)據(jù)就是近期經(jīng)常要查詢的數(shù)據(jù)，如果數(shù)據(jù)全都在湖上，那冷熱數(shù)據(jù)可能就沒(méi)什么區(qū)別了，查的速度都差不多。這個(gè)時(shí)候，我們?cè)趧?chuàng)建物化視圖的時(shí)候就可以指定熱數(shù)據(jù)的周期，比如我這里設(shè)置了是三天，這樣物化視圖里就只會(huì)保留最近3天的數(shù)據(jù)。然后，StarRocks 還支持物化視圖改寫(xiě)的功能，也就是說(shuō)業(yè)務(wù)側(cè)不用改 SQL，SQL 寫(xiě)的查詢的還是原表，但是 StarRocks 會(huì)自動(dòng)判斷這個(gè)SQL命中了物化視圖中的數(shù)據(jù)。當(dāng)業(yè)務(wù)頻繁訪問(wèn)這三天的數(shù)據(jù)的時(shí)候，實(shí)際上訪問(wèn)的都是物化視圖，這樣速度就會(huì)很快。如果查詢?nèi)诤狭死錈釘?shù)據(jù)，StarRocks 支持自動(dòng)將冷熱分區(qū)合并，可以看右下的這個(gè)圖，熱數(shù)據(jù)會(huì)從MV中獲取，冷數(shù)據(jù)還是從湖上獲取，然后 StarRocks 內(nèi)部會(huì)先做一個(gè) Union，然后再執(zhí)行后續(xù)的處理。這也能加快查詢速度，但可能加快的沒(méi)有那么多。
場(chǎng)景四：全鏈路ETL
今天我想介紹的最后一個(gè)場(chǎng)景是全鏈路ELT。StarRocks 不僅是一個(gè)查詢引擎，他也是能夠?qū)懙?。換句話說(shuō)， StarRocks 具有一定的輕量 ETL 能力。首先 StarRocks 近期對(duì) Spill，也就是當(dāng)內(nèi)存不足時(shí)將查詢的中間結(jié)果向磁盤(pán)溢寫(xiě)這個(gè)能力進(jìn)行了大幅度的優(yōu)化，這可以說(shuō)是 ETL 必備的能力了。然后 StarRocks 可以通過(guò) VVP 也就是 Flink進(jìn)行 CTAS 或 CDAS，導(dǎo)入各種數(shù)據(jù)，打造適合大批量數(shù)據(jù)的全鏈路的實(shí)時(shí)數(shù)倉(cāng)，不止如此，StarRocks也是可以寫(xiě)湖的，社區(qū)對(duì) Iceberg 和 Hive 支持的比較好，也可以直接將 ORC 或者 Parquet 文件寫(xiě)到文件系統(tǒng)中。我們呢，近期也支持了寫(xiě) Paimon。這樣一來(lái)，StarRocks 擁有非常完善的 Connector Sink，可以讀內(nèi)表或者湖上的數(shù)據(jù)，再寫(xiě)回湖，實(shí)現(xiàn)降冷操作，寫(xiě)的速度也很快，寫(xiě) HDFS 的速度端到端能夠達(dá)到 Trino 的3倍，對(duì)象存儲(chǔ)由于 IO的影響很大快不了這么多但也是快的。這樣一來(lái)，就可以由 StarRocks 這一個(gè)引擎，完成一個(gè)全鏈路的輕量 ELT。
二、使用阿里云EMR StarRocks構(gòu)建基于Paimon的極速實(shí)時(shí)湖倉(cāng)
阿里云 EMR Serverless StarRocks 的特點(diǎn)我這里列舉了很多條，大家可以自己看一下。其中有些是社區(qū)版就有的能力，有些是我們自己的增強(qiáng)。我們做的優(yōu)化一方面是易用性上的，可以看最右邊這一列，阿里云的 EMR Serverless StarRocks 是完全云原生的，可以做到免運(yùn)維的即開(kāi)即用，彈性能力也很好；另一方面是生態(tài)上的，針對(duì)我們?cè)粕系漠a(chǎn)品做了各種各樣的集成，非常便利。對(duì)內(nèi)核我們根據(jù)情況也做了一些改進(jìn)，這里我就不一一列舉了，感興趣的大家歡迎來(lái)體驗(yàn)。
可以看到，我們的產(chǎn)品是分為三個(gè)版本的。存算一體就是比較傳統(tǒng)的，大家最常遇到的那個(gè)版本，數(shù)據(jù)都存放在云盤(pán)或本地盤(pán)上，好處是讀寫(xiě)性能非常高，適合追求高效率和高并發(fā)的大數(shù)據(jù)分析的用戶；存算分離是指存儲(chǔ)在 OSS 上，能夠節(jié)約大量存儲(chǔ)成本，并且存算分離集群的緩存做的也是很不錯(cuò)的，對(duì)于經(jīng)常訪問(wèn)的熱數(shù)據(jù)，能夠做到查詢性能對(duì)齊存算一體；前不久我們產(chǎn)品的存算分離版本也是摘掉了 beta 版的標(biāo)識(shí)，意味著基本穩(wěn)定，可以放心使用了。數(shù)據(jù)湖分析版本則是純數(shù)據(jù)湖查詢的版本，和今天我們講的場(chǎng)景關(guān)系比較密切；如果大家想找一個(gè) Trino 集群的平替，就想把一個(gè) Trino 集群平遷過(guò)來(lái)，選擇數(shù)據(jù)湖分析版本是不會(huì)有錯(cuò)的，當(dāng)然，這并不是說(shuō)其他版本就不能查外表了，也能查，但畢竟專業(yè)的人做專業(yè)的事，如果用戶只有湖分析的需求，選這個(gè)版本是更好的。
接下來(lái)我會(huì)用幾張圖來(lái)展示一下 EMR Serverless StarRocks 產(chǎn)品層面的一些功能與亮點(diǎn)?？梢钥吹剑@是一個(gè)即開(kāi)即用的 SQL Editor，伴隨著新建集群會(huì)自動(dòng)創(chuàng)建好。我們想要執(zhí)行任何 SQL，比如我這里的 Create external Catalog，只需要寫(xiě)在這里然后用鼠標(biāo)選中，就可以運(yùn)行了。這個(gè) SQL 也是可以持久保留的，不會(huì)丟。這里建好后，左邊數(shù)據(jù)庫(kù)管理這里就能過(guò)看到我們創(chuàng)建的 Catalog，可以看到這個(gè) Catalog 下有哪些數(shù)據(jù)庫(kù)哪些數(shù)據(jù)表，甚至可以展開(kāi)看到每張表的結(jié)構(gòu)是什么樣的。我們?nèi)绻雱?chuàng)建物化視圖也是一樣的，可以看到這個(gè) CREATE MATERIALILZED VIEW 語(yǔ)句，我們?cè)O(shè)置刷新間隔 INTERNAL 為1小時(shí)，這個(gè)物化視圖就會(huì)異步的以一小時(shí)一次的頻率去刷新當(dāng)然也可以手動(dòng)刷新，相關(guān)的命令有很多，大家可以參考文檔。
前面還提到了 StarRocks 的 Profile，這是一個(gè)非常常用且好用的工具，但是我們也看到了，打印出來(lái)的 profile 是一大長(zhǎng)串文本，雖然兼容并包，但里面各種各樣的指標(biāo)實(shí)在太多太長(zhǎng)了，非常不清晰，可能光是找哪個(gè)地方慢都要找半天還不一定能找到。于是我們就產(chǎn)品化了一個(gè)分析診斷工具，就是圖上的這個(gè)，我們 Manager 里是能看到所有查詢的，然后我們會(huì)把所有慢查詢單拎出來(lái)，默認(rèn)是執(zhí)行了5秒以上的就是慢查詢，當(dāng)然也可以自己調(diào)。對(duì)于執(zhí)行緩慢的查詢，在開(kāi)啟 profile 后，我們會(huì)提供一個(gè)可視化的 profile 查看頁(yè)面，就像這幅圖的右半部分，執(zhí)行越慢的算子就越紅。我這里是查了一個(gè) Paimon 外表，然后做了一個(gè)兩表 join，可以看到這個(gè)查詢中執(zhí)行最慢的就是 Connector Scan 也就是掃描表的時(shí)候慢，我們?nèi)绻胍獌?yōu)化就可以考慮加緩存等等?？傊@里就可以非常直觀的看到查詢的瓶頸在什么地方，方便我們進(jìn)行針對(duì)性的優(yōu)化。
最后再簡(jiǎn)單看一下監(jiān)控。監(jiān)控不止能看到集群的概況，也就是 CPU 內(nèi)存磁盤(pán)使用率這些，也能看到集群使用的相關(guān)信息，我圖里展示的只是很小的一部分，這是一個(gè)我自己的測(cè)試集群啊所以可能使用率不是很高，這里對(duì)查詢數(shù)、查詢延遲等大家關(guān)注的很多指標(biāo)都進(jìn)行了統(tǒng)計(jì)，并且這個(gè)界面是十分簡(jiǎn)潔的，一眼就能看清楚。
三、StarRocks + Paimon的最新進(jìn)展
接下來(lái)是第三部分，我會(huì)介紹一下 StarRocks 集成 Paimon 這塊，最近上新了什么東西，也就是一個(gè)簡(jiǎn)短的 Release Note，告訴大家我們支持了這些新特性。
首先一個(gè)比較重要的是，我們支持了讀 Paimon 的 Deletion Vector，目前還只支持了主鍵表，這類表相比傳統(tǒng)的 MOR 主鍵表，讀性能會(huì)好非常多。其次，我們支持了物化視圖改寫(xiě)，前面提到的很多場(chǎng)景都是建立在物化視圖改寫(xiě)之上的，沒(méi)有這個(gè)功能，我們之前聊的場(chǎng)景二和場(chǎng)景三都沒(méi)辦法實(shí)現(xiàn)，所以改寫(xiě)也是非常重要。第三，我們把 Paimon 也接入了 StarRocks 的 unified catalog，關(guān)于這個(gè)是什么我后面會(huì)說(shuō)。最后，我們之前也提到過(guò)， StarRocks 現(xiàn)在也能寫(xiě) Paimon了，雖然這個(gè)功能現(xiàn)在還沒(méi)發(fā)布，但是我可以告訴大家，現(xiàn)在已經(jīng)具備這個(gè)能力了。
說(shuō) Deletion Vector 很多人可能一臉懵，不知道這是個(gè)什么，接下來(lái)簡(jiǎn)單講講。Append 表的 Deletion Vector Paimon 那邊也在做，但是現(xiàn)在，Deletion Vector 還是一種特殊的主鍵表。傳統(tǒng)的主鍵表都是 MOR 的，也就是在讀的時(shí)候，會(huì)根據(jù)元數(shù)據(jù)對(duì) Upsert 了的文件進(jìn)行 Merge 也就是合并，每次讀都要 Merge。而 Deletion Vector則是用 Bitmap 來(lái)標(biāo)記，我數(shù)據(jù)文件中的哪些列是被 Upsert 掉了需要?jiǎng)h除的，也就不需要合并，只要跳過(guò)就可以了。右邊是我隨便找了一個(gè) Deletion Vector 表的文件結(jié)構(gòu)。如果大家對(duì)PK表的目錄結(jié)構(gòu)比較熟悉應(yīng)該一眼就能看出來(lái)，和傳統(tǒng)的 PK 表相比多了什么？多了一個(gè) index 路徑，以及 manifest 路徑下面多了一個(gè) index manifest。左邊這幅圖是摘自 Paimon 的官方網(wǎng)站，index 就是哪個(gè) bitmap，用來(lái)標(biāo)記哪些行是需要被刪掉的，index meta則是index的元數(shù)據(jù)，用來(lái)表示 index 里的這段 bitmap 對(duì)應(yīng)的是哪個(gè)數(shù)據(jù)文件等等。這和 Iceberg 的 Position Delete 在思想上是差不多的，只是實(shí)現(xiàn)方式不太一樣。很多人的業(yè)務(wù)實(shí)際使用中，由于查全量PK表太慢，都是查ro 表也就是做了 Full Compaction 的那一部分，這樣當(dāng)然會(huì)比較快，但是也就喪失了實(shí)時(shí)性。改用 Deletion Vector 后會(huì)怎么樣呢？我們來(lái)看實(shí)測(cè)。
下面的圖這是我們的實(shí)際測(cè)試結(jié)果。構(gòu)造了一個(gè)表，共有5億行數(shù)據(jù)，其中主鍵的范圍是0到10億，但由于主鍵是隨機(jī)的肯定會(huì)出現(xiàn)碰撞，這樣構(gòu)造的表的獨(dú)立主鍵數(shù)，也就是如果我們進(jìn)行 FullCompaction 剩下的條數(shù)大概 3.9億多不到4億。然后為了能看出來(lái)差異我故意搞了個(gè)最小的集群，一臺(tái)FE一臺(tái)BE，并且每個(gè)節(jié)點(diǎn)都只有8CU，這已經(jīng)不能再小了，用這個(gè)集群，可以看右邊，相比傳統(tǒng)的 MOR 表，Deletion Vector 執(zhí)行這種簡(jiǎn)單的聚合查詢會(huì)有 6～8 倍不等的性能提升，這可以說(shuō)是非?？捎^的。Deletion Vector 的缺點(diǎn)是寫(xiě)速度會(huì)比 MOR 慢一些，因?yàn)楫吘箤?xiě)的時(shí)候要寫(xiě) Index，做的事情更多了，只要能接受這個(gè)缺點(diǎn)，大家使用 PaimonPK 表的時(shí)候，我們都會(huì)推薦開(kāi)啟 Deletion Vector。
然后是物化視圖改寫(xiě)，我們前面說(shuō)了那么半天其實(shí)大家可能已經(jīng)知道改寫(xiě)是什么了。我這里再描述一下。直接看左邊吧，這是一個(gè) TPCH 的例子，我創(chuàng)建了一個(gè) t1 t2 join 的物化視圖，之后我執(zhí)行了一個(gè)t1 t2 t3三個(gè)表 join 的查詢，查的是原表。這種情況下，StarRocks 發(fā)現(xiàn)，這個(gè)查詢中有一個(gè) join 命中了物化視圖，然后這一部分的查詢就會(huì)自動(dòng)被改寫(xiě)到物化視圖上，這個(gè)過(guò)程用戶是不感知的，也就是所謂透明加速。目前來(lái)說(shuō)，支持的改寫(xiě)類型有我右邊列出來(lái)的這些。分別是完全匹配，部分匹配也就是表命中了但是 join 沒(méi)命中，以及 query delta 也就是左邊的這種情況。
物化視圖包含3表 join，查一個(gè)兩表 join 這個(gè)場(chǎng)景也就是 View delta Join 目前還命中不了，我們也在努力支持中。
然后是 Unified Catalog。有人可能會(huì)覺(jué)得，我所有湖格式的外表都在一個(gè)統(tǒng)一的 Metastore 里，我要給每種湖格式都建一個(gè) catalog，我覺(jué)得這還是太麻煩了，怎么辦？StarRocks提供了 Unified Catalog 這個(gè)功能，專門(mén)就針對(duì)這種情況，這是一個(gè)特殊的外表 catalog，里面什么表都有，只要元數(shù)據(jù)一樣，就都能查。Paimon也是支持了 unified catalog，目前支持的元數(shù)據(jù)類型是 hms 和 dlf，filesystem 算是 Paimon 特有的，目前確實(shí)還不太能支持。
最后來(lái)說(shuō)說(shuō) Paimon Sink，所謂Sink就是寫(xiě)入，業(yè)務(wù)中常常用來(lái)降冷。目前，我們把Paimon也接入了StarRocks的 Connector Sink 框架，可以說(shuō)基本的寫(xiě)入功能已經(jīng)具備了。但是當(dāng)前版本的限制還比較多，因?yàn)槲覀兪怯肑NI實(shí)現(xiàn)了一個(gè) Writer，導(dǎo)致不但速度比較慢，內(nèi)存消耗還很大。所以當(dāng)前版本的 Paimon Sink 我們還沒(méi)有對(duì)外正式發(fā)布。我們下一步會(huì)對(duì)接 StarRocks 的 Native Writer，爭(zhēng)取將一個(gè)完備的 Paimon Sink，在測(cè)試充分之后帶給用戶們。
四、StarRocks + Paimon未來(lái)規(guī)劃
最后一部分，請(qǐng)?jiān)试S我小小的劇透一下未來(lái)的規(guī)劃，其中每一項(xiàng)都是現(xiàn)在進(jìn)行時(shí)，我們來(lái)看看都有什么。
首先是元數(shù)據(jù)緩存。Paimon 的物化視圖改寫(xiě)現(xiàn)在有個(gè)痛點(diǎn)，就是每次改寫(xiě)的時(shí)候都會(huì)去重新確認(rèn)一下分區(qū)的最后更新時(shí)間來(lái)判斷分區(qū)是否過(guò)期，這個(gè)過(guò)程是要訪問(wèn)遠(yuǎn)端文件系統(tǒng)的，這就導(dǎo)致了當(dāng)數(shù)據(jù)量很小的時(shí)候，可能開(kāi)了改寫(xiě)比不開(kāi)還要慢。我們會(huì)實(shí)現(xiàn)一個(gè) Catalog 級(jí)別的緩存，這個(gè)據(jù)我所知應(yīng)該是在 Paimon 里實(shí)現(xiàn)了的，這能夠減少遠(yuǎn)端文件讀取，有效提高響應(yīng)速度。第二是一個(gè)分布式 Plan，這適用于 Big Meta Data 場(chǎng)景，因?yàn)?StarRocks 在查詢的時(shí)候FE是單點(diǎn)的，我們知道 Paimon 的元數(shù)據(jù)都是文件系統(tǒng)中的實(shí)體文件，雖然文件不大但是需要FE這邊來(lái)進(jìn)行反序列化和解析，這種多生產(chǎn)者單消費(fèi)者的場(chǎng)景很容易導(dǎo)致FE成為瓶頸乃至Full GC。所以我們就在想能不能用BE來(lái)做這件事。這在 Iceberg 那邊已經(jīng)實(shí)現(xiàn)了，Paimon 也正在進(jìn)行中。第三點(diǎn)是 Paimon 最近支持了索引，有 Bloom Filter 和 Bitmap 兩種，這兩個(gè)我們也都會(huì)支持。第四，StarRocks+Paimon 是我們 DLF 2.0 云上統(tǒng)一湖倉(cāng)的主力，這個(gè)場(chǎng)景未來(lái)會(huì)用的越來(lái)越多，希望能夠盡快給大家?guī)?lái)喜訊。最后，上面這些工作在 Paimon 和 StarRocks 兩邊都會(huì)有涉及，歡迎有意愿的開(kāi)發(fā)者來(lái)共創(chuàng)。
