滴滴的時(shí)序曲線量從 2017 年 到 2023 年增長(zhǎng)了幾十倍。整個(gè)過程中我們不斷地調(diào)整和改進(jìn)以應(yīng)對(duì)這樣的增長(zhǎng)。例如時(shí)序數(shù)據(jù)庫的選型從最初的 InfluxDB，到 RRDtool，又開發(fā)了內(nèi)存 TSDB 分擔(dān)查詢壓力，再到 2020 年開始使用 VictoriaMetrics。載體也從全公司最高配的物理機(jī)型到現(xiàn)在的全容器部署。其中經(jīng)歷了很多的思考和取舍，下文將按時(shí)間順序，為大家講述這一系列的故事。

2017年 InfluxDB 時(shí)代

時(shí)序數(shù)據(jù)庫的一哥 InfluxDB，是我們最初選擇的時(shí)序數(shù)據(jù)庫。但隨著時(shí)序曲線的規(guī)模變大，InfluxDB 的局限性也開始暴露了出來。同時(shí)社區(qū)中關(guān)于 InfluxDB OOM 的討論也日益增多，其根本原因就在于熱點(diǎn)寫入和查詢，想象一個(gè)命中幾百萬曲線的查詢落在了一個(gè) InfluxDB 實(shí)例上，OOM 幾乎是必然的。大家也可以在 InfluxDB 社區(qū)中搜索 OOM，有 400 多個(gè)結(jié)果“InfluxDB OOM”。

由于這些問題日益突出，我們不得不重新思考時(shí)序數(shù)據(jù)庫的選型。下圖為當(dāng)時(shí)的可觀測(cè)系統(tǒng)在 Influxdb 掛掉后，看圖功能的表現(xiàn)：

InfluxDBOOM，看圖功能的表現(xiàn)

2017～2018 Open-Falcon 時(shí)代

InfluxDB 單機(jī)性能有限，集群方案又不開放。盡管我們對(duì) InfluxDB 按照業(yè)務(wù)線做了拆分，但仍面臨著單個(gè)服務(wù)節(jié)點(diǎn)曲線量巨大的情況，對(duì)于 InfluxDB 來說難以處理。

在經(jīng)過深入探索和多次試驗(yàn)后，我們決定采用 Open-Falcon 使用的 RRDtool 存儲(chǔ)方案，在存儲(chǔ)和查詢鏈路，使用相同的一致性哈希算法，將曲線打散到不同的實(shí)例中，從而解決了在 InfluxDB 時(shí)代因?yàn)闊狳c(diǎn)過高而導(dǎo)致 OOM 的難題。

2018～2020 后 Open-Falcon 時(shí)代

直至 2018 年 4月，RRDtool 方案都一直在滴滴運(yùn)行著。但隨著曲線量的迅速增長(zhǎng)，我們又面臨新的問題——成本問題。成本幾乎是每家互聯(lián)網(wǎng)公司在發(fā)展到一定階段都難以回避的問題。特別是作為非贏利產(chǎn)品的可觀測(cè)平臺(tái)，成本問題尤為突出。甚至自 2017 年之后的三年里，盡管我們的存儲(chǔ)集群內(nèi)存使用率曾高達(dá) 90% 以上，仍無法獲取新機(jī)器的支援。其中一個(gè)原因是，我們需要的機(jī)器配置過高，甚至連當(dāng)時(shí)配備的 NVMe 磁盤這種頂配機(jī)型的 IO 使用率也超過了 90%。預(yù)算委員會(huì)完全不相信會(huì)有一種服務(wù)同時(shí)對(duì) CPU、內(nèi)存和 IO 都有如此高的需求。

面對(duì)這種困境，我們陷入了兩難境地。一方面是用戶源源不斷的壓力，另一方面是無法滿足存儲(chǔ)所需求機(jī)型的要求。

在經(jīng)過一段時(shí)間的思考與調(diào)研，我們發(fā)現(xiàn) 80% 以上的查詢請(qǐng)求都集中在最新的 2 個(gè)小時(shí)內(nèi)。因此，我們嘗試將存儲(chǔ)進(jìn)行冷熱分層，建設(shè)一個(gè)新服務(wù)來分擔(dān)存儲(chǔ)的壓力，正好在這個(gè)時(shí)候，我們了解到了 Facebook Gorilla 的論文，于是一個(gè)名為 Cacheserver 服務(wù)應(yīng)運(yùn)而生。

