一、ByConity 產(chǎn)生背景

ByConity 是基于 ClickHouse 產(chǎn)生。ClickHouse 社區(qū)已經(jīng)發(fā)展了很多年。字節(jié)從 2017 年開(kāi)始大規(guī)模使用 ClickHouse。在驗(yàn)證了多款產(chǎn)品之后，最終發(fā)現(xiàn) ClickHouse 是唯一能夠支撐字節(jié)當(dāng)時(shí)的體量以及保證查詢體驗(yàn)的產(chǎn)品。在使用 ClickHouse 過(guò)程中遇到了很多的痛點(diǎn)，比如說(shuō)運(yùn)維成本居高不下，擴(kuò)縮容成本高，同時(shí)也有關(guān)聯(lián)查詢的局限性。

字節(jié)從 18 年開(kāi)始對(duì) ClickHouse 進(jìn)行很多功能優(yōu)化，但字節(jié)的業(yè)務(wù)發(fā)展比較快，無(wú)論是數(shù)據(jù)量還是業(yè)務(wù)的復(fù)雜度，上升得非常快。發(fā)展了兩年之后發(fā)現(xiàn)簡(jiǎn)單的功能迭代可能已經(jīng)難以滿足業(yè)務(wù)發(fā)展需要，所以進(jìn)行了整個(gè)架構(gòu)重新的設(shè)計(jì)。當(dāng)時(shí)從擁抱云原生架構(gòu)的初衷，重新設(shè)計(jì)了存算分離架構(gòu)，當(dāng)時(shí)這個(gè)版本可以算是一個(gè) ByConity 的雛形。這個(gè)版本之后，字節(jié)內(nèi)部有很多業(yè)務(wù)從原先 MPP 架構(gòu)向存算分離架構(gòu)遷移。目前已經(jīng)有一半以上的場(chǎng)景已經(jīng)遷移到存算分離架構(gòu)上來(lái)。在 22 年的時(shí)候，我們決定將這些優(yōu)化回饋到社區(qū)。在與 ClickHouse 官方討論之后，官方建議我們自己去開(kāi)源產(chǎn)品。在 23 年 1 月份字節(jié)發(fā)布了開(kāi)源的第一個(gè)版本 Beta 版。然后經(jīng)歷了大概半年的社區(qū)的反饋，以及本身功能的迭代后，我們?cè)?23 年 5 月份正式發(fā)布了 GA 版本。現(xiàn)在 ByConity GA 版本已經(jīng)發(fā)展了一年多時(shí)間。在這當(dāng)中也陸續(xù)推出了幾個(gè)小版本，像 0.2.0、0.3.0、0.4.0 等等。這些小版本當(dāng)中，一方面是進(jìn)行功能的迭代以及問(wèn)題的修復(fù)，另一方面不停地進(jìn)行性能的優(yōu)化。

這里說(shuō)下使用 ClickHouse 的一些痛點(diǎn)，ClickHouse 是一個(gè)典型的 MPP 架構(gòu)數(shù)據(jù)庫(kù)，它有很好的性能優(yōu)勢(shì)。比如說(shuō)單表查詢，尤其是聚合查詢的時(shí)候，它擁有領(lǐng)先其他競(jìng)品的性能，但是使用它的時(shí)候也會(huì)有很多的痛點(diǎn)，其中一個(gè)最主要的痛點(diǎn)就是擴(kuò)容成本非常高，因?yàn)楸旧砑軜?gòu)的設(shè)計(jì)的原因，以及數(shù)據(jù)與計(jì)算節(jié)點(diǎn)捆綁的因素。我們每次進(jìn)行擴(kuò)容的時(shí)候，需要數(shù)據(jù)交進(jìn)行重分布，會(huì)有很高的運(yùn)維成本以及數(shù)據(jù)驗(yàn)證等資源方面的代價(jià)，對(duì)線上會(huì)是很大的影響。同時(shí)它很難平衡資源的有效利用，以及資源隔離。比如說(shuō)如果希望一個(gè)業(yè)務(wù)能夠與其他業(yè)務(wù)進(jìn)行隔離，最好給他一個(gè)單獨(dú)的集群，但是單獨(dú)集群又很難把硬件資源很好地利用起來(lái)，因?yàn)楫?dāng)業(yè)務(wù)比較空閑的時(shí)候，這些資源就可能會(huì)浪費(fèi)。

在讀寫方面也是一樣，有時(shí)候如果大家都是讀寫同一份資源上，寫請(qǐng)求一旦大了之后，就會(huì)很大影響線上的一些讀請(qǐng)求，讀寫這塊也沒(méi)有辦法很好的分離。同時(shí) ClickHouse 另外一個(gè)比較痛的點(diǎn)是雖然它的單表查詢性能非常好，但是在多表 join 這塊是業(yè)界一直詬病的，沒(méi)有辦法做很高效多表查詢，它的 join 優(yōu)化效果非常差。所以我們?cè)谑褂?ClickHouse 時(shí)，通常使用方法是在數(shù)據(jù)進(jìn)入 ClickHouse 之前，進(jìn)行很多的前期處理，會(huì)由 ETL 過(guò)程生成大寬表，然后把大寬表內(nèi)容導(dǎo)入到 ClickHouse 后再進(jìn)行查詢。

二、ByConity 設(shè)計(jì)與優(yōu)化

