導(dǎo)讀

公司每日產(chǎn)生海量數(shù)據(jù)，按業(yè)務(wù)需要進(jìn)行統(tǒng)計產(chǎn)出各類分析報表，但巨大的數(shù)據(jù)量加上復(fù)雜的數(shù)據(jù)模型，以及個性化的分析維度，采用傳統(tǒng)的離線預(yù)計算方式難以靈活支持，為此需引入一種滿足實時多維分析場景的計算引擎框架來支撐業(yè)務(wù)精細(xì)化運營場景。本文將分享ClickHouse在自助分析場景中的探索及實踐，文章將從以下4個方面介紹：

• 自助分析場景OLAP技術(shù)選型
• 高斯平臺自助分析場景
• ClickHouse的優(yōu)化實踐
• ClickHouse未來的規(guī)劃與展望

一、自助分析場景OLAP技術(shù)選型

1.1 背景

轉(zhuǎn)轉(zhuǎn)平臺主要對業(yè)務(wù)運營數(shù)據(jù)（埋點）進(jìn)行分析，埋點數(shù)據(jù)包含在售商品的曝光、點擊、展現(xiàn)等事件，覆蓋場景數(shù)據(jù)量很大，且在部分分析場景需要支持精確去重。大數(shù)據(jù)量加上去重、數(shù)據(jù)分組等計算使得指標(biāo)在統(tǒng)計過程中運算量較大。除此之外，在一些數(shù)據(jù)分析場景中需要計算留存率、漏斗轉(zhuǎn)化等復(fù)雜的數(shù)據(jù)模型。

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

作為分析平臺，既需要保證數(shù)據(jù)時效性、架構(gòu)的高可用，也要做到任意維度、任意指標(biāo)的秒級響應(yīng)?；谝陨锨闆r，需要一個即席查詢的引擎來實現(xiàn)。

1.2 OLAP選型考量

轉(zhuǎn)轉(zhuǎn)對OLAP引擎選型考量有三個方面：性能，靈活性，復(fù)雜性。

• 性能：

數(shù)據(jù)量級（億級/百億級/千億級等）

數(shù)據(jù)計算反饋時效性（毫秒級/秒級/分鐘級）

• 靈活性：

能否支持聚合結(jié)果或明細(xì)數(shù)據(jù)的查詢，還是兩者都支持

數(shù)據(jù)鏈路能否支持離線數(shù)據(jù)和實時數(shù)據(jù)的攝取

是否支持高并發(fā)的即席查詢

• 復(fù)雜性：

架構(gòu)簡單

使用門檻低

運維難度低

擴(kuò)展性強

根據(jù)這三個方面的考量，調(diào)研了目前主流的幾類開源OLAP引擎：

OLAP引擎主要分為兩大類：

• 基于預(yù)計算的MOLAP引擎的優(yōu)勢是對整個計算結(jié)果做了預(yù)計算，查詢比較穩(wěn)定，可以保證查詢結(jié)果亞秒級或者是秒級響應(yīng)。但由于依賴預(yù)計算，查詢的靈活性比較弱，無法統(tǒng)計預(yù)計算外的數(shù)據(jù)，代表是Kylin和Druid。
• 基于MPP架構(gòu)的ROLAP引擎可以支持實時數(shù)據(jù)的攝入和實時分析，查詢場景靈活，但查詢穩(wěn)定性較弱，取決于運算的數(shù)據(jù)量級和資源配比，基于MPP架構(gòu)的OLAP一般都是基于內(nèi)存的，代表是Impala和Presto。

Kylin采用的技術(shù)是完全預(yù)聚合立方體，能提供較好的SQL支持以及join能力，查詢速度基本上都是亞秒級響應(yīng)。同時，Kylin有良好的web管理界面，可以監(jiān)控和使用立方體。但當(dāng)維度較多，交叉深度較深時，底層的數(shù)據(jù)會爆炸式的膨脹。而且Kylin的查詢靈活性比較弱，這也是MOLAP引擎普遍的弱點。

Druid采用位圖索引、字符串編碼和預(yù)聚合技術(shù)，可以對數(shù)據(jù)進(jìn)行實時攝入，支持高可用高并發(fā)的查詢，但是對OLAP引擎的分析場景支持能力比較弱，join的能力不成熟，無法支持需要做精確去重計算的場景。

