引言

極光開發者服務為移動app開發者提供各種豐富可靠高效的開發者產品服務，面對不同產品服務的業務數據分析統計訴求，如何在千億級的海量數據中實現多維分析和ad-hoc即席查詢，為開發者提供高效、精準的數據分析查詢服務成為極光面臨的問題。

極光大數據服務團隊通過對ClickHouse的深入探索實踐表明，ClickHouse比較完美解決了查詢瓶頸，單表十億級別數據量級查詢，95%可以在毫秒級別（ms）完成計算返回結果。

極光開發者服務數據分析需求

極光開發者服務包括推送、統計、認證、魔鏈、IM、短信等產品服務，隨著業務發展，每天有上百萬個app使用，為14億級月活終端用戶提供各類移動應用服務，每天產生千億級記錄，而且每個產品服務依據自身業務特點，對數據分析有不同要求，涵蓋基礎用戶統計分析、推送統計分析、認證消耗分析、頁面流分析、留存分析、終端分析、事件分析、用戶行為路徑分析、用戶畫像分析等業務分析模塊，涉及的數據指標多達500+，這對數據分析和BI指標統計提出了挑戰。極光服務中典型的數據分析需求有如下幾類：

極光推送產品的「消息實時統計」，開發者希望以小時為維度實時查看消息下發、送達和點擊等數據，以判斷消息下發進度。

極光推送產品的「消息轉化漏斗」，開發者希望從APP應用維度和單條消息維度，分別查看推送消息的轉化數據，同時希望可以支持平臺、通道和消息類型等維度篩選。

極光推送產品的「消息折損分析」，開發者希望從APP應用維度和單條消息維度，分別查看消息折損的原因和類別，能夠查看在不同消息發送階段的折損數量。

極光運營增長產品的「精準人群計算與人群預測」，運營人員自定義條件規則圈選目標人群，人群需要例行計算出人群包用與運營觸達服務。同時還希望使用極光AI服務預測潛在沉默人群、潛在高價值人群用于提前干預運營。

極光運營增長產品的「運營計劃實時監控」，運營人員希望創建完成運營計劃后，可以實時查看運營計劃的用戶消息觸達、用戶目標達成率等數據，以便于隨時優化和干預運營計劃，確保運營目標的達成。

極光運營增長產品的「營銷分與智能標簽」，運營人員基于可視化規則創建的營銷分和智能標簽，需要例行計算以便更新用戶數據，用于支撐營銷運營策略。

?

技術選型和演進

極光開發者服務數據分析的技術選型和演進主要分為3個階段，第一階段業務早期數據量較少，直接在Mysql數據庫中存儲就可以滿足分析查詢需求；第二階段隨著業務發展，數據規模越來越大，要借助Hbase、Kylin的一些nosql組件，對數據建模，實現多維度預計算；第三階段數據持續增加和維度爆炸，預計算成本和可維護性越來越差，這時就需要一種支持海量數據存儲、查詢靈活、高效且運維成本較低的OLAP數據庫。

經過對主流OLAP組件對比調研發現，ClickHouse有三個特征滿足極光開發者服務數據分析使用要求：

01、支持列式存儲和數據壓縮

為了實現支持單表百億數據集中查詢分析時，能夠靈活選擇各種維度組合并且秒級返回執行結果，ClickHouse按列存儲的特性便可以極大提升數據查詢的效率，因為按列存儲與按行存儲相比，前者可以有效減少查詢時所需掃描的數據量，如果數據按行存儲，數據庫首先會逐行掃描，并獲取每行數據的所有字段，再從每一行數據中返回查詢所需要的字段，導致會掃描所有的字段。如果數據按列組織，數據庫可以直接獲取想查詢的列的數據，從而避免了多余的數據行掃描。

ClickHouse采用的壓縮算法可以將列的數據進行壓縮處理，數據中的重復項越多，則壓縮率越高；壓縮率越高，則數據體量越小；而數據體量越小，則數據在網絡中的傳輸越快，對網絡帶寬和磁盤I/O的壓力也就會進一步地變小，并且支持LZ4、ZSTD壓縮算法，其中ZSTD可以提供極高壓縮比，節省大量存儲空間。

02、MPP架構

