- 一、自助分析場景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需要重構底層代碼。
未來轉轉會針對痛點進行持續優化，輸出更多的技術實踐給大家。