5月22日，資深者眼中字節(jié)跳動(dòng)宣布開源 ByConity 云原生數(shù)據(jù)倉庫，開發(fā)開源項(xiàng)目地址：https://github.com/ByConity/ByConity。云原

ByConity 基于 ClickHouse 內(nèi)核開發(fā)，生數(shù)采用計(jì)算存儲(chǔ)分離的資深者眼中架構(gòu)、主流的開發(fā)開源 OLAP 引擎和自研的表引擎，提供便捷的云原彈性擴(kuò)縮容和極速的分析性能，覆蓋實(shí)時(shí)分析和海量數(shù)據(jù)的生數(shù)離線分析，幫助企業(yè)更好地挖掘數(shù)據(jù)價(jià)值。資深者眼中

ByConity 于 2022 年計(jì)劃開源，開發(fā)開源2023 年 1 月發(fā)布 beta 0.1.0 版本，云原一些關(guān)注字節(jié) ClickHouse 使用情況的生數(shù)的開發(fā)者在 ByConity 開源初期便進(jìn)行了一些測(cè)試，如華為終端云、資深者眼中唯品會(huì)、開發(fā)開源展心展力、云原中電云、傳音控股等團(tuán)隊(duì)。部分團(tuán)隊(duì)使用 ByConity 進(jìn)行了 TPC-DS 測(cè)試，也有一些深度試用的團(tuán)隊(duì)采用生產(chǎn)數(shù)據(jù)和具體場(chǎng)景進(jìn)行了測(cè)試。

在此期間，社區(qū)收到了很多團(tuán)隊(duì)對(duì)于 ByConity 性能的積極反饋，當(dāng)然也有團(tuán)隊(duì)遇到了一些部署中的難題和阻礙，并為社區(qū)提供了許多非常不錯(cuò)的改進(jìn)建議。在和社區(qū)用戶交流的過程中我們發(fā)現(xiàn)，不同的團(tuán)隊(duì)可能會(huì)遇到一些相似的問題，也會(huì)基于各自的業(yè)務(wù)需求設(shè)計(jì)對(duì)應(yīng)的解決方案。

今年5月 ByConity 正式開源發(fā)布 GA 0.1.0 版本，為了幫助更多關(guān)注者在早期更好地使用 ByConity，社區(qū)邀請(qǐng)了幾位參與 ByConity 測(cè)試和試用的團(tuán)隊(duì)成員與 ByConity 資深研發(fā)工程師進(jìn)行了一次交流，希望將社區(qū)的經(jīng)驗(yàn)分享給遇到同樣問題和正在考慮解決方法的團(tuán)隊(duì)。

參與此次交流的幾位嘉賓為：

Kevin Fang，字節(jié)跳動(dòng) ByConity 資深研發(fā)工程師

趙金濤，華為大數(shù)據(jù)研發(fā)工程師

徐慶岳，中電云數(shù)據(jù)庫內(nèi)核技術(shù)專家

程偉，MetaApp 大數(shù)據(jù)研發(fā)工程師

本文根據(jù)此次交流中的部分要點(diǎn)整理而成。

Q1：各位在平時(shí)工作中會(huì)使用大數(shù)據(jù)的哪些技術(shù)和產(chǎn)品？是什么契機(jī)讓你們接觸到 ByConity？

程偉：我們主要是做了一個(gè) OLAP 日志分析平臺(tái)，開始選的是 ClickHouse，中間存在一些問題。后來通過字節(jié)跳動(dòng) ClickHouse 技術(shù)沙龍了解到字節(jié)對(duì) ClickHouse 進(jìn)行了優(yōu)化，輸出到 ByConity 中，做了開源 ，我們就開始嘗試。

徐：我們是在做定制云計(jì)算，自己也有一些數(shù)據(jù)庫產(chǎn)品。在私有云的部分項(xiàng)目中遇到了一些問題，比如說有些產(chǎn)品數(shù)據(jù)量特別大，每天會(huì)有 2 個(gè) PB 的數(shù)據(jù)進(jìn)來，查詢一般需要是秒級(jí)，響應(yīng)要求也比較高。在產(chǎn)品中，除了查詢需求，也有匯入的需求，比如單節(jié)點(diǎn)匯入需求要達(dá)到差不多 400 兆每秒，查詢也要比較快。

