導讀

微信的多維指標監(jiān)控平臺，具備自定義維度、指標的監(jiān)控能力，主要服務于用戶自定義監(jiān)控。作為框架級監(jiān)控的補充，它承載著聚合前 45億/min、4萬億/天的數(shù)據(jù)量。當前，針對數(shù)據(jù)層的查詢請求也達到了峰值 40萬/min，3億/天。較大的查詢請求使得數(shù)據(jù)查詢遇到了性能瓶頸：查詢平均耗時 > 1000ms，失敗率居高不下。針對這些問題，微信團隊對數(shù)據(jù)層查詢接口進行了針對性的優(yōu)化來滿足上述場景，將平均查詢速度從1000ms+優(yōu)化到了100ms級別。本文為各位分享優(yōu)化過程，希望對你有用！

1 背景介紹

2 優(yōu)化分析

2.1 用戶查詢行為分析

2.2 數(shù)據(jù)層架構(gòu)

2.3 為什么查詢會慢

3 優(yōu)化方案設計

3.1 拆分子查詢請求

3.2 拆分子查詢請求+redis Cache

3.3 更進一步-子維度表

4 優(yōu)化成果

4.1 緩存命中率>85%

4.2 查詢耗時優(yōu)化至 100ms

5 結(jié)語

背景介紹

微信多維指標監(jiān)控平臺（以下簡稱多維監(jiān)控），是具備靈活的數(shù)據(jù)上報方式、提供維度交叉分析的實時監(jiān)控平臺。

在這里，最核心的概念是“協(xié)議”、“維度”與“指標”。例如，如果想要對某個【省份】、【城市】、【運營商】的接口【錯誤碼】進行監(jiān)控，監(jiān)控目標是統(tǒng)計接口的【平均耗時】和【上報量】。在這里，省份、城市、運營商、錯誤碼，這些描述監(jiān)控目標屬性的可枚舉字段稱之為“維度”，而【上報量】、【平均耗時】等依賴“聚合計算”結(jié)果的數(shù)據(jù)值，稱之為“指標”。而承載這些指標和維度的數(shù)據(jù)表，叫做“協(xié)議”。

多維監(jiān)控對外提供 2 種 API：

維度枚舉查詢：用于查詢某一段時間內(nèi)，一個或多個維度的排列組合以及其對應的指標值。它反映的是各維度分布“總量”的概念，可以“聚合”，也可以“展開”，或者固定維度對其它維度進行“下鉆”。數(shù)據(jù)可以直接生成柱狀圖、餅圖等。
時間序列查詢：用于查詢某些維度條件在某個時間范圍的指標值序列。可以展示為一個時序曲線圖，橫坐標為時間，縱坐標為指標值。

然而，不管是用戶還是團隊自己使用多維監(jiān)控平臺的時候，都能感受到明顯的卡頓。主要表現(xiàn)在看監(jiān)控圖像或者是查看監(jiān)控曲線，都會經(jīng)過長時間的數(shù)據(jù)加載。

團隊意識到，這是數(shù)據(jù)量上升必然帶來的瓶頸。目前，多維監(jiān)控平臺已經(jīng)接入了數(shù)千張協(xié)議表，每張表的特點都不同。維度組合、指標量、上報量也不同。針對大量數(shù)據(jù)的實時聚合以及 OLAP 分析，數(shù)據(jù)層的性能瓶頸越發(fā)明顯，嚴重影響了用戶體驗。于是這讓團隊人員不由得開始思考：難道要一直放任它慢下去嗎？答案當然是否定的。因此，微信團隊針對數(shù)據(jù)層的查詢進行了優(yōu)化。

優(yōu)化分析

2.1 用戶查詢行為分析

要優(yōu)化，首先需要了解用戶的查詢習慣，這里的用戶包含了頁面用戶和異常檢測服務。于是微信團隊盡可能多地上報用戶使用多維監(jiān)控平臺的習慣，包括但不限于：常用的查詢類型、每個協(xié)議表的查詢維度和查詢指標、查詢量、失敗量、耗時數(shù)據(jù)等。

在分析了用戶的查詢習慣后，有了以下發(fā)現(xiàn)：