Cacheserver 的設(shè)計(jì)靈感來源于 Facebook Gorilla 論文，旨在與原有存儲(chǔ)服務(wù)共同承擔(dān)請(qǐng)求，只針對(duì)最新 2 小時(shí)數(shù)據(jù)的查詢請(qǐng)求，大大減輕了 RRDtool 服務(wù)集群的壓力。這種冷熱分層的架構(gòu)不僅緩解了存儲(chǔ)成本問題，還提升了整體性能和查詢效率。

Cacheserver 架構(gòu)

2020 ～ 今 VictoriaMetrics 時(shí)代

隨著滴滴容器時(shí)代的到來，我們面臨著更加艱巨的情況。

首先，隨著容器覆蓋率的不斷提高，時(shí)序曲線量瘋狂增長(zhǎng)。而 2020 年隨著容器覆蓋率繼續(xù)提升，曲線增長(zhǎng)預(yù)計(jì)會(huì)超過 100%。

此外，成本壓力繼續(xù)增大。盡管 RRDtool 架構(gòu)可以橫向擴(kuò)展，但可觀測(cè)自身的成本無法再隨業(yè)務(wù)增長(zhǎng)而線性增長(zhǎng)。

當(dāng)前 RRDtool 架構(gòu)高需低產(chǎn)，必須使用 SSD/NVMe 機(jī)型，使用普通磁盤在落盤時(shí)會(huì)直接 hang 死。而且功能上也僅支持 sum、avg、max、min 等有限的幾個(gè)函數(shù)，無法滿足用戶日趨豐富的需求。

為節(jié)省存儲(chǔ)空間，當(dāng)時(shí)僅保留 2 小時(shí)原始數(shù)據(jù)。而用戶需要更長(zhǎng)時(shí)間（例如 15天）的原始數(shù)據(jù)進(jìn)行查看和分析，然而，更改降采策略會(huì)帶來 2 個(gè)問題：一是 RRDtool 的降采修改會(huì)導(dǎo)致所有數(shù)據(jù)丟失。二是存儲(chǔ) 15 天的原始點(diǎn)會(huì)使每條曲線存儲(chǔ)空間變?yōu)樵瓉淼?8.5 倍（120KB → 1MB）。

因此從 2020 年初開始，我們開始著手調(diào)研新的方案。需要更高效、靈活的存儲(chǔ)架構(gòu)以應(yīng)對(duì)以上種種問題。

有哪些備選方案？

在選擇新的存儲(chǔ)方案時(shí)，我們考慮了多個(gè)備選方案，包括：

Druid

Prometheus

Thanos/Cortex

M3

VictoriaMetrics

Druid？

Druid 是滴滴另一套系統(tǒng) Woater 的時(shí)序存儲(chǔ)方案，由大數(shù)據(jù)團(tuán)隊(duì)運(yùn)維。然而，我們最終不考慮 Druid，主要原因如下：

模型不滿足：Woater 的存儲(chǔ)模型是預(yù)先定義好的 Schema（Dimensions），而我們需要的是動(dòng)態(tài) Schema，這是 Druid 原生不支持的，雖然大數(shù)據(jù)團(tuán)隊(duì)表示可以開發(fā)支持，但有著諸多條件限制。

成本問題：將現(xiàn)有數(shù)據(jù)存儲(chǔ)到 Druid 成本將增長(zhǎng) 10 倍。

性能問題：Druid 寫入性能還不如 RRDtool，寫入能力較差，因?yàn)?Druid 要做 Rollup，而 RRDtool 是直接 Append 數(shù)據(jù)。

“無用”的 Rollup：Druid 的亮點(diǎn)功能 Rollup，對(duì)于我們的場(chǎng)景并不適用，因?yàn)榻^大部分查詢都是針對(duì)原始值而非 Rollup 結(jié)果。

Prometheus？

