ClickHouse埋點(diǎn)明細(xì)設(shè)計(jì)與監(jiān)控平臺(tái)應(yīng)用

羅大偉

摘要：最近兩年，國內(nèi)很多中大型互聯(lián)網(wǎng)企業(yè)都在倡導(dǎo)數(shù)字化轉(zhuǎn)型，數(shù)據(jù)已經(jīng)成為公司非常重要的資產(chǎn)，可以幫助企業(yè)做精準(zhǔn)營銷和商業(yè)決策。監(jiān)控工具早先是做服務(wù)器監(jiān)測(cè)，功能單一，現(xiàn)在已逐步發(fā)展為實(shí)時(shí)智能分析平臺(tái)：采集請(qǐng)求源頭到底層服務(wù)所有中間調(diào)用環(huán)節(jié)運(yùn)行數(shù)據(jù)。監(jiān)控平臺(tái)提供豐富的全端埋點(diǎn)采集、時(shí)序指標(biāo)聚合、報(bào)文解析、日志規(guī)整、全鏈路追蹤、數(shù)據(jù)分析、自定義告警、報(bào)盤展示等功能。論文詳細(xì)描述監(jiān)控平臺(tái)采集海量埋點(diǎn)明細(xì)上報(bào)ClickHouse以及埋點(diǎn)明細(xì)在監(jiān)控平臺(tái)的應(yīng)用。

關(guān)鍵詞：數(shù)字化轉(zhuǎn)型;監(jiān)控平臺(tái);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引言

隨著移動(dòng)互聯(lián)網(wǎng)和物聯(lián)網(wǎng)時(shí)代的到來，微服務(wù)與全端產(chǎn)品盛行，企業(yè)越來越注重?cái)?shù)據(jù)精細(xì)化治理，怎么從海量數(shù)據(jù)取提取有效的價(jià)值顯得越來越重要。感知終端設(shè)備最常規(guī)做法使用監(jiān)控工具在終端界面多處埋點(diǎn)，用戶訪問與操作設(shè)備時(shí)，埋點(diǎn)事件被觸發(fā)。后端需要監(jiān)測(cè)微服務(wù)與平臺(tái)各方面運(yùn)行流轉(zhuǎn)情況，也需要做很多埋點(diǎn)。大批量的埋點(diǎn)明細(xì)數(shù)據(jù)需要供統(tǒng)計(jì)分析使用，落庫存儲(chǔ)需要選擇一個(gè)簡(jiǎn)單、高效、適用的存儲(chǔ)數(shù)據(jù)庫。

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

業(yè)務(wù)系統(tǒng)接入監(jiān)控埋點(diǎn)被觸發(fā)有以下特征：

1）埋點(diǎn)事件觸發(fā)不會(huì)再更改;

2）埋點(diǎn)明細(xì)字段事先定義類型明確，容易壓縮;

3）業(yè)務(wù)系統(tǒng)多，埋點(diǎn)需求廣泛，需要靈活加屬性;

4）埋點(diǎn)觸發(fā)不要求數(shù)據(jù)的絕對(duì)精準(zhǔn)記錄，不需要事務(wù);

5）埋點(diǎn)數(shù)據(jù)尤其全埋點(diǎn)，大大高于頁面瀏覽量，埋點(diǎn)觸發(fā)數(shù)據(jù)量很大;

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

本文重點(diǎn)介紹監(jiān)控平臺(tái)采集埋點(diǎn)觸發(fā)信息后使用ClickHouse存儲(chǔ)埋點(diǎn)明細(xì)數(shù)據(jù)表設(shè)計(jì)，以及埋點(diǎn)明細(xì)在監(jiān)控指標(biāo)的應(yīng)用。

2埋點(diǎn)明細(xì)設(shè)計(jì)

對(duì)于海量數(shù)據(jù)的存儲(chǔ)，需要很大的容量分布式部署，價(jià)格昂貴。ClickHouse數(shù)據(jù)默認(rèn)使用LZ4算法壓縮，在Yandex.Metrica的生產(chǎn)環(huán)境中，數(shù)據(jù)總體壓縮比可以達(dá)到8：1（未壓縮前17PB，壓縮后2PB）。而經(jīng)過筆者在生產(chǎn)環(huán)境幾百億行數(shù)據(jù)驗(yàn)證，埋點(diǎn)明細(xì)數(shù)據(jù)設(shè)計(jì)合理，壓縮比可達(dá)到20：1，極大節(jié)省存儲(chǔ)成本。

