ByteHouse 的前世今生

字節(jié)跳動(dòng)最早是在 2017 年底開始使用 ClickHouse 的，用于支撐增長(zhǎng)分析的業(yè)務(wù)場(chǎng)景。對(duì)于字節(jié)跳動(dòng)而言，增長(zhǎng)分析的重要性不言而喻。這是一項(xiàng)十分考驗(yàn)運(yùn)營(yíng)團(tuán)隊(duì)能力的工作，如何衡量不同運(yùn)營(yíng)方法的有效性，應(yīng)該對(duì)哪些數(shù)據(jù)指標(biāo)進(jìn)行考量，如何對(duì)指標(biāo)的波動(dòng)進(jìn)行更深層次的原因分析，這些需要重點(diǎn)關(guān)注。這其中涉及大量數(shù)據(jù)分析，對(duì)于數(shù)據(jù)分析平臺(tái)的實(shí)時(shí)性也有著非常高的要求。在比對(duì)、試用過多款 OLAP 分析產(chǎn)品后，字節(jié)跳動(dòng)最終選擇了 ClickHouse，并且整體方案的可行性在實(shí)際業(yè)務(wù)應(yīng)用中得到了很好的驗(yàn)證。

在取得了不錯(cuò)的業(yè)務(wù)效果之后，采用 ClickHouse 的方案快速推廣，從支持增長(zhǎng)分析的單一場(chǎng)景，很快擴(kuò)展到 BI 分析、AB 測(cè)試、模型預(yù)估等多個(gè)場(chǎng)景。同時(shí)，研發(fā)團(tuán)隊(duì)也持續(xù)不斷打磨和改進(jìn) ClickHouse 能力，比如增強(qiáng)數(shù)據(jù)接入功能、提升 SQL-based 指標(biāo)計(jì)算的執(zhí)行效率，包括 UDF 增強(qiáng)、SQL 語法增強(qiáng)等，很快使 ClickHouse 成為字節(jié)內(nèi)部最主流的分析平臺(tái)。

在產(chǎn)品的不斷打磨中，2020 年字節(jié)跳動(dòng)火山引擎正式立項(xiàng)，把基于 ClickHouse 做了很多增強(qiáng)和自研的 ByteHouse 作為 ToB 的核心產(chǎn)品之一加快產(chǎn)品化步伐，以期讓更多的用戶在分析領(lǐng)域獲得更快、更好的業(yè)務(wù)體驗(yàn)。在 2021 年 8 月份，ByteHouse 正式對(duì)外發(fā)布并提供服務(wù)。

至 2022 年 6 月底，字節(jié)跳動(dòng)內(nèi)部的 ByteHouse 節(jié)點(diǎn)總數(shù)已經(jīng)超過18000個(gè)，管理總數(shù)據(jù)量超過 700PB，每天上億次的分析查詢跑在ByteHouse上，有離線的、有實(shí)時(shí)的。其中支撐抖音、頭條的行為分析平臺(tái)其集群規(guī)模已經(jīng)達(dá)到2400個(gè)節(jié)點(diǎn)。截止當(dāng)前，字節(jié)內(nèi)部 80% 的分析型應(yīng)用都跑在ByteHouse平臺(tái)上。

字節(jié)跳動(dòng)最初為什么選擇 ClickHouse

字節(jié)跳動(dòng)曾做過各類分析型產(chǎn)品做過調(diào)研，如 Kylin、Druid、SparkSQL 等。那究竟為什么最后字節(jié)跳動(dòng)選擇了 ClickHouse，并進(jìn)一步投入力量研發(fā)出 ByteHouse 使之成為字節(jié)跳動(dòng)內(nèi)部核心的數(shù)據(jù)分析平臺(tái)呢？這里以兩個(gè)具體的字節(jié)跳動(dòng)業(yè)務(wù)案例來展開一些細(xì)節(jié)：

推薦系統(tǒng)實(shí)時(shí)指標(biāo)

