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

背景介紹：

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