按照我們自己目前的方法，匯入需求能達(dá)到，但查詢的時(shí)候，甲方會(huì)希望“能不能再快一點(diǎn)？” 。當(dāng)時(shí)我們基于自己開發(fā)團(tuán)隊(duì)的一些產(chǎn)品感覺有點(diǎn)吃力，就對(duì)其他產(chǎn)品做了一些了解，比如 ClickHouse、騰訊云和字節(jié)的產(chǎn)品，當(dāng)然也有一些創(chuàng)業(yè)型公司的項(xiàng)目。當(dāng)時(shí)得知 ByConity 開源了，我們想有更多了解，就邀請(qǐng) ByConity 負(fù)責(zé)人進(jìn)行了交流。溝通后發(fā)現(xiàn)有些技術(shù)方面確實(shí)值得借鑒，于是我們做了一些針對(duì)性測(cè)試，看看某些功能點(diǎn)上是不是可以使用。

趙：我們內(nèi)部也在廣泛使用 ClickHouse，在使用過程中發(fā)現(xiàn)它存在一些架構(gòu)上的短板，比如說擴(kuò)縮容的成本很高，擴(kuò)縮容的時(shí)候需要刷元數(shù)據(jù)、停 merge、停 mutate、搬遷數(shù)據(jù)等代價(jià)非常大，集群的資源難以根據(jù)負(fù)載靈活調(diào)整，存在浪費(fèi)。這個(gè)時(shí)候看到包括 ClickHouse 公司在內(nèi)，大數(shù)據(jù)領(lǐng)域有非常多的產(chǎn)品都在構(gòu)建云原生能力。

我們認(rèn)為云原生是大數(shù)據(jù)的必然趨勢(shì)。也是這個(gè)時(shí)候，我們從網(wǎng)上得知字節(jié)把在 ClickHouse 領(lǐng)域多年的技術(shù)積累貢獻(xiàn)出來，開源給社區(qū)了。基于這個(gè)契機(jī)，我們投入到社區(qū)里面來，希望借鑒 ByConity 的一些思想，把 ClickHouse 打造成一個(gè)高性能的云原生數(shù)據(jù)庫。

Q2：其實(shí)咱們碰到的很多的問題都是有共性的，例如在應(yīng)用 ClickHouse 解決業(yè)務(wù)問題的時(shí)候，遇到擴(kuò)縮容、性能方面的一些問題。那想問各位老師，大家覺得在解決這些問題的過程中有哪些難點(diǎn)，我們最需要攻克的關(guān)鍵技術(shù)點(diǎn)是什么？

程偉：一是在計(jì)算方面，希望能夠計(jì)算得快一些；再就是能夠支持更多的數(shù)據(jù)源；另外是能夠支持更龐大的數(shù)據(jù)量。

徐：通過對(duì) ByConity 技術(shù)的了解，它應(yīng)該是按 Snowflake 論文來走的，包括元數(shù)據(jù)、數(shù)據(jù)的存算分離以及分布式的 MPP。在擴(kuò)縮容這一塊，S3 或者 HDFS 確實(shí)是一個(gè)很高的提高。但是在計(jì)算方面，未來怎么能夠感知每個(gè)查詢所需的計(jì)算資源多少？比如一個(gè)查詢需要一臺(tái)機(jī)器，下一個(gè)查詢可能需要 100 臺(tái)機(jī)器，從計(jì)算方面如何彈性？這可能也是云計(jì)算本身存在的最大的一個(gè)理由，就是能夠感知什么時(shí)候把計(jì)算資源根據(jù)租戶來分配，或者根據(jù)不同的查詢來分配。如果是根據(jù)租戶，比如根據(jù)每個(gè)租戶的節(jié)點(diǎn)拓?fù)渥卟煌牟樵儯珺yConity 應(yīng)該是這種路線實(shí)現(xiàn)的。但是如果能夠更智能地感知當(dāng)前的查詢需要多少個(gè)計(jì)算資源，那就更好了。