公司內(nèi)部 A/B 實(shí)驗(yàn)平臺(tái)已經(jīng)提供了 T+1 的離線實(shí)驗(yàn)指標(biāo)，而推薦系統(tǒng)需要更快地觀察算法模型、或者某個(gè)功能的上線效果，因此需要一份能夠?qū)崟r(shí)反饋的數(shù)據(jù)作為補(bǔ)充，而且還要求：

? 能同時(shí)查詢聚合指標(biāo)和明細(xì)數(shù)據(jù)；

? 能支持多達(dá)幾百列的維度和指標(biāo)，且場(chǎng)景靈活變化，會(huì)不斷增加；

? 可以高效地按 ID 過濾數(shù)據(jù)；

? 需要支持一些機(jī)器學(xué)習(xí)和統(tǒng)計(jì)相關(guān)的指標(biāo)計(jì)算（比如 AUC）。

選型開始時(shí)，最需要解決的是“快”，所以選擇了 Kylin 作為主要分析引擎，其優(yōu)點(diǎn)是能夠提供毫秒級(jí)別的查詢延時(shí)。但是 Kylin 存在維度爆炸導(dǎo)致預(yù)計(jì)算時(shí)間越來越長(zhǎng)，數(shù)據(jù)可用時(shí)間沒有保證的問題。此外，新業(yè)務(wù)上線會(huì)產(chǎn)生新的指標(biāo)和維度，Kylin 無法支持維度和指標(biāo)在線更新。

后期改用 SparkSQL ，同樣存在不少問題，如查詢分析的延遲太長(zhǎng)、資源使用率高、穩(wěn)定性不夠好頻發(fā)OOM，以及無法支持跨更長(zhǎng)時(shí)間周期的數(shù)據(jù)做分析等。

綜合考量，最后選擇了 ClickHouse：

? 能更快地觀察算法模型，沒有預(yù)計(jì)算所導(dǎo)致的高數(shù)據(jù)時(shí)延；

? 既適合聚合查詢，在配合跳數(shù)索引后，也能充分支持明細(xì)查詢；

? BitSet 的過濾 Bloom Filter 是比較好的解決方案。

同時(shí)，團(tuán)隊(duì)也持續(xù)投入研發(fā)力量，不斷自研增強(qiáng)產(chǎn)品能力，比如通過異步構(gòu)建索引使得整體寫入吞吐量能力提升 20%。通過對(duì) Kafka 多消費(fèi)線程的改造和增強(qiáng)，實(shí)現(xiàn)并行消費(fèi)，使得寫入性能得到線性提升。此外，自研 HaKafka 引擎，提升了系統(tǒng)的 HA 高可用能力，即使出現(xiàn)節(jié)點(diǎn)故障也不用擔(dān)心數(shù)據(jù)有完整性問題。

廣告投放實(shí)時(shí)分析

通常運(yùn)營(yíng)人員需要查看廣告投放的實(shí)時(shí)效果，由于業(yè)務(wù)的特點(diǎn)，當(dāng)天產(chǎn)生的數(shù)據(jù)往往會(huì)涉及到對(duì)歷史數(shù)據(jù)的刷新，技術(shù)上最初是基于 Druid 實(shí)現(xiàn)，但有些問題一直難以解決。例如，實(shí)時(shí)數(shù)據(jù)會(huì)涉及到歷史3個(gè)月的時(shí)間分區(qū)，Druid 會(huì)產(chǎn)生很多 segment，歷史數(shù)據(jù)重刷后需要額外時(shí)間去做合并的操作，無法保證數(shù)據(jù)的實(shí)時(shí)消費(fèi)；另外，業(yè)務(wù)數(shù)據(jù)的維度非常多，數(shù)據(jù)粒度非常細(xì)，所以 Druid 的預(yù)聚合的意義不大，業(yè)務(wù)更多的需求是直接來消費(fèi)明細(xì)數(shù)據(jù)。

