5月22日，字節(jié)跳動宣布開源 ByConity 云原生數(shù)據(jù)倉庫，項目地址：https://github.com/ByConity/ByConity。
ByConity 基于 ClickHouse 內核開發(fā)，采用計算存儲分離的架構、主流的 OLAP 引擎和自研的表引擎，提供便捷的彈性擴縮容和極速的分析性能，覆蓋實時分析和海量數(shù)據(jù)的離線分析，幫助企業(yè)更好地挖掘數(shù)據(jù)價值。
ByConity 于 2022 年計劃開源，2023 年 1 月發(fā)布 beta 0.1.0 版本，一些關注字節(jié) ClickHouse 使用情況的的開發(fā)者在 ByConity 開源初期便進行了一些測試，如華為終端云、唯品會、展心展力、中電云、傳音控股等團隊。部分團隊使用 ByConity 進行了 TPC-DS 測試，也有一些深度試用的團隊采用生產數(shù)據(jù)和具體場景進行了測試。
在此期間，社區(qū)收到了很多團隊對于 ByConity 性能的積極反饋，當然也有團隊遇到了一些部署中的難題和阻礙，并為社區(qū)提供了許多非常不錯的改進建議。在和社區(qū)用戶交流的過程中我們發(fā)現(xiàn)，不同的團隊可能會遇到一些相似的問題，也會基于各自的業(yè)務需求設計對應的解決方案。
今年5月 ByConity 正式開源發(fā)布 GA 0.1.0 版本，為了幫助更多關注者在早期更好地使用 ByConity，社區(qū)邀請了幾位參與 ByConity 測試和試用的團隊成員與 ByConity 資深研發(fā)工程師進行了一次交流，希望將社區(qū)的經(jīng)驗分享給遇到同樣問題和正在考慮解決方法的團隊。
參與此次交流的幾位嘉賓為：
Kevin Fang，字節(jié)跳動 ByConity 資深研發(fā)工程師
趙金濤，華為大數(shù)據(jù)研發(fā)工程師
徐慶岳，中電云數(shù)據(jù)庫內核技術專家
程偉，metaApp 大數(shù)據(jù)研發(fā)工程師
本文根據(jù)此次交流中的部分要點整理而成。
Q1：各位在平時工作中會使用大數(shù)據(jù)的哪些技術和產品？是什么契機讓你們接觸到 ByConity？
程偉：我們主要是做了一個 OLAP 日志分析平臺，開始選的是 ClickHouse，中間存在一些問題。后來通過字節(jié)跳動 ClickHouse 技術沙龍了解到字節(jié)對 ClickHouse 進行了優(yōu)化，輸出到 ByConity 中，做了開源 ，我們就開始嘗試。
徐：我們是在做定制云計算，自己也有一些數(shù)據(jù)庫產品。在私有云的部分項目中遇到了一些問題，比如說有些產品數(shù)據(jù)量特別大，每天會有 2 個 PB 的數(shù)據(jù)進來，查詢一般需要是秒級，響應要求也比較高。在產品中，除了查詢需求，也有匯入的需求，比如單節(jié)點匯入需求要達到差不多 400 兆每秒，查詢也要比較快。
按照我們自己目前的方法，匯入需求能達到，但查詢的時候，甲方會希望“能不能再快一點?” 。當時我們基于自己開發(fā)團隊的一些產品感覺有點吃力，就對其他產品做了一些了解，比如 ClickHouse、騰訊云和字節(jié)的產品，當然也有一些創(chuàng)業(yè)型公司的項目。當時得知 ByConity 開源了，我們想有更多了解，就邀請 ByConity 負責人進行了交流。溝通后發(fā)現(xiàn)有些技術方面確實值得借鑒，于是我們做了一些針對性測試，看看某些功能點上是不是可以使用。
趙：我們內部也在廣泛使用 ClickHouse，在使用過程中發(fā)現(xiàn)它存在一些架構上的短板，比如說擴縮容的成本很高，擴縮容的時候需要刷元數(shù)據(jù)、停 merge、停 mutate、搬遷數(shù)據(jù)等代價非常大，集群的資源難以根據(jù)負載靈活調整，存在浪費。這個時候看到包括 ClickHouse 公司在內，大數(shù)據(jù)領域有非常多的產品都在構建云原生能力。
我們認為云原生是大數(shù)據(jù)的必然趨勢。也是這個時候，我們從網(wǎng)上得知字節(jié)把在 ClickHouse 領域多年的技術積累貢獻出來，開源給社區(qū)了?；谶@個契機，我們投入到社區(qū)里面來，希望借鑒 ByConity 的一些思想，把 ClickHouse 打造成一個高性能的云原生數(shù)據(jù)庫。
Q2：其實咱們碰到的很多的問題都是有共性的，例如在應用 ClickHouse 解決業(yè)務問題的時候，遇到擴縮容、性能方面的一些問題。那想問各位老師，大家覺得在解決這些問題的過程中有哪些難點，我們最需要攻克的關鍵技術點是什么？
程偉：一是在計算方面，希望能夠計算得快一些;再就是能夠支持更多的數(shù)據(jù)源;另外是能夠支持更龐大的數(shù)據(jù)量。
徐：通過對 ByConity 技術的了解，它應該是按 Snowflake 論文來走的，包括元數(shù)據(jù)、數(shù)據(jù)的存算分離以及分布式的 MPP。在擴縮容這一塊，S3 或者 HDFS 確實是一個很高的提高。但是在計算方面，未來怎么能夠感知每個查詢所需的計算資源多少?比如一個查詢需要一臺機器，下一個查詢可能需要 100 臺機器，從計算方面如何彈性?這可能也是云計算本身存在的最大的一個理由，就是能夠感知什么時候把計算資源根據(jù)租戶來分配，或者根據(jù)不同的查詢來分配。如果是根據(jù)租戶，比如根據(jù)每個租戶的節(jié)點拓撲走不同的查詢，ByConity 應該是這種路線實現(xiàn)的。但是如果能夠更智能地感知當前的查詢需要多少個計算資源，那就更好了。
趙：我認為在大數(shù)據(jù)多維分析領域有兩點是需要平衡的，第一是性能，第二是靈活性，極高的性能必然會損失靈活性。比如像 ClickHouse，它的各節(jié)點是完全對等的，元數(shù)據(jù)和數(shù)據(jù)都分片保存在節(jié)點上，這種 ShareNothing 的架構結合 ClickHouse 強大的 MPP 計算能力和極致的細節(jié)優(yōu)化使得 ClickHouse 性能非?？?。如果我們想在保證 ClickHouse 性能的基礎上，具備更高的靈活性，讓它靈活擴縮容，這種訴求和 ClickHouse 原生架構存在沖突。所以基于 ClickHouse 的原生架構去發(fā)展很難實現(xiàn)類似彈性伸縮這樣的靈活性。
那我們就需要對 ClickHouse 架構改造升級，需要在比較高的靈活性下，仍然能保證性能。在這個過程中，就存在技術挑戰(zhàn)，比如需要將數(shù)據(jù)和節(jié)點的綁定解耦，需要實現(xiàn)節(jié)點的徹底無狀態(tài)，元數(shù)據(jù)要從本地磁盤抽到統(tǒng)一的元數(shù)據(jù)中心，數(shù)據(jù)要從本地磁盤推到 HDFS 或者是 S3 等的這些對象存儲上。對于大數(shù)據(jù)分析引擎來講，這種架構升級涉及的細節(jié)非常多，牽一發(fā)而動全身，技術挑戰(zhàn)也很大。而這種改造必然會帶來性能的降低。這時我們要采取其他的一些技術手段，比如緩存等，來提升性能。
Q3：在了解項目之后是如何上手的？是否遇到了一些障礙？體驗如何？
程偉：我們最初使用 ByConity，是基于社區(qū)提供的 TPC-DS 測試項目來上手的。社區(qū)有一個比較詳細的教程介紹如何通過 Docker 來部署 ByConity。把 ByConity 部署以后，跑了 TPC-DS 數(shù)據(jù)。在教程中會涉及到一些不清楚的點，加上我們想修改一些配置，由于對這些配置的了解情況并不是很多，所以就沒有達到需要的效果。目前經(jīng)過跟社區(qū)進行溝通，已經(jīng)解決了這些問題。我們現(xiàn)在已經(jīng)將 ByConity 部署在 K8s 上，并且基于 ByConity 提供了日志分析服務。
我們團隊對 ByConity 社區(qū)一個最大印象就是溝通的成本非常低，非常有效果，我們遇到一個問題的時候，在社區(qū)提出，很快就有社區(qū)的相關同學，以及社區(qū)中的一些其他愛好者來協(xié)助我們解決這些問題。
徐：我們團隊也在 Docker 上對 ByConity 進行了部署和測試，主要是看對 SQL 兼容性。但由于項目原因我們更關注 ByConity 寫入和讀取的速度，更多關注技術細節(jié)，比如說跟 HDFS 打交道的時候做的一些優(yōu)化細節(jié)，我們會從源碼級角度去看。和社區(qū)接觸的過程中，團隊的響應很快。在測試中我們也給社區(qū)找出了一個 bug。
在使用中感覺 ByConity 的性能提升很多，比如查詢性能。如果說把單個 libHDFS 上拿出來做對比的話，跟 ClickHouse 社區(qū)比可以達到百分之四五十的性能提升。后續(xù)我們還會再測一測優(yōu)化函數(shù)性能提升如何。
趙：ByConity 開源以后，我們首先跑了雛形，然后分析了 ByConity 的源碼和基于 ClickHouse 的一些改進點。在此過程中，發(fā)現(xiàn) ByConity 是想構建一個比較完善的云原生的數(shù)據(jù)庫，對 ClickHouse 的各種功能角色解耦非常徹底。
我們也和社區(qū)一起共建，比如 MergeTree 支持對象存儲，Hive 外表支持對象存儲，Hive 外表的功能完善等等。在過程此中我們多次和社區(qū)一起討論，一起把能力打磨成熟。近期我們在使用的時候發(fā)現(xiàn)某些場景下相比 ClickHouse 性能大幅劣化，也正在和社區(qū)一起去分析瓶頸，提升性能。
Q4：后續(xù)團隊希望將 ByConity 用于什么業(yè)務場景，有什么短期和長期的規(guī)劃？
程偉：現(xiàn)階段我們主要將 ByConity 用在日志分析平臺的搭建。我們使用了 ByConity 的一個 Map 類型來將日志保存起來。一般來說大家都會采用固定的一些字段來做。但我們用了 Map，是因為我們日志中不確定的字段太多，所以我們根據(jù)名字和類型，通過創(chuàng)建 3 個 Map 來將我們的日志保存起來。這樣日志查詢的時候只需要拿到日志的 schema，就可以根據(jù) schema 對應的類型來拿到對應的日志?，F(xiàn)在我們每天會打入幾百萬條數(shù)日志數(shù)據(jù)，目前表現(xiàn)還是非常不錯的。
另外我們有一個 OLAP 的數(shù)據(jù)分析平臺，會有 A/B 測試，數(shù)據(jù)指標分析等功能，現(xiàn)階段是基于 ClickHouse 來做的，未來我們可能會用 ByConity 來進行嘗試，替代 ClickHouse 來把這一部分的業(yè)務給推起來。
徐：云計算公司，像大家都知道的比如火山引擎、華為云都有自研的產品，但不可能每個產品都自研，也會使用開源項目。 ByConity 跟社區(qū)版的 ClickHouse 架構差異比較大，也會在某些場景下符合我們的一些需求，在選型的時候就會考慮使用 ByConity。同時我們也會考慮 ByConity 的團隊怎么樣，以及社區(qū)的活躍度。 社區(qū)如果不能繼續(xù)推進的話，對于后續(xù)一些功能的使用就會有影響。
未來我們也會和社區(qū)和團隊做交流，看我們有哪些合適的使用場景，有哪些技術點是雙方可以一起來提升的，以及哪些是可以回饋社區(qū)的。因為大家都是技術愛好者，希望能夠相互成就。
趙：我們的首版本還在構建中，會用于多維分析場景。首先會借鑒 ByConity 構建一個比較完善的云原生的數(shù)據(jù)庫，實現(xiàn)資源彈性伸縮。我們還會借鑒 ByConity 的架構，構建湖倉一體的能力，不僅僅能夠用于分析場景，還能用于數(shù)倉的場景，比如說可以分析 Hive 外表、Iceberg、Hudi 等等。
首先我們會聚焦第一個場景，會和社區(qū)一起解決一些迫在眉睫的問題。比如查詢性能，ByConity 熱讀的性能比較理想，但冷讀的查詢性能還有比較大的提升空間。所以這段時間我們會把精力放在提升 ByConity 的冷讀性能上，我們正在分析冷讀的情景，想方法讓 ByConity 能夠持平或者至少接近 ClickHouse 的原生版本。
我們還發(fā)現(xiàn)某些異常場景下偶現(xiàn)數(shù)據(jù)丟失等現(xiàn)象，我們會著重提升可靠性，確保運行穩(wěn)定可靠。
性能和可靠性提升后我們會借鑒 ByConity 資源隔離以及云原生的能力，來構建一個比較完善的云原生數(shù)據(jù)庫，能夠實現(xiàn)集群的彈性伸縮，集群能夠根據(jù)查詢量的大小動態(tài)的去分配資源等等，這些是我們未來的目標。
Q5：對 ByConity 技術路線的看法和訴求
程偉：我們對 ByConity 目前的功能，包括未來想要做的云原生數(shù)倉的愿景，都非?？春谩Ｖ笫欠衲軌蛑С?ClickHouse 相關的一些數(shù)據(jù)遷移工作，或者說能夠給出一些遷移 ClickHouse 的幫助?這樣的話能夠讓 ByConity 可以更好地去應用起來。
再就是 ByConity 未來是否可以變成一個更通用的分布式計算引擎，可以對更多的數(shù)據(jù)源進行一些計算。
徐：這個問題還是比較大的，我覺得每個產品都有自己的場景，對于使用方來說可能主要是看產品的成熟度，如果做得好，甚至可以培養(yǎng)用戶的習慣。不同的數(shù)據(jù)庫產品大多使用方法不同，可能使用的 SQL 語句都不同，如果對產品不熟悉，更換產品的對于大多數(shù)人來說上手都比較困難。如果 ByConity 成熟之后，在很多場景下，性能和靈活性都兼具了，用戶多了，也就慢慢培養(yǎng)了用戶的習慣。
數(shù)據(jù)庫的技術路線，我想做數(shù)據(jù)庫的應該都知道，比如存算分離、讀寫分離等，但是如何把一個產品做成功，可能跟產品未來的發(fā)展、社區(qū)的發(fā)展相關。比如多云部署是否支持等。
趙： ByConity 的 GA 版本已發(fā)布，我認為接下來首先要把 ByConity 的能力繼續(xù)完善，補齊功能，增強冷讀性能，提升可靠性，構建一個比較完善的云原生數(shù)據(jù)庫。第二點是把 ByConity 強大的性能拓寬到其他領域，比如說能夠把它用到數(shù)倉領域，在一定程度上或者在某些場景下能夠替代 Spark，能夠加速模型層的計算。
Q6：在社區(qū)建設方面大家有什么看法
程偉：作為資深用戶，對社區(qū)的最大的訴求，一是能夠有更詳細的文檔幫助用戶快速上手，以及一些比較詳細的配置文檔，能夠讓我們對 ByConity 的一些參數(shù)進行調整，達到一個更好的狀態(tài)。再就是與社區(qū)溝通中快速反饋的方式。另外就是社區(qū)進度的同步，是否有定期的活動。
Kevin：文檔化建設是社區(qū)非常重要的一部分，后面會有兩種類型的文檔，一種是給用戶看的，比如用戶手冊，另外一個是面向開發(fā)者，會有更多的技術細節(jié)。大家在看文檔中遇到一些問題也歡迎隨時提出。
關于問題反饋，我們最推薦的還是 GitHub 的 issue，大家都能看到，也能幫助遇到相同問題的人。
定期活動我們肯定是有的，比如我們每月都會舉辦的 webinar，就會有一個專題去講這些內容。前面講了 ByConity 的一些技術架構的點，后面會分享一些計劃要做的內容。
徐：之后希望看到 ByConity 技術點和功能迭代更加完善，也希望看到一些好的實現(xiàn)方法。社區(qū)共建這塊，我覺得可以針對運維同學做一些事情，比如做開設一些課程培訓，并進行認證，可以加深對于產品的熟悉程度，也培養(yǎng)了更多的用戶。
Kevin：這個角度特別好，目前我們面向的更多是開發(fā)人員，隨著被用了更多之后，第一手接觸的大部分是運維人員。對于這批人我們如何提供更友好的支持，比如教程、上手以及解決問題的通道。后續(xù)我們也可以一起商量，通過社區(qū)一起來做。
趙：后續(xù)可以定期組織一些 meetup，邀請不同企業(yè)的開發(fā)人員來分享各自的實踐。另外還可以組織一些代碼解讀的活動，解讀 ByConity 的架構和關鍵技術，比如它的查詢優(yōu)化器、導入、集群管理等等，尤其一些關鍵流程是如何實現(xiàn)的，這樣也能讓更多的開發(fā)者參與進來繁榮社區(qū)。
總結
Kevin：非常歡迎大家參與社區(qū)共建，一起形成技術的輸出。比如每個團隊側重做的模塊不一樣，可能對某個模塊會有非常深的理解，這些我們是不是可以用文章的形式發(fā)布出來，匯總起來，放到社區(qū)中，讓其他的開發(fā)者都能夠從中受益。
最后希望大家在平時業(yè)務當中總結出來的，包括在自己業(yè)務上得到驗證的一些經(jīng)驗方法，一方面能夠回饋給社區(qū)，讓有共性的這些業(yè)務場景能夠去使用;另外一方面也希望業(yè)界的各位專家們一起加入 ByConity，把 ByConity 打造得更好。
彩蛋
此次訪談中還有一些精彩的技術溝通未在本文章展開，如：
在 Map 使用過程中的一些建議和處理方式
ByConity 冷讀和熱度的查詢性能差異
數(shù)據(jù)湖在 ByConity 未來發(fā)展中的考慮與應用場景
數(shù)據(jù)遷移工具的相關討論
如何使用云原生進行降本增效
Keeper 高可用的探討
本次訪談完整視頻已上傳 ByConity B站：開源云原生數(shù)倉 ByConity，社區(qū)共建讓技術走得更遠_嗶哩嗶哩_bilibili
ByConity 是一個開放的社區(qū)，歡迎更多對云原生數(shù)據(jù)倉庫感興趣的小伙伴加入社區(qū)，一起交流，一起共建。
