ClickHouse埋點明細設計與監控平臺應用

羅大偉

摘要：最近兩年，國內很多中大型互聯網企業都在倡導數字化轉型，數據已經成為公司非常重要的資產，可以幫助企業做精準營銷和商業決策。監控工具早先是做服務器監測，功能單一，現在已逐步發展為實時智能分析平臺：采集請求源頭到底層服務所有中間調用環節運行數據。監控平臺提供豐富的全端埋點采集、時序指標聚合、報文解析、日志規整、全鏈路追蹤、數據分析、自定義告警、報盤展示等功能。論文詳細描述監控平臺采集海量埋點明細上報ClickHouse以及埋點明細在監控平臺的應用。

關鍵詞：數字化轉型;監控平臺;ClickHouse

Abstract In the last two years，many medium and large Internet companies in China have been advocating digital transformation. Data has become a very important asset for companies，which can help them make precise marketing and business decisions. The monitoring tool，which started as a single-purpose server monitor，has evolved into a real-time intelligent analysis platform that collects data from the source of the request to all intermediate calls to the underlying service. The monitoring platform provides rich functions such as full-end sensor collection，timing metric aggregation，message parsing，log normalization，full-link tracking，data analysis，custom alarm，dashboard display and so on. The paper describes in detail the monitor platform to collect a large number of sensor details to report to ClickHouse and the application of sensor details in monitoring platform.

Key Words ?digital transformation，monitor platform，ClickHouse.

1引言

隨著移動互聯網和物聯網時代的到來，微服務與全端產品盛行，企業越來越注重數據精細化治理，怎么從海量數據取提取有效的價值顯得越來越重要。感知終端設備最常規做法使用監控工具在終端界面多處埋點，用戶訪問與操作設備時，埋點事件被觸發。后端需要監測微服務與平臺各方面運行流轉情況，也需要做很多埋點。大批量的埋點明細數據需要供統計分析使用，落庫存儲需要選擇一個簡單、高效、適用的存儲數據庫。

ClickHouse是一個用于聯機分析（OLAP）的列式數據庫管理系統（DBMS）[4]。Yandex.Metric公司使用ClickHouse存儲了超過20萬億行的數據，90%的自定義查詢能夠在1秒內返回[1]。ClickHouse數據表列與列之間由不同的文件保存，存儲有較高的壓縮比;有多樣化的表引擎結構，十分靈活;既支持分區（縱向擴展，利用多線程），又支持分片（橫向擴展，利用分布式），將多線程和分布式的技術應用到了極致;同時采用多主架構，規避了單點故障問題。計算機存儲系統是一種層次結構，如圖1所示，存儲媒介距離CPU越近，則訪問數據的速度越快，所以利用CPU向量化執行的特性，對于程序的性能提升意義非凡，ClickHouse利用SSE4.2指令集實現向量化執行。

業務系統接入監控埋點被觸發有以下特征：

1）埋點事件觸發不會再更改;

2）埋點明細字段事先定義類型明確，容易壓縮;

3）業務系統多，埋點需求廣泛，需要靈活加屬性;

4）埋點觸發不要求數據的絕對精準記錄，不需要事務;

5）埋點數據尤其全埋點，大大高于頁面瀏覽量，埋點觸發數據量很大;

這些特征與ClickHouse的使用場景是高度吻合的。Clickhouse使用門檻較低，與mysql語法非常相似，容易上手。

本文重點介紹監控平臺采集埋點觸發信息后使用ClickHouse存儲埋點明細數據表設計，以及埋點明細在監控指標的應用。

2埋點明細設計

對于海量數據的存儲，需要很大的容量分布式部署，價格昂貴。ClickHouse數據默認使用LZ4算法壓縮，在Yandex.Metrica的生產環境中，數據總體壓縮比可以達到8：1（未壓縮前17PB，壓縮后2PB）。而經過筆者在生產環境幾百億行數據驗證，埋點明細數據設計合理，壓縮比可達到20：1，極大節省存儲成本。

埋點明細基礎字段設計如圖2所示，其中session_id用于一段時間內用戶行為、系統狀況的統計。source用于記錄埋點數據來源，采集來源主要有：服務端，移動端，Web小程序，數據倉庫;微服務依賴的中間件。垂直業務部門系統作為第一級分類。一個垂直部門對應多個系統。系統下有多個微服務應用、手機與PC等前端應用，根據前后端不同的場景需求，建立第二級分類——埋點類型，埋點類型設置有：

1）頁面類：移動端、WEB端、小程序頁面;