最后團(tuán)隊(duì)也選擇了 ClickHouse 技術(shù)路線，并持續(xù)做了改進(jìn)和增強(qiáng)，如：

? 對(duì) Buffer Engine 做了改進(jìn)，解決了社區(qū)版本在 Buffer Engine 和 ReplicatedMergeTree 同時(shí)使用下查詢一致性的問題。

? 自研事務(wù)機(jī)制，確保每次插入數(shù)據(jù)的原子性，增強(qiáng)數(shù)據(jù)消費(fèi)的穩(wěn)定性，解決了社區(qū)版本由于缺少事務(wù)支持，在異常場(chǎng)景下，往往會(huì)出現(xiàn)丟失或者重復(fù)消費(fèi)的情況。具體實(shí)現(xiàn)上是將 Offset 和 Parts 數(shù)據(jù)綁定在一起，每次消費(fèi)時(shí)，會(huì)默認(rèn)創(chuàng)建一個(gè)事務(wù)，由事務(wù)負(fù)責(zé)把 Part 數(shù)據(jù)和 Offset 一同寫入磁盤中，如果出現(xiàn)失敗，事務(wù)會(huì)一起回滾 Offset 和寫入的 Part 然后重新消費(fèi)。

ByteHouse 具備哪些特點(diǎn)

隨著 ByteHouse 在字節(jié)跳動(dòng)內(nèi)部支撐的分析業(yè)務(wù)越來越多，ByteHouse 也成為了字節(jié)跳動(dòng)內(nèi)部分析平臺(tái)構(gòu)建的事實(shí)標(biāo)準(zhǔn)。ByteHouse 在字節(jié)廣泛的應(yīng)用中，不斷從業(yè)務(wù)角度出發(fā)不斷打磨產(chǎn)品，并從實(shí)際應(yīng)用角度思考什么樣的數(shù)據(jù)分析產(chǎn)品才是更好用的。我們認(rèn)為，一個(gè)優(yōu)秀的數(shù)據(jù)分析產(chǎn)品應(yīng)該具備以下特點(diǎn)：

能支撐更全面的分析場(chǎng)景

數(shù)據(jù)庫行業(yè)流傳著“沒有銀彈”的說法，大家認(rèn)為沒有一個(gè)分析類產(chǎn)品能夠滿足所有場(chǎng)景。這固然是很有道理的，但是也不必走向另外一個(gè)極端，所有場(chǎng)景都要“一事一庫”。如果有一個(gè)通用性的數(shù)據(jù)分析產(chǎn)品，能夠支撐 80% 以上的常見場(chǎng)景，這能為企業(yè)減少大量的時(shí)間和精力，并且能更有信心的應(yīng)對(duì)營(yíng)業(yè)務(wù)帶來的數(shù)據(jù)分析挑戰(zhàn)。

ClickHouse 的一個(gè)問題就是適用的場(chǎng)景相對(duì)較窄，對(duì)于寬表模型的查詢和分析效率非常高，但涉及到多表關(guān)聯(lián)的分析場(chǎng)景卻表現(xiàn)不佳，甚至不支持此類業(yè)務(wù)場(chǎng)景。因而，ClickHouse的這種高性能的表現(xiàn)更多的是基于“本能”層面。ByteHouse 團(tuán)隊(duì)以打造一款綜合且性能強(qiáng)大的分析平臺(tái)為目標(biāo)，對(duì)ClickHouse 做了全方位的增強(qiáng)，推出了全自研的查詢優(yōu)化器，從而讓性能表現(xiàn)從“本能”層面躍遷到“智能”層面，從而更好的應(yīng)對(duì)各類分析場(chǎng)景。

