羅大偉

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

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

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

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

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

1）埋點事件觸發(fā)不會再更改;

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

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

4）埋點觸發(fā)不要求數(shù)據的絕對精準記錄，不需要事務;

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

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

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

2埋點明細設計

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

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

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

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

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

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

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

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

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

3埋點明細上報流程

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

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

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

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

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

4 Clickhouse在監(jiān)控指標的應用

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

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

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

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

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

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

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

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

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

-- 56是系統(tǒng)號 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聚合好的數(shù)據分別按天進行推進對齊寫入InfluxDB的minute/hour/day的measurement中，完成數(shù)據回溯。

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

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

舉個例子。A集群有100臺服務器，指標1記錄了A集群分鐘級平均負載值，B集群有150臺服務器，指標2記錄了B級群平均負載值?，F(xiàn)在要匯總AB平均負載，因為服務器在集群里個數(shù)分布并不均勻，不能將負載值相加除以2。新建指標在過濾條件寫集群A或者B，的確能解決問題，但是下次需求變了，需要按照機器配置、所屬事業(yè)部、數(shù)據要重新回溯比較麻煩，為此使用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;對于更加復雜與海量數(shù)據統(tǒng)計時，就超出InfluxDB適用范圍了，InfluxDB超過3個以上的tag做分組，數(shù)據量大tag（訂單號/用戶id等）分組查詢會比較慢，這樣的綜合場景可以使用ClickHouse也會遇到查詢緩慢的現(xiàn)象。為此需要對復雜的SQL逐段拆解來做物化視圖。物化視圖相當于中間表，數(shù)據會根據主表數(shù)據變化寫入實際存儲中。根據物化視圖再組裝新SQL，會帶來不少性能提升，簡化了數(shù)據倉庫建中間表的步驟。

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

5結語

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

參考文獻：

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

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

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

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

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

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