談談 ByConity 存儲計算分離架構和優勢

作者 |王蘊博@ByConity布道師

策劃 | 蔡芳芳

引言

ByConity 是一款位元組跳動開源的雲原生數倉引擎。它的一個重要優勢是采用存儲計算分離的架構，實作了讀寫分離和彈性擴縮容。這種架構確定讀操作和寫操作不會互相影響，使得計算資源和存儲資源解耦，兩者可以按需的且獨立的擴縮容，確定資源高效利用，同時保證資料讀寫的強一緻性。此外，ByConity 支援多租戶資源隔離功能，保證不同租戶之間不會互相影響，更加适合多租戶環境，同時 ByConity 采用主流的 OLAP 引擎優化，提供更加優異的讀寫性能。

延伸閱讀：位元組跳動開源ByConity：基于ClickHouse的存算分離架構雲原生數倉

ByConity 技術背景

ClickHouse 是一個開源的列式資料庫管理系統，它采用 Shared-Nothing 的架構，這種架構有以下典型特點：

• 每個節點獨立管理一部分資料
• 節點之間沒有資料共享
• 存儲和計算緊耦合

它的查詢執行大緻分為兩個階段。第一階段是每個節點獨立處理它管理的資料分片，負責 I/O、查詢和計算。第二階段是 Coordinator 節點将第一階段每個節點計算的結果進行預設彙總，然後傳回給用戶端。這種架構可以實作高性能和可擴充性，特别适合固定業務規模的情況下進行高并發查詢。同時，由于節點之間無資料共享，擴充性也比較容易實作，可以實作線性擴充。

圖 1 Clickhouse 架構

但在實際使用過程中，我們發現如下問題：

• 擴縮容代價高：對于快速發展的業務，需要頻繁進行擴容操作，而資料的 reshuffle 以及資料搬遷會影響實際讀寫操作
• 多租戶之間可能會互相影響：不同業務之間可能會有不同的業務特征，導緻某些業務在特定時間點上占用了整個叢集的資源池，影響其他租戶
• 讀寫操作受到影響：每個節點都必須負責一部分讀寫任務，當節點資源使用較多時，查詢性能可能會受到影響
• 資源使用情況會存在浪費：特别是在多個中小型業務共用同一個叢集的情況下，可能會存在資源預估不足或者其他情況導緻資源浪費

ByConity 架構介紹

基于以上使用過程中發現的問題，我們在開源的 ClickHouse 架構基礎上進行了更新，引入了計算與存儲分離的架構，将原本計算和存儲分别在每個節點本地管理的架構轉換為在分布式存儲上統一管理整個叢集内所有資料的架構，使得每個計算節點成為一個無狀态的單純計算節點，并利用分布式存儲的擴充能力和計算節點的無狀态特性實作動态的擴縮容。此外，該架構還支援多租戶隔離和讀寫任務的分離。實作了以下優勢：

• 高彈性、高擴充性：計算和存儲獨立擴縮容
• 多租戶隔離：不同租戶使用不同計算組
• 讀寫分離：讀寫使用不同的計算資源

存儲計算分離架構

從總體架構上講，ByConity 的存儲計算分離架構如圖 3 所示，主要分為三層：共享服務層、計算層和雲存儲層。

• 共享服務層：主要元件是 Cloud Service，是所有查詢的入口，會對查詢進行解析和優化，生成 Query Plan 然後下發給計算層處理。它同時相當于一個協調者的角色，負責一些服務、元件和事務的管理，也包含中繼資料的管理--Metadata Storage。
• 計算層：主要是計算資源組--Virtual Warehouse（簡稱 VW） ，計算資源元件可以動态啟停，包括一個 Read VW 和一個 Writer VW。在 Read VW 中，每個 Worker 節點都有一個 Optimizer 和 Runtime 子產品，以及一個 Disk Cache 子產品來緩存部分資料以減少對分布式存儲遠端系統的通路，熱點資料存儲在 Disk Cache 子產品中。在 Writer VW 中，資料會先以 ClickHouse 格式寫入本地磁盤--Local Disk，然後再批量寫入分布式存儲，以提高寫入性能。
• 雲存儲層：是分布式統一存儲系統，ByConity 所有的資料都存儲在這一層，在計算層進行查詢時，會從雲存儲層中讀取資料。雲存儲層的具體實作可以采用各種雲存儲服務，如 HDFS、S3 等。

除此之外，ByConity 還包括一些共享的服務元件，如 TSO、Daemon Manager、Resource Manager、背景任務和服務發現等元件。

圖 2 ByConity 存儲計算分離架構

ByConity 架構優勢

資源隔離

在大資料場景下，資源隔離是非常重要的，它可以提高系統的資源使用率、性能、安全性、可靠性和靈活性，幫助企業解決諸多業務痛點問題，如：

• 避免不同租戶之間的資源沖突，提高資料安全性和租戶使用體驗；
• 根據不同的業務場景需求配置設定不同的資源，提高資源使用率和性能；
• 提高資料安全性，通過隔離不同的資料處理任務或資料庫執行個體，限制通路權限；
• 實作彈性擴縮容，根據不同的業務和資料量需求動态調整資源配置設定；
• 提高系統的可靠性和穩定性，隔離故障，避免對整個系統造成影響。