埋點(diǎn)明細(xì)基礎(chǔ)字段設(shè)計(jì)如圖2所示，其中session_id用于一段時(shí)間內(nèi)用戶行為、系統(tǒng)狀況的統(tǒng)計(jì)。source用于記錄埋點(diǎn)數(shù)據(jù)來源，采集來源主要有：服務(wù)端，移動(dòng)端，Web小程序，數(shù)據(jù)倉庫;微服務(wù)依賴的中間件。垂直業(yè)務(wù)部門系統(tǒng)作為第一級(jí)分類。一個(gè)垂直部門對(duì)應(yīng)多個(gè)系統(tǒng)。系統(tǒng)下有多個(gè)微服務(wù)應(yīng)用、手機(jī)與PC等前端應(yīng)用，根據(jù)前后端不同的場(chǎng)景需求，建立第二級(jí)分類——埋點(diǎn)類型，埋點(diǎn)類型設(shè)置有：

1）頁面類：移動(dòng)端、WEB端、小程序頁面;

2）接口類：中后臺(tái)微服務(wù)接口，前臺(tái)HTTP API;

3）事件類：自定義埋點(diǎn)事件被觸發(fā)。

系統(tǒng)間隔離性比較強(qiáng)，按照系統(tǒng)建庫，按照埋點(diǎn)類型建表，埋點(diǎn)明細(xì)表基礎(chǔ)字段都相同，不同的是埋點(diǎn)分類的特性字段。

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

一張埋點(diǎn)明細(xì)表包含基礎(chǔ)字段、專有字段、業(yè)務(wù)自定義字段?；A(chǔ)字段是每一個(gè)埋點(diǎn)都包含的，不分系統(tǒng)與應(yīng)用。專有字段是相同類型埋點(diǎn)都包含，按埋點(diǎn)類型進(jìn)行區(qū)分。頁面類/接口類/事件類都有自己的類型特性，比如說頁面類有頁面名稱、頁面深度、頁面停留時(shí)長(zhǎng)、上一級(jí)頁面;接口類有url、method、執(zhí)行時(shí)長(zhǎng)、請(qǐng)求與響應(yīng)長(zhǎng)度，需要區(qū)分建表更好維護(hù)，一張明細(xì)表結(jié)構(gòu)如圖3所示：

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

3埋點(diǎn)明細(xì)上報(bào)流程

監(jiān)控平臺(tái)提供的客戶端需要安裝在應(yīng)用工程中，才能完成應(yīng)用內(nèi)接入監(jiān)控的工作?？蛻舳瞬杉瘧?yīng)用的消息入隊(duì)列，批量上報(bào)到采集消息服務(wù)器組中。服務(wù)器采集到消息列表經(jīng)過格式化處理，以JSON形式壓入kafka，利用kafka的積壓能力存儲(chǔ)消息，避免服務(wù)器出現(xiàn)問題消息丟失，同時(shí)kafka也是高吞吐的[3]，傳遞消息性能很好。

后臺(tái)消費(fèi)服務(wù)會(huì)并發(fā)啟動(dòng)多個(gè)java線程，每次消費(fèi)一批kafka消息，將消息處理后存入Redis進(jìn)行短期聚合;按照埋點(diǎn)配置的指標(biāo)，結(jié)合Redis數(shù)據(jù)，對(duì)齊InfluxDB存入分鐘/小時(shí)/天級(jí)聚的數(shù)據(jù)。將消息明細(xì)按照系統(tǒng)與埋點(diǎn)類型做好分組，匹配好明細(xì)字段，批量寫入ClickHouse不同的埋點(diǎn)明細(xì)表中。埋點(diǎn)明細(xì)上送的流程如下圖4所示：

明細(xì)存儲(chǔ)ClickHouse的邏輯會(huì)隨著業(yè)務(wù)量的增長(zhǎng)而改變。一張埋點(diǎn)明細(xì)表中的數(shù)據(jù)非常龐大，或者埋點(diǎn)存儲(chǔ)不均勻，會(huì)影響到查詢性能?？梢灾付◣讉€(gè)埋點(diǎn)的數(shù)據(jù)做遷出，形成一張新表。新表放在本機(jī)或者外遷，在監(jiān)控控臺(tái)中設(shè)置埋點(diǎn)的路由。下次采集消息會(huì)讀取新路由信息，按照新規(guī)則來寫表。

