熱鬧紛繁的 OLAP 賽道,又迎來一個開源新玩家。

這幾年 OLAP 賽道持續火熱,國內外不少開源項目和商業公司活躍其中。在一眾玩家中,ClickHouse 憑借彪悍的性能表現、活躍的開源社區和相當快的迭代速度,市場普及率一路狂飆。

圍繞 ClickHouse,最近有兩則新聞頗引人關注:一個是阿里云官宣與 ClickHouse 商業公司合作,成為 ClickHouse 在中國獨家的云服務提供商;另一個則是字節跳動 ByteHouse 與亞馬遜云科技合作推出新一代云數倉服務。兩種不同的組合,背后其實是國內外市場對 ClickHouse 云原生化產品和應用的濃厚興趣。

(資料圖片)

作為國內極具代表性的 ClickHouse 大規模采用者,字節跳動在歷經數年的 ClickHouse 云原生化改造和應用中沉淀了許多寶貴的實踐經驗和思考。2021 年 8 月,字節跳動將經過多年定制化改造的 ClickHouse,沉淀為 ByteHouse 對外提供服務。自那時起,就有人猜測:ByteHouse 會不會開源?

其實字節跳動為開源準備已久。今年,字節跳動將 ByteHouse 內核向社區開源為 ByConity,并于近日正式官宣發布 0.1.0 版本。

ByConity 定位為開源的云原生數據倉庫,采用 Apache 2.0 許可協議,基于 ClickHouse 內核,但采用了存儲計算分離的全新架構,支持多個關鍵功能特性,如存儲計算分離、彈性擴縮容、租戶資源隔離和數據讀寫的強一致性等。通過利用主流的 OLAP 引擎優化,如列存儲、向量化執行、MPP 執行、查詢優化等,ByConity 可以提供優異的讀寫性能。ByConity 適合用于 Online Analytical Processing(OLAP)場景和輕載數倉場景,包括但不限于交互式分析、實時日志監控、流數據處理和分析等。

借此機會,InfoQ 獨家采訪了 ByConity 背后的技術團隊,深入了解 ByConity 開源準備過程、架構亮點、ByConity 與 ClickHouse 的差異,以及 ByConity 后續規劃等問題。這也是 ByConity 開源后團隊首次接受采訪。

一、開源準備

為了和早些推出的商業品牌作區分、避免用戶混淆,團隊為開源版本取了新名字 ByConity。新名字由三個英文單詞組合再生而來:

? By 來自 Byte,代表存儲數據的基本單位,也比喻海量數據;

? Con 來自 Convert,代表改變和革新;

? Conity 也來自 Community,代表一群人,也就是開源開發者社區。

從采用 ClickHouse 遇到痛點進而自研改造,到推出商業化服務 ByteHouse,再到現在推出開源項目 ByConity,陳星認為這是一個自然而然的過程,ByteHouse 和 ByConity 背后實際也是同一個技術團隊在支持。在他看來,行業內有很多公司和團隊存在使用 ClickHouse 的痛點,對于解決這些問題并進一步拓寬其使用場景感興趣。開源能夠帶來更多技術層面的合作,也能幫助 ByConity 更快地擴展到更廣泛的不同行業中去,這是推動團隊將 ByConity 開源出來的重要動機之一。

在決定開源之前,團隊也考慮過是否能將自研修改合并回 ClickHouse 社區,并圍繞向社區完整貢獻和聯合開發,與 ClickHouse 核心研發團隊、ClickHouse 創業公司負責人做了幾次閉門溝通,但得到的反饋是架構差異過大、合并難度和代價大、無法聯合開發。最終按照 ClickHouse 社區給到的建議,團隊決定獨立開源,并跟 ClickHouse 社區進行了消息同步。

2022 年 5 月,團隊啟動 ByConity 開源相關研發和準備工作。到正式開源這期間,技術層面關鍵迭代主要有以下幾點:

