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

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

字節(jié)從 18 年開始對(duì) ClickHouse 進(jìn)行很多功能優(yōu)化，但字節(jié)的業(yè)務(wù)發(fā)展比較快，無論是數(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)上來。在 22 年的時(shí)候，我們決定將這些優(yōu)化回饋到社區(qū)。在與 ClickHouse 官方討論之后，官方建議我們自己去開源產(chǎn)品。在 23 年 1 月份字節(jié)發(fā)布了開源的第一個(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)行功能的迭代以及問題的修復(fù)，另一方面不停地進(jìn)行性能的優(yōu)化。

這里說下使用 ClickHouse 的一些痛點(diǎn)，ClickHouse 是一個(gè)典型的 MPP 架構(gòu)數(shù)據(jù)庫(kù)，它有很好的性能優(yōu)勢(shì)。比如說單表查詢，尤其是聚合查詢的時(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í)它很難平衡資源的有效利用，以及資源隔離。比如說如果希望一個(gè)業(yè)務(wù)能夠與其他業(yè)務(wù)進(jìn)行隔離，最好給他一個(gè)單獨(dú)的集群，但是單獨(dú)集群又很難把硬件資源很好地利用起來，因?yàn)楫?dāng)業(yè)務(wù)比較空閑的時(shí)候，這些資源就可能會(huì)浪費(fèi)。

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

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

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

上面介紹整個(gè)架構(gòu)設(shè)計(jì)，再來說 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)過優(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è)過程中就會(huì)涉及到自研的查詢優(yōu)化器，對(duì) Query Plan 進(jìn)行優(yōu)化和改寫。支持比較常見的優(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ā)過文章，在 ByConity 最初 GA 的時(shí)候，就對(duì)比了業(yè)界的一些比較流行的開源產(chǎn)品，在 TPC-DS 的標(biāo)準(zhǔn)數(shù)據(jù)集上跟這些產(chǎn)品做了 Benchmark，結(jié)果 ByContiy 整體性能非常好?？梢栽谕饷嬲业竭@些文章看 Benchmark 的細(xì)節(jié)。其實(shí)在 ByConity 開源并進(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)中所需要的非常重要的能力，比如說一致性。ClickHouse 另外一個(gè)比較痛的點(diǎn)就是它缺乏一致性，因?yàn)樗旧硎遣恢С质聞?wù)的，它只能在一個(gè)有限的范圍內(nèi)支持一定的原子性 ACID 級(jí)別，但這在很多業(yè)務(wù)場(chǎng)景下是不夠的。如果不支持事務(wù)，在很多時(shí)候一旦上游發(fā)生 fail，需要進(jìn)行 recover 的時(shí)候，或者說數(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 開源組件實(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ā)揮作用，首先把中間過程的 Part 數(shù)據(jù)刪掉，因?yàn)槭∷呀?jīng)沒有用了。根據(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)憂一些問題，比如說對(duì)遠(yuǎn)端存儲(chǔ)的數(shù)據(jù) IO 是不是真的能夠滿足查詢的需要？所以在 ByConity 對(duì)冷讀，也就是直接對(duì)遠(yuǎn)端存儲(chǔ)讀寫的操作，做了很多的優(yōu)化。冷讀的性能無論如何都會(huì)比已經(jīng)在 Disk Cache 當(dāng)中緩存的數(shù)據(jù)的熱讀操作還是要慢。ByConity 一直在對(duì)這個(gè)過程進(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í)是相鄰的，或者說基本上相鄰，中間可能隔了很少的一部分?jǐn)?shù)據(jù)，那可以把這兩個(gè) IO 請(qǐng)求合并成一個(gè)。拆分是說有的時(shí)候一個(gè) IO 請(qǐng)求非常大，它所涉及到的數(shù)據(jù)塊非常大，如果直接進(jìn)行請(qǐng)求的話，會(huì)有一個(gè)比較高的等待時(shí)間。所以在這種情況下，我們可以把它拆分成多個(gè) lO 請(qǐng)求，然后采用并發(fā)方式去 load 數(shù)據(jù)。這兩種情況在真正 IO 過程中其實(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è)過程當(dāng)中還會(huì)引入比如 task stealing 的操作，比如有的線程非常重的話，它所承的一些 task 可以被其他線程 steal。優(yōu)化過程中也經(jīng)過了很多迭代，比如實(shí)現(xiàn)的第一個(gè)版本發(fā)現(xiàn) task 是按照 mark range 平均分布的。但發(fā)現(xiàn)效果不是特別的好，因?yàn)樵谶@個(gè)當(dāng)中有很多連續(xù)的數(shù)據(jù)塊，還是可以稍微合并一下，所以后來實(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)過一系列的冷讀優(yōu)化后，無論是從 HDFS 還是從 S3 去做冷讀數(shù)據(jù)讀取，都比最初的版本好很多。如果大家用到比較早期的 ByConity 版本，遇到冷讀這個(gè)性能覺得有問題的話，可以盡快升級(jí)到最新的版本。

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

