ByteHouse 的前世今生

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

廣告投放實時分析

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

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

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

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

ByteHouse 具備哪些特點

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

能支撐更全面的分析場景

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

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

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

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

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

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

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

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

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

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

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

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

穩(wěn)定、高可用

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

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

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

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

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

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

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

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

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

ByteHouse 的未來展望

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

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

審核編輯 ：李倩