ByConity 是怎樣解決這些痛點(diǎn)的呢？首先來(lái)介紹一下 ByConity 整個(gè)架構(gòu)設(shè)計(jì)，ByConity 架構(gòu)可以分為三層，最上面是共享服務(wù)層，中間是計(jì)算層，最下面存儲(chǔ)層，先看最上面共享服務(wù)層，這層是整個(gè)集群所共享的公共資源節(jié)點(diǎn)，這些節(jié)點(diǎn)中有一組就是 ByConity 整個(gè)集群的入口，一組 Server 以及多個(gè)共享的服務(wù)，如 TSO，Resource Manager、Daemon Manager 等組成，同時(shí)這層有元數(shù)據(jù)存儲(chǔ)，ByConity 有統(tǒng)一的中央元數(shù)據(jù)層。Server 承擔(dān)的工作主要是 SQL 解析、生成執(zhí)行計(jì)劃，以及優(yōu)化器對(duì)執(zhí)行計(jì)劃進(jìn)行優(yōu)化，同時(shí)它會(huì)跟元數(shù)據(jù)存儲(chǔ)打交道，把元數(shù)據(jù)存儲(chǔ)很好地管理起來(lái)，并且 Server 里有元數(shù)據(jù)的 Cache，所以可以加速元數(shù)據(jù)訪問(wèn)。這些共享服務(wù)中其中比較重要的一個(gè)是 TSO，它生成分布式事務(wù)所需要單調(diào)遞增的時(shí)間戳，Resource Manager 主要管理 Workload 中間計(jì)算中所需要的資源，并進(jìn)行資源分配的組件。Demon Manager 管理 Daemon。Daemon 類似 ClickHouse 里經(jīng)常所需要做的 Merge task，在 ByConity 里也同樣需要做。同時(shí)還有一些比較重要的后臺(tái)進(jìn)程，比如像 Kafka 的 Consumer，如果我們?cè)谶M(jìn)行實(shí)時(shí)數(shù)倉(cāng)的數(shù)據(jù)導(dǎo)入，需要用到這樣的組件，也是由 Daemon Manager 進(jìn)行管理。

上面是服務(wù)層的組件，中間 Worker 層設(shè)計(jì)是無(wú)狀態(tài)的，這是存量分離的比較重要因素。也就是說(shuō) worker 是可以彈性無(wú)感的擴(kuò)縮容。為什么能做到呢？首先數(shù)據(jù)存放在遠(yuǎn)端的 CFS 層，遠(yuǎn)端數(shù)據(jù)層可以支持 HDFS 或者 S3 存儲(chǔ)。Worker 查詢會(huì)從遠(yuǎn)端存儲(chǔ)把數(shù)據(jù)拿過(guò)來(lái)，然后在本地會(huì)有一定的基于磁盤的緩存進(jìn)行加速，但這個(gè)緩存是由集群完全自動(dòng)管理的，也不涉及到數(shù)據(jù)的一致性等，所以可以認(rèn)為 Worker 是無(wú)狀態(tài)的。同時(shí)引入了 Virtual Warehouse 的概念，一組 Worker 可以成為一個(gè) Virtual Warehouse，資源隔離基本上基于這個(gè)概念。比如說(shuō)架構(gòu)里推薦的是做讀寫分類，也就是讀和寫 Load 需要建立不同的 Virtual warehouse 去做，這樣的話就可以相當(dāng)程度上能夠讓這個(gè)重的寫操作不會(huì)去影響到在線讀操作。同樣在不同業(yè)務(wù)之間的資源隔離也可以用類似的方式去做。

上面介紹整個(gè)架構(gòu)設(shè)計(jì)，再來(lái)說(shuō) ByConity 在功能的優(yōu)化做了哪些。首先比較重要的就是解決了 ClickHouse 復(fù)雜查詢這個(gè)大痛點(diǎn)。ByConity 對(duì)這種復(fù)雜多 Join 查詢支持得非常好。為什么可以支持得非常好呢？這當(dāng)中就需要涉及到整個(gè)查詢 Pipeline 的改造，以及自研優(yōu)化器的引入。整個(gè)計(jì)算層的改造主要是比如在 Server 改寫了整個(gè) ClickHouse 解釋器，里面引入了 Query Planner 組件，Planner 可以生成 Query plan，然后 Query plan 經(jīng)優(yōu)化器優(yōu)化，可以生成改寫后的經(jīng)過(guò)優(yōu)化的 Query plan。每個(gè) Query plan 是由多個(gè) Plan Segment 組成。每個(gè) Plan Segment 都可以下發(fā)到后面的計(jì)算層進(jìn)行進(jìn)一步的解析和計(jì)算。每一個(gè) Plan segment 的計(jì)算可以使用類似原先 ClickHouse 的Pipeline schedule 的執(zhí)行方式。在這個(gè)過(guò)程中就會(huì)涉及到自研的查詢優(yōu)化器，對(duì) Query Plan 進(jìn)行優(yōu)化和改寫。支持比較常見(jiàn)的優(yōu)化手段，比如 RBO、CBO。RBO 是基于規(guī)則的，有基于像 Visitor 的改寫方式，以及基于這種 Query patterner 的改寫方式。基于 Visitor 的比如像謂詞下推，列裁剪等。CBO 是基于 Cost，是用 Cascade 這種搜索框架對(duì) Join 進(jìn)行 Reorder。同時(shí)優(yōu)化器還支持一些高級(jí)的優(yōu)化手段，像 runtime filter，或者像 CT 的一些優(yōu)化等等。