趙：我認(rèn)為在大數(shù)據(jù)多維分析領(lǐng)域有兩點(diǎn)是需要平衡的，第一是性能，第二是靈活性，極高的性能必然會(huì)損失靈活性。比如像 ClickHouse，它的各節(jié)點(diǎn)是完全對(duì)等的，元數(shù)據(jù)和數(shù)據(jù)都分片保存在節(jié)點(diǎn)上，這種 ShareNothing 的架構(gòu)結(jié)合 ClickHouse 強(qiáng)大的 MPP 計(jì)算能力和極致的細(xì)節(jié)優(yōu)化使得 ClickHouse 性能非常快。如果我們想在保證 ClickHouse 性能的基礎(chǔ)上，具備更高的靈活性，讓它靈活擴(kuò)縮容，這種訴求和 ClickHouse 原生架構(gòu)存在沖突。所以基于 ClickHouse 的原生架構(gòu)去發(fā)展很難實(shí)現(xiàn)類似彈性伸縮這樣的靈活性。

那我們就需要對(duì) ClickHouse 架構(gòu)改造升級(jí)，需要在比較高的靈活性下，仍然能保證性能。在這個(gè)過程中，就存在技術(shù)挑戰(zhàn)，比如需要將數(shù)據(jù)和節(jié)點(diǎn)的綁定解耦，需要實(shí)現(xiàn)節(jié)點(diǎn)的徹底無狀態(tài)，元數(shù)據(jù)要從本地磁盤抽到統(tǒng)一的元數(shù)據(jù)中心，數(shù)據(jù)要從本地磁盤推到 HDFS 或者是 S3 等的這些對(duì)象存儲(chǔ)上。對(duì)于大數(shù)據(jù)分析引擎來講，這種架構(gòu)升級(jí)涉及的細(xì)節(jié)非常多，牽一發(fā)而動(dòng)全身，技術(shù)挑戰(zhàn)也很大。而這種改造必然會(huì)帶來性能的降低。這時(shí)我們要采取其他的一些技術(shù)手段，比如緩存等，來提升性能。

Q3：在了解項(xiàng)目之后是如何上手的？是否遇到了一些障礙？體驗(yàn)如何？

程偉：我們最初使用 ByConity，是基于社區(qū)提供的 TPC-DS 測(cè)試項(xiàng)目來上手的。社區(qū)有一個(gè)比較詳細(xì)的教程介紹如何通過 Docker 來部署 ByConity。把 ByConity 部署以后，跑了 TPC-DS 數(shù)據(jù)。在教程中會(huì)涉及到一些不清楚的點(diǎn)，加上我們想修改一些配置，由于對(duì)這些配置的了解情況并不是很多，所以就沒有達(dá)到需要的效果。目前經(jīng)過跟社區(qū)進(jìn)行溝通，已經(jīng)解決了這些問題。我們現(xiàn)在已經(jīng)將 ByConity 部署在 K8s 上，并且基于 ByConity 提供了日志分析服務(wù)。

我們團(tuán)隊(duì)對(duì) ByConity 社區(qū)一個(gè)最大印象就是溝通的成本非常低，非常有效果，我們遇到一個(gè)問題的時(shí)候，在社區(qū)提出，很快就有社區(qū)的相關(guān)同學(xué)，以及社區(qū)中的一些其他愛好者來協(xié)助我們解決這些問題。

徐：我們團(tuán)隊(duì)也在 Docker 上對(duì) ByConity 進(jìn)行了部署和測(cè)試，主要是看對(duì) SQL 兼容性。但由于項(xiàng)目原因我們更關(guān)注 ByConity 寫入和讀取的速度，更多關(guān)注技術(shù)細(xì)節(jié)，比如說跟 HDFS 打交道的時(shí)候做的一些優(yōu)化細(xì)節(jié)，我們會(huì)從源碼級(jí)角度去看。和社區(qū)接觸的過程中，團(tuán)隊(duì)的響應(yīng)很快。在測(cè)試中我們也給社區(qū)找出了一個(gè) bug。

