【融雲分析】從過剩儲存資源到分散式時序資料庫的長儲存

背景介紹：

作為一名 Infra，管理平臺的各種基礎組建以及基本的服務質量是必修的功課，而如何對複雜和繁多的基礎平臺，甚至包括上面執行的 Ops 系統、業務系統，其穩定性的各項指標都是衡量 Infra 是否稱職的非常重要的標準。

單純離散的指標本身是沒有實際意義的，只有將離散的指標透過某種方式進行儲存，並支援對終端使用者友好的查詢以及聚合，才會真正的有意義。因此，一個效能足夠的，分散式的，使用者友好且方便下面 DevOps 團隊進行部署的 TSDB ( Time Series Database )就成了一個不可缺少的系統。

常見的 TSDB 包括 InfluxDB , OpenTSDB , Prometheus 等，其中，開源版本的 InfluxDB 雖然優秀，但並不支援叢集部署，且 TICK Stack 本身對資料清洗的靈活性支援並不太好，直接使用開源版本，會有統計資訊被收集並上報；而 OpenTSDB 由於基於 HBase ，在部署時成本過高，且本身並不是一套完整的監控系統，而基於 Prometheus 與 TiKV 進行開發的話，整個系統可在保持最簡潔的同時，也有非常豐富的生態支援。

因此，基於實際情況，融雲最終選擇 TiPrometheus 作為 Infra 部的監控平臺儲存方案。

專案簡介：

上圖為 Prometheus 的官方系統架構圖，而實現 TiPrometheus ，用到了上圖中沒有體現到的一個 Prometheus 的功能：Remote Storage ，如其名所示，其主要功能是給 Prometheus 提供了遠端寫的能力，這個功能對於查詢是透明的，主要用於長儲存。而我們當時的 TiPrometheus 實現了基於 TiKV 以及 PD 實現的 Prometheus 的 Remote Storage 。

核心實現

Prometheus 記錄的資料結構分為兩部分 Label 及 Samples 。 Label 記錄了一些特徵資訊，Samples 包含了指標資料和 Timestamp 。

Label 和時間範圍結合，可以查詢到需要的 Value 。

為了查詢這些記錄，需要構建兩種索引 Label Index 和 Time Index ，並以特殊的 Key 儲存 Value 。

l Label Index

每對 Label 為會以 index:label:<name>#<latency> 為 key ，labelID 為 Value 存入。新的記錄會 "," 分割追加到 Value 後面。這是一種搜尋中常用的倒排索引。

l Time Index

每個 Sample 項會以 index:timeseries:<labelID>:<splitTime> 為 Key，Timestamp 為 Value ，SplitTime 為時間切片的起始點。追加的 Timestamp 同樣以","分割。

l Doc 儲存

我們將每一條 Samples 記錄以 timeseries:doc:<labelID>:<timestamp> 為 Key 存入 TiKV ，其中 LabelID 是 Label 全文的雜湊值。

下面做一個梳理：

寫入過程

1. 生成 labelID

2. 構建 time index，index:timeseries:<labelID>:<splitTime>"ts,ts"

3. 寫入時序資料 timeseries:doc:<labelID>:<timestamp> "value"

4. 寫入時序資料 timeseries:doc:<labelID>:<timestamp> "value"

查詢過程

1. 根據倒排索引查出 labelID 的集合，多對 Label 的查詢會對 labelID 集合求交集。

2. 根據 labelID 和時間範圍內的時間分片查詢包含的 Timestamp 。

3. 根據 labelID 和 Timestamp 查出所需的 Value 。

Why TiPrometheus

該專案最初源於參加 PingCAP 組織的 Hackathon ，當時希望與參與者一起完成大家腦海裡的想法，其實最重要的事情就是，做出來的東西並不是為了單純的 Demo ，而是要做一個在實際工作中應用於生產環境的實際能力，且能解決生產中的問題。

剛開始還有過各種奇思妙想，包括在 TiSpark 上做一套 ML ，Hadoop over TiKV 等，不過這些想法實現起來都有些過於硬核，對於只有兩天工作時間就需要完成的專案來說，可能性太小；或者說，如果希望實現 Demo ，所需 Hack 的點過多。而 GEO 全文檢索在融雲現有的生產上，以及現有的系統中，也並沒有需要去填補的大坑，因此，也就沒有什麼必要去在這方面花費力氣去解決一個並不存在的問題。

由於 IM 服務是一種計算密集型的服務，且服務質量是融雲的核心競爭力；而目前儲存資源呈現出零散分佈的節點，且每個節點的儲存資源使用率並不高，為了最大化利用現有的閒置資源，融雲最終設計並實現了這套 TiPrometheus 系統。

Result

打通了 TiKV 與 Prometheus ，為基於 K , V 儲存的時序資料庫設計提供了一個可行的思路。

為 Prometheus 的長儲存提供了一套實用的解決方案。