背景介紹

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

圖1 行為分析系統(tǒng)架構(gòu)設(shè)計(jì)

問(wèn)題和挑戰(zhàn)

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

但是在已有的ClickHouse集群上我們很難做到。原因是ClickHouse是基于Shared-Nothing的架構(gòu)，每個(gè)節(jié)點(diǎn)是獨(dú)立的，不會(huì)共享存儲(chǔ)資源，因而計(jì)算資源和存儲(chǔ)資源是緊耦合的，會(huì)導(dǎo)致如下問(wèn)題：

擴(kuò)縮容成本變高，且會(huì)涉及到數(shù)據(jù)遷移，使我們不能實(shí)時(shí)按需的擴(kuò)縮容，而且會(huì)導(dǎo)致資源的浪費(fèi)，成本不可控

緊耦合的架構(gòu)會(huì)導(dǎo)致多租戶(hù)在共享集群環(huán)境相互影響，造成用戶(hù)查詢(xún)相互影響

由于集群上節(jié)點(diǎn)的讀寫(xiě)在同一個(gè)節(jié)點(diǎn)完成，導(dǎo)致讀寫(xiě)相互影響

在復(fù)雜查詢(xún)上例如多表Join等操作的性能支持并不是很好，無(wú)法滿(mǎn)足用戶(hù)查詢(xún)多樣化的需求

技術(shù)選型

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

圖2 ByConity三層技術(shù)架構(gòu)圖

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

資源隔離：對(duì)不同的租戶(hù)進(jìn)行資源的隔離，租戶(hù)之間不會(huì)受到相互影響。

讀寫(xiě)分離：計(jì)算資源和存儲(chǔ)資源解耦，確保讀操作和寫(xiě)操作不會(huì)相互影響。

彈性擴(kuò)縮容：支持彈性的擴(kuò)縮容，能夠?qū)崟r(shí)、按需的對(duì)計(jì)算資源進(jìn)行擴(kuò)縮容，保證資源的高效利用。

數(shù)據(jù)強(qiáng)一致：數(shù)據(jù)讀寫(xiě)的強(qiáng)一致性，確保數(shù)據(jù)始終是最新的，讀寫(xiě)之間沒(méi)有不一致。

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

業(yè)務(wù)收益

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

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

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

運(yùn)維成本低，故障節(jié)點(diǎn)秒級(jí)替換：

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

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

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

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

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

未來(lái)展望

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

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

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

未來(lái)階段ByConity會(huì)主要聚焦在以下幾個(gè)方向：

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

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

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