日增320TB數(shù)據(jù)，從ClickHouse遷移至ByConity后，查詢性能十分穩(wěn)定！

背景介紹

ByConity適合多種業(yè)務場景，在實時數(shù)據(jù)接入、大寬表聚合查詢、海量數(shù)據(jù)下復雜分析計算、多表關聯(lián)查詢場景下有非常好的性能。我們用一個實際的業(yè)務場景來介紹下，這套行為分析系統(tǒng)是基于用戶多維度行為分析平臺，提供事件分析、留存分析、轉(zhuǎn)化分析、用戶分群、用戶留存等多種分析方式和場景。本文將介紹下該用戶多維度行為分析平臺在使用原ClickHouse集群遇到的問題和挑戰(zhàn)，以及通過遷移ByConity后如何解決這些問題并給業(yè)務帶來的收益。

圖1 行為分析系統(tǒng)架構設計

問題和挑戰(zhàn)

早期這套系統(tǒng)部署在ClickHouse集群，一方面，由于業(yè)務的高速發(fā)展導致數(shù)據(jù)量日益膨脹，每日最大新增數(shù)據(jù)超過320TB，每日新增行數(shù)超過2.3萬億條，用戶數(shù)據(jù)維度超過2萬多個；另一方面，用戶查詢需求更加靈活和多樣化，需要同時支持明細查詢、聚合查詢以及交互式分析查詢，并快速給出響應結果。此外，在數(shù)據(jù)量不斷增加的情況下（年增長35%），我們既要能支撐這么大的數(shù)據(jù)增量帶來的挑戰(zhàn)，又要把成本增速控制在一定范圍內(nèi)。

但是在已有的ClickHouse集群上我們很難做到。原因是ClickHouse是基于Shared-Nothing的架構，每個節(jié)點是獨立的，不會共享存儲資源，因而計算資源和存儲資源是緊耦合的，會導致如下問題：

擴縮容成本變高，且會涉及到數(shù)據(jù)遷移，使我們不能實時按需的擴縮容，而且會導致資源的浪費，成本不可控

緊耦合的架構會導致多租戶在共享集群環(huán)境相互影響，造成用戶查詢相互影響

由于集群上節(jié)點的讀寫在同一個節(jié)點完成，導致讀寫相互影響

在復雜查詢上例如多表Join等操作的性能支持并不是很好，無法滿足用戶查詢多樣化的需求

技術選型

因此在2022年初業(yè)務開始使用計算存儲分離架構的ByConity來作為主要的OLAP引擎。ByConity是一個開源的云原生數(shù)據(jù)倉庫，它采用計算存儲分離的架構，支持多個關鍵功能特性，如計算存儲分離、彈性擴縮容、多租戶資源隔離和數(shù)據(jù)讀寫的強一致性等。通過利用主流的OLAP引擎優(yōu)化，如列存儲、向量化執(zhí)行、MPP執(zhí)行、查詢優(yōu)化等，ByConity可以提供優(yōu)異的讀寫性能。

圖2 ByConity三層技術架構圖

ByConity是在開源的ClickHouse架構基礎上進行了升級，引入了計算與存儲分離的架構，將原本計算和存儲分別在每個節(jié)點本地管理的架構，轉(zhuǎn)換為在分布式存儲上統(tǒng)一管理整個集群內(nèi)所有數(shù)據(jù)的架構，使得每個計算節(jié)點成為一個無狀態(tài)的單純計算節(jié)點，并利用分布式存儲的擴展能力和計算節(jié)點的無狀態(tài)特性實現(xiàn)動態(tài)的擴縮容。正是由于這種改進，使得ByConity具有以下重要特性：

資源隔離：對不同的租戶進行資源的隔離，租戶之間不會受到相互影響。

讀寫分離：計算資源和存儲資源解耦，確保讀操作和寫操作不會相互影響。

彈性擴縮容：支持彈性的擴縮容，能夠?qū)崟r、按需的對計算資源進行擴縮容，保證資源的高效利用。

數(shù)據(jù)強一致：數(shù)據(jù)讀寫的強一致性，確保數(shù)據(jù)始終是最新的，讀寫之間沒有不一致。

高性能：采用了主流的OLAP引擎優(yōu)化，例如列存、向量化執(zhí)行、MPP執(zhí)行、查詢優(yōu)化等提供優(yōu)異的讀寫性能

業(yè)務收益

在我們引入了ByConity后，整體性能可以達到91%用戶查詢都可以在10秒內(nèi)完成，通過來自用戶的反饋調(diào)研，這個性能指標也是在用戶可接受的范圍內(nèi)。這里總結下我們遷移ByConity帶來的總體收益和經(jīng)驗：

避免資源搶占，查詢性能百分百穩(wěn)定：