在使用中感覺 ByConity 的性能提升很多，比如查詢性能。如果說把單個(gè) libHDFS 上拿出來做對(duì)比的話，跟 ClickHouse 社區(qū)比可以達(dá)到百分之四五十的性能提升。后續(xù)我們還會(huì)再測(cè)一測(cè)優(yōu)化函數(shù)性能提升如何。

趙：ByConity 開源以后，我們首先跑了雛形，然后分析了 ByConity 的源碼和基于 ClickHouse 的一些改進(jìn)點(diǎn)。在此過程中，發(fā)現(xiàn) ByConity 是想構(gòu)建一個(gè)比較完善的云原生的數(shù)據(jù)庫，對(duì) ClickHouse 的各種功能角色解耦非常徹底。

我們也和社區(qū)一起共建，比如 MergeTree 支持對(duì)象存儲(chǔ)，Hive 外表支持對(duì)象存儲(chǔ)，Hive 外表的功能完善等等。在過程此中我們多次和社區(qū)一起討論，一起把能力打磨成熟。近期我們?cè)谑褂玫臅r(shí)候發(fā)現(xiàn)某些場(chǎng)景下相比 ClickHouse 性能大幅劣化，也正在和社區(qū)一起去分析瓶頸，提升性能。

Q4：后續(xù)團(tuán)隊(duì)希望將 ByConity 用于什么業(yè)務(wù)場(chǎng)景，有什么短期和長期的規(guī)劃？

程偉：現(xiàn)階段我們主要將 ByConity 用在日志分析平臺(tái)的搭建。我們使用了 ByConity 的一個(gè) Map 類型來將日志保存起來。一般來說大家都會(huì)采用固定的一些字段來做。但我們用了 Map，是因?yàn)槲覀內(nèi)罩局胁淮_定的字段太多，所以我們根據(jù)名字和類型，通過創(chuàng)建 3 個(gè) Map 來將我們的日志保存起來。這樣日志查詢的時(shí)候只需要拿到日志的 schema，就可以根據(jù) schema 對(duì)應(yīng)的類型來拿到對(duì)應(yīng)的日志。現(xiàn)在我們每天會(huì)打入幾百萬條數(shù)日志數(shù)據(jù)，目前表現(xiàn)還是非常不錯(cuò)的。

另外我們有一個(gè) OLAP 的數(shù)據(jù)分析平臺(tái)，會(huì)有 A/B 測(cè)試，數(shù)據(jù)指標(biāo)分析等功能，現(xiàn)階段是基于 ClickHouse 來做的，未來我們可能會(huì)用 ByConity 來進(jìn)行嘗試，替代 ClickHouse 來把這一部分的業(yè)務(wù)給推起來。

徐：云計(jì)算公司，像大家都知道的比如火山引擎、華為云都有自研的產(chǎn)品，但不可能每個(gè)產(chǎn)品都自研，也會(huì)使用開源項(xiàng)目。 ByConity 跟社區(qū)版的 ClickHouse 架構(gòu)差異比較大，也會(huì)在某些場(chǎng)景下符合我們的一些需求，在選型的時(shí)候就會(huì)考慮使用 ByConity。同時(shí)我們也會(huì)考慮 ByConity 的團(tuán)隊(duì)怎么樣，以及社區(qū)的活躍度。 社區(qū)如果不能繼續(xù)推進(jìn)的話，對(duì)于后續(xù)一些功能的使用就會(huì)有影響。

未來我們也會(huì)和社區(qū)和團(tuán)隊(duì)做交流，看我們有哪些合適的使用場(chǎng)景，有哪些技術(shù)點(diǎn)是雙方可以一起來提升的，以及哪些是可以回饋社區(qū)的。因?yàn)榇蠹叶际羌夹g(shù)愛好者，希望能夠相互成就。

趙：我們的首版本還在構(gòu)建中，會(huì)用于多維分析場(chǎng)景。首先會(huì)借鑒 ByConity 構(gòu)建一個(gè)比較完善的云原生的數(shù)據(jù)庫，實(shí)現(xiàn)資源彈性伸縮。我們還會(huì)借鑒 ByConity 的架構(gòu)，構(gòu)建湖倉一體的能力，不僅僅能夠用于分析場(chǎng)景，還能用于數(shù)倉的場(chǎng)景，比如說可以分析 Hive 外表、Iceberg、Hudi 等等。