升級 ByConity Codebase,和社區 ClickHouse 21.8 版本代碼做同步,因為最初字節跳動引入 ClickHouse 的時候用的還是早期版本,但 ClickHouse 社區在版本 19 到 22 之間做了比較大的重構,導致整個執行 model 發生了一些變化,這部分需要做不少代碼重寫工作,將整個代碼基線提升到社區新的 LTS 版本; 移除公司內部依賴組件,尋找對應的開源替代方案做兼容和適配,比如 FoudationDB 適配、ClickHouse-Keeper 適配等; 基于 Processor Model 重構 MPP 實現,提升性能與穩定性:主要解決了 ClickHouse 對于復雜 Query 的執行支持不好,功能也比較局限(Join 只支持 broadcast join)等問題;適配 ClickHouse 新版本基于 Processor Push Mode 的執行模式; 優化器迭代,重點迭代了優化規則(RBO),CBO 方面重點增強統計信息自動收集等:比如當用戶表有改動時,后臺任務會檢查統計信息表的修改行數,當達到一定閾值時觸發自動收集; 云原生架構設計下,增強數倉場景的查詢性能,數據能夠自動預讀,避免被動 cache 在實時場景下緩存命中率低的問題:支持 HDFS/S3 等分布式文件系統或者對象存儲系統,并針對不同的分布式存儲系統做了讀寫性能優化,存儲系統中也實現了基于本地磁盤的二級緩存系統,可以采用高性能本地盤來進一步加速存儲讀寫性能。

前兩點主要是為對外開源做準備,后三點則是在原來內部版本基礎上進一步優化升級。除了技術層面的準備,還涉及公司開源流程、代碼合規、工程質量、配套部署工具開發等一系列相關準備。

據陳星介紹,ByConity 開源非常徹底,引擎核心能力都開源了,只有因公司合規要求受限的部分做了一些裁剪。本質上 ByteHouse 云數倉的內核就是 ByConity,引擎能力基本一樣。后續 ByteHouse 研發新功能,也會直接在 ByConity 基礎上用開源的模式做,這對于團隊的研發模式來說是一個非常大的改變。

作為正式官宣開源前準備工作的關鍵一環,今年 1 月,團隊發布了 ByConity beta(v0.1.0-beta)版本,并在社區小范圍征集用戶試用。過去四個月陸陸續續已經有不少團隊試用 ByConity 并在 GitHub 上提 issue 反饋,其中有一些團隊已經在驗證生產場景中的數據和工作負載。翟鹿淵表示,希望通過這樣的小范圍試用,確認 ByConity 能真正幫助大家解決問題、帶來好處,再正式開源,讓更廣泛的用戶知道該如何使用 ByConity、能真正把 ByConity 用起來。比起一開始就官宣開源,這可能是一種相對謹慎但更務實的做法。

二、社區反響

Beta 版本推出后,ByConity 團隊從社區得到了不少反饋。好的一面是,有不少團隊和開發者對 ByConity 表現出濃厚興趣,其中不乏知名科技公司和團隊,比如傳音控股、電子云、華為、美團、天翼云、唯品會等,都在積極測試和驗證。據翟鹿淵介紹,目前國內采用了 ClickHouse 的公司中,ByConity 大致覆蓋了頭部的三分之一,都是使用規模相對比較大的。其中華為終端云團隊已經參與到了 ByConity 部分研發工作中,比如這次發布的 0.1.0 版本中有一個對象存儲集成功能的預覽版,就是華為終端云團隊參與共同開發的。

當然難免也會出現一些挑戰。在知乎 ByConity 相關問題下面,有網友反饋代碼風格對開發者不是很友好,一個方法里幾百上千行代碼,批評 ByConity 肯定是延續了 ClickHouse 開源代碼的問題。對此,陳星表示虛心接受批評,ByConity 本身就是基于 ClickHouse 內核開發,因此 CH 的代碼風格問題,ByConity 難以避免,再加上早期內部研發更多追求快速上線使用,對于代碼風格可能沒有特別高要求和統一規范。目前 ByConity 團隊已經在規劃和推進代碼重構工作、希望做出好的示范,也希望后續社區能夠一起推進這項工作。