Impala支持窗口函數(shù)和UDF，查詢性能比較好，但對內(nèi)存的依賴較大，且Impala的元數(shù)據(jù)存儲在Hive Metastore里，需要與Hadoop組件緊密的結(jié)合，對實時數(shù)據(jù)攝入一般要結(jié)合Kudu這類存儲引擎做DML操作，多系統(tǒng)架構(gòu)運維也比較復(fù)雜。

Presto可跨數(shù)據(jù)源做聯(lián)邦查詢，能支持多表的join，但在高并發(fā)的場景下性能較弱的。

ClickHouse單機(jī)性能很強，基于列式存儲，能利用向量化引擎做到并行化計算，查詢基本上是毫秒級或秒級的反饋，但ClickHouse沒有完整的事務(wù)支持，對分布式表的join能力較弱。

Doris運維簡單，擴(kuò)縮容容易且支持事務(wù)，但Doris版本更新迭代較快且成熟度不夠，也沒有像ClickHouse自帶的一些函數(shù)如漏斗、留存，不足以支撐轉(zhuǎn)轉(zhuǎn)的業(yè)務(wù)場景。

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

1.3 ClickHouse

ClickHouse是面向?qū)崟r聯(lián)機(jī)分析處理的基于列式存儲的開源分析引擎，是俄羅斯于2016年開源的，底層開發(fā)語言為C++，可以支撐PB數(shù)據(jù)量級的分析。ClickHouse有以下特性：

• 具有完備的dbms功能，SQL支持較為完善。
• 基于列式存儲和數(shù)據(jù)壓縮，支持索引。
• 向量化引擎與SIMD提高CPU的利用率，多核多節(jié)點并行執(zhí)行，可基于較大的數(shù)據(jù)集計算，提供亞秒級的查詢響應(yīng)。
• 支持?jǐn)?shù)據(jù)復(fù)制和數(shù)據(jù)完整性。
• 多樣化的表引擎。ClickHouse支持Kafka、HDFS等外部數(shù)據(jù)查詢引擎，以及MergeTree系列的引擎、Distribute分布式表引擎。

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

• 交互式報表查詢：可基于ClickHouse構(gòu)建用戶行為特征寬表，對于多維度，多指標(biāo)的計算能秒級給出計算反饋。
• 用戶畫像系統(tǒng)：在ClickHouse里面構(gòu)建用戶特征寬表，支持用戶細(xì)查、人群圈選等。
• AB測試：利用ClickHouse的高效存儲和它提供的一些自帶的函數(shù)，如grouparray函數(shù)，可以做到秒級給出AB實驗的效果數(shù)據(jù)。
• 監(jiān)控系統(tǒng)：通過Flink實時采集業(yè)務(wù)指標(biāo)、系統(tǒng)指標(biāo)數(shù)據(jù)，寫到ClickHouse，可以結(jié)合Grafana做指標(biāo)顯示。

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

2.1 系統(tǒng)介紹

轉(zhuǎn)轉(zhuǎn)高斯平臺的核心功能主要包含兩個部分：

• 埋點數(shù)據(jù)管理：埋點元數(shù)據(jù)管理，埋點元數(shù)據(jù)質(zhì)量監(jiān)控和告警；
• 自助分析：基于業(yè)務(wù)特點和多部門復(fù)合需求，提供多維度、多指標(biāo)的交叉分析能力，可以支持用戶畫像標(biāo)簽選擇、人群圈選，AB TEST等分析功能，全面支撐日常數(shù)據(jù)分析需求。

2.2 系統(tǒng)架構(gòu)

下圖展示了高斯平臺的系統(tǒng)架構(gòu)，總共分為四層：

?數(shù)據(jù)采集層：數(shù)據(jù)來源主要是業(yè)務(wù)庫和埋點數(shù)據(jù)。業(yè)務(wù)庫數(shù)據(jù)存儲在MySQL里，埋點數(shù)據(jù)通常是LOG日志。MySQL業(yè)務(wù)庫的數(shù)據(jù)通過Flink-CDC實時抽取到Kafka；LOG日志由Flume Agent采集并分發(fā)到實時和離線兩條通道，實時埋點日志會sink寫入Kafka，離線的日志sink到HDFS。

