OLAP平臺介紹

在兩年多以前，嗶哩嗶哩還沒有專門的OLAP平臺，但是業務一直都有這種交互式分析的需求，所以業務各自自建自己的OLAP引擎。當時有在使用的引擎五花八門，包括Apache Kylin、ES、Druid、ClickHouse、Presto等等，缺乏一套統一的接入規范和平臺工具，維護成本非常高，穩定性也比較差。

階段一：數據服務引擎收斂到ClickHouse

我們所有組件OLAP平臺除了平臺工具的建設，在引擎側首先做的事情，就是把OLAP引擎進行盡可能地收斂，簡化在引擎維護的成本，從而能夠將資源投入到更有價值的方向。因此，我們第一個做的事情，就是把大部分數據服務的引擎統一收斂到ClickHouse上。

為什么選型ClickHouse，主要是基于以下的幾個理由：首先ClickHouse的性能非常強大，相信大家只要用過的都會有這個感受，基于它本地文件系統存儲，計算存儲一體設計的優勢，以及它采用native語言實現，性能優先的工程實現思路，向量化執行引擎，到今天可能依然是性能最快的分布式OLAP引擎。當然某些場景ClickHouse支持得不是很好，比如大表關聯等需要大量數據shuffle的場景，因為它主要還是采用的scatter-gather這種分布式執行模型，而不是MPP架構。

同時ClickHouse的能力非常豐富，比如它豐富又靈活的built-in Function，以及各種MergeTree存儲引擎、物化視圖、索引等等，這使得它的能力覆蓋了很多之前業務自建的不同業務特點選型的其它OLAP引擎。

另外，然后在我們選型的時候，ClickHouse在業界也已經被大規模使用，經過業界實際場景的檢驗，社區也比較活躍。

我們基于ClickHouse支持的一些典型的數據服務場景包括：用戶行為分析平臺、標簽圈選平臺，內容分析平臺等等。

我這里主要講我們在用戶行為分析平臺的實踐案例。用戶的行為數據分析可能是每一個互聯網公司內部進行精細數字化運營管理必不可少的一環，用戶行為數據的特點就是量級會非常大，因為可能用戶在你的app上的每個行為都會產生一條數據，一般都是公司最大的幾個數據流之一，在B站的話每天這個流有千億級別的數據。然后我們要對行為數據進行各種各樣的分析，包括像天、城市等各種維度分組的UV/VV統計、留存分析、漏斗分析、行為路徑分析等等。最開始的時候第一版用戶行為分析平臺是使用Spark去執行分析任務的，基本上單次分析都要10分鐘甚至半個小時以上，所以用戶的使用體驗非常差，消耗的資源也非常多，遷移到ClickHouse后，我們當前是使用了64個節點組成的ClickHouse集群，總計大概5PB的數據量，P90的查詢都能夠在4S以內響應，基本上做到了交互式響應的用戶體驗。

在建設的過程中，我們碰到的第一個問題是：數據寫入的問題。因為數據量特別大，而且還有波峰波谷，數據的寫入以及寫入新數據引發的ClickHouse merge小文件的操作會占用大量的磁盤IO，嚴重影響查詢的性能，而如果預留足夠的資源給寫入，由于數據有波峰波谷，會有很大的資源浪費，所有我們實現了一個基于Spark ClickHouse BulkLoad。在Spark Task內使用ClickHouse本地進程進行ClickHouse內部數據文件的生成和合并，然后利用兩階段提交協議，把文件投遞到ClickHouse集群中，并加載文件到表內。通過這種方式，把大部分寫的IO代價從ClickHouse集群移到了Spark任務中，從而保證了查詢的穩定響應。

解決寫入問題后，第二個就是如何保證查詢的效率，這方面是引擎和行為分析服務協同，包括UserID的字典映射成正整形，然后通過物化視圖構建Bitmap，將UV、漏斗、人群分組等業務需求都轉化成高效的bitmap的交并差計算，ClickHouse在這方面提供了非常豐富和強大的相關Function實現，還有像是數據sharding存儲，將全局分布式算子轉化為邏輯上等價的local算子操作。之前我們團隊有發布一篇??《B站基于ClickHouse的海量用戶行為分析應用實踐》???，大家有興趣可以去看看。

階段二：文本檢索遷移到ClickHouse

在第一個階段，我們把數據服務場景的引擎都統一收斂到了ClickHouse，Kylin和Druid集群則全部下線了。第二個階段，我們主要做個事情是把文本檢索的場景也遷移ClickHouse上。