優(yōu)化的效果也發(fā)過(guò)文章，在 ByConity 最初 GA 的時(shí)候，就對(duì)比了業(yè)界的一些比較流行的開(kāi)源產(chǎn)品，在 TPC-DS 的標(biāo)準(zhǔn)數(shù)據(jù)集上跟這些產(chǎn)品做了 Benchmark，結(jié)果 ByContiy 整體性能非常好。可以在外面找到這些文章看 Benchmark 的細(xì)節(jié)。其實(shí)在 ByConity 開(kāi)源并進(jìn)行了一年迭代之后，也有了更多的性能優(yōu)化，包括像 QPS 的優(yōu)化、Projection 的優(yōu)化等，這些優(yōu)化會(huì)進(jìn)一步提升性能。目前如果再重新做 TPC-DS Benchmark 會(huì)進(jìn)一步提升。

除了本身的性能優(yōu)化以外，ByConity 還有一些在真正生產(chǎn)使用當(dāng)中所需要的非常重要的能力，比如說(shuō)一致性。ClickHouse 另外一個(gè)比較痛的點(diǎn)就是它缺乏一致性，因?yàn)樗旧硎遣恢С质聞?wù)的，它只能在一個(gè)有限的范圍內(nèi)支持一定的原子性 ACID 級(jí)別，但這在很多業(yè)務(wù)場(chǎng)景下是不夠的。如果不支持事務(wù)，在很多時(shí)候一旦上游發(fā)生 fail，需要進(jìn)行 recover 的時(shí)候，或者說(shuō)數(shù)據(jù)有一定的異常，需要進(jìn)行 Retry 等一些操作的時(shí)候，如果缺乏一致性，會(huì)對(duì) OLAP 中的數(shù)據(jù)產(chǎn)生很大影響，也會(huì)影響到后續(xù)的業(yè)務(wù)分析以及后續(xù)系統(tǒng)的正確性。所以在 OLAP 系統(tǒng)中，事務(wù)和一致性也是比較重要的。在 ByConity 中是支持分布式事務(wù)的，并且能夠支持到 Read committed 的隔離級(jí)別。怎么做到的呢？首先 ByConity 有統(tǒng)一的元數(shù)據(jù)層，這個(gè)元數(shù)據(jù)層是用 FoundationDB 開(kāi)源組件實(shí)現(xiàn)的，F(xiàn)oundationDB 本身支持原子性操作，比如像 CAS，所以 ByConity 可以很好地利用 FoundationDB 的能力去實(shí)現(xiàn)分布式事務(wù)當(dāng)中的一些比較重要的原子操作。另外就是引入了分布式的時(shí)鐘，就是這個(gè) TSO 組件可以為分布式事務(wù)提供單調(diào)遞增的事務(wù) ID。這是比較重要的分布式事務(wù)中的組件吧。因?yàn)檫@些組件的支持，可以實(shí)現(xiàn)典型的兩階段提交。在階段一寫入數(shù)據(jù)的時(shí)候，可以同時(shí)寫入事務(wù) ID，并且將 undo buffer 寫入遠(yuǎn)端的存儲(chǔ)并提交元信息。第二階段是對(duì)這個(gè)事務(wù)真的進(jìn)行提交，提交事務(wù)的時(shí)候，可以根據(jù)事務(wù)記錄的提交時(shí)間進(jìn)行處理。比如如果事務(wù)執(zhí)行成功，可以真正更新 part 的提交時(shí)間，把 undo buffer 清理掉，并且把這個(gè)事務(wù)的記錄點(diǎn)給清理掉。如果事務(wù)失敗，需要進(jìn)行一些回滾。那剛才記錄的 undo buffer 就可以在回滾中發(fā)揮作用，首先把中間過(guò)程的 Part 數(shù)據(jù)刪掉，因?yàn)槭∷呀?jīng)沒(méi)有用了。根據(jù) Undo buffer 把遠(yuǎn)端存儲(chǔ)當(dāng)中已經(jīng)寫了的數(shù)據(jù)進(jìn)行回滾，同時(shí)在這些都處理好之后，再把 Undo buffer 和事務(wù)記錄給處理掉，這就是一個(gè)非常典型的兩階段提交的分布事務(wù)操作。由于這樣的支持，ByConity 在一致性上面是有很好的保證。

另外因?yàn)槭谴嫠惴蛛x架構(gòu)，所以大家可能會(huì)比較擔(dān)憂一些問(wèn)題，比如說(shuō)對(duì)遠(yuǎn)端存儲(chǔ)的數(shù)據(jù) IO 是不是真的能夠滿足查詢的需要？所以在 ByConity 對(duì)冷讀，也就是直接對(duì)遠(yuǎn)端存儲(chǔ)讀寫的操作，做了很多的優(yōu)化。冷讀的性能無(wú)論如何都會(huì)比已經(jīng)在 Disk Cache 當(dāng)中緩存的數(shù)據(jù)的熱讀操作還是要慢。ByConity 一直在對(duì)這個(gè)過(guò)程進(jìn)行優(yōu)化，使得它對(duì)整個(gè)系統(tǒng)的查詢影響盡量小。這些優(yōu)化手段包括很多很細(xì)節(jié)優(yōu)化，很多也是借鑒了操作系統(tǒng)的 IO 優(yōu)化手段，以及其他分布式系統(tǒng)中的 IO 優(yōu)化手段。下面介紹其中的一些。