類似的問題,翟鹿淵也被問到過,比如有開發者認為 ByConity 的代碼和 ClickHouse 重合度比較高。潛在的質疑或挑戰點在于,ByConity 不是一個完全自主研發的項目。對此團隊的態度很坦蕩,ByConity 的起點是 ClickHouse,這是事實,作為 ClickHouse 的下游項目,ByConity 會在向上兼容性方面做基礎保證,并在開源許可的 header 文件中對受益于哪些開源項目給到完整的說明。

ByConity 不會為了體現差異而做代碼調整(比如重命名一些函數、在命名空間上做些修飾等)。ByConity 希望能夠繼承 ClickHouse 的長處和優勢,比如性能上的優勢、工程設計上的亮點等,ByConity 都會繼續保留;同時針對實際業務場景中需要解決的問題,ByConity 會在新架構上做延展,以求在更廣泛的場景上發揮出更大作用,讓更多公司或團隊受益。

三、架構亮點與差異

從 2017 年引入 ClickHouse 至今,ByConity 團隊基于 ClickHouse 內核做了深度改造和大量升級優化,不管是技術難度還是技術投入程度都非常大。具體的優化思路在早前的采訪和白皮書做過詳細說明,近期 ByConity 社區也會聯合 InfoQ 陸續發布一系列 ByConity 技術解讀文章。

目前 ByConity 整體架構如下圖所示,分為 3 層:服務接入層、計算層和存儲層,其中服務接入層響應用戶查詢,計算層負責計算數據,存儲層存放用戶數據。詳細介紹可查閱 ByConity 的整體架構說明文檔。

ByConity 最新架構圖

基于從外部收到的反饋,翟鹿淵將 ByConity 相比傳統 MPP 架構的亮點概括為以下三點:

? 首先是存儲計算分離的改造。傳統 MPP 很難對計算資源做隔離,據翟鹿淵介紹,現在業界大多數使用 ClickHouse 方案的公司和團隊,采用的隔離方式基本是靠物理集群隔離,運維管理成本極高。存算分離之外,ByConity 依托于虛擬化容器調度能力,既能實現業務和業務之間的隔離,又能非常靈活地調配硬件資源,這其實是很多公司想解決,但可能只解了一半或者暫時還沒有好解決方案的嚴重問題。

? 其次是自研的面向 ClickHouse runtime 執行層、與之完全匹配的查詢優化器。基于四個大方向(基于規則、基于 cost、基于數據依賴、基于反饋)提供極致優化能力,能極大提高查詢性能,特別是在復雜查詢場景下能帶來數倍至數百倍的性能提升。雖然業界成熟的數倉引擎都會配備查詢優化器,但據了解,從 ClickHouse 技術方案衍生出來的查詢優化器,目前在業界應該沒有第二個方案。

? 然后是對元數據存儲和管理的優化。使用 ClickHouse 比較多的團隊可能都會遇到一個問題,隨著集群管理的元數據越來越多,ZooKeeper/Keeper 會面臨很大的 coordinate 壓力,可能出現元數據不一致的問題,輕則查詢報錯,重則整個集群宕機。這類問題在 ByConity 從系統層面得到了解決。ByConity 基于高性能的分布式 key-value store(FoundationDB)做元數據管理,并在 catalog api 上層實現了完備事務語義(ACID)支持,提供了高效可靠的元數據服務,能夠將元數據吞吐拉升到百萬級別。

除了架構上的差異化亮點,ByConity 和 ClickHouse 在使用過程中又有哪些異同?社區也有不少開發者對此有疑問。前不久 ByConity 社區組織了一場直播,從使用角度對兩者差異做了介紹,主要從以下幾個關鍵維度展開:

? 在資源隔離與擴縮容設計上的架構與組件差異