接下來介紹 ByConity 典型的使用場(chǎng)景。首先是字節(jié)內(nèi)部的一些使用，介紹一個(gè)抖音集團(tuán)做行為分析的場(chǎng)景。首先抖音的數(shù)據(jù)量是非常大，在這個(gè)場(chǎng)景中抖音的用戶行為數(shù)據(jù)在經(jīng)過埋點(diǎn)日志上報(bào)之后，它會(huì)在數(shù)倉(cāng)層建模去存放這些埋點(diǎn)數(shù)據(jù)，以及有像用戶畫像的相關(guān)數(shù)據(jù)。這些數(shù)據(jù)有離線的，也有實(shí)時(shí)的。實(shí)時(shí)這塊還是還在存算分離改造遷移過程中。但離線這塊已經(jīng)完全從原來存算一體的版本遷移到存算分離版本，也就是 ByConity 中。所以說抖音行為分析的離線分析，已經(jīng)完全可以在 ByConity 里面做。它是對(duì)整個(gè)抖音的用戶行為分析平臺(tái)進(jìn)行了很好的支撐。這個(gè)平臺(tái)被稱為 DataFinder，DataFinder 被抖音內(nèi)部很多業(yè)務(wù)使用。比如說抖音 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ù)有問題的時(shí)候，或者上游的系統(tǒng)有問題的時(shí)候，維護(hù)的復(fù)雜度會(huì)非常低。

因?yàn)?ByConity 是開源產(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)，通過實(shí)時(shí)鏈路傳輸?shù)?OLAP 引擎中，然后再由 OLAP 引擎做作為計(jì)算層，對(duì)上面的BI 分析以及報(bào)表應(yīng)用提供引擎的計(jì)算能力，展心展力在 OLAP 的迭代也有一個(gè)過程，最早是使用了 ES，后面換成了 ClickHouse，現(xiàn)在最終再換成 ByConity，所以這個(gè)也是從 ClickHouse 遷移到 ByConity 的一個(gè)非常典型的場(chǎng)景，遷移的效果也非常好。首先性能，因?yàn)?ByConity 性能在很多或大部分的查詢場(chǎng)景下，對(duì)于 ClickHouse 是有優(yōu)勢(shì)的。尤其是查詢相對(duì)比較復(fù)雜，或者說有一些比較特殊的場(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ò)縮容無感的優(yōu)勢(shì)，使得擴(kuò)縮容可以做得非常頻繁，并且運(yùn)維的代價(jià)非常低，所以這種方式也可以非常好的節(jié)省他們的成本。如果說本來這些資源是準(zhǔn)備好的，那在現(xiàn)在，就可以進(jìn)行動(dòng)態(tài)的伸縮。

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

最后介紹 ByConity 將到來的版本 1.0。這個(gè)版本有一些重新的定位，以及一些新特性。首先說 ByConity 1.0 版本提供了三個(gè)核心的觀念。首先就是一直秉持的業(yè)界領(lǐng)先的性能優(yōu)勢(shì)，因?yàn)?ByConity 性能，剛才也介紹了有很多優(yōu)化手段。除了自研的優(yōu)化器解決本身 ClickHouse 的多表 Join 的場(chǎng)景以外，在過去的一年的迭代當(dāng)中也做了很多的優(yōu)化，所以整體性能肯定是業(yè)界領(lǐng)先的。另外存算分離從設(shè)計(jì)之初時(shí)，整個(gè)架構(gòu)設(shè)計(jì)就是秉持著云原生和存算分離的理念去進(jìn)行設(shè)計(jì)的，稱為整個(gè)業(yè)界最純粹的存算分離的版本，整個(gè) worker 層是真正無狀態(tài)的，真正是可以無感擴(kuò)縮容的。這是一直秉持的理念，另外一個(gè)是希望新引入的一個(gè)理念：完整的數(shù)據(jù)倉(cāng)庫(kù)。ByConity 1.0 不僅可以定位成一個(gè) OLAP 層引擎，而且希望把它定位成一個(gè)完整的數(shù)倉(cāng)，也就是說希望 ODS 層就可以從 ByConity 開始去建設(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)行。跟原來 MPP 模式有很大的不一樣。在 MPP 模式很多的并行計(jì)算任務(wù)以及資源會(huì)在一開始就 plan 好，并且分配好。分配好之后，當(dāng)中很難去動(dòng)態(tài)改變，當(dāng)中如果出了問題，它也能只能從頭開始重試，沒有辦法從中間的出問題的點(diǎn)開始重試。那 BSP 模式就可以很好地解決這個(gè)問題，這也是為什么能夠支撐長(zhǎng)時(shí)任務(wù)的非常重要的點(diǎn)。BSP 模式從執(zhí)行的分階段進(jìn)行，除了這個(gè)支撐之外，它還需要可以通過磁盤進(jìn)行數(shù)據(jù)的 shuffer 的一個(gè)非常重要的功能。這兩個(gè)功能要能夠很好地整合，我們才能夠?qū)?BSP 模式進(jìn)行非常好的支持?；诖疟P數(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ì)提供比如說像這種 parallelism 的自動(dòng)調(diào)整的 AQE 能力。