Prometheus 是可觀測(cè)領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，其存儲(chǔ)模型、DSL 以及生態(tài)都吸引著眾多用戶和企業(yè)的關(guān)注。但在滴滴的場(chǎng)景下，我們也沒有選擇 Prometheus，主要原因在于：

沒有長(zhǎng)期存儲(chǔ)：Prometheus 主要專注于對(duì)短期數(shù)據(jù)的存儲(chǔ)和查詢，而我們需要長(zhǎng)期保留。

沒有集群方案：Prometheus 無內(nèi)置的集群方案，要實(shí)現(xiàn)橫向擴(kuò)展，需要依賴第三方架構(gòu)如 Thanos、Cortex 等，這無疑增加了復(fù)雜性。

沒有高可用能力。

盡管針對(duì)這些問題，社區(qū)提供了一些解決方案，但在滴滴的體量下，這些解決方案都無法滿足我們的生產(chǎn)化需求。

Thanos、Cortex?

Thanos 和 Cortex 可以說是 Prometheus 當(dāng)時(shí)唯二的，集群化和長(zhǎng)期存儲(chǔ)方案。它們的設(shè)計(jì)目標(biāo)都是要解決如下問題：

Global View：可以跨多個(gè) Prometheus 實(shí)例進(jìn)行查詢以實(shí)現(xiàn)全局視圖。

Long Term Storage：實(shí)現(xiàn)長(zhǎng)期存儲(chǔ)以滿足長(zhǎng)期分析和回溯的需求。

High Availability。

這些特性使得 Thanos 和 Cortex 成為 Prometheus 生態(tài)中重要的補(bǔ)充。

Thanos 架構(gòu)

Cortex 架構(gòu)

但 Thanos/Cortex 也存在一些問題：

Cortex 的存儲(chǔ)結(jié)構(gòu)，其內(nèi)部仍在探索當(dāng)中，還不夠穩(wěn)定，Blocks 在當(dāng)時(shí)還處于 Experimental 狀態(tài)。

Thanos 和 Cortex 均需要引入對(duì)象存儲(chǔ)，可能帶來一些額外的管理成本，性能上也要畫一個(gè)問號(hào)。

Thanos Remote Read 內(nèi)存開銷太多，例如當(dāng)時(shí)有人提出如下圖所示的問題：

Thanos 內(nèi)存問題

缺乏大規(guī)模生產(chǎn)環(huán)境的洗禮：Thanos 和 Cortex，這兩個(gè)看似美好的解決方案，都有他們的硬傷。也缺乏大規(guī)模生產(chǎn)環(huán)境的實(shí)際驗(yàn)證，可靠性和穩(wěn)定性可能還需更多的驗(yàn)證和優(yōu)化。

Uber M3?

M3 是 Uber 開源的 TSDB 解決方案，盡管有一些優(yōu)勢(shì)，但也存在一些缺點(diǎn)，包括管理成本高（例如引入 etcd）和機(jī)器成本沒有優(yōu)勢(shì)（仍需要高配 SSD）。

M3 架構(gòu)

VictoriaMetrics？

Victoriametrics 架構(gòu)

VictoriaMetrics 是一個(gè)性能高、資源要求和運(yùn)維成本都比較時(shí)序數(shù)據(jù)庫，其主要特色和原理包括：

要求資源低：VictoriaMetrics 可以在普通機(jī)型上運(yùn)行，不需要使用 SSD/NVMe 等高性能硬件。

核心存儲(chǔ)模型：基于 LSM，類似 Clickhouse。它將數(shù)據(jù)緩沖在內(nèi)存中，并每秒鐘將其刷寫到磁盤上的分區(qū)目錄中。較小的分區(qū)會(huì)在后臺(tái)逐漸合并成更大的分區(qū)。

列式存儲(chǔ)：VictoriaMetrics 采用列式存儲(chǔ)，使得讀寫性能非常高，1個(gè)CPU核心可以掃描 30M points/s。

寫入速度強(qiáng)：?jiǎn)螌?shí)例 760K point/s 的寫能力（vs RRDtool 210～260K point/s）。

壓縮：采用改進(jìn)版 Gorilla 結(jié)合通用壓縮算法（Facebook zstd），平均僅需 1.2～1.5 bytes/point，壓縮比達(dá) 13%。

