【融雲分析】從過剩存儲資源到分布式時序數據庫的長存儲
作為一名 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 全文的散列值。
下面做一個梳理：
寫入過程
-
生成 labelID
-
構建 time index，index:timeseries:<labelID>:<splitTime>"ts,ts"
-
寫入時序數據 timeseries:doc:<labelID>:<timestamp> "value"
- 寫入時序數據 timeseries:doc:<labelID>:<timestamp> "value"
查詢過程
-
根據倒排索引查出 labelID 的集合，多對 Label 的查詢會對 labelID 集合求交集。
-
根據 labelID 和時間範圍內的時間分片查詢包含的 Timestamp 。
- 根據 labelID 和 Timestamp 查出所需的 Value 。
Why TiPrometheus
該項目最初源於參加 PingCAP 組織的 Hackathon ，當時希望與參與者一起完成大家腦海裏的想法，其實最重要的事情就是，做出來的東西並不是為了單純的 Demo ，而是要做一個在實際工作中應用於生產環境的實際能力，且能解決生產中的問題。
剛開始還有過各種奇思妙想，包括在 TiSpark 上做一套 ML ，Hadoop over TiKV 等，不過這些想法實現起來都有些過於硬核，對於只有兩天工作時間就需要完成的項目來說，可能性太小；或者說，如果希望實現 Demo ，所需 Hack 的點過多。而 GEO 全文檢索在融雲現有的生產上，以及現有的系統中，也並沒有需要去填補的大坑，因此，也就沒有什麽必要去在這方面花費力氣去解決一個並不存在的問題。
由於 IM 服務是一種計算密集型的服務，且服務質量是融雲的核心競爭力；而目前存儲資源呈現出零散分布的節點，且每個節點的存儲資源使用率並不高，為了最大化利用現有的閑置資源，融雲最終設計並實現了這套 TiPrometheus 系統。
Result
打通了 TiKV 與 Prometheus ，為基於 K , V 存儲的時序數據庫設計提供了一個可行的思路。
為 Prometheus 的長存儲提供了一套實用的解決方案。
【融雲分析】從過剩存儲資源到分布式時序數據庫的長存儲