首先我們會(huì)聚焦第一個(gè)場(chǎng)景，會(huì)和社區(qū)一起解決一些迫在眉睫的問題。比如查詢性能，ByConity 熱讀的性能比較理想，但冷讀的查詢性能還有比較大的提升空間。所以這段時(shí)間我們會(huì)把精力放在提升 ByConity 的冷讀性能上，我們正在分析冷讀的情景，想方法讓 ByConity 能夠持平或者至少接近 ClickHouse 的原生版本。

我們還發(fā)現(xiàn)某些異常場(chǎng)景下偶現(xiàn)數(shù)據(jù)丟失等現(xiàn)象，我們會(huì)著重提升可靠性，確保運(yùn)行穩(wěn)定可靠。

性能和可靠性提升后我們會(huì)借鑒 ByConity 資源隔離以及云原生的能力，來構(gòu)建一個(gè)比較完善的云原生數(shù)據(jù)庫，能夠?qū)崿F(xiàn)集群的彈性伸縮，集群能夠根據(jù)查詢量的大小動(dòng)態(tài)的去分配資源等等，這些是我們未來的目標(biāo)。

Q5：對(duì) ByConity 技術(shù)路線的看法和訴求

程偉：我們對(duì) ByConity 目前的功能，包括未來想要做的云原生數(shù)倉的愿景，都非常看好。之后是否能夠支持 ClickHouse 相關(guān)的一些數(shù)據(jù)遷移工作，或者說能夠給出一些遷移 ClickHouse 的幫助？這樣的話能夠讓 ByConity 可以更好地去應(yīng)用起來。

再就是 ByConity 未來是否可以變成一個(gè)更通用的分布式計(jì)算引擎，可以對(duì)更多的數(shù)據(jù)源進(jìn)行一些計(jì)算。

徐：這個(gè)問題還是比較大的，我覺得每個(gè)產(chǎn)品都有自己的場(chǎng)景，對(duì)于使用方來說可能主要是看產(chǎn)品的成熟度，如果做得好，甚至可以培養(yǎng)用戶的習(xí)慣。不同的數(shù)據(jù)庫產(chǎn)品大多使用方法不同，可能使用的 SQL 語句都不同，如果對(duì)產(chǎn)品不熟悉，更換產(chǎn)品的對(duì)于大多數(shù)人來說上手都比較困難。如果 ByConity 成熟之后，在很多場(chǎng)景下，性能和靈活性都兼具了，用戶多了，也就慢慢培養(yǎng)了用戶的習(xí)慣。

數(shù)據(jù)庫的技術(shù)路線，我想做數(shù)據(jù)庫的應(yīng)該都知道，比如存算分離、讀寫分離等，但是如何把一個(gè)產(chǎn)品做成功，可能跟產(chǎn)品未來的發(fā)展、社區(qū)的發(fā)展相關(guān)。比如多云部署是否支持等。

趙：ByConity 的 GA 版本已發(fā)布，我認(rèn)為接下來首先要把 ByConity 的能力繼續(xù)完善，補(bǔ)齊功能，增強(qiáng)冷讀性能，提升可靠性，構(gòu)建一個(gè)比較完善的云原生數(shù)據(jù)庫。第二點(diǎn)是把 ByConity 強(qiáng)大的性能拓寬到其他領(lǐng)域，比如說能夠把它用到數(shù)倉領(lǐng)域，在一定程度上或者在某些場(chǎng)景下能夠替代 Spark，能夠加速模型層的計(jì)算。

Q6：在社區(qū)建設(shè)方面大家有什么看法

程偉：作為資深用戶，對(duì)社區(qū)的最大的訴求，一是能夠有更詳細(xì)的文檔幫助用戶快速上手，以及一些比較詳細(xì)的配置文檔，能夠讓我們對(duì) ByConity 的一些參數(shù)進(jìn)行調(diào)整，達(dá)到一個(gè)更好的狀態(tài)。再就是與社區(qū)溝通中快速反饋的方式。另外就是社區(qū)進(jìn)度的同步，是否有定期的活動(dòng)。

