導(dǎo)讀

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

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

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

1.1 背景

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

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

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

1.2 OLAP選型考量

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

• 性能：

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

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

• 靈活性：

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

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

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

• 復(fù)雜性：

架構(gòu)簡單

使用門檻低

運(yùn)維難度低

擴(kuò)展性強(qiáng)

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

OLAP引擎主要分為兩大類：

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

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

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

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

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

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

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

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

1.3 ClickHouse

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

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

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

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

二、高斯平臺(tái)自助分析場景

2.1 系統(tǒng)介紹

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

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

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

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

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

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

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

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

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

（1）行為分析

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

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

技術(shù)實(shí)現(xiàn)：采用ClickHouse的物化視圖、聚合表引擎，以及明細(xì)表引擎。ClickHouse的物化視圖可以做實(shí)時(shí)的數(shù)據(jù)累加計(jì)算，POPULATE關(guān)鍵詞決定物化視圖的更新策略。在創(chuàng)建物化視圖時(shí)使用POPULATE關(guān)鍵詞會(huì)對(duì)底層表的歷史數(shù)據(jù)做物化視圖的計(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實(shí)時(shí)消費(fèi)Kafka，自定義Sink（支持配置自定義Flush批次大小、時(shí)間）到ClickHouse，利用ClickHouse做實(shí)時(shí)指標(biāo)的計(jì)算。

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

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

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

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

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

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

上圖是實(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é)點(diǎn)的數(shù)量來調(diào)整此參數(shù)值。
• max_memory_usage：設(shè)置單個(gè)查詢單臺(tái)機(jī)器的最大內(nèi)存使用量，建議設(shè)置值為總內(nèi)存的80%，因?yàn)樾枰A(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：后臺(tái)線程池的大小，默認(rèn)值為16，轉(zhuǎn)轉(zhuǎn)調(diào)整為32。這個(gè)線程池大小包含了后臺(tái)merge的線程數(shù)，增大這個(gè)參數(shù)值是有利于提升merge速度的。

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

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

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

4.1 ClickHouse應(yīng)用實(shí)踐痛點(diǎn)

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

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

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

五、總結(jié)

本文主要分享了:

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

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

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