對(duì)于一款關(guān)系型數(shù)據(jù)庫產(chǎn)品來說，優(yōu)化器就是大腦，通過優(yōu)化器對(duì)查詢語句進(jìn)行改寫優(yōu)化，基于代價(jià)尋找最優(yōu)執(zhí)行路徑、生成執(zhí)行計(jì)劃，并且結(jié)合資源動(dòng)態(tài)負(fù)載情況，讓整體性能的輸出更加穩(wěn)健、也更加智能。從效果來看，在部分場(chǎng)景下，優(yōu)化器使得性能提升達(dá) 10 倍以上；此外，在 TPC-DS 標(biāo)準(zhǔn)測(cè)試測(cè)試場(chǎng)景中，啟用優(yōu)化器的收益也十分顯著，能夠完成全部 99 個(gè)測(cè)試場(chǎng)景，而且性能也提升數(shù)倍不等。

而應(yīng)對(duì)傳統(tǒng)數(shù)倉負(fù)載中的復(fù)雜查詢場(chǎng)景，僅僅有查詢優(yōu)化器的增強(qiáng)還不夠，ByteHouse 為此還做了大量的工作。如 Runtime Filter，能夠智能過濾掉分析中不相干數(shù)據(jù)，減少中間過程數(shù)據(jù)的網(wǎng)絡(luò)傳輸，提升整體分析效率，在星型和雪花型業(yè)務(wù)分析場(chǎng)景中有很好的效果。另外通過優(yōu)化網(wǎng)絡(luò)技術(shù)，比如連接復(fù)用、RDMA、傳輸壓縮等技術(shù)，也極大提升了整體分析性能。此外還包括其他一系列的能力增強(qiáng)，比如細(xì)粒度資源管控、數(shù)據(jù)交換的優(yōu)化等，能夠讓 ByteHouse 在復(fù)雜分析場(chǎng)景中游刃有余。

從收益效果上看，在字節(jié)內(nèi)部部分業(yè)務(wù)場(chǎng)景中，多表關(guān)聯(lián)分析性能提升 26 倍，單表復(fù)雜查詢也提升 3 倍左右，在標(biāo)準(zhǔn)SSB測(cè)試場(chǎng)景中也表現(xiàn)不俗，為支撐更全面的分析場(chǎng)景的目標(biāo)邁出重要一步。

數(shù)據(jù)分析能力能隨業(yè)務(wù)快速擴(kuò)縮，極致彈性

在 node-base 架構(gòu)下，存算一體的模式不夠靈活，難以滿足業(yè)務(wù)對(duì)彈性的需求，擴(kuò)容的代價(jià)無論是時(shí)間成本和資源成本都很高。應(yīng)對(duì)這些挑戰(zhàn)，ByteHouse 團(tuán)隊(duì)花費(fèi)極大精力從底層開始秉承 Cloud-Native 云原生的架構(gòu)理念進(jìn)行整體重構(gòu)，讓資源可以伴隨業(yè)務(wù)的需求進(jìn)行靈活的彈性伸縮，擴(kuò)容的代價(jià)更低更可控。另外，業(yè)務(wù)上可以通過讀寫分離做更好的資源管控和分流，從而讓整體業(yè)務(wù)的 SLA 更有保障。下面介紹部分 ByteHouse 架構(gòu)重構(gòu)中的關(guān)鍵技術(shù)點(diǎn)。

首先是基于分布式 KV 構(gòu)建元數(shù)據(jù)管理服務(wù)，元數(shù)據(jù)信息會(huì)持久化保存在狀態(tài)存儲(chǔ)池里面，為了降低對(duì)元數(shù)據(jù)庫的訪問壓力，對(duì)于訪問頻度高的元數(shù)據(jù)會(huì)進(jìn)行緩存。元數(shù)據(jù)服務(wù)自身是無狀態(tài)的，可以水平擴(kuò)展。

在高性能層面，除了前面介紹的全自研優(yōu)化器之外，還通過智能的分布式多級(jí)緩存技術(shù)來彌補(bǔ)存算分離架構(gòu)下遠(yuǎn)程數(shù)據(jù)訪問時(shí)額外的網(wǎng)絡(luò)開銷和IO開銷帶來的性能損失。此外 virtule warehouse 計(jì)算資源實(shí)現(xiàn)了容器化部署，做到了無狀態(tài)化，從而可以快速、靈活的進(jìn)行彈性伸縮，且不影響業(yè)務(wù)。