? 在庫表創建、數據導入與查詢上的差異

? 在事務支持與特殊表引擎上的差異

ByConity 與 ClickHouse 的差異總結(來源:ByConity 社區)

感興趣的讀者可以在bilibili搜索ByConity官方賬號查看直播回放視頻進一步了解。

四、后續規劃

隨著 ByConity 正式官宣開源,后續項目會遵循開源社區的模式來運營和治理,社區治理原則相關的文檔目前已經同步到項目 GitHub 上,并面向整個社區開放討論。

對于 ByConity 接下來的技術發展路線,團隊基于自身現狀初步做了一些規劃,今年下半年側重點會放在權限控制、數據安全和組件高可用等方向。還有一些社區關注度比較高的問題,比如對數據湖分析的支持,包括對接 Hudi、Iceberg 等功能,也在 Roadmap 規劃之中。

ByConity 2023 年技術路線 Roadmap

陳星表示,未來 ByConity 希望從一個只面向即時型分析的輕量級數倉,向一個能夠處理更多復雜工作負載、更成熟的數倉去演化。當然,這其中挑戰非常大,也不是短時間內能夠做好的,需要與社區共同努力。

對于一個新的開源項目,社區往往會非常關注項目的長期投入和發展問題。翟鹿淵表示,字節去年成立開源委員會,就是字節更加重視開源的一個信號,而開源委員會有一條原則是做精品項目,從公司層面會聚焦少數重點項目做長期的戰略投入,ByConity 是其中之一。另外,如前所述,ByConity 和 ByteHouse 研發團隊基本是完全重合的,只是每個人的工作有一部分在做商業版、一部分在解決開源社區相關反饋,開源和商業版融合度非常高。未來 ByConity 會朝著一個更加開放的引擎開發模式去發展,今年年中會將內外部代碼層面完全拉齊,后續對 ByteHouse 的改動會基于 ByConity 源代碼用開源的方式來開發,即先在上游開發,開發完成后在再往回拉。這個開發模式調整可以說是大動干戈,但也從側面印證了字節長期投入 ByConity 的決心。

未來除了 ByConity 社區自身的代碼貢獻,字節內部業務場景、ByteHouse 的客戶場景帶來的迭代和改進也會反哺給 ByConity,幫助 ByConity 持續迭代優化。比如,字節內部使用規模還在逐步增大,可能會打破以往設計方案的一些假設條件,導致調度策略或者資源分配策略要適應內部業務做優化和調整,這些優化都會輸出到 ByConity。商業化產品同理,商業版用戶在使用中遇到的問題或反饋的修改,也會同步到 ByConity。

五、寫在最后

對于一個開源項目,引入更多參與者、讓社區往多元化方向發展往往是重要目標之一,ByConity 也不例外。從發布 Beta 版開始,ByConity 團隊就公布了社區路線圖,并積極與社區成員共同探討和解決大家在試用過程中遇到的問題,團隊有耐心、也有信心,更是非常期待未來能夠與更多開發者和合作伙伴一起共建共享,激發更多創造力。

對于社區多元化可能會給項目創始團隊帶來的新問題,比如項目無法按照最初規劃的技術發展路線演進等,陳星和翟鹿淵都表示,希望這個幸福的煩惱早些到來。

網頁搜索「GitHub - ByConity」查看官方地址;

ByConity官方微信公眾號回復「用戶手冊」,獲取ByConity完整背景和技術架構。

采訪嘉賓介紹:

陳星,火山引擎分析型數據庫負責人,具體包括 ClickHouse、Doris、下一代云原生數據庫,支持內部多種業務場景背后分析引擎。加入字節跳動數據平臺之前,在 IBM 從事 DB2 內核研發工作,對數據庫技術有一些了解。

翟鹿淵,火山引擎 ByteHouse 產品經理,主導 ByteHouse 海外商業化和引擎 ByConity 開源。之前在 Kyligence 做 Apache Kylin 商業產品。