比如 IO schedule 就是一個(gè)比較重要的組件，這個(gè)組件能夠讓 IO 請(qǐng)求的并發(fā)量比較大，并且請(qǐng)求所涉及到的數(shù)據(jù)比較接近的情況下，能夠得到比較好的優(yōu)化效果。首先會(huì)對(duì) lO 請(qǐng)求進(jìn)行一定的合并和分解，合并是針對(duì)比如兩個(gè) lO 請(qǐng)求比較小，但它其實(shí)是相鄰的，或者說(shuō)基本上相鄰，中間可能隔了很少的一部分?jǐn)?shù)據(jù)，那可以把這兩個(gè) IO 請(qǐng)求合并成一個(gè)。拆分是說(shuō)有的時(shí)候一個(gè) IO 請(qǐng)求非常大，它所涉及到的數(shù)據(jù)塊非常大，如果直接進(jìn)行請(qǐng)求的話，會(huì)有一個(gè)比較高的等待時(shí)間。所以在這種情況下，我們可以把它拆分成多個(gè) lO 請(qǐng)求，然后采用并發(fā)方式去 load 數(shù)據(jù)。這兩種情況在真正 IO 過(guò)程中其實(shí)都會(huì)有。

同時(shí) ByConity 也會(huì)做一些 Prefetch 預(yù)讀，尤其是在遠(yuǎn)端存儲(chǔ)的單次 IO 請(qǐng)求比較高延，但是可以引入很多并發(fā)的情況下，它能夠工作得非常好。另外在預(yù)讀的時(shí)候，ByConity 引入了很多細(xì)節(jié)的考量，能夠在 ClickHouse 的數(shù)據(jù)結(jié)構(gòu)情況下使預(yù)讀效果盡量的好。我們知道 ClickHouse 對(duì)遠(yuǎn)端數(shù)據(jù)的 IO 讀取，是用 Mark range 作為單位的，在讀取一個(gè) Block 數(shù)據(jù)的時(shí)候，它會(huì)看 mark 的 range，在每個(gè) mark range 中我們可以把數(shù)據(jù)分解成多個(gè) task 去進(jìn)行并行的讀取。尤其在 S3 這樣的存儲(chǔ)時(shí)，可以去發(fā)很多的并行讀的線程去同時(shí)做讀取，在這種時(shí)候拆分成 task 是非常有效的。這些 task 分別去做 IO 的讀取，同時(shí)在這個(gè)過(guò)程當(dāng)中還會(huì)引入比如 task stealing 的操作，比如有的線程非常重的話，它所承的一些 task 可以被其他線程 steal。優(yōu)化過(guò)程中也經(jīng)過(guò)了很多迭代，比如實(shí)現(xiàn)的第一個(gè)版本發(fā)現(xiàn) task 是按照 mark range 平均分布的。但發(fā)現(xiàn)效果不是特別的好，因?yàn)樵谶@個(gè)當(dāng)中有很多連續(xù)的數(shù)據(jù)塊，還是可以稍微合并一下，所以后來(lái)實(shí)現(xiàn)了一個(gè)版本會(huì)把 Mark Range 進(jìn)行動(dòng)態(tài)分布，會(huì)根據(jù)讀取數(shù)據(jù)的請(qǐng)求的 mark range 連續(xù)性去做。同時(shí)這些 task 也會(huì)被多個(gè)線程去分布式執(zhí)行。同時(shí)我們也發(fā)現(xiàn)線程啟動(dòng) task 的時(shí)候有一個(gè)比較長(zhǎng)的啟動(dòng)時(shí)間，在這里也進(jìn)行了很多異步化的處理，能夠讓啟動(dòng)時(shí)間盡量的少。經(jīng)過(guò)一系列的冷讀優(yōu)化后，無(wú)論是從 HDFS 還是從 S3 去做冷讀數(shù)據(jù)讀取，都比最初的版本好很多。如果大家用到比較早期的 ByConity 版本，遇到冷讀這個(gè)性能覺(jué)得有問(wèn)題的話，可以盡快升級(jí)到最新的版本。

三、ByConity 使用場(chǎng)景

