可觀測平臺如何存儲時序曲線？滴滴實踐全歷程分享

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

2017年 InfluxDB 時代

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

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

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

2017～2018 Open-Falcon 時代

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

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

2018～2020 后 Open-Falcon 時代

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

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

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

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

Cacheserver 架構(gòu)

2020 ～ 今 VictoriaMetrics 時代

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

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

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

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

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

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

有哪些備選方案？

在選擇新的存儲方案時，我們考慮了多個備選方案，包括：

Druid

Prometheus

Thanos/Cortex

M3

VictoriaMetrics

Druid？

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

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

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

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

“無用”的 Rollup：Druid 的亮點功能 Rollup，對于我們的場景并不適用，因為絕大部分查詢都是針對原始值而非 Rollup 結(jié)果。

Prometheus？

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

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

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

沒有高可用能力。

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

Thanos、Cortex?

Thanos 和 Cortex 可以說是 Prometheus 當時唯二的，集群化和長期存儲方案。它們的設(shè)計目標都是要解決如下問題：

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

Long Term Storage：實現(xiàn)長期存儲以滿足長期分析和回溯的需求。

High Availability。

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

Thanos 架構(gòu)

Cortex 架構(gòu)

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

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

Thanos 和 Cortex 均需要引入對象存儲，可能帶來一些額外的管理成本，性能上也要畫一個問號。

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

Thanos 內(nèi)存問題

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

Uber M3?

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

M3 架構(gòu)

VictoriaMetrics？

Victoriametrics 架構(gòu)

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

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

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

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

寫入速度強：單實例 760K point/s 的寫能力（vs RRDtool 210～260K point/s）。

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

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

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

兼容 Prometheus：在寫入、寫入方式等都兼容 Prometheues。并針對 PromQL 做了增強（MetricsQL）

亂序時間戳的弱支持。

容量可計算：VictoriaMetrics 的容量是可計算的，我們可以更直觀和方便的預估存儲需求。

VictoriaMetrics Capacity Planning

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

VictoriaMetrics 的問題及解決方案

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

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

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

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

多集群 VictoriaMetrics 設(shè)計

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

VictoriaMetrics 多集群設(shè)計

結(jié)尾

以上介紹了滴滴可觀測的時序存儲解決方案的發(fā)展歷程。希望通過這個分享，能夠為其他團隊和開發(fā)者提供一些有益的經(jīng)驗和啟示，也歡迎一起交流和探討。

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