5月22日，字節(jié)跳動宣布開源ByConity云原生數(shù)據(jù)倉庫。
(資料圖)
ByConity基于ClickHouse內(nèi)核開發(fā)，采用計算存儲分離的架構(gòu)、主流的OLAP引擎和自研的表引擎，提供便捷的彈性擴(kuò)縮容和極速的分析性能，覆蓋實時分析和海量數(shù)據(jù)(603138)的離線分析，幫助企業(yè)更好地挖掘數(shù)據(jù)價值。
字節(jié)跳動是國內(nèi)使用 ClickHouse 規(guī)模最大的企業(yè)之一，此前隨著其業(yè)務(wù)發(fā)展和數(shù)據(jù)規(guī)模的增加，在不同的業(yè)務(wù)場景中遇到了一系列的問題，包括擴(kuò)縮容成本高、復(fù)雜查詢性能受限等。為了滿足業(yè)務(wù)訴求，字節(jié)跳動數(shù)據(jù)平臺團(tuán)隊在 ClickHouse 社區(qū)版本基礎(chǔ)上做出架構(gòu)升級，開發(fā)出云原生版本、存儲計算分離的數(shù)據(jù)倉庫 ByConity，并自研優(yōu)化器，提升其復(fù)雜查詢等性能。
本文將深度介紹ByConity項目背景、工作原理、功能特性、技術(shù)架構(gòu)，以及未來規(guī)劃。
一、項目背景
ByConity 是字節(jié)跳動開源的云原生數(shù)據(jù)倉庫，它采用計算-存儲分離的架構(gòu)，支持多個關(guān)鍵功能特性，如計算存儲分離、彈性擴(kuò)縮容、租戶資源隔離和數(shù)據(jù)讀寫的強一致性等。通過利用主流的 OLAP 引擎優(yōu)化，如列存儲、向量化執(zhí)行、MPP 執(zhí)行、查詢優(yōu)化等，ByConity 可以提供優(yōu)異的讀寫性能。
ByConity 的背景可以追溯到 2018 年，當(dāng)時字節(jié)跳動開始在內(nèi)部使用 ClickHouse，因為業(yè)務(wù)的發(fā)展，要服務(wù)于大量的用戶，數(shù)據(jù)規(guī)模變得越來越巨大。由于 ClickHouse 是 Shared-Nothing 的架構(gòu)，每個節(jié)點是獨立的，不會共享存儲資源等，因而計算資源和存儲資源是緊耦合的，這使得 ClickHouse 在使用過程中會遇到以下情況：
首先，這導(dǎo)致擴(kuò)縮容成本變高，且會涉及到數(shù)據(jù)遷移，使他們不能實時按需的擴(kuò)縮容，從而導(dǎo)致資源的浪費；
其次，ClickHouse 緊耦合的架構(gòu)會導(dǎo)致多租戶在共享集群環(huán)境相互影響，同時由于讀寫在同一個節(jié)點完成，導(dǎo)致讀寫相互影響；
最后，ClickHouse 在復(fù)雜查詢上例如多表 Join 等操作的性能支持并不是很好。
基于這些痛點，字節(jié)在 ClickHouse 架構(gòu)基礎(chǔ)上進(jìn)行了升級，于 2020 年在內(nèi)部啟動了 ByConity 項目，2022年準(zhǔn)備開源，并于 2023 年 1 月發(fā)布 Beta 版本，5月底正式對外開源。
圖1 字節(jié) ClickHouse 使用情況
據(jù)介紹，ByConity開源之前，字節(jié)跳動數(shù)據(jù)平臺團(tuán)隊也曾考慮將自研修改合并回ClickHouse社區(qū)，與ClickHouse核心研發(fā)團(tuán)隊、ClickHouse創(chuàng)業(yè)公司負(fù)責(zé)人做了幾次閉門溝通，得到的反饋是架構(gòu)差異過大、合并難度和代價大、無法聯(lián)合開發(fā)。于是，按照ClickHouse社區(qū)給到的建議，數(shù)據(jù)平臺團(tuán)隊決定獨立開源，并跟ClickHouse社區(qū)消息同步。
二、功能特性
ByConity 引入了計算與存儲分離的架構(gòu)，將原本計算和存儲分別在每個節(jié)點本地管理的架構(gòu)，轉(zhuǎn)換為在分布式存儲上統(tǒng)一管理整個集群內(nèi)所有數(shù)據(jù)的架構(gòu)，使得每個計算節(jié)點成為一個無狀態(tài)的單純計算節(jié)點，并利用分布式存儲的擴(kuò)展能力和計算節(jié)點的無狀態(tài)特性實現(xiàn)動態(tài)的擴(kuò)縮容。正是由于這種改進(jìn)，使得ByConity具有以下重要特性：
資源隔離：對不同的租戶進(jìn)行資源的隔離，租戶之間不會受到相互影響；
讀寫分離：計算資源和存儲資源解耦，確保讀操作和寫操作不會相互影響；
彈性擴(kuò)縮容：支持彈性的擴(kuò)縮容，能夠?qū)崟r、按需的對計算資源進(jìn)行擴(kuò)縮容，保證資源的高效利用；
數(shù)據(jù)強一致：數(shù)據(jù)讀寫的強一致性，確保數(shù)據(jù)始終是最新的，讀寫之間沒有不一致；
高性能：采用了主流的 OLAP 引擎優(yōu)化，例如列存、向量化執(zhí)行、MPP 執(zhí)行、查詢優(yōu)化等提供優(yōu)異的讀寫性能。
三、技術(shù)架構(gòu)
3.1 整體架構(gòu)
ByConity 的架構(gòu)分為三層，如圖2所示，包括服務(wù)接入層，計算層和數(shù)據(jù)存儲層。服務(wù)接入層負(fù)責(zé)客戶端數(shù)據(jù)和服務(wù)的接入，也就是 ByConity Server；ByConity 的計算資源層，由一個或者多個計算組構(gòu)成，每個 Virtual Warehouse（VW）是一個計算組；數(shù)據(jù)存儲層由分布式文件系統(tǒng)，如 HDFS、S3 等構(gòu)成。
圖2 ByConity 三層技術(shù)架構(gòu)圖
3.2 工作原理
圖3 是 ByConity 組件交互圖，圖中虛線部分表示一個 SQL 的流入，實線部分的雙向箭頭表示組件內(nèi)的交互，單向箭頭表示數(shù)據(jù)的處理并輸出給客戶端。字節(jié)跳動數(shù)據(jù)平臺團(tuán)隊將通過一個 SQL 的完整生命周期來具體分析它在 ByConity 各個組件的交互過程。
圖3 ByConity 內(nèi)部組件交互圖
第一階段：客戶端提交 Query 請求給 Server 端，Server 端首先進(jìn)行 Parsering，然后通過 Analyzer 和 Optimizer分析和優(yōu)化生成更加高效的可執(zhí)行計劃。這里需要讀取元數(shù)據(jù) MetaData，元數(shù)據(jù)存儲在一個分布式 KV 里，ByConity 使用 FoundationDB，并通過 Catalog 讀取元數(shù)據(jù)。
第二階段：ByConity 把通過分析和優(yōu)化器后產(chǎn)生的可執(zhí)行計劃交由調(diào)度器（Plan Scheduler），調(diào)度器通過訪問Resource Manager 獲取空閑的計算資源，并決定把查詢?nèi)蝿?wù)調(diào)度到哪些節(jié)點去執(zhí)行。
第三階段：Query請求最終在 ByConity 的 Worker 上執(zhí)行，Worker 會從最底層的 Cloud Storage 讀取數(shù)據(jù)，并通過建立 Pipeline 的方式進(jìn)行計算。最終多個 Worker 的計算結(jié)果通過 Server 匯聚，并返回給客戶端。
ByConity 還有兩個主要的組件，分別是 Time-stamp Oracle 和 Deamon Manager。前者支持事務(wù)處理，后者則對后來的一些任務(wù)進(jìn)行管理和調(diào)度。
3.3 主要組件庫
1）元數(shù)據(jù)管理
ByConity 提供了一個高可用和高性能的元數(shù)據(jù)讀寫服務(wù)--Catalog Server，并且支持了完備的事務(wù)語義特性（ACID）。同時字節(jié)跳動數(shù)據(jù)平臺團(tuán)隊對 Catalog Server 做了比較好的抽象，使得后端的存儲系統(tǒng)是可插拔的，當(dāng)前他們支持的是蘋果開源的 FoundationDB，后面可以通過擴(kuò)展去支持更多的后端存儲系統(tǒng)。
2）查詢優(yōu)化器
查詢優(yōu)化器是數(shù)據(jù)庫系統(tǒng)的核心之一。一個優(yōu)秀的優(yōu)化器可以大大提高查詢性能。尤其是在復(fù)雜的查詢場景下，優(yōu)化器可以帶來數(shù)倍至數(shù)百倍的性能提升。ByConity 自研優(yōu)化器基于兩個方向提升優(yōu)化能力：
RBO：基于規(guī)則的優(yōu)化能力。支持：列裁剪、分區(qū)裁剪、表達(dá)式簡化、子查詢解除關(guān)聯(lián)、謂詞下推、冗余運算符消除、Outer-Join to Inner-Join、運算符下推存儲、分布式運算符拆分等常見的啟發(fā)式優(yōu)化能力。
CBO：基于成本的優(yōu)化能力。支持：Join Reorder、Outer-Join Reorder、Join/Agg Reorder、CTE、Materialized View、Dynamic Filter Push-Down、Magic Set 等基于成本的優(yōu)化能力，并為分布式計劃集成 Property Enforcement。
3）查詢調(diào)度
ByConity 目前支持兩種查詢調(diào)度策略：Cache-aware 調(diào)度和 Resource-aware 調(diào)度。其中：
Cache-aware 調(diào)度針對計算和存儲分離的場景，旨在最大化 Cache 的使用避免冷讀。Cache-aware 調(diào)度策略會盡可能地將任務(wù)調(diào)度到擁有對應(yīng)數(shù)據(jù)緩存的節(jié)點上，實現(xiàn)計算命中 Cache，提升讀寫性能。同時，由于系統(tǒng)進(jìn)行動態(tài)的擴(kuò)縮容，當(dāng)計算組的拓?fù)浒l(fā)生變化時，需要最小化 Cache 失效對查詢性能的影響。
Resource-aware 調(diào)度通過感知整個集群中計算組不同節(jié)點的資源使用情況，并有針對性地進(jìn)行調(diào)度，以最大化資源利用，同時還會進(jìn)行流量控制，確保合理使用資源，避免過載造成的負(fù)面影響，如系統(tǒng)宕機等。
4）計算組
ByConity支持不同的租戶使用不同的計算資源，如圖4 所示。在 ByConity 新的架構(gòu)下，很容易實現(xiàn)了多租戶隔離和讀寫分離等特性。不同租戶可以使用不同的計算組，實現(xiàn)多租戶隔離，同時支持讀寫分離。由于擴(kuò)縮容方便，計算組可以按需進(jìn)行動態(tài)的擴(kuò)縮容，保證資源利用率高效。當(dāng)資源利用率不高時，可以進(jìn)行資源共享，借調(diào)計算組給其他租戶使用，實現(xiàn)資源的最大化利用并降低成本。
圖4 計算組和多租戶
5）虛擬文件系統(tǒng)
虛擬文件系統(tǒng)模塊作為數(shù)據(jù)讀寫的中間層，ByConity 做了比較好的封裝，將存儲作為一種服務(wù)暴露給其他模塊使用，實現(xiàn)“存儲服務(wù)化”。虛擬文件系統(tǒng)提供了一個統(tǒng)一的文件系統(tǒng)抽象，屏蔽了不同的后端實現(xiàn)，方便擴(kuò)展并支持多種存儲系統(tǒng)，如 HDFS 或?qū)ο蟠鎯Φ取?/p>
6）緩存加速
ByConity 通過緩存進(jìn)行查詢加速，在計算-存儲分離的架構(gòu)下，ByConity 在元數(shù)據(jù)和數(shù)據(jù)維度都進(jìn)行緩存加速。在元數(shù)據(jù)維度，通過在 ByConity 的 Server 端的內(nèi)存中進(jìn)行緩存，以 Table 和 Partition 作為粒度。在數(shù)據(jù)維度，通過在ByConity 的 Worker 端，也就是計算組進(jìn)行緩存，而且在 Worker 端的緩存是層次化的，同時利用了 Memory 和磁盤，以 Mark 集合作為緩存粒度，從而有效地提高查詢速度。
7）如何獲取和部署
ByConity 目前支持四種獲取和部署模式，歡迎社區(qū)開發(fā)者使用，并提 Issue：單機Docker、K8s集群部署、物理機部署、源代碼編譯：
四、開源規(guī)劃
Roadmap：
據(jù)悉，ByConity 在 2023 年的開源社區(qū)路線圖中包括多個關(guān)鍵里程碑。這些里程碑旨在增強 ByConity 的功能、性能和易用性。其中，開發(fā)新的存儲引擎、支持更多的數(shù)據(jù)類型和與其他數(shù)據(jù)管理工具的集成是字節(jié)跳動重點關(guān)注領(lǐng)域。具體包含以下幾個方向：
性能提升：使用索引進(jìn)行加速，包含 Skip-index 優(yōu)化、新的 Zorder-index 和倒排索引等支持、外表索引的構(gòu)建和加速、以及索引的自動推薦和轉(zhuǎn)換；查詢優(yōu)化器的持續(xù)優(yōu)化；分布式緩存機制等。
穩(wěn)定性提升：支持更多維度的資源隔離，提供更好多租戶能力；豐富 Metrics，提升可觀察性和問題診斷能力。
企業(yè)級特性增強：實現(xiàn)更細(xì)粒度權(quán)限控制；完善數(shù)據(jù)安全性相關(guān)的功能（備份、恢復(fù)和數(shù)據(jù)加密）；持續(xù)探索數(shù)據(jù)的深度壓縮，節(jié)約存儲成本。
生態(tài)兼容性提升：支持 S3、TOS 等對象存儲；提升生態(tài)兼容性方便集成；支持?jǐn)?shù)據(jù)湖聯(lián)邦查詢?nèi)?Hudi、Iceberg等。
五、社區(qū)合作共建
總之，ByConity 是一個開源的云原生數(shù)據(jù)倉庫，提供讀寫分離、彈性擴(kuò)縮容、租戶資源隔離和數(shù)據(jù)讀寫的強一致性。其計算-存儲分離的架構(gòu)，結(jié)合主流的 OLAP 引擎優(yōu)化，確保了優(yōu)異的讀寫性能。隨著 ByConity 的不斷發(fā)展和改進(jìn)，其希望成為未來云原生數(shù)據(jù)倉庫的重要工具。
網(wǎng)頁搜索「GitHub - ByConity」查看官方地址。ByConity官方微信公眾號回復(fù)「用戶手冊」，獲取ByConity完整背景和技術(shù)架構(gòu)。
據(jù)了解，ByConity 發(fā)布 Beta 版本后，得到了來自華為、電子云、展心展力、天翼云、唯品會、傳音控股等十幾家企業(yè)開發(fā)者的支持，他們幫助 ByConity 分別在各自的環(huán)境下跑通了 TPC-DS 驗證，有些在自身業(yè)務(wù)場景下進(jìn)行測試并反饋出不錯的效果，并提出了諸多改進(jìn)建議。
ByConity項目負(fù)責(zé)人對此表示非常感謝，他也歡迎有意向的團(tuán)隊一起參與社區(qū)共建。據(jù)了解，目前ByConity已收到一些社區(qū)伙伴共建的意愿和想法。例如，ByConity與華為終端云的交流中達(dá)成了共建合作，未來會在 Kerberos 鑒權(quán)、ORC 的支持、以及支持 S3 存儲上一起共建。
（免責(zé)聲明：此文內(nèi)容為廣告，相關(guān)素材由廣告主提供，廣告主對本廣告內(nèi)容的真實性負(fù)責(zé)。本網(wǎng)發(fā)布目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點和對其真實性負(fù)責(zé)，請自行核實相關(guān)內(nèi)容。廣告內(nèi)容僅供讀者參考。）
（責(zé)任編輯：劉靜 HZ010）關(guān)鍵詞：
