一、ByConity 產生背景

ByConity 是基于 ClickHouse 產生。ClickHouse 社區已經發展了很多年。字節從 2017 年開始大規模使用 ClickHouse。在驗證了多款產品之后，最終發現 ClickHouse 是唯一能夠支撐字節當時的體量以及保證查詢體驗的產品。在使用 ClickHouse 過程中遇到了很多的痛點，比如說運維成本居高不下，擴縮容成本高，同時也有關聯查詢的局限性。

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

這里說下使用 ClickHouse 的一些痛點，ClickHouse 是一個典型的 MPP 架構數據庫，它有很好的性能優勢。比如說單表查詢，尤其是聚合查詢的時候，它擁有領先其他競品的性能，但是使用它的時候也會有很多的痛點，其中一個最主要的痛點就是擴容成本非常高，因為本身架構的設計的原因，以及數據與計算節點捆綁的因素。我們每次進行擴容的時候，需要數據交進行重分布，會有很高的運維成本以及數據驗證等資源方面的代價，對線上會是很大的影響。同時它很難平衡資源的有效利用，以及資源隔離。比如說如果希望一個業務能夠與其他業務進行隔離，最好給他一個單獨的集群，但是單獨集群又很難把硬件資源很好地利用起來，因為當業務比較空閑的時候，這些資源就可能會浪費。

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

二、ByConity 設計與優化

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

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

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

優化的效果也發過文章，在 ByConity 最初 GA 的時候，就對比了業界的一些比較流行的開源產品，在 TPC-DS 的標準數據集上跟這些產品做了 Benchmark，結果 ByContiy 整體性能非常好。可以在外面找到這些文章看 Benchmark 的細節。其實在 ByConity 開源并進行了一年迭代之后，也有了更多的性能優化，包括像 QPS 的優化、Projection 的優化等，這些優化會進一步提升性能。目前如果再重新做 TPC-DS Benchmark 會進一步提升。

除了本身的性能優化以外，ByConity 還有一些在真正生產使用當中所需要的非常重要的能力，比如說一致性。ClickHouse 另外一個比較痛的點就是它缺乏一致性，因為它本身是不支持事務的，它只能在一個有限的范圍內支持一定的原子性 ACID 級別，但這在很多業務場景下是不夠的。如果不支持事務，在很多時候一旦上游發生 fail，需要進行 recover 的時候，或者說數據有一定的異常，需要進行 Retry 等一些操作的時候，如果缺乏一致性，會對 OLAP 中的數據產生很大影響，也會影響到后續的業務分析以及后續系統的正確性。所以在 OLAP 系統中，事務和一致性也是比較重要的。在 ByConity 中是支持分布式事務的，并且能夠支持到 Read committed 的隔離級別。怎么做到的呢？首先 ByConity 有統一的元數據層，這個元數據層是用 FoundationDB 開源組件實現的，FoundationDB 本身支持原子性操作，比如像 CAS，所以 ByConity 可以很好地利用 FoundationDB 的能力去實現分布式事務當中的一些比較重要的原子操作。另外就是引入了分布式的時鐘，就是這個 TSO 組件可以為分布式事務提供單調遞增的事務 ID。這是比較重要的分布式事務中的組件吧。因為這些組件的支持，可以實現典型的兩階段提交。在階段一寫入數據的時候，可以同時寫入事務 ID，并且將 undo buffer 寫入遠端的存儲并提交元信息。第二階段是對這個事務真的進行提交，提交事務的時候，可以根據事務記錄的提交時間進行處理。比如如果事務執行成功，可以真正更新 part 的提交時間，把 undo buffer 清理掉，并且把這個事務的記錄點給清理掉。如果事務失敗，需要進行一些回滾。那剛才記錄的 undo buffer 就可以在回滾中發揮作用，首先把中間過程的 Part 數據刪掉，因為失敗它已經沒有用了。根據 Undo buffer 把遠端存儲當中已經寫了的數據進行回滾，同時在這些都處理好之后，再把 Undo buffer 和事務記錄給處理掉，這就是一個非常典型的兩階段提交的分布事務操作。由于這樣的支持，ByConity 在一致性上面是有很好的保證。