接下來(lái)介紹 ByConity 典型的使用場(chǎng)景。首先是字節(jié)內(nèi)部的一些使用，介紹一個(gè)抖音集團(tuán)做行為分析的場(chǎng)景。首先抖音的數(shù)據(jù)量是非常大，在這個(gè)場(chǎng)景中抖音的用戶行為數(shù)據(jù)在經(jīng)過(guò)埋點(diǎn)日志上報(bào)之后，它會(huì)在數(shù)倉(cāng)層建模去存放這些埋點(diǎn)數(shù)據(jù)，以及有像用戶畫像的相關(guān)數(shù)據(jù)。這些數(shù)據(jù)有離線的，也有實(shí)時(shí)的。實(shí)時(shí)這塊還是還在存算分離改造遷移過(guò)程中。但離線這塊已經(jīng)完全從原來(lái)存算一體的版本遷移到存算分離版本，也就是 ByConity 中。所以說(shuō)抖音行為分析的離線分析，已經(jīng)完全可以在 ByConity 里面做。它是對(duì)整個(gè)抖音的用戶行為分析平臺(tái)進(jìn)行了很好的支撐。這個(gè)平臺(tái)被稱為 DataFinder，DataFinder 被抖音內(nèi)部很多業(yè)務(wù)使用。比如說(shuō)抖音 APP、西瓜視頻、今日頭條，它們都會(huì)依賴 DataFinder 組件去做用戶行為的查詢服務(wù)。ByConity 在這個(gè)場(chǎng)景中提供了很好的查詢引擎支撐。那遷移改造之后效果如何呢？首先性能是 ByConity 的優(yōu)勢(shì)，改造之后的查詢性能是非常穩(wěn)定的，穩(wěn)定是指查詢時(shí)延是能夠達(dá)到要求，同時(shí)因?yàn)樘峁┝撕芎玫馁Y源隔離性，業(yè)務(wù)能夠有很好的避免資源搶占。在一些極端情況下，例如瞬時(shí)的大的任務(wù)，對(duì)整個(gè)集群的影響是比較小的，同時(shí)因?yàn)檎麄€(gè)存在分離的架構(gòu)優(yōu)勢(shì)，整個(gè)運(yùn)維成本得到很大的降低，尤其是像需要擴(kuò)縮容的時(shí)候，ByConity 可以支持彈性 Worker 的擴(kuò)縮容，運(yùn)維成本是非常低。同時(shí)在這樣的數(shù)據(jù)體量上，經(jīng)常會(huì)發(fā)現(xiàn)節(jié)點(diǎn)故障，以前如果是在 ClickHouse 情況下，節(jié)點(diǎn)出故障是去替換，容錯(cuò)其實(shí)都有很大的代價(jià)。在 ByConity 這些運(yùn)維成本也會(huì)被降低到很低。同時(shí)因?yàn)橐恢滦院头植际绞聞?wù)的支持，整個(gè)數(shù)據(jù)的一致性也能得到一定的保障，上游數(shù)據(jù)有問(wèn)題的時(shí)候，或者上游的系統(tǒng)有問(wèn)題的時(shí)候，維護(hù)的復(fù)雜度會(huì)非常低。

因?yàn)?ByConity 是開(kāi)源產(chǎn)品，有其他的公司基于 ByConity 做平臺(tái)的實(shí)踐。那這邊介紹一個(gè)展心展力，基于 ByConity 的可觀測(cè)平臺(tái)的實(shí)踐。可觀測(cè)也是 OLAP 查詢引擎的領(lǐng)域用的非常多的場(chǎng)景，那么展心展力的這個(gè)場(chǎng)景也是比較典型的。客戶端上報(bào)的日志，以及有一些可觀測(cè)的工具上報(bào)指標(biāo)，通過(guò)實(shí)時(shí)鏈路傳輸?shù)?OLAP 引擎中，然后再由 OLAP 引擎做作為計(jì)算層，對(duì)上面的BI 分析以及報(bào)表應(yīng)用提供引擎的計(jì)算能力，展心展力在 OLAP 的迭代也有一個(gè)過(guò)程，最早是使用了 ES，后面換成了 ClickHouse，現(xiàn)在最終再換成 ByConity，所以這個(gè)也是從 ClickHouse 遷移到 ByConity 的一個(gè)非常典型的場(chǎng)景，遷移的效果也非常好。首先性能，因?yàn)?ByConity 性能在很多或大部分的查詢場(chǎng)景下，對(duì)于 ClickHouse 是有優(yōu)勢(shì)的。尤其是查詢相對(duì)比較復(fù)雜，或者說(shuō)有一些比較特殊的場(chǎng)景，比如像 like 這樣場(chǎng)景情況下，都有一些明顯的性能優(yōu)勢(shì)。這些性能優(yōu)勢(shì)會(huì)導(dǎo)致做同樣查詢的流量，處理會(huì)比用原先用 ClickHouse 需要更少的資源，所以可以幫整個(gè) OLAP 層節(jié)省很多的資源。展心展力的 CPU 和內(nèi)存資源都得到了相當(dāng)程度的節(jié)省。另外展心展力自己引入了另一個(gè)非常好的，稱為定時(shí)擴(kuò)縮容的方式機(jī)制。這個(gè)定時(shí)擴(kuò)縮容的意思是可以在系統(tǒng)流量波峰的時(shí)候，把資源進(jìn)行擴(kuò)容，然后在流量波谷的時(shí)候再進(jìn)行縮容，因?yàn)榇嫠惴蛛x架構(gòu)以及擴(kuò)縮容無(wú)感的優(yōu)勢(shì)，使得擴(kuò)縮容可以做得非常頻繁，并且運(yùn)維的代價(jià)非常低，所以這種方式也可以非常好的節(jié)省他們的成本。如果說(shuō)本來(lái)這些資源是準(zhǔn)備好的，那在現(xiàn)在，就可以進(jìn)行動(dòng)態(tài)的伸縮。

四、ByConity 1.0 版本預(yù)覽