但 ClickHouse 并沒有對資源隔離做專門的設計，它是通過叢集和 replication 的配置、load_balanding 政策，以及指定本地表的寫入做到一定的讀寫分離。對于冷熱分離，ClickHouse 是通過配置存儲政策和使用 TTL、TO DISK、TO VOLUME 等技術實作。

ByConity 通過存儲計算分離的架構設計很好的實作了資源隔離，它引入了計算組（Virtual Warehouse 簡稱：VW）的概念，Virtual Warehouse 是計算資源的虛拟組織，可以将計算資源按需劃分為多個虛拟叢集，在不同租戶之間提供實體資源隔離。同時，把原本與計算資源耦合的存儲統一到分布式存儲管理後，計算資源與存儲資源是完全解耦的且無狀态的，進而計算節點主要承擔的是計算任務，這些任務可以是資料寫入、使用者查詢，也可以是一些背景任務。是以 ByConity 通過部署和使用 Virtual Warehouse 來實作多級資源隔離：

圖 3 ByConity 計算組

• 租戶隔離：ByConity 的 Virtual Warehouse 是無狀态的，可以根據不同的業務和場景進行按需的建立，且每個 Virtual Warehouse 是獨占系統資源，是以會很輕松的實作多租戶的隔離。當然，為了提高資源使用率，ByConity 也支援 Virtal Warehouse 之間的資源租借，實作資源共享。
• 計算資源隔離：Virtual Warehouse 使得計算資源做到實體層面的隔離，且每個 Virtual Warehouse 可以包含多個 worker，可以被靈活建立。

讀寫分離

除了資源隔離外，我們還希望達到讀寫的分離，讀寫的分離是将讀操作和寫操作分别處理。因為在實際業務中，讀操作和寫操作對硬體資源的要求，以及時間的要求是不同的，是以我們希望用不同的硬體資源去執行讀操作和寫操作，避免讀寫互相影響，影響系統性能和浪費資源，具體好處如下：

• 降低存儲成本：将讀操作和寫操作引導到不同的存儲節點上，避免不必要的資料複制和備援。
• 提高查詢效率：将讀操作引導到專門的讀節點上，減少查詢等待時間，進而提高資料處理效率和使用者體驗。
• 降低網絡成本：将讀操作引導到離使用者更近的讀節點上，減少資料傳輸的距離和網絡成本。
• 提高系統可用性：将讀操作和寫操作分别引導到不同的節點上，當某個節點發生故障時，隻會影響到該節點上的讀或寫操作，不會影響到整個系統的可用性

ByConity 可以通過 Virtual Warehouse 實作讀寫分離，使用者可以通過指定讀操作和寫操作使用哪個 Virtual Warehouse，系統會自動将不同的讀寫請求轉發。例如 Insert 操作使用專門用于寫入的計算組，Select 操作使用專門用于讀取的計算組，讀寫作業之間不會互相影響。但由于 ByConity 使用了統一的分布式存儲，必然會存在性能的問題，這裡 ByConity 是通過本地緩存（Local Cache）去解決的。

本地緩存

對于大容量的本地緩存管理，ByConity 使用 Bucket-LRU 算法，它是在 LRU 算法的基礎上進行了優化，會将緩存中的資料塊分為多個桶，每個桶中儲存一定數量的資料塊，并對每個桶使用 LRU 算法進行淘汰。這樣可以将緩存中的資料塊分散到多個桶中，進而降低了緩存淘汰的頻率，同時也減少了 LRU 算法的開銷。即使在計算組擴縮容等導緻網絡拓撲發生變化時，也依然使用這種機制，避免資料的 reshuffling。

圖 4 ByConity 的緩存力度 Segment

針對緩存的粒度，ByConity 引入 Segment 概念，如圖 4，它是一個介于檔案為機關和壓縮塊為機關的一個緩存粒度，大小可配置，并且适合檔案存儲。Segment 是由多個 Mark 組成的，每個 Mark 包含多個壓縮塊。當查詢需要讀取某個 Segment 時，可以先檢查緩存中是否存在該 Segment，如果存在，則直接從緩存中讀取資料，否則需要從磁盤讀取資料。在實際使用中，需要根據資料的特點和需求選擇合适的緩存政策，并進行優化和調整，以達到最優的性能和效果。ByConity 的緩存政策有以下幾種：

• 按照 Segment 的通路頻次：根據資料通路的頻次來判斷哪些資料是熱點資料，并進行緩存。
• 按照 Segment 的通路範圍：有些資料雖然通路頻次不高，但是其查詢範圍較大，也需要被緩存。
• 根據資料更新時間來決定熱點資料：對于實時表等場景，新過來的資料往往是熱點資料，需要被緩存。
• 基于統計資訊來優化緩存政策（開發中）：根據統計資訊來決定哪些資料是熱點資料，需要被緩存。