集群容易擴(kuò)展：采用 Share Nothing 設(shè)計(jì)。擴(kuò)縮容機(jī)器方便。機(jī)器損壞時(shí)還可以自動(dòng) Rerouting。

無降采樣：不降采的設(shè)計(jì)，使得原始數(shù)據(jù)得以保留。

兼容 Prometheus：在寫入、寫入方式等都兼容 Prometheues。并針對(duì) PromQL 做了增強(qiáng)（MetricsQL）

亂序時(shí)間戳的弱支持。

容量可計(jì)算：VictoriaMetrics 的容量是可計(jì)算的，我們可以更直觀和方便的預(yù)估存儲(chǔ)需求。

VictoriaMetrics Capacity Planning

如上所述，因?yàn)?VictoriaMetrics 在性能、壓縮率、查詢速度和擴(kuò)展性等方面表現(xiàn)出色。在綜合考慮了各個(gè)方面的需求和考慮后，我們認(rèn)為 VictoriaMetrics 是適合我們的時(shí)序數(shù)據(jù)存儲(chǔ)方案，能夠滿足我們的需求。

VictoriaMetrics 的問題及解決方案

盡管 VictoriaMetrics 作為時(shí)序數(shù)據(jù)庫解決方案有許多優(yōu)勢(shì)，但也存在一些潛在問題，這里列舉幾點(diǎn)并簡(jiǎn)要地給出了我們的解決方案：

資源占用問題：磁盤空間占用量與存儲(chǔ)點(diǎn)數(shù)成正比，存儲(chǔ)越多越長(zhǎng)的數(shù)據(jù)，磁盤空間需求越多。為解決這個(gè)問題，我們針對(duì)不同的業(yè)務(wù)線，設(shè)置了不同的保留時(shí)長(zhǎng)。

無降采樣：VictoriaMetrics 不支持?jǐn)?shù)據(jù)降采樣，即不會(huì)自動(dòng)對(duì)數(shù)據(jù)進(jìn)行聚合或丟棄，而是保留原始數(shù)據(jù)。這在某些場(chǎng)景下可能會(huì)導(dǎo)致數(shù)據(jù)存儲(chǔ)需求較高，特別是在存儲(chǔ)長(zhǎng)期數(shù)據(jù)時(shí)。不過，由于 VictoriaMetrics 查詢速度快且壓縮率較高，這個(gè)問題并沒有對(duì)成本和系統(tǒng)性能造成顯著影響。

活躍度有限、不夠主流：相對(duì)于其他一些主流的時(shí)序存儲(chǔ)方案，當(dāng)時(shí) VictoriaMetrics 的活躍度可能還不夠高。然而，通過對(duì)代碼的深入了解和與作者的多次交流，我們對(duì)VictoriaMetrics 的質(zhì)量和性能表現(xiàn)逐漸建立信心。

多集群 VictoriaMetrics 設(shè)計(jì)

我們基于 VictoriaMetrics 設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)多集群方案，旨在提高系統(tǒng)的可擴(kuò)展性和可用性。例如下圖我們?cè)?region 1 搭建了多套集群，分別處理不同業(yè)務(wù)線的數(shù)據(jù)，隔離了各業(yè)務(wù)線的資源競(jìng)爭(zhēng)和影響，也縮小了故障域。多個(gè) region 之間也可以選擇 mixer 來實(shí)現(xiàn)跨區(qū)域的數(shù)據(jù)讀取和合并。

VictoriaMetrics 多集群設(shè)計(jì)

結(jié)尾

以上介紹了滴滴可觀測(cè)的時(shí)序存儲(chǔ)解決方案的發(fā)展歷程。希望通過這個(gè)分享，能夠?yàn)槠渌麍F(tuán)隊(duì)和開發(fā)者提供一些有益的經(jīng)驗(yàn)和啟示，也歡迎一起交流和探討。

限于文章篇幅，無法在這里展開更多。例如 VictoriaMetrics 的容器化部署，故障管理，復(fù)制，數(shù)據(jù)遷移等。這些內(nèi)容將在后續(xù)的文章中為大家介紹，敬請(qǐng)期待！