2）接口類：中后臺微服務接口，前臺HTTP API;

3）事件類：自定義埋點事件被觸發。

系統間隔離性比較強，按照系統建庫，按照埋點類型建表，埋點明細表基礎字段都相同，不同的是埋點分類的特性字段。

明細表PARTITION設置為一天一分區，使用toDate（occur_time）。OrderBy設置為（sensor_no，occur_time），每一個查詢sensor_no是必須的where條件，鎖定埋點;occur_time作為另一個必需條件，用于選擇時間范圍，按照ClickHouse存儲特性設計能極大縮小范圍。TTL設置為6個月過期，超過6個月的數據到數據中心歸檔。

一張埋點明細表包含基礎字段、專有字段、業務自定義字段。基礎字段是每一個埋點都包含的，不分系統與應用。專有字段是相同類型埋點都包含，按埋點類型進行區分。頁面類/接口類/事件類都有自己的類型特性，比如說頁面類有頁面名稱、頁面深度、頁面停留時長、上一級頁面;接口類有url、method、執行時長、請求與響應長度，需要區分建表更好維護，一張明細表結構如圖3所示：

埋點明細表字段個數并不是表定義好之后固定下來的，如圖3所示，隨著埋點業務屬性配置變多，表的自定義字段會逐步增加。如果增加的業務屬性已經在同一張明細表中被其他埋點定義，則直接復用，否則添加新列。ClickHouse可快速加列，隨著埋點業務迭代，明細表會逐漸變成寬表。

3埋點明細上報流程

監控平臺提供的客戶端需要安裝在應用工程中，才能完成應用內接入監控的工作。客戶端采集應用的消息入隊列，批量上報到采集消息服務器組中。服務器采集到消息列表經過格式化處理，以JSON形式壓入kafka，利用kafka的積壓能力存儲消息，避免服務器出現問題消息丟失，同時kafka也是高吞吐的[3]，傳遞消息性能很好。

后臺消費服務會并發啟動多個java線程，每次消費一批kafka消息，將消息處理后存入Redis進行短期聚合;按照埋點配置的指標，結合Redis數據，對齊InfluxDB存入分鐘/小時/天級聚的數據。將消息明細按照系統與埋點類型做好分組，匹配好明細字段，批量寫入ClickHouse不同的埋點明細表中。埋點明細上送的流程如下圖4所示：

明細存儲ClickHouse的邏輯會隨著業務量的增長而改變。一張埋點明細表中的數據非常龐大，或者埋點存儲不均勻，會影響到查詢性能?？梢灾付◣讉€埋點的數據做遷出，形成一張新表。新表放在本機或者外遷，在監控控臺中設置埋點的路由。下次采集消息會讀取新路由信息，按照新規則來寫表。

ClickHouse的架構靈活，支持單節點、單副本、多節點、多副本多種架構[5]。遇到一個埋點的明細數據依然龐大，機器不能滿足要求時，可將此表按照分片規則升級為Distributed分布式表，ClickHouse計算引擎利用多臺機器的CPU資源來提高性能。

這樣的操作會規避流量高峰期，操作前做好副本備份。遷表首先要先做好路由，按照路由邏輯設置雙寫（同時寫原表與新表）。接著來遷移，遷移完成并確認數據無誤后在監控控臺取消埋點雙寫，摘除原表寫入，最后刪除原表已遷出的埋點。

4 Clickhouse在監控指標的應用

InfluxDB是支持時序數據高效讀寫、壓縮存儲、實時計算能力的數據庫服務，具有成本優勢的高性能讀、高性能寫、高存儲率[2]。監控平臺使用InfluxDB存儲控臺埋點配置的指標數據，按照分鐘/小時/天級粒度聚合存儲數據點Point，有非常好的查詢性能，對于Grafana報盤圖表展示也很友好。

Point存儲包含measurement（指標：相當于一張表），tag（自定義屬性）、value（指標值）、timestamp。指標基于埋點配置生成，需要配置聚合方式（在value和tag上求和/平均/總數/方差/中位值等），根據埋點用tag和value配置where過濾條件，按照指標實際需求拿tag做分組配置。InfluxDB指標數據的使用也遇到一些迫切需要解決的業務局限性：

1）指標是從埋點的指標配置成功后的下一分鐘才開始聚合，沒有歷史時序數據，會有不少業務方想在報盤上能看到指標配置前的數據;

2）聚合好的數據準確性缺乏驗證機制，如果業務方提出質疑，拿不出有效的證據來證明;