在存儲(chǔ)層面，實(shí)現(xiàn)了存儲(chǔ)服務(wù)化，對(duì)數(shù)據(jù)存儲(chǔ)層進(jìn)行統(tǒng)一抽象，構(gòu)造 VFS 虛擬存儲(chǔ)系統(tǒng)，能夠支持更多的存儲(chǔ)語義，包括 HDFS 塊存儲(chǔ)、對(duì)象存儲(chǔ)等，既解決了存儲(chǔ)在擴(kuò)展性、讀寫吞吐瓶頸、一致性等問題，同時(shí)能大幅降低存儲(chǔ)成本。

強(qiáng)一致性的事務(wù)機(jī)制、MVCC 多版本并發(fā)控制、細(xì)粒度鎖等技術(shù)保障，也能讓 ByteHouse 更好地去滿足核心分析業(yè)務(wù)對(duì)一致性和并發(fā)能力的要求。

此外，在負(fù)載管理上，圍繞計(jì)算、內(nèi)存、網(wǎng)絡(luò)帶寬這三項(xiàng)核心資源進(jìn)行持續(xù)優(yōu)化，同時(shí)也在不斷引入AI等新技術(shù)讓系統(tǒng)資源的動(dòng)態(tài)調(diào)配更加智能和高效；細(xì)粒度、多級(jí)的資源隔離能力也能更好的匹配業(yè)務(wù)差異化的需求，讓整體系統(tǒng)運(yùn)行更加穩(wěn)定可靠。

穩(wěn)定、高可用

以抖音集團(tuán)內(nèi)部建于2017年的行為分析平臺(tái)為例，僅頭條和抖音兩款應(yīng)用每天會(huì)產(chǎn)生萬億條級(jí)別的事件記錄，且至少保存1年，分析的特征維度多達(dá)上千，既有聚合查詢也有明細(xì)查詢，其自助式查詢分析要求必須達(dá)到秒級(jí)響應(yīng)。當(dāng)前這個(gè)平臺(tái)運(yùn)行在 2400 個(gè)節(jié)點(diǎn)的 ByteHouse 集群上。

對(duì)社區(qū)版 ClickHouse 或者其他大部分分析類產(chǎn)品來說，要達(dá)到這個(gè)規(guī)模是非常困難的，幾乎難以實(shí)現(xiàn)。ByteHouse 做了哪些能力增強(qiáng)來不斷突破規(guī)模上限、持續(xù)支持業(yè)務(wù)高速增長(zhǎng)呢？這里我們先重點(diǎn)介紹兩方面的能力增強(qiáng)：

一、通過自研的 HaMergeTree 替代社區(qū)的 ReplicatedMergeTree，降低對(duì) ZooKeeper 的請(qǐng)求次數(shù)，減少在 Zookeeper 上存儲(chǔ)的數(shù)據(jù)量，副本直接通過 log 日志來交換信息，不需要再?gòu)?Zookeeper 獲取，從而極大減輕 Zookeeper 的負(fù)載，讓其壓力與集群內(nèi)數(shù)據(jù)量規(guī)模脫鉤。

二、通過元數(shù)據(jù)持久化的方案，提升故障恢復(fù)能力。社區(qū)版本的元數(shù)據(jù)常駐于內(nèi)存中，這會(huì)導(dǎo)致重啟時(shí)間非常長(zhǎng)，因而當(dāng)故障發(fā)生后，恢復(fù)的時(shí)間也很長(zhǎng)，動(dòng)輒一到兩個(gè)小時(shí)，這個(gè)是業(yè)務(wù)不能接受的。ByteHouse 的做法是將元數(shù)據(jù)持久化到 RocksDB，啟動(dòng)時(shí)直接從 RocksDB 加載元數(shù)據(jù)，內(nèi)存中也僅僅存放必要的 Part 信息，這樣就減少元數(shù)據(jù)對(duì)內(nèi)存的占用，在性能基本無損失的情況下，單機(jī)支持的part 不再受內(nèi)存容量的限制，可以達(dá)到 100 萬以上；最重要的是極大縮短了集群的故障恢復(fù)時(shí)間，從1-2 小時(shí)直接縮短到 3 分鐘，大大提高了系統(tǒng)的高可用能力，為業(yè)務(wù)提供了堅(jiān)實(shí)保障。