【時間序列】查詢占比 99% 以上

出現(xiàn)如此懸殊的比例可能是因為：調(diào)用一次維度枚舉，即可獲取所關(guān)心的各個維度。但是針對每個維度組合值，無論是頁面還是異常檢測都會在查詢維度對應的多條時間序列曲線中，從而出現(xiàn)「時間序列查詢」比例遠遠高于「維度枚舉查詢」。

針對1天前的查詢占比約 90%

出現(xiàn)這個現(xiàn)象可能是因為每個頁面數(shù)據(jù)都會帶上幾天前的數(shù)據(jù)對比來展示。異常檢測模塊每次會對比大約 7 天數(shù)據(jù)的曲線，造成了對大量的非實時數(shù)據(jù)進行查詢。

2.2 數(shù)據(jù)層架構(gòu)

分析完用戶習慣，再看下目前的數(shù)據(jù)層架構(gòu)。多維監(jiān)控底層的數(shù)據(jù)存儲/查詢引擎選擇了 Apache-Druid 作為數(shù)據(jù)聚合、存儲的引擎，Druid 是一個非常優(yōu)秀的分布式 OLAP 數(shù)據(jù)存儲引擎，它的特點主要在于出色的預聚合能力和高效的并發(fā)查詢能力，它的大致架構(gòu)如圖：

節(jié)點	解析
Mater節(jié)點	Overlord：實時數(shù)據(jù)攝入消費控制器 Coordinator：協(xié)調(diào)集群上數(shù)據(jù)分片的發(fā)布和負載均衡
實時節(jié)點	MiddleManager：實時數(shù)據(jù)寫入中間管理者，創(chuàng)建 Peon 節(jié)點進行數(shù)據(jù)消費任務并管理其生命周期 Peon：消費實時數(shù)據(jù)，打包并發(fā)布實時數(shù)據(jù)分片
存儲節(jié)點	Historical：存儲數(shù)據(jù)分片 DeepStorage：分片中轉(zhuǎn)存儲，不對外查詢 MetaDataStorage：元信息，如表結(jié)構(gòu) Zookeeper：存儲實時任務和狀態(tài)信息

2.3 為什么查詢會慢

查詢慢的核心原因，經(jīng)微信團隊分析如下：

協(xié)議數(shù)據(jù)分片存儲的數(shù)據(jù)片段為 2-4h 的數(shù)據(jù)，每個 Peon 節(jié)點消費回來的數(shù)據(jù)會存儲在一個獨立分片。
假設異常檢測獲取 7 * 24h 的數(shù)據(jù)，協(xié)議一共有 3 個 Peon 節(jié)點負責消費，數(shù)據(jù)分片量級為 12*3*7 = 252，意味著將會產(chǎn)生 252次數(shù)據(jù)分片 I/O。
在時間跨度較大時、MiddleManager、Historical 處理查詢?nèi)菀壮瑫r，Broker 內(nèi)存消耗較高。
部分協(xié)議維度字段非常復雜，維度排列組合極大 (>100w)，在處理此類協(xié)議的查詢時，性能就會很差。

優(yōu)化方案設計

根據(jù)上面的分析，團隊確定了初步的優(yōu)化方向：

減少單 Broker 的大跨度時間查詢。
減少 Druid 的 Segments I/O 次數(shù)。
減少 Segments 的大小。

3.1 拆分子查詢請求

在這個方案中，每個查詢都會被拆解為更細粒度的“子查詢”請求。例如連續(xù)查詢 7 天的時間序列，會被自動拆解為 7 個 1天的時間序列查詢，分發(fā)到多個 Broker，此時可以利用多個 Broker 來進行并發(fā)查詢，減少單個 Broker 的查詢負載，提升整體性能。

但是這個方案并沒有解決 Segments I/O 過多的問題，所以需要在這里引入一層緩存。

3.2 拆分子查詢請求+Redis Cache

這個方案相較于 v1，增加了為每個子查詢請求維護了一個結(jié)果緩存，存儲在 Redis 中：

