ClickHouse在自助行為分析場景的實踐應用

• 一、自助分析場景OLAP技術選型

• 1.1 背景

• 1.2 OLAP選型考量

• 1.3 ClickHouse

• 二、高斯平臺自助分析場景

• 2.1 系統介紹

• 2.2 系統架構

• 2.3 ClickHouse在高斯平臺的業務場景

• 三、ClickHouse的最佳化實踐

• 3.1 記憶體最佳化

• 3.2 效能調優引數

• 3.3 億級資料JOIN

• 四、ClickHouse未來的規劃與展望

• 4.1 ClickHouse應用實踐痛點

• 4.2 未來規劃及展望

• 五、總結

導讀

公司每日產生海量資料，按業務需要進行統計產出各類分析報表，但巨大的資料量加上覆雜的資料模型，以及個性化的分析維度，採用傳統的離線預計算方式難以靈活支援，為此需引入一種滿足實時多維分析場景的計算引擎框架來支撐業務精細化運營場景。本文將分享ClickHouse在自助分析場景中的探索及實踐，文章將從以下4個方面介紹：

• 自助分析場景OLAP技術選型
• 高斯平臺自助分析場景
• ClickHouse的最佳化實踐
• ClickHouse未來的規劃與展望

一、自助分析場景OLAP技術選型

1.1 背景

轉轉平臺主要對業務運營資料（埋點）進行分析，埋點資料包含在售商品的曝光、點選、展現等事件，覆蓋場景資料量很大，且在部分分析場景需要支援精確去重。大資料量加上去重、資料分組等計算使得指標在統計過程中運算量較大。除此之外，在一些資料分析場景中需要計算留存率、漏斗轉化等複雜的資料模型。

雖然在離線數倉的數倉分層和彙總層對通用指標做了預計算處理，但由於這些模型的分析維度通常是不確定的，因此預計算無法滿足產品或者運營提出的個性化報表的需求，需分析師或數倉工程師進行sql開發，使得資料開發鏈路長交付慢，資料價值也隨著時間的推移而減少。

作為分析平臺，既需要保證資料時效性、架構的高可用，也要做到任意維度、任意指標的秒級響應。基於以上情況，需要一個即席查詢的引擎來實現。

1.2 OLAP選型考量

轉轉對OLAP引擎選型考量有三個方面：效能，靈活性，複雜性。

• 效能：

• 資料量級（億級/百億級/千億級等）
• 資料計算反饋時效性（毫秒級/秒級/分鐘級）

• 靈活性：

• 能否支援聚合結果或明細資料的查詢，還是兩者都支援
• 資料鏈路能否支援離線資料和實時資料的攝取
• 是否支援高併發的即席查詢

• 複雜性：

• 架構簡單
• 使用門檻低
• 運維難度低
• 擴充套件性強

根據這三個方面的考量，調研了目前主流的幾類開源OLAP引擎：

OLAP引擎主要分為兩大類：

• 基於預計算的MOLAP引擎的優勢是對整個計算結果做了預計算，查詢比較穩定，可以保證查詢結果亞秒級或者是秒級響應。但由於依賴預計算，查詢的靈活性比較弱，無法統計預計算外的資料，代表是Kylin和Druid。
• 基於MPP架構的ROLAP引擎可以支援實時資料的攝入和實時分析，查詢場景靈活，但查詢穩定性較弱，取決於運算的資料量級和資源配比，基於MPP架構的OLAP一般都是基於記憶體的，代表是Impala和Presto。

Kylin採用的技術是完全預聚合立方體，能提供較好的SQL支援以及join能力，查詢速度基本上都是亞秒級響應。同時，Kylin有良好的web管理介面，可以監控和使用立方體。但當維度較多，交叉深度較深時，底層的資料會爆炸式的膨脹。而且Kylin的查詢靈活性比較弱，這也是MOLAP引擎普遍的弱點。

Druid採用點陣圖索引、字串編碼和預聚合技術，可以對資料進行實時攝入，支援高可用高併發的查詢，但是對OLAP引擎的分析場景支援能力比較弱，join的能力不成熟，無法支援需要做精確去重計算的場景。

Impala支援視窗函式和UDF，查詢效能比較好，但對記憶體的依賴較大，且Impala的後設資料儲存在Hive Metastore裡，需要與Hadoop元件緊密的結合，對實時資料攝入一般要結合Kudu這類儲存引擎做DML操作，多系統架構運維也比較複雜。