我們把ES承載的業務分成兩類，一類是文本檢索，最典型的業務就是日志平臺，用戶需要根據一些關鍵詞去檢索日志做troubleshooting，或是使用日志數據進行數據分析，它的特點是不需要進行打分排序，只是進行精確的文本檢索。另外一類是搜索排序，比如我們很多C端業務的搜索類需求，這個是需要進行打分排序的。B站之前的日志平臺主要也是采用業界非常流行的ETK技術棧去實現，我們在第二階段把這部分業務遷移到了ClickHouse上。

這樣做的原因有以下幾點，第一是由于日志量非常大，ES有明顯的寫分詞瓶頸，同時數據存儲成本非常高，對于機型的CPU、內存都有比較高的要求。并且，ES的數據分析能力較弱，再入一份數據到大數據平臺代價又很大，在B站需要大幾百臺機器來支持日志平臺，因此，我們主要的驅動力是做降本增效。

將日志平臺從ES遷移到ClickHouse，收益就是寫入性能提升了大概10倍，存儲成本降低至原來的1/3，結構化字段的查詢性能提升了2倍，P90的查詢都能夠在3s內響應，滿足這種交互式troubleshooting的需求。

這里面稍微講一些關鍵的點：首先絕大部分的日志查詢都是在一個時間段范圍檢索某一個app_id的日志數據，可能還有更多的維度篩選條件和檢索關鍵字，我們利用ClickHouse Primary Key和正向索引的能力，把ClickHouse需要掃描的數據限定在一個相對較小的范圍內，同時在message字段是建token bloomfilter索引，這種索引能夠對日志文本進行分詞然后構建bloomfilter索引，是一個非常輕量化的反向索引，通過關鍵詞和tokenbloomfilter索引可以進一步縮小需要掃描的數據量，最后是利用clickhouse強悍的現場計算能力處理數據。

日志的很多場景除了一些公共字段，它的schema是會不斷變化的，最常見的就是新增字段。ES可以很好的支持這種schema free的數據類型，但是對于ClickHouse來說，這個動態字段一般是放到Map數據類型中，這個就會帶來兩個問題：一個是存儲壓縮效率會受到很大影響，第二個是查詢的效率，訪問Map中數據的時候要把整個Map讀出來，而且用戶使用存儲在Map中的字段做過濾的時候，就很難使用正向索引去過濾數據了，這對我們的查詢性能是一個非常大的挑戰。

我們仔細分析了這種場景，發現雖然這些場景數據schema是不斷變化的，它需要日志平臺提供這種能力，但是schema變化的頻率本身不會很高，比如說大部分業務實際上是在發布上線新版本的時候日志schema出現了變化，這個周期是以周甚至月來計算的，在ClickHouse引擎內部，在一個存儲文件內，我們實際上可以認為數據的schema是不太會發生變化的。

基于這個觀察發現，我們設計實現了一種新的Map類型的實現，它的訪問方式是Map，但是實際在ClickHouse內部存儲的時候，是把Map展開存儲按列存儲的，而且支持用戶按照這種隱式類定義索引，所以它實際存儲和查詢的效率和打平按列存儲基本上是一樣的。

到現在，B站的ClickHouse集群基本上覆蓋了所有業務的交互式數據分析場景，每天承載千萬次查詢，萬億條數據寫入，P90的查詢都能夠在200ms內響應。

階段三：湖倉一體降本增效

在完成上兩個階段的工作目標后，我們第三個階段的工作主要是圍繞湖倉一體進行進一步降本增效展開的：

所謂的湖倉一體，我的理解就是基于傳統Hadoop/Spark和基于HDFS的數據湖生態，開放的查詢引擎和統一的數據存儲和元數據管理服務，再加上像Iceberg這樣的表存儲格式以及數倉高級的一些能力，包括比如數據組織優化、索引、預計算、實時數據可見，upsert支持等能力。既保留了湖的靈活性，又能夠接近或者嘗試達到專門分布式OLAP引擎的查詢效率和能力。

在B站，我們是以Iceberg為核心，構建我們的湖倉一體技術棧，Spark和Flink可以接入流或者批的數據寫入Iceberg，我們自研了一個Iceberg的數據管理和優化服務，叫Magnus，所有Iceberg表的寫入事件都會向它匯報，然后根據配置的策略對Iceberg表的數據拉起Spark任務進行異步的數據優化工作，比如合并小文件，優化數據排序方式，生成索引等等。然后通過Trino支持針對Iceberg表的查詢。還引入了Alluxio用于Icebergmetadata、索引等文件的緩存加速。