數(shù)據(jù)存儲層：主要是對數(shù)據(jù)采集層過來的數(shù)據(jù)進(jìn)行存儲，存儲采用的是Kafka和HDFS，ClickHouse基于底層數(shù)據(jù)清洗和數(shù)據(jù)接入，實現(xiàn)寬表存儲。

數(shù)據(jù)服務(wù)層：對外統(tǒng)一封裝的HTTP服務(wù)，由外部系統(tǒng)調(diào)用，對內(nèi)提供了SQL化的客戶端工具。

數(shù)據(jù)應(yīng)用層：主要是基于ClickHouse的高斯自助分析平臺和用戶畫像平臺兩大產(chǎn)品。高斯分析平臺可以對于用戶去做事件分析，計算PV、UV等指標(biāo)以及留存、LTV、漏斗分析、行為分析等，用戶畫像平臺提供了人群的圈選、用戶細(xì)查等功能。

2.3 ClickHouse在高斯平臺的業(yè)務(wù)場景

（1）行為分析

業(yè)務(wù)背景：App上線活動專題頁，業(yè)務(wù)方想查看活動頁面上線后各個坑位的點擊的效果。

技術(shù)實現(xiàn)：采用ClickHouse的物化視圖、聚合表引擎，以及明細(xì)表引擎。ClickHouse的物化視圖可以做實時的數(shù)據(jù)累加計算，POPULATE關(guān)鍵詞決定物化視圖的更新策略。在創(chuàng)建物化視圖時使用POPULATE關(guān)鍵詞會對底層表的歷史數(shù)據(jù)做物化視圖的計算。

技術(shù)實現(xiàn)：采用ClickHouse的物化視圖、聚合表引擎，以及明細(xì)表引擎。ClickHouse的物化視圖可以做實時的數(shù)據(jù)累加計算，POPULATE關(guān)鍵詞決定物化視圖的更新策略。在創(chuàng)建物化視圖時使用POPULATE關(guān)鍵詞會對底層表的歷史數(shù)據(jù)做物化視圖的計算。

（2）AB-TEST分析

業(yè)務(wù)背景：轉(zhuǎn)轉(zhuǎn)早期AB-TEST采用傳統(tǒng)的T+1日數(shù)據(jù)，但T+1日數(shù)據(jù)已無法滿足業(yè)務(wù)需求。

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

三、ClickHouse的優(yōu)化實踐

3.1 內(nèi)存優(yōu)化

在數(shù)據(jù)分析過程中常見的問題大都是和內(nèi)存相關(guān)的。如上圖所示，當(dāng)內(nèi)存使用量大于了單臺服務(wù)器的內(nèi)存上限，就會拋出該異常。

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

• 如果是在進(jìn)行count和disticnt計算時內(nèi)存不足，可以使用一些預(yù)估函數(shù)減少內(nèi)存的使用量來提升查詢速度；
• 如果SQL語句進(jìn)行了group by或者是order by操作，可以配置max_bytes_before_external_group_by和max_bytes_before_external_sort這兩個參數(shù)調(diào)整。

3.2 性能調(diào)優(yōu)參數(shù)

上圖是實踐的一些優(yōu)化參數(shù)，主要是限制并發(fā)處理的請求數(shù)和限制內(nèi)存相關(guān)的參數(shù)。

• max_concurrent_queries：限制每秒的并發(fā)請求數(shù)，默認(rèn)值100，轉(zhuǎn)轉(zhuǎn)調(diào)整參數(shù)值為150。需根據(jù)集群性能以及節(jié)點的數(shù)量來調(diào)整此參數(shù)值。
• max_memory_usage：設(shè)置單個查詢單臺機(jī)器的最大內(nèi)存使用量，建議設(shè)置值為總內(nèi)存的80%，因為需要預(yù)留一些內(nèi)存給系統(tǒng)os使用。
• max_memory_usage_for_all_queries：設(shè)置單服務(wù)器上查詢的最大內(nèi)存量，建議設(shè)置為總內(nèi)存的80%~90%。
• max_memory_usage_for_user & max_bytes_before_external_sort：group by和order by使用超出內(nèi)存的閾值后，預(yù)寫磁盤進(jìn)行g(shù)roup by或order by操作。
• background_pool_size：后臺線程池的大小，默認(rèn)值為16，轉(zhuǎn)轉(zhuǎn)調(diào)整為32。這個線程池大小包含了后臺merge的線程數(shù)，增大這個參數(shù)值是有利于提升merge速度的。

