5月22日，字節跳動宣布開源 ByConity 云原生數據倉庫，項目地址：https://github.com/ByConity/ByConity。

ByConity 基于 ClickHouse 內核開發，采用計算存儲分離的架構、主流的 OLAP 引擎和自研的表引擎，提供便捷的彈性擴縮容和極速的分析性能，覆蓋實時分析和海量數據的離線分析，幫助企業更好地挖掘數據價值。

ByConity 于 2022 年計劃開源，2023 年 1 月發布 beta 0.1.0 版本，一些關注字節 ClickHouse 使用情況的的開發者在 ByConity 開源初期便進行了一些測試，如華為終端云、唯品會、展心展力、中電云、傳音控股等團隊。部分團隊使用 ByConity 進行了 TPC-DS 測試，也有一些深度試用的團隊采用生產數據和具體場景進行了測試。

在此期間，社區收到了很多團隊對于 ByConity 性能的積極反饋，當然也有團隊遇到了一些部署中的難題和阻礙，并為社區提供了許多非常不錯的改進建議。在和社區用戶交流的過程中我們發現，不同的團隊可能會遇到一些相似的問題，也會基于各自的業務需求設計對應的解決方案。

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

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

Kevin Fang，字節跳動 ByConity 資深研發工程師

趙金濤，華為大數據研發工程師

徐慶岳，中電云數據庫內核技術專家

程偉，MetaApp 大數據研發工程師

本文根據此次交流中的部分要點整理而成。

Q1：各位在平時工作中會使用大數據的哪些技術和產品？是什么契機讓你們接觸到 ByConity？

程偉：我們主要是做了一個 OLAP 日志分析平臺，開始選的是 ClickHouse，中間存在一些問題。后來通過字節跳動 ClickHouse 技術沙龍了解到字節對 ClickHouse 進行了優化，輸出到 ByConity 中，做了開源 ，我們就開始嘗試。

徐：我們是在做定制云計算，自己也有一些數據庫產品。在私有云的部分項目中遇到了一些問題，比如說有些產品數據量特別大，每天會有 2 個 PB 的數據進來，查詢一般需要是秒級，響應要求也比較高。在產品中，除了查詢需求，也有匯入的需求，比如單節點匯入需求要達到差不多 400 兆每秒，查詢也要比較快。

按照我們自己目前的方法，匯入需求能達到，但查詢的時候，甲方會希望“能不能再快一點？” 。當時我們基于自己開發團隊的一些產品感覺有點吃力，就對其他產品做了一些了解，比如 ClickHouse、騰訊云和字節的產品，當然也有一些創業型公司的項目。當時得知 ByConity 開源了，我們想有更多了解，就邀請 ByConity 負責人進行了交流。溝通后發現有些技術方面確實值得借鑒，于是我們做了一些針對性測試，看看某些功能點上是不是可以使用。

趙：我們內部也在廣泛使用 ClickHouse，在使用過程中發現它存在一些架構上的短板，比如說擴縮容的成本很高，擴縮容的時候需要刷元數據、停 merge、停 mutate、搬遷數據等代價非常大，集群的資源難以根據負載靈活調整，存在浪費。這個時候看到包括 ClickHouse 公司在內，大數據領域有非常多的產品都在構建云原生能力。

我們認為云原生是大數據的必然趨勢。也是這個時候，我們從網上得知字節把在 ClickHouse 領域多年的技術積累貢獻出來，開源給社區了。基于這個契機，我們投入到社區里面來，希望借鑒 ByConity 的一些思想，把 ClickHouse 打造成一個高性能的云原生數據庫。

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

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

徐：通過對 ByConity 技術的了解，它應該是按 Snowflake 論文來走的，包括元數據、數據的存算分離以及分布式的 MPP。在擴縮容這一塊，S3 或者 HDFS 確實是一個很高的提高。但是在計算方面，未來怎么能夠感知每個查詢所需的計算資源多少？比如一個查詢需要一臺機器，下一個查詢可能需要 100 臺機器，從計算方面如何彈性？這可能也是云計算本身存在的最大的一個理由，就是能夠感知什么時候把計算資源根據租戶來分配，或者根據不同的查詢來分配。如果是根據租戶，比如根據每個租戶的節點拓撲走不同的查詢，ByConity 應該是這種路線實現的。但是如果能夠更智能地感知當前的查詢需要多少個計算資源，那就更好了。