MPP ( Massively Parallel Processing)，即大規模并行處理，在數據庫集群中，每個節點都有獨立的磁盤存儲系統和內存系統，業務數據根據數據庫模型和應用特點劃分到各個節點上，每臺數據節點通過專用網絡或者商業通用網絡互相連接，彼此協同計算，作為整體提供數據庫服務。ClickHouse是一款MPP(Massively Parallel Processing)架構的列式存儲數據庫，支持大規模并行處理，以多主對等的扁平架構，保證了海量數據在各個節點的分布式存儲。并且充分發揮單節點性能，提供了極高的能效比。

03、高性能表引擎+向量執行+高效索引

為了高效的使用CPU，數據不僅僅按列存儲，同時還可利用SIMD 指令進一步加速執行效率，這部分是ClickHouse 優于大量同類OLAP 產品的重要因素；

主鍵索引采用排序+稀疏索引結構，只要過濾條件在索引列中包含即可觸發索引快速查詢，即使作為過濾條件的數據不在索引中，由于各種并行處理機制ClickHouse全表掃描的速度也很快，列式存儲用于減少不必要的字段讀取，而索引則用于減少不必要的記錄讀取。ClickHouse同時支持豐富的二級索引，支持跳表結構、Bloom Filter等過濾功能，從而在查詢時盡可能的減少不必要的記錄讀取，提高查詢性能。

開發者服務數據分析架構

架構設計特點：

?

對比Lambda架構，采用ZooKeeper將實時和離線作為統一存儲，很大程度上規避了Lambda架構上實時和離線分離維護復雜度高的問題，數據完整性、一致性、準確性、時效性得到極大提高；

對比Kappa架構，避免了重度依賴消息隊列，數據查詢和計算性能可靠穩定性得到保證；

支持SQL查詢語法，配合Native、Jdbc多種服務接口，ZooKeeper通過多項技術優化實現高效OLAP執行查詢；

支持實時批量插入數據和離線文件導入，即滿足現網實時流秒級ad-hoc即席查詢，同時離線導入海量預計算指標數據文件，滿足大時間范圍指標快速查詢，為業務提供最佳SLA上卷下鉆查詢服務；

提供豐富高效的數據結構類型和功能函數，滿足快速開發實現各種業務數據分析場景；

組網設計

ClickHouse不同于Elasticsearch、HDFS這類主從架構的分布式系統，它采用多主（無中心）架構，集群中的每個節點角色對等，客戶端訪問任意一個節點都能得到相同的效果。

ClickHouse借助分片將數據進行橫向切分，而分片依賴集群，每個集群由1到多個分片組成，每個分片對應了ClickHouse的1個服務節點；分片數量的上限取決于節點數量（1個分片只能對應1個服務節點）。ClickHouse提供了本地表與分布式表的概念；一張本地表等同于一個數據分片。而分布式表是張邏輯表，本身不存儲任何數據，它是本地表的訪問代理，其作用類似分庫中間件。借助分布式表，能夠代理訪問多個數據分片，從而實現分布式查詢。

ClickHouse的數據副本一般通過ReplicatedMergeTree復制表系列引擎實現，副本之間借助ZooKeeper實現數據的一致性，在生產環境一般是分布式表提供查詢服務，本地表提供寫入功能，實現讀寫分離。

綜上所述，生產環境高可用組網方式：

部署ZooKeeper集群，支持ClickHouse分布式DDL執行、ReplicatedMergeTree表主備節點之間的狀態同步功能；

部署Chproxy集群，為外部查詢提供代理功能，提供多種能力：

將ClickHouse集群劃分為多個邏輯集群，不同邏輯集群按需進行配置；

Chproxy節點都是無狀態模式，上層可以掛在負載均衡（loadbalancing），可做到Chproxy層面的高可用，也可橫向擴展業務能力；

對邏輯用戶進行查詢、訪問、安全等限制，并支持緩存結果；

ClickHouse采用分布式表+集群分片方式，實現表存儲高可用和負載均衡；

性能測試

選用了ClickHouse官方提供的一個測試方案：SSB(Star Schema Benchmark)

https://clickhouse.com/docs/en/getting-started/example-datasets/star-schema

測試服務器選取中等配置：

cpu:16核Intel(R)Xeon(R) Gold 6278C CPU @ 2.60GHz；

內存：32GB；

