近日，火山引擎數(shù)智平臺(tái)VeDI與DataFun聯(lián)合舉辦以“OLAP計(jì)算引擎”為主題的直播活動(dòng)，來(lái)自火山引擎數(shù)智平臺(tái)VeDI的產(chǎn)品專家從技術(shù)選型、能力分析、性能優(yōu)化以及應(yīng)用場(chǎng)景落地多個(gè)角度，介紹火山引擎ByteHouse如何基于ClickHouse實(shí)現(xiàn)實(shí)時(shí)計(jì)算能力升級(jí)。

據(jù)介紹，火山引擎ByteHouse來(lái)源于字節(jié)跳動(dòng)多年內(nèi)部沉淀。由于場(chǎng)景越來(lái)越豐富以及數(shù)據(jù)分析需求增長(zhǎng)，業(yè)務(wù)對(duì)于實(shí)時(shí)數(shù)倉(cāng)的要求也越來(lái)越高。首先是數(shù)據(jù)體量大以及不斷增長(zhǎng)的問(wèn)題。早在2019 年，字節(jié)內(nèi)部每天新增的數(shù)據(jù)量就達(dá)到了100TB。其次，在海量數(shù)據(jù)基礎(chǔ)上，由于數(shù)據(jù)類型多樣（包括批式數(shù)據(jù)和流式數(shù)據(jù)）、查詢需求多樣、交互式分析復(fù)雜，數(shù)據(jù)引擎需要具備靈活性。目前，行業(yè)Redis、 SparkSQL 等開源方案可以從不同角度滿足上述兩個(gè)需求，但是維護(hù)多個(gè)開源數(shù)據(jù)庫(kù)將導(dǎo)致成本高，選擇一款可以避免成本無(wú)限擴(kuò)展的計(jì)算引擎成為字節(jié)數(shù)據(jù)研發(fā)首要考慮的問(wèn)題。

(資料圖片僅供參考)

ClickHouse性能高、靈活性強(qiáng)，且主要依賴磁盤、成本相對(duì)可控，成為字節(jié)跳動(dòng)內(nèi)部計(jì)算引擎的首選。但原生 ClickHouse 能力難以支持 upset 、實(shí)時(shí)數(shù)據(jù)更新等一些場(chǎng)景，在很多層面有局限性，例如：

· 單表性能強(qiáng)勁，但多表能力局限，且對(duì)標(biāo)準(zhǔn) SQL 兼容性低。

· 缺乏成熟運(yùn)維管理工具，運(yùn)維復(fù)雜程度高。

· ClickHouse 為 MPP 架構(gòu)（存算一體架構(gòu)），性能強(qiáng)，但橫向擴(kuò)容成本非常高、數(shù)據(jù)隔離性差。

ByteHouse產(chǎn)品專家在直播中介紹到，“為了解決以上問(wèn)題，我們主要從4個(gè)方向進(jìn)行優(yōu)化，讓OLAP引擎能力、性能、運(yùn)維、架構(gòu)進(jìn)一步升級(jí)?！?/strong>

第一，豐富的自研表引擎，實(shí)現(xiàn)OLAP引擎能力進(jìn)化。 ByteHouse 彌補(bǔ)了ClickHouse表引擎的不足，并衍生出全新的表引擎，包括使高可用表引擎、實(shí)時(shí)數(shù)據(jù)引擎、Unique 引擎、Bitmap 引擎。以Unique 引擎為例，它解決了社區(qū)版 ReplacingMergeTree 實(shí)時(shí)更新延遲問(wèn)題，真正做到實(shí)時(shí) upset。

第二，新增優(yōu)化器、字典、索引支持能力，實(shí)現(xiàn)OLAP引擎性能進(jìn)化。ClickHouse在多表場(chǎng)景中性能存在缺陷，而ByteHouse 通過(guò)自研CBO 和 RBO（基于代價(jià)和基于規(guī)則的優(yōu)化器），支持了多層嵌套的下推、Join 子查詢的下推、Join-Reorder、Bucket Join、Runtime Filter 等優(yōu)化器特性，做到 TPC-DS 的性能可以達(dá)到 99 條sql100%覆蓋，極大提升多表場(chǎng)景下的性能。另外，ByteHouse還支持了全局字典以及更多索引，如 Bitmap index，讓查詢效率更快。

第三， 自動(dòng)化、可視化，實(shí)現(xiàn)OLAP引擎運(yùn)維進(jìn)化。ByteHouse 提供標(biāo)準(zhǔn)化運(yùn)維、集群健康度檢測(cè)、問(wèn)題發(fā)生時(shí)的診斷工具，幫助運(yùn)維人員提高效率。例如，集群健康度的檢測(cè)工具，類似于集群的實(shí)時(shí)巡檢，能夠報(bào)告當(dāng)前集群狀態(tài)、出現(xiàn)了什么問(wèn)題、問(wèn)題如何解決，最大程度把問(wèn)題前置化，降低運(yùn)維風(fēng)險(xiǎn)。從效果上看， 18000 個(gè)節(jié)點(diǎn)只需要不到 10 個(gè)運(yùn)維人員來(lái)支持。

第四， 存算分離，實(shí)現(xiàn)OLAP引擎架構(gòu)進(jìn)化。ByteHouse推出了 MPP 2. 0 即存算分離架構(gòu)。一方面， 存算分離可以更好實(shí)現(xiàn)資源隔離，每一個(gè)計(jì)算任務(wù)都會(huì)提交到不同的計(jì)算資源中，做到用戶之間互不影響，還能靈活擴(kuò)容、縮容存儲(chǔ)計(jì)算資源；另一方面，存算分離能做到真正云原生（Cloud native），ByteHouse 存儲(chǔ)層既支持 HDFS，也支持 S3 對(duì)象或者其他的對(duì)象存儲(chǔ)，實(shí)現(xiàn)云原生部署。

目前，ByteHouse已經(jīng)在行為分析、精準(zhǔn)營(yíng)銷、實(shí)時(shí)監(jiān)控等業(yè)務(wù)場(chǎng)景中落地。以實(shí)時(shí)監(jiān)控為例，很多互聯(lián)網(wǎng)APP有線上運(yùn)營(yíng)活動(dòng)、直播電商等業(yè)務(wù)，數(shù)據(jù)實(shí)時(shí)性格外重要。數(shù)據(jù)從生產(chǎn)到展現(xiàn)在大屏上，延遲往往要控制在分鐘級(jí)甚至秒級(jí)以內(nèi)。而ByteHouse高吞吐性能、查詢性能，使數(shù)據(jù)從輸入端到輸出端的流程達(dá)到秒級(jí)。在數(shù)據(jù)保障層面，ByteHouse 也能精細(xì)到Exactly Once 的語(yǔ)義，保證數(shù)據(jù)不丟失、不重復(fù)，最終達(dá)到數(shù)據(jù)高效存儲(chǔ)、準(zhǔn)確查詢。（作者：吳卓港）