OLAP平臺介紹

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

階段一：數(shù)據(jù)服務(wù)引擎收斂到ClickHouse

我們所有組件OLAP平臺除了平臺工具的建設(shè)，在引擎?zhèn)仁紫茸龅氖虑椋褪前袿LAP引擎進行盡可能地收斂，簡化在引擎維護的成本，從而能夠?qū)①Y源投入到更有價值的方向。因此，我們第一個做的事情，就是把大部分數(shù)據(jù)服務(wù)的引擎統(tǒng)一收斂到ClickHouse上。

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

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

另外，然后在我們選型的時候，ClickHouse在業(yè)界也已經(jīng)被大規(guī)模使用，經(jīng)過業(yè)界實際場景的檢驗，社區(qū)也比較活躍。

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

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

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

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

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

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

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

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

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

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

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

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

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

到現(xiàn)在，B站的ClickHouse集群基本上覆蓋了所有業(yè)務(wù)的交互式數(shù)據(jù)分析場景，每天承載千萬次查詢，萬億條數(shù)據(jù)寫入，P90的查詢都能夠在200ms內(nèi)響應(yīng)。

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

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

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

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

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

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

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

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

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

B站OLAP平臺的引擎選擇

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

總結(jié)

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

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

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

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