ByConity 的本地緩存的主要目的是在分布式存儲中，通過使用較少成本（容量）的本地高速緩存盤，來緩存資料以減少網絡讀取帶來的性能延遲增加問題。本地緩存的使用可以提高資料的通路速度和響應速度，進而減少對網絡的依賴，降低系統的延遲，提高系統的性能和穩定性。

無感擴縮容

随着業務資料翻倍增長，必須通過不斷的擴容支撐業務發展，但在 ClickHouse 的基礎上擴容的成本很高，這是因為 ClickHouse 從架構上沒有專門考慮擴縮容，導緻需要運維同學手動或者通過自動化腳本去建立新的 ClickHouse 節點和遷移副本資料來完成擴容，是以存在時間成本和遷移結果校驗的問題。再者，在擴容中需要将新的分片部署到新的節點上，這會導緻資料不再均衡，需要通過資料再均衡來解決。

ByConity 的存儲計算分離架構可以天然解決這個問題，能實作業務無感的擴縮容。ByConity 擴容分為兩種：一種是縱向擴容，即調整 Worker 的 CPU 核數和記憶體大小；另一種是橫向擴容，通過增、減 Worker 的數量，提升系統并發能力。這些依然通過 ByConity 的 Virtual Warehouse 和 Worker 去實作：

• 一方面資料總管（Resource Manager）負責對計算資源進行統一的管理和排程，能夠收集各個計算組的性能資料，資源使用量，為讀寫任務和背景任務動态配置設定資源并進行擴縮容，提高資源使用率。ByConity 的元件都已經容器化，通過調整 Kubernets 的 replica 數量可以非常友善的對指定的計算組進行擴縮容。除此之外，還可以結合計算組資源使用量，通過設定 kubernets 的擴縮容門檻值實作動态擴縮容。
• 另一方面，ByConity 的中繼資料和資料存儲在遠端，計算節點的無狀态化使擴縮容變得十分輕量，隻需等計算執行個體啟動完成，即可立即服務，無需額外的資料遷移開銷，實作實時擴縮容。

ByConity 使用場景

ByConity 使用大量成熟 OLAP 技術，例如列存引擎、MPP 執行、智能查詢優化、向量化執行、Codegen、Indexing、資料壓縮，主要用于 OLAP 查詢和計算場景。在實時資料接入、大寬表聚合查詢、海量資料下複雜分析計算、多表關聯查詢場景下有非常好的性能。

場景分類	場景	描述	特點
互動式查詢	使用者自定義查詢	支援多元查詢分析的資料應用	自由次元、多表關聯、響應快
自助式報表	支援 Tableau 等 BI 工具	自由次元、多表關聯、響應快
使用者畫像分析	支援 DMP 等圈人畫像平台	自由次元、多表關聯、響應快
營銷效果分析	支援流量效果漏鬥分析	多表關聯、實時
行為日志分析	支援日志探索分析	日志檢索、資料量大
實時資料看闆	實時業務監控大屏	支援 DataV 等可視化大屏	實時
直播資料統計看闆	支援實時報表	實時
業務儀表盤	支援報表工具	統計、響應快
系統鍊路監控	支援實時監控應用	實時
實時資料倉庫	實時資料接入	支援實時資料寫入、更新	實時資料寫入，立即可見
準實時 ETL 計算	支援複雜計算，資料清洗	混合負載

表 1

總結和展望

總結來說 ByConity 使用了存儲計算分離的架構，且在多個方面進行了優化和更新，具有以下的優勢和特性：

• 資源隔離：對不同的租戶進行資源的隔離，租戶之間不會受到互相影響。
• 讀寫分離：計算資源和存儲資源解耦，確定讀操作和寫操作不會互相影響。
• 彈性擴縮容：支援彈性的擴縮容，能夠實時、按需的對計算資源進行擴縮容，保證資源的高效利用。
• 資料強一緻：資料讀寫的強一緻性，確定資料始終是最新的，讀寫之間沒有不一緻。
• 高性能：采用主流的 OLAP 引擎優化，例如列存、向量化執行、MPP 執行、查詢優化等提供優異的讀寫性能。

圖 5 是接下來 ByConity 未來發展規劃圖，未來我們計劃從以下幾個方面進行優化和改進：

圖 5 ByConity 未來發展規劃

• 支援分布式 Disk Cache，一方面解決節點重新開機導緻 Local Cache 丢失的問題，另一方面希望達到全局最優的 Cache 機制，提升 Cache 命中率。
• 支援外表服務，例如 Hudi 和 Iceberg 等
• 支援存儲服務化，在 ByConity 存儲資料層上，利用 Spark 引擎或 Presto 引擎的計算能力執行一些 ETL 任務等

加入我們

ByConity 社群擁有大量的使用者，同時是一個非常開放的社群，邀請大家和我們一起讨論共建，在 Github 上建立了 issue：https://github.com/ByConity/ByConity/issues/2

延伸閱讀：

位元組跳動開源ByConity：基于ClickHouse的存算分離架構雲原生數倉

本文轉載來源：

https://www.infoq.cn/article/eDuYRT4rzgHBpqfV1T49