Kevin：文檔化建設(shè)是社區(qū)非常重要的一部分，后面會(huì)有兩種類型的文檔，一種是給用戶看的，比如用戶手冊(cè)，另外一個(gè)是面向開發(fā)者，會(huì)有更多的技術(shù)細(xì)節(jié)。大家在看文檔中遇到一些問題也歡迎隨時(shí)提出。

關(guān)于問題反饋，我們最推薦的還是 GitHub 的 issue，大家都能看到，也能幫助遇到相同問題的人。

定期活動(dòng)我們肯定是有的，比如我們每月都會(huì)舉辦的 webinar，就會(huì)有一個(gè)專題去講這些內(nèi)容。前面講了 ByConity 的一些技術(shù)架構(gòu)的點(diǎn)，后面會(huì)分享一些計(jì)劃要做的內(nèi)容。

徐：之后希望看到 ByConity 技術(shù)點(diǎn)和功能迭代更加完善，也希望看到一些好的實(shí)現(xiàn)方法。社區(qū)共建這塊，我覺得可以針對(duì)運(yùn)維同學(xué)做一些事情，比如做開設(shè)一些課程培訓(xùn)，并進(jìn)行認(rèn)證，可以加深對(duì)于產(chǎn)品的熟悉程度，也培養(yǎng)了更多的用戶。

Kevin：這個(gè)角度特別好，目前我們面向的更多是開發(fā)人員，隨著被用了更多之后，第一手接觸的大部分是運(yùn)維人員。對(duì)于這批人我們?nèi)绾翁峁└押玫闹С郑热缃坛獭⑸鲜忠约敖鉀Q問題的通道。后續(xù)我們也可以一起商量，通過社區(qū)一起來做。

趙：后續(xù)可以定期組織一些 meetup，邀請(qǐng)不同企業(yè)的開發(fā)人員來分享各自的實(shí)踐。另外還可以組織一些代碼解讀的活動(dòng)，解讀 ByConity 的架構(gòu)和關(guān)鍵技術(shù)，比如它的查詢優(yōu)化器、導(dǎo)入、集群管理等等，尤其一些關(guān)鍵流程是如何實(shí)現(xiàn)的，這樣也能讓更多的開發(fā)者參與進(jìn)來繁榮社區(qū)。

總結(jié)

Kevin：非常歡迎大家參與社區(qū)共建，一起形成技術(shù)的輸出。比如每個(gè)團(tuán)隊(duì)側(cè)重做的模塊不一樣，可能對(duì)某個(gè)模塊會(huì)有非常深的理解，這些我們是不是可以用文章的形式發(fā)布出來，匯總起來，放到社區(qū)中，讓其他的開發(fā)者都能夠從中受益。

最后希望大家在平時(shí)業(yè)務(wù)當(dāng)中總結(jié)出來的，包括在自己業(yè)務(wù)上得到驗(yàn)證的一些經(jīng)驗(yàn)方法，一方面能夠回饋給社區(qū)，讓有共性的這些業(yè)務(wù)場(chǎng)景能夠去使用；另外一方面也希望業(yè)界的各位專家們一起加入 ByConity，把 ByConity 打造得更好。

彩蛋

此次訪談中還有一些精彩的技術(shù)溝通未在本文章展開，如：

在 Map 使用過程中的一些建議和處理方式

ByConity 冷讀和熱度的查詢性能差異

數(shù)據(jù)湖在 ByConity 未來發(fā)展中的考慮與應(yīng)用場(chǎng)景

數(shù)據(jù)遷移工具的相關(guān)討論

如何使用云原生進(jìn)行降本增效

Keeper 高可用的探討

本次訪談完整視頻已上傳 ByConity B站：開源云原生數(shù)倉 ByConity，社區(qū)共建讓技術(shù)走得更遠(yuǎn)_嗶哩嗶哩_bilibili

ByConity 是一個(gè)開放的社區(qū)，歡迎更多對(duì)云原生數(shù)據(jù)倉庫感興趣的小伙伴加入社區(qū)，一起交流，一起共建。

審核編輯黃宇