最后介紹 ByConity 將到來(lái)的版本 1.0。這個(gè)版本有一些重新的定位，以及一些新特性。首先說(shuō) ByConity 1.0 版本提供了三個(gè)核心的觀念。首先就是一直秉持的業(yè)界領(lǐng)先的性能優(yōu)勢(shì)，因?yàn)?ByConity 性能，剛才也介紹了有很多優(yōu)化手段。除了自研的優(yōu)化器解決本身 ClickHouse 的多表 Join 的場(chǎng)景以外，在過(guò)去的一年的迭代當(dāng)中也做了很多的優(yōu)化，所以整體性能肯定是業(yè)界領(lǐng)先的。另外存算分離從設(shè)計(jì)之初時(shí)，整個(gè)架構(gòu)設(shè)計(jì)就是秉持著云原生和存算分離的理念去進(jìn)行設(shè)計(jì)的，稱為整個(gè)業(yè)界最純粹的存算分離的版本，整個(gè) worker 層是真正無(wú)狀態(tài)的，真正是可以無(wú)感擴(kuò)縮容的。這是一直秉持的理念，另外一個(gè)是希望新引入的一個(gè)理念：完整的數(shù)據(jù)倉(cāng)庫(kù)。ByConity 1.0 不僅可以定位成一個(gè) OLAP 層引擎，而且希望把它定位成一個(gè)完整的數(shù)倉(cāng)，也就是說(shuō)希望 ODS 層就可以從 ByConity 開(kāi)始去建設(shè)，也要提供一系列的能力。能讓數(shù)倉(cāng)的建設(shè)不僅僅是能夠做它的查詢層，同時(shí)也可以做數(shù)據(jù)的處理，包括 ELT 能力。

首先是 ELT 能力，就是希望能夠把 ByConity 定位成一個(gè)數(shù)倉(cāng)引擎的非常重要的功能，ELT 能力是指在 ByConity 內(nèi)部進(jìn)能夠進(jìn)行一定的數(shù)據(jù)處理，能夠進(jìn)行長(zhǎng)任務(wù)的支持，這個(gè)區(qū)別于之前 ClickHouse，它就是查詢層引擎的定位。定位是查詢層引擎的話，基本上所有的查詢都是同步的，都是短時(shí)的，在這種情況下，它整個(gè)的計(jì)算層以及存儲(chǔ)層設(shè)計(jì)就專門針對(duì)短時(shí)的查詢進(jìn)行優(yōu)化，跟需要進(jìn)行數(shù)據(jù)處理的長(zhǎng)任務(wù)支持是完全不一樣的。比如需要去進(jìn)行長(zhǎng)時(shí)任務(wù)的情況，首先需要異步化的改造，需要引入查詢隊(duì)列入。對(duì) Server 以及 worker 里的很多能力進(jìn)行了改造和擴(kuò)充。比如在 server 引入了隊(duì)列的 manager，以及維持多個(gè)隊(duì)列的形式。在 worker 中引入了進(jìn)行資源管控的一些模塊，也結(jié)合 resource manage 能力，可對(duì)整個(gè) worker 里的資源耗費(fèi)情況進(jìn)行很好的管控。同時(shí)也可以對(duì)整個(gè)查詢的資源進(jìn)行預(yù)估。在這種情況下就可以很好的去評(píng)估一個(gè)查詢，它到底需要使用多少資源，目前這個(gè)資源夠不夠等？如果不夠的話可以把它放到隊(duì)列里面稍后去執(zhí)行。如果夠的話，采用哪些 worker、哪些資源去進(jìn)行計(jì)算？整個(gè)這塊進(jìn)行了很好的改造和支持。同時(shí)也進(jìn)行了整個(gè)執(zhí)行模式的改造，從整個(gè) MPP 執(zhí)行模式改造成為 BSP 的模式。BSP 模式我們認(rèn)為是分階段的一個(gè)模式，它主要的理念是下一個(gè)階段的執(zhí)行都必須等到上一個(gè)階段執(zhí)行完全成功之后才會(huì)進(jìn)行。跟原來(lái) MPP 模式有很大的不一樣。在 MPP 模式很多的并行計(jì)算任務(wù)以及資源會(huì)在一開(kāi)始就 plan 好，并且分配好。分配好之后，當(dāng)中很難去動(dòng)態(tài)改變，當(dāng)中如果出了問(wèn)題，它也能只能從頭開(kāi)始重試，沒(méi)有辦法從中間的出問(wèn)題的點(diǎn)開(kāi)始重試。那 BSP 模式就可以很好地解決這個(gè)問(wèn)題，這也是為什么能夠支撐長(zhǎng)時(shí)任務(wù)的非常重要的點(diǎn)。BSP 模式從執(zhí)行的分階段進(jìn)行，除了這個(gè)支撐之外，它還需要可以通過(guò)磁盤進(jìn)行數(shù)據(jù)的 shuffer 的一個(gè)非常重要的功能。這兩個(gè)功能要能夠很好地整合，我們才能夠?qū)?BSP 模式進(jìn)行非常好的支持。基于磁盤數(shù)據(jù) shuffer 是 ByConity 1.0 里面會(huì)引入的一個(gè)非常重要的能力。例如在一個(gè) worker 內(nèi)有一定數(shù)據(jù)計(jì)算結(jié)果之后，會(huì)把這些中間結(jié)果落地到 worker 的磁盤當(dāng)中，并且 exchange manager 可以讓其他的 worker 從磁盤中進(jìn)行讀取。這也是支持長(zhǎng)時(shí)任務(wù)所要求必備的基于磁盤的 Exchange 能力。同時(shí)在 1.0 還會(huì)提供一些比較高級(jí)的能力，比如 Adaptive query execution 能力。AQE 其實(shí)是在進(jìn)行 Spark 和 Flink 應(yīng)用的時(shí)候都會(huì)遇到的比較高級(jí)的 Adaptive 的能力。在 ByConity 1.0 也會(huì)提供比如說(shuō)像這種 parallelism 的自動(dòng)調(diào)整的 AQE 能力。