超高速云盤（350MB/s）：500GB；

數據盤采用ext4文件系統，ioscheduler采用deadline方式；

使用dbgen生產6億數據，導入test庫中：

測試結果如下：

掃描6億數據執行查詢分析SQL，時間消耗保持在10秒以下，性能已經非常出眾，滿足產品業務要求。

經驗分享

ZooKeeper集群生產環境建議采用3.6.x以上版本，集群采用5節點，配置文件使用ClickHouse推薦配置參數，采用supervisor保活，盡量保證ZooKeeper集群運行穩定可靠；

生產環境建議采用高配置服務器，推薦內存和存儲空間（壓縮后）比1:50，存儲采用ssd，對比機械硬盤讀寫可以提高10倍以上，如果考慮成本可以采用zstd壓縮和冷熱數據分級存儲；

Hive導入ClickHouse，推薦使用Apache Seatunnel，開發簡單穩定高效；

離線預決算指標結果文件導出為Parquet格式，并且按照ClickHouse表分區方式拆分文件，文件內數據按照orderby字段排序，滿足TB級別數據1小時導入；

實時寫入批量建議大于20萬條，并且按照表分區拆分，數據按照orderby字段排序，這樣導入效率極高，減少分區排序消耗；

推薦生產環境分布式表提供查詢服務，本地表提供寫入功能，實現讀寫分離；

不同用戶賬號查詢并發數使用max_concurrent_queries_for_user實現控制，避免出現某個賬號占用所有查詢資源，其他賬號無法得到資源保證；

建議增加groupby或者sort的磁盤溢出功能，配置max_bytes_before_external_group_by和max_bytes_before_external_sort 參數，提高查詢穩定性；

數據去重查詢建議采用ReplacingMergeTree+Final查詢，實現數據精準去重；

數據更新不同場景可以采用不同方案，單條更新可以參考數據去重實現方式，批量更新可以采用先刪后寫方式實現，這里要注意刪除采用同步刪除并且設置insert_deduplicate=0；

啟動字典表和低基數字典功能，可以提高維度字典關聯速度和減少存儲；

物化視圖和projection可以實現多種維度排序組合加速查詢，但是需要更多空間和消耗部分服務器性能，簡單理解為空間換時間；

udf實現支持3種方式，推薦選擇2：

lambda語法內建udf，實現簡單，但是功能受限；

配置

user_defined_executable_functions_config，導入外部程序實現udf功能，通過開發獨立腳本或者程序實現復雜處理功能；

修改源碼，直接加入udf函數，需要較高人力成本投入，運維復雜高；

維度變化較少的指標，建議使用預計算實現歷史數據計算，這樣可以提高查詢效率，如果出現查詢OOM情況，在沒有辦法增加資源情況下，建議縮短查詢范圍，分解為多次查詢再聚合結果；

盡量避免大表之間JOIN，如果確實無法避免，可以考慮采用分區分桶實現，本地化JOIN結果再聚合，避免全局JOIN內存不足；

數據遷移可以按照分區方式導出為native格式文件，采用離線加載方式導入；

ClickHouse、ZooKeeper、Chproxy可以通過Prometheus+Grafana實現監控告警。

ClickHouse集群監控：

ZooKeeper集群監控：

Chproxy集群監控：

未來規劃

ClickHouse集群維護開發工具，提高集群擴縮容、數據遷移等操作效率；

ClickHouse-keeper代替ZooKeeper，簡化組網部署，提高服務穩定性和可維護性；

ClickHouse采用RBAC實現精細化訪問控制；

ClickHouse容器化+存算分離探索。

關于極光

極光（Aurora Mobile，納斯達克股票代碼：JG）成立于2011年，是中國領先的客戶互動和營銷科技服務商。成立之初，極光專注于為企業提供穩定高效的消息推送服務，憑借先發優勢，已經成長為市場份額遙遙領先的移動消息推送服務商。隨著企業對客戶觸達和營銷增長需求的不斷加強，極光前瞻性地推出了消息云和營銷云等解決方案，幫助企業實現多渠道的客戶觸達和互動需求，以及人工智能和大數據驅動的營銷科技應用，助力企業數字化轉型。

總結

以上是生活随笔為你收集整理的极光笔记 | 极光clickhouse千亿级数据分析实践之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。