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