另外一個(gè)比較重要的 1.0 提出來的是湖倉(cāng)一體能力。湖倉(cāng)一體是 1.0 希望能夠用湖上建倉(cāng)的方式去進(jìn)行這個(gè)湖倉(cāng)一體的建設(shè)。也是依賴 ByConity 1.0 提供出來的很多能力去進(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é)果可以物化下來放在物化視圖里，后面就自動(dòng)的查詢改寫，查詢請(qǐng)求直接通過訪問物化視圖的方式得到，不用真正去訪問遠(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)一步地迭代開發(fā)，在 1.0 之后，還會(huì)提供比如說數(shù)據(jù)湖的寫入這樣的能力。一些像倉(cāng)下存湖的場(chǎng)景能夠得到進(jìn)一步的支持。

另外一個(gè) 1.0 里面比較重要的能力是倒排索引。倒排索引其實(shí)是 ClickHouse 社區(qū)本來一直在迭代、支持的能力。在 ByConity 里倒排索引能力進(jìn)行了一定的增強(qiáng)。首先在分詞方式方面，支持 token 分詞，Mgram 分詞。除此以外，還支持中文分詞，引入中文的分詞庫(kù)，通過配置分詞庫(kù)去進(jìn)行中文的分詞。同時(shí)引入了詞組匹配和相似度的檢索，目前還在開發(fā)，在下一個(gè)版本 1.0 會(huì)真正上線這個(gè)能力。這些能力上線之后，整個(gè)倒排索引會(huì)使得像這種 like查詢的場(chǎng)景下，性能得到非常大的提升。比如說查詢耗時(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 方言，所以使用上面來講比 elastic search 要易用很多。

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

接下來介紹 24 年整個(gè)迭代的路線。1.0 版本是下一個(gè)版本，這個(gè)版本可能會(huì)在 Q3 中，比如說 7 月底時(shí)間點(diǎn)發(fā)出來。整個(gè)一整年的迭代都會(huì)有各類功能的建設(shè)。其實(shí)上半年已經(jīng)完成了剛才提到的湖倉(cāng)能力、MySQL 兼容性、LT 以及全文檢索的能力建設(shè)。這些能力也不是一下放出，而是在那之前，比如 0.2、0.3 等版本中陸續(xù)放出這些能力的功能點(diǎn)。之前是以功能點(diǎn)的形式在小版本中提供出來，在 1.0 版本會(huì)認(rèn)為整個(gè)建設(shè)能夠比較完備，是一個(gè)可以達(dá)到 GA 狀態(tài)的版本，大家可以真正在生產(chǎn)環(huán)境下去比較完整地使用這些方面的能力。下半年還會(huì)對(duì)上述的這些領(lǐng)域進(jìn)行進(jìn)一步的支持，比如說在湖倉(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ā)展過程中。后續(xù)有更新版本的 ClickHouse，也會(huì)去考慮對(duì)它的新 SQL 進(jìn)行一定支持。同時(shí)也吸收了自于社區(qū)的一些反饋，就像元數(shù)據(jù)，有很多社區(qū)小伙伴反饋說 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 的使用有沒有替代。之前選型 FDB 產(chǎn)品也是因?yàn)樾阅苌峡紤]，還有比如像 range 查詢等，這些需要依賴 FDB 的優(yōu)越的性能，我們也會(huì)得到一定的重構(gòu)以及其他方案的支持。