ClickHouse的架構(gòu)靈活，支持單節(jié)點(diǎn)、單副本、多節(jié)點(diǎn)、多副本多種架構(gòu)[5]。遇到一個(gè)埋點(diǎn)的明細(xì)數(shù)據(jù)依然龐大，機(jī)器不能滿足要求時(shí)，可將此表按照分片規(guī)則升級(jí)為Distributed分布式表，ClickHouse計(jì)算引擎利用多臺(tái)機(jī)器的CPU資源來提高性能。

這樣的操作會(huì)規(guī)避流量高峰期，操作前做好副本備份。遷表首先要先做好路由，按照路由邏輯設(shè)置雙寫（同時(shí)寫原表與新表）。接著來遷移，遷移完成并確認(rèn)數(shù)據(jù)無誤后在監(jiān)控控臺(tái)取消埋點(diǎn)雙寫，摘除原表寫入，最后刪除原表已遷出的埋點(diǎn)。

4 Clickhouse在監(jiān)控指標(biāo)的應(yīng)用

InfluxDB是支持時(shí)序數(shù)據(jù)高效讀寫、壓縮存儲(chǔ)、實(shí)時(shí)計(jì)算能力的數(shù)據(jù)庫服務(wù)，具有成本優(yōu)勢(shì)的高性能讀、高性能寫、高存儲(chǔ)率[2]。監(jiān)控平臺(tái)使用InfluxDB存儲(chǔ)控臺(tái)埋點(diǎn)配置的指標(biāo)數(shù)據(jù)，按照分鐘/小時(shí)/天級(jí)粒度聚合存儲(chǔ)數(shù)據(jù)點(diǎn)Point，有非常好的查詢性能，對(duì)于Grafana報(bào)盤圖表展示也很友好。

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

1）指標(biāo)是從埋點(diǎn)的指標(biāo)配置成功后的下一分鐘才開始聚合，沒有歷史時(shí)序數(shù)據(jù)，會(huì)有不少業(yè)務(wù)方想在報(bào)盤上能看到指標(biāo)配置前的數(shù)據(jù);

2）聚合好的數(shù)據(jù)準(zhǔn)確性缺乏驗(yàn)證機(jī)制，如果業(yè)務(wù)方提出質(zhì)疑，拿不出有效的證據(jù)來證明;

3）隨著業(yè)務(wù)變化，指標(biāo)也要更改，對(duì)已經(jīng)存在的指標(biāo)數(shù)據(jù)，配置更改后已經(jīng)聚合的往往不準(zhǔn)確，失去了本身的價(jià)值;

4）埋點(diǎn)下有多個(gè)配置好的指標(biāo)，要根據(jù)這多個(gè)指標(biāo)得到復(fù)合指標(biāo)，根據(jù)多個(gè)指標(biāo)的tag和value不能覆蓋埋點(diǎn)明細(xì)全部數(shù)據(jù)，無法從指標(biāo)角度快速解決問題。

如圖5所示，我們可以從ClickHouse埋點(diǎn)明細(xì)數(shù)據(jù)為出發(fā)點(diǎn)，針對(duì)業(yè)務(wù)時(shí)序指標(biāo)現(xiàn)有的幾個(gè)重要問題，提供指定解決方案。

對(duì)于時(shí)序指標(biāo)剛剛建立，歷史數(shù)據(jù)缺失，使用以下的SQL即可拿到歷史數(shù)據(jù)。

-- 以事件明細(xì)表為例，做求和聚合運(yùn)算

-- 56是系統(tǒng)號(hào) 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 也可按小時(shí)按天聚合通過SQL拿到ClickHouse聚合好的數(shù)據(jù)分別按天進(jìn)行推進(jìn)對(duì)齊寫入InfluxDB的minute/hour/day的measurement中，完成數(shù)據(jù)回溯。

業(yè)務(wù)方對(duì)于陡增陡減的指標(biāo)數(shù)據(jù)可能會(huì)持有懷疑態(tài)度，會(huì)來問為什么會(huì)出現(xiàn)這樣的流量變化。為此需要給產(chǎn)品運(yùn)營提供指標(biāo)校準(zhǔn)功能和短期明細(xì)數(shù)據(jù)在監(jiān)控控臺(tái)查閱權(quán)限。同時(shí)能夠?qū)诵闹笜?biāo)（牽涉交易、積分等核心業(yè)務(wù)數(shù)據(jù)）進(jìn)行核對(duì)校驗(yàn)。為此啟動(dòng)一個(gè)監(jiān)控新服務(wù)應(yīng)用，按照埋點(diǎn)明細(xì)的分鐘級(jí)進(jìn)行聚合查詢，晚5分鐘短期回溯校驗(yàn)指標(biāo)數(shù)據(jù)，如何出現(xiàn)偏差，上送偏差分鐘，供監(jiān)控開發(fā)人員分析與解決問題。