Presto可跨資料來源做聯邦查詢，能支援多表的join，但在高併發的場景下效能較弱的。

ClickHouse單機效能很強，基於列式儲存，能利用向量化引擎做到並行化計算，查詢基本上是毫秒級或秒級的反饋，但ClickHouse沒有完整的事務支援，對分散式表的join能力較弱。

Doris運維簡單，擴縮容容易且支援事務，但Doris版本更新迭代較快且成熟度不夠，也沒有像ClickHouse自帶的一些函式如漏斗、留存，不足以支撐轉轉的業務場景。

基於以上考量，最終選擇了ClickHouse作為分析引擎。

1.3 ClickHouse

ClickHouse是面向實時聯機分析處理的基於列式儲存的開源分析引擎，是俄羅斯於2016年開源的，底層開發語言為C++，可以支撐PB資料量級的分析。ClickHouse有以下特性：

• 具有完備的dbms功能，SQL支援較為完善。
• 基於列式儲存和資料壓縮，支援索引。
• 向量化引擎與SIMD提高CPU的利用率，多核多節點並行執行，可基於較大的資料集計算，提供亞秒級的查詢響應。
• 支援資料複製和資料完整性。
• 多樣化的表引擎。ClickHouse支援Kafka、HDFS等外部資料查詢引擎，以及MergeTree系列的引擎、Distribute分散式表引擎。

ClickHouse的查詢場景主要分為四大類：

• 互動式報表查詢：可基於ClickHouse構建使用者行為特徵寬表，對於多維度，多指標的計算能秒級給出計算反饋。
• 使用者畫像系統：在ClickHouse裡面構建使用者特徵寬表，支援使用者細查、人群圈選等。
• AB測試：利用ClickHouse的高效儲存和它提供的一些自帶的函式，如grouparray函式，可以做到秒級給出AB實驗的效果資料。
• 監控系統：透過Flink實時採集業務指標、系統指標資料，寫到ClickHouse，可以結合Grafana做指標顯示。

二、高斯平臺自助分析場景

2.1 系統介紹

轉轉高斯平臺的核心功能主要包含兩個部分：

• 埋點資料管理：埋點後設資料管理，埋點後設資料質量監控和告警；
• 自助分析：基於業務特點和多部門複合需求，提供多維度、多指標的交叉分析能力，可以支援使用者畫像標籤選擇、人群圈選，AB TEST等分析功能，全面支撐日常資料分析需求。

2.2 系統架構

下圖展示了高斯平臺的系統架構，總共分為四層：

資料採集層：資料來源主要是業務庫和埋點資料。業務庫資料儲存在MySQL裡，埋點資料通常是LOG日誌。MySQL業務庫的資料透過Flink-CDC實時抽取到Kafka；LOG日誌由Flume Agent採集並分發到實時和離線兩條通道，實時埋點日誌會sink寫入Kafka，離線的日誌sink到HDFS。

資料儲存層：主要是對資料採集層過來的資料進行儲存，儲存採用的是Kafka和HDFS，ClickHouse基於底層資料清洗和資料接入，實現寬表儲存。

資料服務層：對外統一封裝的HTTP服務，由外部系統呼叫，對內提供了SQL化的客戶端工具。

資料應用層：主要是基於ClickHouse的高斯自助分析平臺和使用者畫像平臺兩大產品。高斯分析平臺可以對於使用者去做事件分析，計算PV、UV等指標以及留存、LTV、漏斗分析、行為分析等，使用者畫像平臺提供了人群的圈選、使用者細查等功能。

2.3 ClickHouse在高斯平臺的業務場景

 1、行為分析

業務背景：App上線活動專題頁，業務方想檢視活動頁面上線後各個坑位的點選的效果。

技術實現：採用ClickHouse的物化檢視、聚合表引擎，以及明細表引擎。ClickHouse的物化檢視可以做實時的資料累加計算，POPULATE關鍵詞決定物化檢視的更新策略。在建立物化檢視時使用POPULATE關鍵詞會對底層錶的歷史資料做物化檢視的計算。

2、AB-TEST分析

業務背景：轉轉早期AB-TEST採用傳統的T+1日資料，但T+1日資料已無法滿足業務需求。

技術方案：Flink實時消費Kafka，自定義Sink（支援配置自定義Flush批次大小、時間）到ClickHouse，利用ClickHouse做實時指標的計算。

三、ClickHouse的最佳化實踐