在原來ClickHouse的集群上，我們經(jīng)常會遇到資源擠占的問題，由于ClickHouse并沒有做到資源隔離和租戶隔離，在多個用戶共用集群進行查詢時，當一個用戶查詢資源開銷非常大，會涉及資源的搶占，導致這個集群上所有共用的用戶查詢都不穩(wěn)定，服務質(zhì)量達不到滿足。但在遷移到ByConity后，由于計算組是完全物理隔離，可以達到天然的資源隔離和租戶隔離，不同用戶的查詢相互不受到影響，整體查詢性能可以達到91%用戶查詢都可以在10秒內(nèi)完成。再者ByConity提供了自研的復雜查詢鏈路，自研 Disk Cache以減少冷數(shù)據(jù)讀取，并對于高頻使用的Array 建立索引等，而且熱讀效率也優(yōu)于原ClickHouse集群，相比在原Clickhouse集群上性能折損在10%以內(nèi)。

運維成本低，故障節(jié)點秒級替換：

原本在Clickhouse集群上，如果發(fā)現(xiàn)集群中某個節(jié)點壞掉，需要先下掉整臺機器維修，這是因為ClickHouse的計算資源、存儲資源、以及元數(shù)據(jù)信息都在這個節(jié)點上，相當于集群少了一個計算資源，也少了一個存儲副本，在替換新的節(jié)點之前，需要把對壞掉節(jié)點的本地磁盤進行備份遷移到新的節(jié)點上，維護成本比較高，且數(shù)據(jù)一致性很難得到保障。而對于ByConity來講，如果發(fā)生計算組壞掉的情況，由于計算組不存儲數(shù)據(jù)，只包含無狀態(tài)的計算節(jié)點，因此只需要替換新的計算組即可，數(shù)據(jù)的可靠性和一致性由HDFS來保障，且本地熱讀數(shù)據(jù)緩存的丟失對業(yè)務查詢性能是可控的，這部分也主要得益于了ByConity存儲和計算分離架構實現(xiàn)。

無感擴縮容，節(jié)約資源成本：

ByConity是可以實現(xiàn)無感擴縮容，它是一個模塊化和容器化的部署，基于Kubernetes的彈性伸縮能力，如果有足夠的機器可以無限的擴容，同時如果服務器發(fā)生故障，我們也不用擔心，因為ByConity的節(jié)點只一個無狀態(tài)的計算節(jié)點，直接下掉對整個集群影響不大。而且通過自適應調(diào)度回避慢節(jié)點，提升吞吐能力，提高節(jié)點資源利用率。同時ByConity的壓縮率極高，以其中一個業(yè)務為例，每日新增460TB數(shù)據(jù)，壓縮后達到100TB，壓縮比達到65%，并支持低基數(shù)編碼 & ZSTD等等壓縮方式，極端情況下存儲占用小于parquet。

數(shù)據(jù)一致性強保障，維護復雜度接近為零：

在遷移到ByConity后，我們完全解決了數(shù)據(jù)一致性問題，因為ByConity不存在本地的主備同步問題，數(shù)據(jù)一致性問題直接交給底層的對象存儲解決，例如HDFS/S3等。這樣對一致性維護的復雜度大大降低，錯誤概率也更低，目前也少有用戶再反饋數(shù)據(jù)一致性問題。但在之前是經(jīng)常遇到，因為ClickHouse集群是多個副本通過節(jié)點間通信去維護的，通過一致性隊列去維護一致性問題，實現(xiàn)上也很復雜，容易出錯。另外，ByConity可以通過HDFS直接訪問到數(shù)據(jù)文件，不同計算引擎適配不同連接器，即可讀入數(shù)據(jù)，具備通用能力。

未來展望

通過長達一年半的實踐摸索，ByConity已經(jīng)成為內(nèi)部使用的主要OLAP引擎，后期會有大量的用戶和數(shù)據(jù)遷入，最終取代原本的ClickHouse集群?？梢钥闯鯞yConity作為一款計算存儲分離的OLAP引擎，具有高性能、高可擴展性和高穩(wěn)定性等優(yōu)點，能夠滿足大規(guī)模體量的數(shù)據(jù)處理和分析的需求。

通過在社區(qū)的交流以及社區(qū)發(fā)布的 Roadmap 討論

https://github.com/ByConity/ByConity/issues/26

未來階段ByConity會主要聚焦在以下幾個方向：

支持執(zhí)行層的多Stage執(zhí)行、ETL能力等

支持數(shù)據(jù)湖聯(lián)邦查詢?nèi)鏗udi、Iceberg等

ByConity社區(qū)擁有大量的用戶，同時是一個非常開放的社區(qū)，我們邀請大家和我們一起在Github上討論共建，也可以加入我們的微信群、飛書群或者Discord參與交流。