保證查詢效率前提下，更快、更準(zhǔn)確的數(shù)據(jù)導(dǎo)入

在實(shí)時(shí)寫入場(chǎng)景中，社區(qū)版 ClickHouse 還是存在部分能力的缺失，比如數(shù)據(jù)分布按 shard 的分布策略很難保障均勻分布，會(huì)存在數(shù)據(jù)傾斜的情況，而且不支持由用戶指定唯一鍵的業(yè)務(wù)需求，也無法保證數(shù)據(jù)的有序消費(fèi)， 單線程的消費(fèi)模式導(dǎo)致吞吐量受限，另外在 HA 高可用上也存在能力缺失。ByteHouse 針對(duì)這些不足對(duì) kafka engion 做了全面的增強(qiáng)。

首先是在分布式架構(gòu)下，通過自研的 HaKafka 引擎為數(shù)據(jù)的實(shí)時(shí)注入提供了 HA 高可用保障，保障數(shù)據(jù)不丟失；支持唯一鍵；通過 memory table，提升了實(shí)時(shí)寫入的吞吐能力，同時(shí)延遲刷盤也大幅降低IOPS，節(jié)省 IO 資源。

在此基礎(chǔ)上 ByteHouse 再向前一步，演進(jìn)到云原生架構(gòu)，能力得到更大的提升，包括支持 exactly-once 消費(fèi)語義，自動(dòng)容錯(cuò)，之前 node-base 架構(gòu)模式的擴(kuò)容難、代價(jià)高的問題也在云原生架構(gòu)下迎刃而解，能夠做到按需的靈活彈性擴(kuò)容和縮容。

此外，ByteHouse 自研了 UniqueMergeTree 表引擎，很好的平衡了寫和讀的性能。UniqueMergeTree 表引擎既支持行更新的模式，也支持部分列更新的模式，用戶可以根據(jù)業(yè)務(wù)要求開啟或關(guān)閉。在性能方面，與 ReplacingMergeTree 相比，UniqueMergeTree 的寫入性能只有輕微下降，但在查詢性能上取得了數(shù)量級(jí)的提升。進(jìn)一步對(duì)比了 UniqueMergeTree 和普通 MergeTree 的查詢性能，發(fā)現(xiàn)兩者是非常接近的。

ByteHouse 的未來展望

我們將持續(xù)圍繞讓 ByteHouse 更快、更穩(wěn)、更智能持續(xù)做技術(shù)迭代，包括更強(qiáng)的優(yōu)化器，當(dāng)前在原型測(cè)試中有 3 倍的性能提升；通過AI技術(shù)的引入讓系統(tǒng)更智能更高效，在原型測(cè)試中，基于 IMDB 的大規(guī)模數(shù)據(jù)集的性能表現(xiàn)上有20%的提升；此外更加智能的物化視圖技術(shù)以及 RDMA 技術(shù)預(yù)期都會(huì)在 23 年實(shí)現(xiàn)產(chǎn)品化落地。

面向未來，ByteHouse 的愿景是打造數(shù)據(jù)分析領(lǐng)域的“抖音”平臺(tái)，能夠?yàn)橛脩魩硪惑w化的集成、分析體驗(yàn)，降低用戶分析門檻，一站式提供分析所需的各種能力，并能通過安全可信的數(shù)據(jù)分享、模型分享幫助用戶便捷地實(shí)現(xiàn)交易和價(jià)值變現(xiàn)。

審核編輯 ：李倩