OLAP平臺(tái)介紹

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在完成上兩個(gè)階段的工作目標(biāo)后，我們第三個(gè)階段的工作主要是圍繞湖倉一體進(jìn)行進(jìn)一步降本增效展開的：

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

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

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

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

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

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

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

B站OLAP平臺(tái)的引擎選擇

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

總結(jié)

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

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

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

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