【融云分析】從過剩存儲資源到分布式時序數據庫的長存儲

背景介紹：

作為一名 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 的長存儲提供了一套實用的解決方案。