講師介紹
李呈祥，哔哩哔哩OLAP平台負責人。曾在阿裡雲和英特爾從事開源大資料架構的開發工作，在大資料領域有多年研究經驗，是Apache Hive和Apache Flink項目的Committer，目前在哔哩哔哩基礎架構部門負責OLAP平台的建設。
分享概要
- OLAP平台介紹
- 階段一：資料服務引擎收斂到ClickHouse
- 階段二：文字檢索遷移到ClickHouse
- 階段三：湖倉一體降本增效
- 總結
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也可以合二為一，這個也是我們後面比較感興趣和想要研究的一個方向。
本文根據李呈祥老師在〖2023 中國資料智能管理峰會-上海站〗現場演講内容整理而成。
PPT領取方式：https://pan.baidu.com/s/1cYFXlFeJVh0ObTUNB51Z6w
提取碼：0331
關于我們
dbaplus社群是圍繞Database、BigData、AIOps的企業級專業社群。資深大咖、技術幹貨，每天精品原創文章推送，每周線上技術分享，每月線下技術沙龍，每季度Gdevops&DAMS行業大會。
關注公衆号【dbaplus社群】，擷取更多原創技術文章和精選工具下載下傳