3.3 億級數(shù)據(jù)JOIN

技術(shù)原理：在做用戶畫像數(shù)據(jù)和行為數(shù)據(jù)導(dǎo)入的時候，數(shù)據(jù)已經(jīng)按照J(rèn)oin Key預(yù)分區(qū)了，相同的Join Key其實是在同一節(jié)點上，因此不需要去做兩個分布式表跨節(jié)點的Join，只需要去Join本地表就行，執(zhí)行過程中會把具體的查詢邏輯改為本地表，Join本地表之后再匯總最后的計算結(jié)果，這樣就能得到正確的結(jié)果。

四、ClickHouse未來的規(guī)劃與展望

4.1 ClickHouse應(yīng)用實踐痛點

• ClickHouse的高并發(fā)能力特別弱，官方的建議的QPS是每秒100左右。高并發(fā)查詢時，ClickHouse性能下降比較明顯。
• ClickHouse不支持事務(wù)性的DDL和其他的分布式事務(wù)，復(fù)制表引擎的數(shù)據(jù)同步的狀態(tài)和分片的元數(shù)據(jù)管理都強依賴于Zookeeper。
• 部分應(yīng)用場景需要做到實時的行級數(shù)據(jù)update和delete操作，ClickHouse缺少完整的操作支持。
• ClickHouse缺少自動的re-balance機(jī)制，擴(kuò)縮容時數(shù)據(jù)遷移需手動均衡。

4.2 未來規(guī)劃及展望

• 服務(wù)平臺化，故障規(guī)范化。提高業(yè)務(wù)易用性，提升業(yè)務(wù)治理，比如：資源的多租戶隔離，異常用戶的限流熔斷，以及對ClickHouse精細(xì)化監(jiān)控報警，包括一些慢查詢監(jiān)控。
• ClickHouse容器化的部署。支持?jǐn)?shù)據(jù)的存算分離，更好的彈性集群擴(kuò)縮容，擴(kuò)縮容后自動數(shù)據(jù)均衡。
• 服務(wù)架構(gòu)智能化。針對部分業(yè)務(wù)場景的高并發(fā)查詢，ClickHouse本身的支持高并發(fā)能力比較弱，引入Doris引擎?；谔囟ǖ臉I(yè)務(wù)場景去自適應(yīng)的選擇ClickHouse或者是Doris引擎。
• ClickHouse內(nèi)核級的優(yōu)化。包括實時寫入一致性保證、分布式事務(wù)支持、移除Zookeeper的服務(wù)依賴。目前Zookeeper在ClickHouse數(shù)據(jù)達(dá)到一定量級是存在瓶頸的，所以移除Zookeeper服務(wù)依賴是迫切和必然的。

五、總結(jié)

本文主要分享了:

• OLAP分析領(lǐng)域技術(shù)生態(tài)
• 轉(zhuǎn)轉(zhuǎn)自助分析平臺的底層架構(gòu)原理
• ClickHouse在落地實踐過程中的調(diào)優(yōu)方案
• ClickHouse應(yīng)用痛點及未來規(guī)劃和展望

在巨大的數(shù)據(jù)量面前，想追求極致的性能及全部場景適應(yīng)性，必須在某些技術(shù)方案上進(jìn)行取舍。ClickHouse從底層列式存儲到上層向量化并行計算，都沒有考慮存算分離、彈性擴(kuò)展的技術(shù)方案，甚至于橫向擴(kuò)容數(shù)據(jù)需要手動re-balance。因此，如果要實現(xiàn)云上的可動態(tài)伸縮、存算分離，ClickHouse需要重構(gòu)底層代碼。

未來轉(zhuǎn)轉(zhuǎn)會針對痛點進(jìn)行持續(xù)優(yōu)化，輸出更多的技術(shù)實踐給大家。