趙：我認為在大數據多維分析領域有兩點是需要平衡的，第一是性能，第二是靈活性，極高的性能必然會損失靈活性。比如像 ClickHouse，它的各節點是完全對等的，元數據和數據都分片保存在節點上，這種 ShareNothing 的架構結合 ClickHouse 強大的 MPP 計算能力和極致的細節優化使得 ClickHouse 性能非常快。如果我們想在保證 ClickHouse 性能的基礎上，具備更高的靈活性，讓它靈活擴縮容，這種訴求和 ClickHouse 原生架構存在沖突。所以基于 ClickHouse 的原生架構去發展很難實現類似彈性伸縮這樣的靈活性。

那我們就需要對 ClickHouse 架構改造升級，需要在比較高的靈活性下，仍然能保證性能。在這個過程中，就存在技術挑戰，比如需要將數據和節點的綁定解耦，需要實現節點的徹底無狀態，元數據要從本地磁盤抽到統一的元數據中心，數據要從本地磁盤推到 HDFS 或者是 S3 等的這些對象存儲上。對于大數據分析引擎來講，這種架構升級涉及的細節非常多，牽一發而動全身，技術挑戰也很大。而這種改造必然會帶來性能的降低。這時我們要采取其他的一些技術手段，比如緩存等，來提升性能。

Q3：在了解項目之后是如何上手的？是否遇到了一些障礙？體驗如何？

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

我們團隊對 ByConity 社區一個最大印象就是溝通的成本非常低，非常有效果，我們遇到一個問題的時候，在社區提出，很快就有社區的相關同學，以及社區中的一些其他愛好者來協助我們解決這些問題。

徐：我們團隊也在 Docker 上對 ByConity 進行了部署和測試，主要是看對 SQL 兼容性。但由于項目原因我們更關注 ByConity 寫入和讀取的速度，更多關注技術細節，比如說跟 HDFS 打交道的時候做的一些優化細節，我們會從源碼級角度去看。和社區接觸的過程中，團隊的響應很快。在測試中我們也給社區找出了一個 bug。

在使用中感覺 ByConity 的性能提升很多，比如查詢性能。如果說把單個 libHDFS 上拿出來做對比的話，跟 ClickHouse 社區比可以達到百分之四五十的性能提升。后續我們還會再測一測優化函數性能提升如何。

趙：ByConity 開源以后，我們首先跑了雛形，然后分析了 ByConity 的源碼和基于 ClickHouse 的一些改進點。在此過程中，發現 ByConity 是想構建一個比較完善的云原生的數據庫，對 ClickHouse 的各種功能角色解耦非常徹底。

我們也和社區一起共建，比如 MergeTree 支持對象存儲，Hive 外表支持對象存儲，Hive 外表的功能完善等等。在過程此中我們多次和社區一起討論，一起把能力打磨成熟。近期我們在使用的時候發現某些場景下相比 ClickHouse 性能大幅劣化，也正在和社區一起去分析瓶頸，提升性能。

Q4：后續團隊希望將 ByConity 用于什么業務場景，有什么短期和長期的規劃？

程偉：現階段我們主要將 ByConity 用在日志分析平臺的搭建。我們使用了 ByConity 的一個 Map 類型來將日志保存起來。一般來說大家都會采用固定的一些字段來做。但我們用了 Map，是因為我們日志中不確定的字段太多，所以我們根據名字和類型，通過創建 3 個 Map 來將我們的日志保存起來。這樣日志查詢的時候只需要拿到日志的 schema，就可以根據 schema 對應的類型來拿到對應的日志。現在我們每天會打入幾百萬條數日志數據，目前表現還是非常不錯的。

另外我們有一個 OLAP 的數據分析平臺，會有 A/B 測試，數據指標分析等功能，現階段是基于 ClickHouse 來做的，未來我們可能會用 ByConity 來進行嘗試，替代 ClickHouse 來把這一部分的業務給推起來。

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