另外一個(gè)比較重要的 1.0 提出來(lái)的是湖倉(cāng)一體能力。湖倉(cāng)一體是 1.0 希望能夠用湖上建倉(cāng)的方式去進(jìn)行這個(gè)湖倉(cāng)一體的建設(shè)。也是依賴 ByConity 1.0 提供出來(lái)的很多能力去進(jìn)行的。在湖倉(cāng)支持方面，ByConity 1.0 很好地對(duì)接到 Hive meta store，能夠?qū)?Hive meta store 的元數(shù)據(jù)進(jìn)行很好的處理。除了能夠直接讀取元數(shù)據(jù)之外，還能夠?qū)υ獢?shù)據(jù)進(jìn)行緩存以及進(jìn)行自動(dòng)的從 Hive Meta store 進(jìn)行同步。除此以外，還對(duì)很多類型的外表做了支持，比如 Hive 的外表，以及 Hudi 格式的外表也做了很好的支持。在數(shù)據(jù)結(jié)構(gòu)方面，對(duì) Parquet 和 ORC 的數(shù)據(jù)結(jié)構(gòu)都進(jìn)行了很好的支持。同時(shí)也支持在 HDFS 和 S3 里進(jìn)行存儲(chǔ)支持。為了進(jìn)一步加速數(shù)據(jù)湖的外表查詢?cè)趥}(cāng)里面的查詢性能，引入了物化視圖，支持了多種物化視圖。除了基于單表的同步物化視圖以外，還可以進(jìn)行多表的異步物化視圖的構(gòu)建，同時(shí)也可以對(duì)外表進(jìn)行物化視圖，也就是對(duì)外表的查詢的中間結(jié)果可以物化下來(lái)放在物化視圖里，后面就自動(dòng)的查詢改寫，查詢請(qǐng)求直接通過(guò)訪問(wèn)物化視圖的方式得到，不用真正去訪問(wèn)遠(yuǎn)端的湖里面的這些數(shù)據(jù)。同時(shí)也支持外表和內(nèi)表能夠進(jìn)行關(guān)聯(lián)查詢，在很多湖上建倉(cāng)的場(chǎng)景下也是非常普遍的。這樣的話離線數(shù)據(jù)進(jìn)湖，實(shí)時(shí)數(shù)據(jù)進(jìn)倉(cāng)，可以對(duì)實(shí)時(shí)數(shù)據(jù)和離線數(shù)據(jù)進(jìn)行關(guān)聯(lián)的查詢。這些能力的支持就可以給融合數(shù)倉(cāng)和數(shù)據(jù)湖的應(yīng)用，提供了一個(gè)非常好的參考模式。后面還會(huì)進(jìn)行進(jìn)一步地迭代開(kāi)發(fā)，在 1.0 之后，還會(huì)提供比如說(shuō)數(shù)據(jù)湖的寫入這樣的能力。一些像倉(cāng)下存湖的場(chǎng)景能夠得到進(jìn)一步的支持。

另外一個(gè) 1.0 里面比較重要的能力是倒排索引。倒排索引其實(shí)是 ClickHouse 社區(qū)本來(lái)一直在迭代、支持的能力。在 ByConity 里倒排索引能力進(jìn)行了一定的增強(qiáng)。首先在分詞方式方面，支持 token 分詞，Mgram 分詞。除此以外，還支持中文分詞，引入中文的分詞庫(kù)，通過(guò)配置分詞庫(kù)去進(jìn)行中文的分詞。同時(shí)引入了詞組匹配和相似度的檢索，目前還在開(kāi)發(fā)，在下一個(gè)版本 1.0 會(huì)真正上線這個(gè)能力。這些能力上線之后，整個(gè)倒排索引會(huì)使得像這種 like查詢的場(chǎng)景下，性能得到非常大的提升。比如說(shuō)查詢耗時(shí)能夠降低 3- 4 倍，同時(shí)對(duì) L(load)的請(qǐng)求也能降低 4- 5 倍。這個(gè)場(chǎng)景大家會(huì)自然地聯(lián)想到 elastic search，因?yàn)檫@個(gè)場(chǎng)景是 elastic search 的典型場(chǎng)景，那使用 ByConity 去做倒排索引的文本檢索，對(duì)于 elastic search 有什么優(yōu)勢(shì)呢？首先它的整個(gè)架構(gòu)設(shè)計(jì)，以及本身這個(gè) OLAP 引擎性能的優(yōu)勢(shì)，寫入的吞吐量是非常大的，同時(shí)查詢性能也相比 elastic search 有更低的延時(shí)。這個(gè)是本身已經(jīng)具有了的性能優(yōu)勢(shì)。同時(shí)因?yàn)榇嫠惴蛛x的架構(gòu)，可以做很好的資源隔離。所以負(fù)載可以做得更均衡，運(yùn)維成本也可以做得更低。另外就是易用性，因?yàn)?ByConity 是一個(gè)基于 SQL 的數(shù)倉(cāng)引擎，它的使用就是標(biāo)準(zhǔn) SQL 語(yǔ)法。還支持了很多種不同的 SQL 方言，所以使用上面來(lái)講比 elastic search 要易用很多。