3.1 記憶體最佳化

在資料分析過程中常見的問題大都是和記憶體相關的。如上圖所示，當記憶體使用量大於了單臺伺服器的記憶體上限，就會丟擲該異常。

針對這個問題，需要對SQL語句和SQL查詢的場景進行分析:

• 如果是在進行count和disticnt計算時記憶體不足，可以使用一些預估函式減少記憶體的使用量來提升查詢速度；
• 如果SQL語句進行了group by或者是order by操作，可以配置max_bytes_before_external_group_by和max_bytes_before_external_sort這兩個引數調整。

3.2 效能調優引數

上圖是實踐的一些最佳化引數，主要是限制併發處理的請求數和限制記憶體相關的引數。

• max_concurrent_queries：限制每秒的併發請求數，預設值100，轉轉調整引數值為150。需根據叢集效能以及節點的數量來調整此引數值。
• max_memory_usage：設定單個查詢單臺機器的最大記憶體使用量，建議設定值為總記憶體的80%，因為需要預留一些記憶體給系統os使用。
• max_memory_usage_for_all_queries：設定單伺服器上查詢的最大記憶體量，建議設定為總記憶體的80%~90%。
• max_memory_usage_for_user & max_bytes_before_external_sort：group by和order by使用超出記憶體的閾值後，預寫磁碟進行group by或order by操作。
• background_pool_size：後臺執行緒池的大小，預設值為16，轉轉調整為32。這個執行緒池大小包含了後臺merge的執行緒數，增大這個引數值是有利於提升merge速度的。

3.3 億級資料JOIN

技術原理：在做使用者畫像資料和行為資料匯入的時候，資料已經按照Join Key預分割槽了，相同的Join Key其實是在同一節點上，因此不需要去做兩個分散式表跨節點的Join，只需要去Join本地表就行，執行過程中會把具體的查詢邏輯改為本地表，Join本地表之後再彙總最後的計算結果，這樣就能得到正確的結果。

四、ClickHouse未來的規劃與展望

4.1 ClickHouse應用實踐痛點

• ClickHouse的高併發能力特別弱，官方的建議的QPS是每秒100左右。高併發查詢時，ClickHouse效能下降比較明顯。
• ClickHouse不支援事務性的DDL和其他的分散式事務，複製表引擎的資料同步的狀態和分片的後設資料管理都強依賴於Zookeeper。
• 部分應用場景需要做到實時的行級資料update和delete操作，ClickHouse缺少完整的操作支援。
• ClickHouse缺少自動的re-balance機制，擴縮容時資料遷移需手動均衡。

4.2 未來規劃及展望

• 服務平臺化，故障規範化。提高業務易用性，提升業務治理，比如：資源的多租戶隔離，異常使用者的限流熔斷，以及對ClickHouse精細化監控報警，包括一些慢查詢監控。

• ClickHouse容器化的部署。支援資料的存算分離，更好的彈性叢集擴縮容，擴縮容後自動資料均衡。

• 服務架構智慧化。針對部分業務場景的高併發查詢，ClickHouse本身的支援高併發能力比較弱，引入Doris引擎。基於特定的業務場景去自適應的選擇ClickHouse或者是Doris引擎。

• ClickHouse核心級的最佳化。包括實時寫入一致性保證、分散式事務支援、移除Zookeeper的服務依賴。目前Zookeeper在ClickHouse資料達到一定量級是存在瓶頸的，所以移除Zookeeper服務依賴是迫切和必然的。

五、總結

本文主要分享了:

• OLAP分析領域技術生態
• 轉轉自助分析平臺的底層架構原理
• ClickHouse在落地實踐過程中的調優方案
• ClickHouse應用痛點及未來規劃和展望

在巨大的資料量面前，想追求極致的效能及全部場景適應性，必須在某些技術方案上進行取捨。ClickHouse從底層列式儲存到上層向量化平行計算，都沒有考慮存算分離、彈性擴充套件的技術方案，甚至於橫向擴容資料需要手動re-balance。因此，如果要實現雲上的可動態伸縮、存算分離，ClickHouse需要重構底層程式碼。

未來轉轉會針對痛點進行持續最佳化，輸出更多的技術實踐給大家。

關於作者

王鵬哲，轉轉資料智慧部高階資料研發工程師，負責公司高斯自助分析平臺及實時資料體系建設。

堅信"不為失敗找藉口，只為成功找方法"。