3）隨著業務變化，指標也要更改，對已經存在的指標數據，配置更改后已經聚合的往往不準確，失去了本身的價值;

4）埋點下有多個配置好的指標，要根據這多個指標得到復合指標，根據多個指標的tag和value不能覆蓋埋點明細全部數據，無法從指標角度快速解決問題。

如圖5所示，我們可以從ClickHouse埋點明細數據為出發點，針對業務時序指標現有的幾個重要問題，提供指定解決方案。

對于時序指標剛剛建立，歷史數據缺失，使用以下的SQL即可拿到歷史數據。

-- 以事件明細表為例，做求和聚合運算

-- 56是系統號 event代表事件

SELECT minute，sum（price）

FROM sensor_56_event

WHERE sensor_no=3721 AND

occur_time>=’2021-05-15 00：00：00’ AND

occur_time<’2021-05-16 00：00：00’

GROUP BY minute;

-- hour/date 也可按小時按天聚合通過SQL拿到ClickHouse聚合好的數據分別按天進行推進對齊寫入InfluxDB的minute/hour/day的measurement中，完成數據回溯。

業務方對于陡增陡減的指標數據可能會持有懷疑態度，會來問為什么會出現這樣的流量變化。為此需要給產品運營提供指標校準功能和短期明細數據在監控控臺查閱權限。同時能夠對核心指標（牽涉交易、積分等核心業務數據）進行核對校驗。為此啟動一個監控新服務應用，按照埋點明細的分鐘級進行聚合查詢，晚5分鐘短期回溯校驗指標數據，如何出現偏差，上送偏差分鐘，供監控開發人員分析與解決問題。

業務場景變了，業務方通過監控控臺更改指標配置，之前的數據可用ClickHouse重新聚合。

舉個例子。A集群有100臺服務器，指標1記錄了A集群分鐘級平均負載值，B集群有150臺服務器，指標2記錄了B級群平均負載值。現在要匯總AB平均負載，因為服務器在集群里個數分布并不均勻，不能將負載值相加除以2。新建指標在過濾條件寫集群A或者B，的確能解決問題，但是下次需求變了，需要按照機器配置、所屬事業部、數據要重新回溯比較麻煩，為此使用ClickHouse的SQL靈活聚合完成這樣的復雜場景邏輯更加簡單。

SELECT minute，cpu，department，sum（`score`）/ count（*）avg_score

FROM sensor_56_event

WHERE sensor_no=3721 AND

occur_time>=’2021-05-15 00：00：00’ AND

occur_time<’2021-05-16 00：00：00’ AND

cluster IN（‘A’，’B’）

GROUP BY minute，cpu，department;對于更加復雜與海量數據統計時，就超出InfluxDB適用范圍了，InfluxDB超過3個以上的tag做分組，數據量大tag（訂單號/用戶id等）分組查詢會比較慢，這樣的綜合場景可以使用ClickHouse也會遇到查詢緩慢的現象。為此需要對復雜的SQL逐段拆解來做物化視圖。物化視圖相當于中間表，數據會根據主表數據變化寫入實際存儲中。根據物化視圖再組裝新SQL，會帶來不少性能提升，簡化了數據倉庫建中間表的步驟。

對于復雜場景的數據分析做系統型精細管理，對ClickHouse表做建模。建立業務需要的分析維度表DIM（往往從離線數倉抽取），經過清洗的明細表DWD，輕度聚合DWD做DWS寬表（多個垂直業務線通用的實時匯總，例如統計當日活動的每個設備明細），個性化維度匯總分析出報表結果的ADS表?；诮?，能更好地完成行為分析、用戶畫像、漏斗分析等大數據分析需求。

5結語

本文基于監控平臺埋點采集與指標聚合現狀，設計埋點明細表結構，使用ClickHouse指標統計常見問題，解決了垂直失業部門使用監控工具遇到的各類技術問題，推動了數字化運營在公司的開展。

參考文獻：

[1]朱凱 ClickHouse原理解析與應用實踐 2020-06 ISBN：9787111654902.

[2]韓健 InfluxDB原理與實戰 2020-05 ISBN：9787111651345.

[3]朱忠華 深入理解Kafka：核心設計與實踐原理 ?2019-01 ISBN：9787121359026.

[4]Clickhouse官網中文手冊 ?2016–2020 Yandex LLC ?https：//clickhouse.tech/docs/zh/.

[5]云數據庫ClickHouse ? 2009-2021 Aliyun.com https：//help.aliyun.com/document_detail/167449.html

上海匯付數據服務有限公司 ?上海 ?200030