另外因為是存算分離架構，所以大家可能會比較擔憂一些問題，比如說對遠端存儲的數據 IO 是不是真的能夠滿足查詢的需要？所以在 ByConity 對冷讀，也就是直接對遠端存儲讀寫的操作，做了很多的優化。冷讀的性能無論如何都會比已經在 Disk Cache 當中緩存的數據的熱讀操作還是要慢。ByConity 一直在對這個過程進行優化，使得它對整個系統的查詢影響盡量小。這些優化手段包括很多很細節優化，很多也是借鑒了操作系統的 IO 優化手段，以及其他分布式系統中的 IO 優化手段。下面介紹其中的一些。

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

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

三、ByConity 使用場景

接下來介紹 ByConity 典型的使用場景。首先是字節內部的一些使用，介紹一個抖音集團做行為分析的場景。首先抖音的數據量是非常大，在這個場景中抖音的用戶行為數據在經過埋點日志上報之后，它會在數倉層建模去存放這些埋點數據，以及有像用戶畫像的相關數據。這些數據有離線的，也有實時的。實時這塊還是還在存算分離改造遷移過程中。但離線這塊已經完全從原來存算一體的版本遷移到存算分離版本，也就是 ByConity 中。所以說抖音行為分析的離線分析，已經完全可以在 ByConity 里面做。它是對整個抖音的用戶行為分析平臺進行了很好的支撐。這個平臺被稱為 DataFinder，DataFinder 被抖音內部很多業務使用。比如說抖音 APP、西瓜視頻、今日頭條，它們都會依賴 DataFinder 組件去做用戶行為的查詢服務。ByConity 在這個場景中提供了很好的查詢引擎支撐。那遷移改造之后效果如何呢？首先性能是 ByConity 的優勢，改造之后的查詢性能是非常穩定的，穩定是指查詢時延是能夠達到要求，同時因為提供了很好的資源隔離性，業務能夠有很好的避免資源搶占。在一些極端情況下，例如瞬時的大的任務，對整個集群的影響是比較小的，同時因為整個存在分離的架構優勢，整個運維成本得到很大的降低，尤其是像需要擴縮容的時候，ByConity 可以支持彈性 Worker 的擴縮容，運維成本是非常低。同時在這樣的數據體量上，經常會發現節點故障，以前如果是在 ClickHouse 情況下，節點出故障是去替換，容錯其實都有很大的代價。在 ByConity 這些運維成本也會被降低到很低。同時因為一致性和分布式事務的支持，整個數據的一致性也能得到一定的保障，上游數據有問題的時候，或者上游的系統有問題的時候，維護的復雜度會非常低。

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

四、ByConity 1.0 版本預覽

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

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

另外一個比較重要的 1.0 提出來的是湖倉一體能力。湖倉一體是 1.0 希望能夠用湖上建倉的方式去進行這個湖倉一體的建設。也是依賴 ByConity 1.0 提供出來的很多能力去進行的。在湖倉支持方面，ByConity 1.0 很好地對接到 Hive meta store，能夠對 Hive meta store 的元數據進行很好的處理。除了能夠直接讀取元數據之外，還能夠對元數據進行緩存以及進行自動的從 Hive Meta store 進行同步。除此以外，還對很多類型的外表做了支持，比如 Hive 的外表，以及 Hudi 格式的外表也做了很好的支持。在數據結構方面，對 Parquet 和 ORC 的數據結構都進行了很好的支持。同時也支持在 HDFS 和 S3 里進行存儲支持。為了進一步加速數據湖的外表查詢在倉里面的查詢性能，引入了物化視圖，支持了多種物化視圖。除了基于單表的同步物化視圖以外，還可以進行多表的異步物化視圖的構建，同時也可以對外表進行物化視圖，也就是對外表的查詢的中間結果可以物化下來放在物化視圖里，后面就自動的查詢改寫，查詢請求直接通過訪問物化視圖的方式得到，不用真正去訪問遠端的湖里面的這些數據。同時也支持外表和內表能夠進行關聯查詢，在很多湖上建倉的場景下也是非常普遍的。這樣的話離線數據進湖，實時數據進倉，可以對實時數據和離線數據進行關聯的查詢。這些能力的支持就可以給融合數倉和數據湖的應用，提供了一個非常好的參考模式。后面還會進行進一步地迭代開發，在 1.0 之后，還會提供比如說數據湖的寫入這樣的能力。一些像倉下存湖的場景能夠得到進一步的支持。

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

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

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