湖倉一體主要應用在什么場景，它能夠給我們帶來什么收益？我們的理解是它查詢性能和使用場景處在離線數據分析和分布式OLAP引擎的中間位置。相比于離線數據分析，它能夠提供更好的查詢性能，同時Iceberg表能夠提供較粗力度的ACID事務能力，保證數據查詢的正確性，還有它能提供實時的數據可見性，將原來離線表、天表、小時表的可見性提升到分鐘級，對于離線數據分析能夠支持更豐富的場景，同時在報表、數倉分析層建模等場景可以提供更好的查詢體驗和計算效率。

另外一方面，相比于ClickHouse這樣的OLAP引擎，湖倉一體的好處是它可以自然作為離線數倉Hive表分層的一部分，無需數據在HDFS和ClickHouse冗余存儲和數據同步，它的計算和存儲是分離架構，能夠有更好的彈性，一般的公司大數據平臺的工具鏈都比較完備，Iceberg表可以非常小成本接入，因為它本來就可以認為是一個特殊存儲類型的Hive表，所以在歷史數據上只會很低頻的訪問，放在Iceberg中會比ClickHouse成本更低，它也可以作為ClickHouse中數據的一個低成本副本存儲方案，或者直接支持一些性能要求沒有那么高的數據服務。簡單總結來說，湖倉一體相比于離線分析可以提供更好的查詢體驗和更高的查詢效率，相比于ClickHouse，查詢效率比不上，但是資源和用戶使用成本則更低。

為了能夠做到更接近分布式OLAP引擎的查詢效率，我們也基于開源Iceberg進行了較多的增強。在數據組織方面，支持Iceberg表可以定義文件間和文件內的數據排序方式，支持Z-Order這種排序方式。同時在索引層面也進行了增強，支持BloomFilter、BitMap、TokenBloomFilter、TokenBitmap等索引類型，在預計算層面，也支持用戶針對單表和星形模型定義預計算，在查詢時自動優化執行計劃，直接使用預計算結果響應匹配的查詢。以上就是湖倉一體具體的應用場景。

指標服務是我們內部的一個統一指標取數平臺，湖倉一體作為其中一個重要的引擎來支撐指標的取數，服務本身根據用戶對于指標取數的SLA要求使用不同的引擎來存儲和響應查詢。目前在指標平臺上，每天Iceberg表響應大概20萬個查詢，P90在1.2S內響應。關于指標取數服務的詳細介紹，大家也可以去看我們的文章??《B站取數服務演進之路》??。

日志平臺3.0的建設，是我們另外一個場景正在落地的一個項目。因為很多日志的歷史數據要存儲很久，使用ClickHouse雖然比ES成本低了很多，所以我們想要進一步降低歷史日志的成本。因此，我們把日志的歷史數據存儲在Iceberg表上，雖然通過湖倉一體提供不如ClickHouse，但其日志檢索性能業務整體可接受，整體的資源成本也比ClickHouse會有更進一步50%以上的減少。

B站OLAP平臺的引擎選擇

所以總結下來，我們現在的OLAP引擎分為三個：ES、ClickHouse和湖倉一體。在引導業務用戶選型的時候，我們首先按照業務類型，搜索排序使用ES，然后對于文本檢索和數據分析，我們主要根據用戶業務對于性能指標的需求進行劃分，大于秒級以上建議湖倉一體，秒級以下用ClickHouse。

總結

首先，ClickHouse是一款非常優秀、綜合能力非常強大的OLAP引擎，基本可以覆蓋數據分析的各種場景的需求。

第二，在像日志這樣的文本檢索場景，ClickHouse是一個成本更低的選擇，如果你也在做降本增效，這是一個我們驗證過的可行方案。

第三，我認為湖倉一體至少目前無法取代ClickHouse這樣的OLAP引擎，更多的是互補的關系，相比于ClickHouse，在部分場景下是成本更低的加速離線數據分析的方案。

最后，我們當前，像湖倉一體的Trino和ClickHouse還是獨立的計算引擎，其實從技術組件維護的角度，合并為一個研發投入的成本會更低，現在如StarRocks、Doris都有往這個方向演進的趨勢，甚至和ETL的計算引擎比如Spark也可以合二為一，這個也是我們后面比較感興趣和想要研究的一個方向。