未來我們也會和社區和團隊做交流，看我們有哪些合適的使用場景，有哪些技術點是雙方可以一起來提升的，以及哪些是可以回饋社區的。因為大家都是技術愛好者，希望能夠相互成就。

趙：我們的首版本還在構建中，會用于多維分析場景。首先會借鑒 ByConity 構建一個比較完善的云原生的數據庫，實現資源彈性伸縮。我們還會借鑒 ByConity 的架構，構建湖倉一體的能力，不僅僅能夠用于分析場景，還能用于數倉的場景，比如說可以分析 Hive 外表、Iceberg、Hudi 等等。

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

我們還發現某些異常場景下偶現數據丟失等現象，我們會著重提升可靠性，確保運行穩定可靠。

性能和可靠性提升后我們會借鑒 ByConity 資源隔離以及云原生的能力，來構建一個比較完善的云原生數據庫，能夠實現集群的彈性伸縮，集群能夠根據查詢量的大小動態的去分配資源等等，這些是我們未來的目標。

Q5：對 ByConity 技術路線的看法和訴求

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

再就是 ByConity 未來是否可以變成一個更通用的分布式計算引擎，可以對更多的數據源進行一些計算。

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

數據庫的技術路線，我想做數據庫的應該都知道，比如存算分離、讀寫分離等，但是如何把一個產品做成功，可能跟產品未來的發展、社區的發展相關。比如多云部署是否支持等。

趙：ByConity 的 GA 版本已發布，我認為接下來首先要把 ByConity 的能力繼續完善，補齊功能，增強冷讀性能，提升可靠性，構建一個比較完善的云原生數據庫。第二點是把 ByConity 強大的性能拓寬到其他領域，比如說能夠把它用到數倉領域，在一定程度上或者在某些場景下能夠替代 Spark，能夠加速模型層的計算。

Q6：在社區建設方面大家有什么看法

程偉：作為資深用戶，對社區的最大的訴求，一是能夠有更詳細的文檔幫助用戶快速上手，以及一些比較詳細的配置文檔，能夠讓我們對 ByConity 的一些參數進行調整，達到一個更好的狀態。再就是與社區溝通中快速反饋的方式。另外就是社區進度的同步，是否有定期的活動。

Kevin：文檔化建設是社區非常重要的一部分，后面會有兩種類型的文檔，一種是給用戶看的，比如用戶手冊，另外一個是面向開發者，會有更多的技術細節。大家在看文檔中遇到一些問題也歡迎隨時提出。

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

定期活動我們肯定是有的，比如我們每月都會舉辦的 webinar，就會有一個專題去講這些內容。前面講了 ByConity 的一些技術架構的點，后面會分享一些計劃要做的內容。

徐：之后希望看到 ByConity 技術點和功能迭代更加完善，也希望看到一些好的實現方法。社區共建這塊，我覺得可以針對運維同學做一些事情，比如做開設一些課程培訓，并進行認證，可以加深對于產品的熟悉程度，也培養了更多的用戶。

Kevin：這個角度特別好，目前我們面向的更多是開發人員，隨著被用了更多之后，第一手接觸的大部分是運維人員。對于這批人我們如何提供更友好的支持，比如教程、上手以及解決問題的通道。后續我們也可以一起商量，通過社區一起來做。

趙：后續可以定期組織一些 meetup，邀請不同企業的開發人員來分享各自的實踐。另外還可以組織一些代碼解讀的活動，解讀 ByConity 的架構和關鍵技術，比如它的查詢優化器、導入、集群管理等等，尤其一些關鍵流程是如何實現的，這樣也能讓更多的開發者參與進來繁榮社區。

總結

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

最后希望大家在平時業務當中總結出來的，包括在自己業務上得到驗證的一些經驗方法，一方面能夠回饋給社區，讓有共性的這些業務場景能夠去使用；另外一方面也希望業界的各位專家們一起加入 ByConity，把 ByConity 打造得更好。

彩蛋

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

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

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

數據湖在 ByConity 未來發展中的考慮與應用場景

數據遷移工具的相關討論

如何使用云原生進行降本增效

Keeper 高可用的探討

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

ByConity 是一個開放的社區，歡迎更多對云原生數據倉庫感興趣的小伙伴加入社區，一起交流，一起共建。

審核編輯黃宇