關(guān)于ByteHouse你想知道的一切分享

ByteHouse 的前世今生

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

廣告投放實時分析

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

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

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

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

ByteHouse 具備哪些特點

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

能支撐更全面的分析場景

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

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

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

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

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

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

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

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

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

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

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

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

穩(wěn)定、高可用

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

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

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

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

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

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

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

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

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

ByteHouse 的未來展望

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

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

審核編輯 ：李倩