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

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

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

(資料圖片)

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

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

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

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

一、開源準備

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

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

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

? Conity 也來自 Community,代表一群人,也就是開源開發(fā)者社區(qū)。

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

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

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

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

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

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

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

二、社區(qū)反響

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

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

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

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

三、架構亮點與差異

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

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

ByConity 最新架構圖

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

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

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

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

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

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

? 在庫表創(chuàng)建、數據導入與查詢上的差異

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

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

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

四、后續(xù)規(guī)劃

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

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

ByConity 2023 年技術路線 Roadmap

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

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

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

五、寫在最后

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

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

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

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

采訪嘉賓介紹:

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

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