業(yè)務(wù)場(chǎng)景變了，業(yè)務(wù)方通過監(jiān)控控臺(tái)更改指標(biāo)配置，之前的數(shù)據(jù)可用ClickHouse重新聚合。

舉個(gè)例子。A集群有100臺(tái)服務(wù)器，指標(biāo)1記錄了A集群分鐘級(jí)平均負(fù)載值，B集群有150臺(tái)服務(wù)器，指標(biāo)2記錄了B級(jí)群平均負(fù)載值?，F(xiàn)在要匯總AB平均負(fù)載，因?yàn)榉?wù)器在集群里個(gè)數(shù)分布并不均勻，不能將負(fù)載值相加除以2。新建指標(biāo)在過濾條件寫集群A或者B，的確能解決問題，但是下次需求變了，需要按照機(jī)器配置、所屬事業(yè)部、數(shù)據(jù)要重新回溯比較麻煩，為此使用ClickHouse的SQL靈活聚合完成這樣的復(fù)雜場(chǎng)景邏輯更加簡(jiǎn)單。

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;對(duì)于更加復(fù)雜與海量數(shù)據(jù)統(tǒng)計(jì)時(shí)，就超出InfluxDB適用范圍了，InfluxDB超過3個(gè)以上的tag做分組，數(shù)據(jù)量大tag（訂單號(hào)/用戶id等）分組查詢會(huì)比較慢，這樣的綜合場(chǎng)景可以使用ClickHouse也會(huì)遇到查詢緩慢的現(xiàn)象。為此需要對(duì)復(fù)雜的SQL逐段拆解來做物化視圖。物化視圖相當(dāng)于中間表，數(shù)據(jù)會(huì)根據(jù)主表數(shù)據(jù)變化寫入實(shí)際存儲(chǔ)中。根據(jù)物化視圖再組裝新SQL，會(huì)帶來不少性能提升，簡(jiǎn)化了數(shù)據(jù)倉庫建中間表的步驟。

對(duì)于復(fù)雜場(chǎng)景的數(shù)據(jù)分析做系統(tǒng)型精細(xì)管理，對(duì)ClickHouse表做建模。建立業(yè)務(wù)需要的分析維度表DIM（往往從離線數(shù)倉抽?。?，經(jīng)過清洗的明細(xì)表DWD，輕度聚合DWD做DWS寬表（多個(gè)垂直業(yè)務(wù)線通用的實(shí)時(shí)匯總，例如統(tǒng)計(jì)當(dāng)日活動(dòng)的每個(gè)設(shè)備明細(xì)），個(gè)性化維度匯總分析出報(bào)表結(jié)果的ADS表?；诮?，能更好地完成行為分析、用戶畫像、漏斗分析等大數(shù)據(jù)分析需求。

5結(jié)語

本文基于監(jiān)控平臺(tái)埋點(diǎn)采集與指標(biāo)聚合現(xiàn)狀，設(shè)計(jì)埋點(diǎn)明細(xì)表結(jié)構(gòu)，使用ClickHouse指標(biāo)統(tǒng)計(jì)常見問題，解決了垂直失業(yè)部門使用監(jiān)控工具遇到的各類技術(shù)問題，推動(dòng)了數(shù)字化運(yùn)營在公司的開展。

參考文獻(xiàn)：

[1]朱凱 ClickHouse原理解析與應(yīng)用實(shí)踐 2020-06 ISBN：9787111654902.

[2]韓健 InfluxDB原理與實(shí)戰(zhàn) 2020-05 ISBN：9787111651345.

[3]朱忠華 深入理解Kafka：核心設(shè)計(jì)與實(shí)踐原理 ?2019-01 ISBN：9787121359026.

[4]Clickhouse官網(wǎng)中文手冊(cè) ?2016–2020 Yandex LLC ?https：//clickhouse.tech/docs/zh/.

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

上海匯付數(shù)據(jù)服務(wù)有限公司 ?上海 ?200030