假設獲取 7*24h 的數(shù)據(jù)，Peon 節(jié)點個數(shù)為 3，如果命中緩存，只會產(chǎn)生 3 次 Druid 的 Segments I/O （最近的 30min）數(shù)據(jù)，相較幾百次 Segments I/O 會大幅減少。

接下來看下具體方法：

3.2.1 時間序列子查詢設計

針對時間序列的子查詢，子查詢按照「天」來分解，整個子查詢的緩存也是按照天來聚合的。以一個查詢?yōu)槔?/p>

{
    "biz_id": 1, // 查詢協(xié)議表ID：1
    "formula": "avg_cost_time", // 查詢公式：求平均
    "keys": [
        // 查詢條件：維度xxx_id=3
        {"field": "xxx_id", "relation": "eq", "value": "3"}
    ],
    "start_time": "2020-04-15 13:23", // 查詢起始時間
    "end_time": "2020-04-17 12:00" // 查詢結(jié)束時間
}

其中 biz_id、 formula,、keys 了每個查詢的基本條件。但每個查詢各不相同，不是這次討論的重點。

本次優(yōu)化的重點是基于查詢時間范圍的子查詢分解，而對于時間序列子查詢分解的方案則是按照「天」來分解，每個查詢都會得到當天的全部數(shù)據(jù)，由業(yè)務邏輯層來進行合并。

舉個例子，04-15 13:23 ～ 04-17 08:20 的查詢，會被分解為 04-15、04-16、04-17 三個子查詢，每個查詢都會得到當天的全部數(shù)據(jù)，在業(yè)務邏輯層找到基于用戶查詢時間的偏移量，處理結(jié)果并返回給用戶。

每個子查詢都會先嘗試獲取緩存中的數(shù)據(jù)，此時有兩種結(jié)果：

結(jié)果

解析

緩存未命中

如果子查詢結(jié)果在緩存中不存在，即 cache miss。只需要將調(diào)用 DruidBorker 獲取數(shù)據(jù)，異步寫入緩存中，同時該子查詢緩存的修改的時間即可。

緩存命中

在談論命中之前，首先引入一個概念「閾值時間(threshold_time)」。它表示緩存更新前的一段時間（一般為10min）。我們默認緩存中的數(shù)據(jù)是不被信任的，因為可能因為數(shù)據(jù)積壓等情況導致一部分數(shù)據(jù)延遲入庫。

如果子查詢命中了緩存，則存在兩種情況：「緩存部分命中」和「緩存完全命中」。其中部分命中如下圖所示。

緩存部分被命中：

end_time > cache_update_time - threshold_time：這種情況說明了「緩存部分被命中」，從 cache_update_time-thresold_time 到 end_time 這段時間都不可信，這段不可信的數(shù)據(jù)需要從 DruidBroker 中查詢，并且在獲取到數(shù)據(jù)后異步回寫緩存，更新 update 時間。

緩存完全命中：
而緩存完全命中則是種理想形式：end_time > cache_update_time - threshold_time。這種情況說明了緩存被完全命中，緩存中的數(shù)據(jù)都可以被相信，這種情況下直接拿出來就可以了。

經(jīng)過上述分析不難看出：對于距離現(xiàn)在超過一天的查詢，只需要查詢一次，之后就無需訪問 DruidBroker 了，可以直接從緩存中獲取。

而對于一些實時熱數(shù)據(jù)，其實只是查詢了
cache_update_time-threshold_time 到 end_time 這一小段的時間。在實際應用里，這段查詢時間的跨度基本上在 20min 內(nèi)，而 15min 內(nèi)的數(shù)據(jù)由 Druid 實時節(jié)點提供。

3.2.2 維度組合子查詢設計

維度枚舉查詢和時間序列查詢不一樣的是：每一分鐘，每個維度的量都不一樣。而維度枚舉拿到的是各個維度組合在任意時間的總量，因此基于上述時間序列的緩存方法無法使用。在這里，核心思路依然是打散查詢和緩存。對此，微信團隊使用了如下方案：

緩存的設計采用了多級冗余模式，即每天的數(shù)據(jù)會根據(jù)不同時間粒度：天級、4小時級、1 小時級存多份，從而適應各種粒度的查詢，也同時盡量減少和 Redis 的 IO 次數(shù)。