最后介紹 1.0 推出后兼容性方面的支持，也就是 MySQL 兼容性。因?yàn)?ByConity 本身基于 ClickHouse，所以它對(duì) ClickHouse 生態(tài)的支持以及 ClickHouse 的 SQL 的語(yǔ)法兼容性肯定是沒(méi)有問(wèn)題的。但是在很多數(shù)倉(cāng)使用場(chǎng)景下，很多用戶其實(shí)更希望能夠通過(guò) MySQL 的方式去使用數(shù)倉(cāng)。或者說(shuō)他們現(xiàn)在數(shù)倉(cāng)使用場(chǎng)景里面就已經(jīng)使用了 MySQL 很多的特性，以及已經(jīng)有很多積累在 MySQL 上面，比如說(shuō) SQL 或者工具的使用等，都希望在 MySQL 的生態(tài)方面得到支持。所以在 1.0 版本對(duì)整個(gè) MySQL 生態(tài)進(jìn)行了全面的支持。那這個(gè)支持包括語(yǔ)法、函數(shù)、數(shù)據(jù)類型，包括 DQL、DML、DDL 等都進(jìn)行了一一排查去支持它。整個(gè)的支持兼容度是大于 90% 的，對(duì)一些目前沒(méi)有兼容的，也在會(huì)在 SQL 層里做很好的說(shuō)明，說(shuō)清楚可以有什么替代方法或者改寫方法。基本上可以保證什么呢？就是已經(jīng)使用了 MySQL 生態(tài)的工具的，比如說(shuō) BI 工具像 Tableau、quick BI、Fine BI 等等，或者說(shuō)一些 IDE 工具，MySQL workbench, DBeaver, Navicat 等，通過(guò)這些工具能夠無(wú)縫地使用和連接到 ByConity去做各種查詢或者各種操作。同時(shí)一些典型的 driver，像 JDBC driver，走 MySQL 協(xié)議連進(jìn)來(lái)也是可以的，都能夠無(wú)縫支持沒(méi)有什么問(wèn)題，盡量保證使用的時(shí)候是可以兼容的。

接下來(lái)介紹 24 年整個(gè)迭代的路線。1.0 版本是下一個(gè)版本，這個(gè)版本可能會(huì)在 Q3 中，比如說(shuō) 7 月底時(shí)間點(diǎn)發(fā)出來(lái)。整個(gè)一整年的迭代都會(huì)有各類功能的建設(shè)。其實(shí)上半年已經(jīng)完成了剛才提到的湖倉(cāng)能力、MySQL 兼容性、LT 以及全文檢索的能力建設(shè)。這些能力也不是一下放出，而是在那之前，比如 0.2、0.3 等版本中陸續(xù)放出這些能力的功能點(diǎn)。之前是以功能點(diǎn)的形式在小版本中提供出來(lái)，在 1.0 版本會(huì)認(rèn)為整個(gè)建設(shè)能夠比較完備，是一個(gè)可以達(dá)到 GA 狀態(tài)的版本，大家可以真正在生產(chǎn)環(huán)境下去比較完整地使用這些方面的能力。下半年還會(huì)對(duì)上述的這些領(lǐng)域進(jìn)行進(jìn)一步的支持，比如說(shuō)在湖倉(cāng)領(lǐng)域會(huì)支持 iceberg 以及 Hudi 和 iceberg 寫入等。另外在性能這塊也是一直秉持的，一定要做到業(yè)界最優(yōu)性能這樣主旨。所以在性能這塊會(huì)一直不停地去做迭代，會(huì)有更多的性能提升點(diǎn)，像 Zero copy、一些系統(tǒng)的改造能夠讓性能得到進(jìn)一步提升、分布式的緩存等。同時(shí)在生態(tài)這塊也會(huì)進(jìn)一步地支持，比如 ClickHouse，要一直是兼容它的生態(tài)，但是 ClickHouse 也在發(fā)展過(guò)程中。后續(xù)有更新版本的 ClickHouse，也會(huì)去考慮對(duì)它的新 SQL 進(jìn)行一定支持。同時(shí)也吸收了自于社區(qū)的一些反饋，就像元數(shù)據(jù)，有很多社區(qū)小伙伴反饋說(shuō) Fundation DB 的運(yùn)維是他們的痛點(diǎn)，F(xiàn)undation DB 本身外面成型的生態(tài)及工具比較少。后面會(huì)在考慮對(duì)整個(gè)元數(shù)據(jù)進(jìn)行重構(gòu)，一方面看一下能不能減少元數(shù)據(jù)存儲(chǔ)的負(fù)擔(dān)。另一方面也可以看一下 FDB 的使用有沒(méi)有替代。之前選型 FDB 產(chǎn)品也是因?yàn)樾阅苌峡紤]，還有比如像 range 查詢等，這些需要依賴 FDB 的優(yōu)越的性能，我們也會(huì)得到一定的重構(gòu)以及其他方案的支持。