每個查詢都會被分解為 N 個子查詢，跨度不同時間，這個過程的粗略示意圖如下：

舉個例子：例如 04-15 13:23 ～ 04-17 08:20 的查詢，會被分解為以下 10 個子查詢：

04-15 13:23 ～ 04-15 14:00

04-15 14:00 ～ 04-15 15:00

04-15 15:00 ～ 04-15 16:00

04-15 16:00 ～ 04-15 20:00

04-15 20:00 ～ 04-16 00:00

04-16 00:00 ～ 04-17 00:00

04-17 00:00 ～ 04-17 04:00

04-17 04:00 ～ 04-17 08:00

04-17 08:00 ～ 04-17 08:20

這里可以發(fā)現(xiàn)，查詢 1 和查詢 10，絕對不可能出現(xiàn)在緩存中。因此這兩個查詢一定會被轉(zhuǎn)發(fā)到 Druid 去進行。2～9 查詢，則是先嘗試訪問緩存。如果緩存中不存在，才會訪問 DruidBroker，在完成一次訪問后將數(shù)據(jù)異步回寫到 Redis 中。

維度枚舉查詢和時間序列一樣，同時也用了 update_time 作為數(shù)據(jù)可信度的保障。因為最細粒度為小時，在理想狀況下一個時間跨越很長的請求，實際上訪問 Druid 的最多只有跨越 2h 內(nèi)的兩個首尾部查詢而已。

3.3 更進一步-子維度表

通過子查詢緩存方案，我們已經(jīng)限制了 I/O 次數(shù)，并且保障 90% 的請求都來自于緩存。但是維度組合復雜的協(xié)議，即 Segments 過大的協(xié)議，仍然會消耗大量時間用于檢索數(shù)據(jù)。

所以核心問題在于：能否進一步降低 Segments 大小？

維度爆炸問題在業(yè)界都沒有很好的解決方案，大家要做的也只能是盡可能規(guī)避它，因此這里，團隊在查詢層實現(xiàn)了子維度表的拆分以盡可能解決這個問題，用空間換時間，具體做法為：

● 對于維度復雜的協(xié)議，抽離命中率高的低基數(shù)維度，建立子維度表，實時消費并入庫數(shù)據(jù)。

● 查詢層支持按照用戶請求中的查詢維度，匹配最小的子維度表。

優(yōu)化成果

4.1 緩存命中率>85%

在做完所有改造后，最重要的一點便是緩存命中率。因為大部分的請求來自于1天前的歷史數(shù)據(jù)，這為緩存命中率提供了保障：

子查詢緩存完全命中率（無需查詢Druid）：86%
子查詢緩存部分命中率（秩序查詢增量數(shù)據(jù)）：98.8%

最明顯的效果就是，查詢訪問 Druid 的請求，下降到了原來的 10% 左右。

4.2 查詢耗時優(yōu)化至 100ms

在整體優(yōu)化過后，查詢性能指標有了很大的提升：

平均耗時 1000+ms -> 140ms；P95：5000+ms -> 220ms。

結(jié)語

微信多維指標監(jiān)控平臺，是微信監(jiān)控平臺的重要組成部分。在分析了用戶數(shù)據(jù)查詢行為之后，我們找到了數(shù)據(jù)查詢慢的主要原因，通過減少單 Broker 的大跨度時間查詢、減少 Druid 的 Segments I/O 次數(shù)、減少 Segments 的大小。我們實現(xiàn)了緩存命中率>85%、查詢耗時優(yōu)化至 100ms。當然，系統(tǒng)功能目前也或多或少尚有不足，在未來團隊會繼續(xù)探索前行，力求使其覆蓋更多的場景，提供更好的服務。

以上是本次分享全部內(nèi)容，歡迎大家在評論區(qū)分享交流。如果覺得內(nèi)容有用，歡迎轉(zhuǎn)發(fā)～

作者:仇弈彬

來源:微信公眾號:騰訊云開發(fā)者

出處
:https://mp.weixin.qq.com/s/_hqYCY-ySKxSkYNC5WXH2g