本篇文章詳細(xì)講述了七云團(tuán)隊在運(yùn)維平臺中如何利用 TDengine 解決海量時序數(shù)據(jù)存儲與查詢的實(shí)際業(yè)務(wù)需求。內(nèi)容涵蓋了從數(shù)據(jù)庫選型、方案落地到業(yè)務(wù)挑戰(zhàn)及解決辦法的完整過程，特別是分享了升級 TDengine 3.x 時的實(shí)戰(zhàn)經(jīng)驗(yàn)，給到有需要的小伙伴參考閱讀。

此前，我?guī)ьI(lǐng)的團(tuán)隊負(fù)責(zé)過一個 AIOps 項(xiàng)目，核心任務(wù)是存儲和查詢大量時序數(shù)據(jù)，包括各種系統(tǒng)和性能指標(biāo)。經(jīng)過深入調(diào)研，我們最終選擇了 TDengine 作為指標(biāo)數(shù)據(jù)的存儲引擎。目前，相關(guān)業(yè)務(wù)已穩(wěn)定運(yùn)行數(shù)年。本文將重點(diǎn)分享我們?nèi)绾卫?TDengine 實(shí)現(xiàn)業(yè)務(wù)落地，以及過程中遇到的挑戰(zhàn)與解決方案。

項(xiàng)目介紹

在展開分享之前，我先簡單介紹一下指標(biāo)采集業(yè)務(wù)和 TDengine，以便幫助大家更好地理解背景和技術(shù)選型。

1. 指標(biāo)采集業(yè)務(wù)

在運(yùn)維平臺中，核心的三大基礎(chǔ)功能包括：采集、監(jiān)控和告警。采集是首要環(huán)節(jié)，需要通過多種方式將服務(wù)器、應(yīng)用等關(guān)鍵指標(biāo)數(shù)據(jù)匯集到平臺中，隨后實(shí)現(xiàn)監(jiān)控圖表展示、告警策略觸發(fā)等一系列運(yùn)維操作。

2. TDengine

TDengine 是一款開源、高性能、云原生的時序數(shù)據(jù)庫。它針對物聯(lián)網(wǎng)、車聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)、金融和 IT 運(yùn)維等場景進(jìn)行了專門優(yōu)化設(shè)計，同時集成了緩存、流式計算、數(shù)據(jù)訂閱等系統(tǒng)功能。這些特性不僅顯著降低了系統(tǒng)設(shè)計的復(fù)雜度，還有效減少了研發(fā)和運(yùn)維成本，是一個極簡高效的時序數(shù)據(jù)處理平臺。

為什么選擇 TDengine

由于采集業(yè)務(wù)的點(diǎn)位眾多且頻率較高，數(shù)據(jù)存儲需要處理高并發(fā)的寫入（TPS）和監(jiān)控、告警等場景下較高的查詢并發(fā)（QPS）。因此，選擇一個高性能、時序化、且易于橫向擴(kuò)展的數(shù)據(jù)存儲引擎是必然的需求。

在調(diào)研了常見的時序數(shù)據(jù)庫解決方案（如 InfluxDB、TimescaleDB、OpenTSDB 和 TDengine）后，我們最終選擇了 TDengine，主要基于以下幾點(diǎn)考慮：

1. 設(shè)計理念契合

TDengine 的設(shè)計高度貼合我們的數(shù)據(jù)采集需求：每個設(shè)備對應(yīng)一張超級表，每個指標(biāo)對應(yīng)一張子表。這種設(shè)計極大簡化了數(shù)據(jù)存儲和管理的復(fù)雜度，讓我們能夠更高效地組織和處理數(shù)據(jù)。

2. 卓越的性能表現(xiàn)

在性能方面，TDengine 明顯優(yōu)于其他主流時序數(shù)據(jù)庫。我們參考了官方文檔中基于 TSBS 標(biāo)準(zhǔn)數(shù)據(jù)集的測試報告，數(shù)據(jù)顯示 TDengine 在寫入和查詢性能上都具有顯著優(yōu)勢。

報告鏈接：http://m.fjzmyy.cn/performance-comparison-influxdb-and-timescaledb-vs-tdengine

3. 強(qiáng)大的分布式架構(gòu)

TDengine 從設(shè)計之初便以分布式高可靠架構(gòu)為核心，具備天然的橫向擴(kuò)展能力。正如官方文檔所述：

TDengine 的設(shè)計是基于單個硬件、軟件系統(tǒng)不可靠，基于任何單臺計算機(jī)都無法提供足夠計算能力和存儲能力處理海量數(shù)據(jù)的假設(shè)進(jìn)行設(shè)計的。因此 TDengine 從研發(fā)的第一天起，就按照分布式高可靠架構(gòu)進(jìn)行設(shè)計，是支持水平擴(kuò)展的，這樣任何單臺或多臺服務(wù)器發(fā)生硬件故障或軟件錯誤都不影響系統(tǒng)的可用性和可靠性。同時，通過節(jié)點(diǎn)虛擬化并輔以負(fù)載均衡技術(shù)，TDengine 能最高效率地利用異構(gòu)集群中的計算和存儲資源降低硬件投資。

業(yè)務(wù)落地方案

1. 庫設(shè)計

我們采用以用戶為單位進(jìn)行庫的拆分，每個用戶對應(yīng)一個獨(dú)立的數(shù)據(jù)庫。在創(chuàng)建庫時，建議對相關(guān)參數(shù)進(jìn)行手動指定，確保對每個配置項(xiàng)的含義和用途有明確的了解。使用默認(rèn)配置可能在未來使用中因缺乏規(guī)劃而引發(fā)問題。

如果庫中的表數(shù)量非常多，建議適當(dāng)增加 vgroup 參數(shù)的值（默認(rèn)僅為 2）。合理規(guī)劃 vgroup 的數(shù)量，可以有效提高系統(tǒng)性能并降低后續(xù)擴(kuò)展和維護(hù)的復(fù)雜性。

2. 表設(shè)計

我們的設(shè)計方案是一個設(shè)備創(chuàng)建一張超級表，一個指標(biāo)創(chuàng)建一張子表。

3. 集群方案

根據(jù)不同業(yè)務(wù)體量我們劃分了不同的集群設(shè)施，我以其中一個集群的要求舉例說明：

•   寫入TPS大約在3w/s
•   查詢QPS大約在1k/s
•   單條指標(biāo)數(shù)據(jù)的大小約為0.5KB
•   庫中存儲的數(shù)據(jù)保留1年

在容量規(guī)劃上，我們主要參考了官方提供的規(guī)劃方案——https://docs.taosdata.com/operation/planning/

做了下面的規(guī)劃內(nèi)容：

• 內(nèi)存規(guī)劃

官方推薦的計算公式：vgroups × replica × (buffer + pages × pagesize + cachesize) 參數(shù)對號入座，10 * 1 * (32MB + 256MB * 4KB + 1MB) = 340MB 還需要再加上 OS 自身的一些內(nèi)存消耗，并且冗余一定的 buffer 空間。我們最終每臺節(jié)點(diǎn)分配了 8GB 內(nèi)存。

• CPU 規(guī)劃

我們來大概計算一下數(shù)據(jù)分片 & 數(shù)據(jù)寫入所需要的 CPU 資源：3w/s ÷ 單核1w/s = 3，即只考慮寫入請求次數(shù)（每次寫入只寫1條數(shù)據(jù)，無批量寫入）只需要 3 個 CPU 核心即可。再給幾個用來滿足查詢需求的計算資源冗余，并且保持 CPU 使用率不超過 50%，我們最終每臺節(jié)點(diǎn)分配了 8 個 CPU 核心。

• 磁盤規(guī)劃

在不考慮 TDengine 對落盤數(shù)據(jù)進(jìn)行壓縮的情況下，那么每秒的寫入速率是 30000/s * 0.5KB = 15000KB/s，約等于 14.65MB/s，這個數(shù)量級的磁盤 IO，哪怕是機(jī)械硬盤也很容易滿足性能要求，所以只需要保證磁盤總量足夠即可。我們最終每臺節(jié)點(diǎn)先給了 500GB 的數(shù)據(jù)盤，隨著數(shù)據(jù)的增長還在擴(kuò)容。

• 網(wǎng)絡(luò)帶寬規(guī)劃

由于業(yè)務(wù)與服務(wù)器均部署在同一內(nèi)網(wǎng)環(huán)境中，數(shù)據(jù)傳輸可以直接使用內(nèi)網(wǎng)帶寬。根據(jù)上述寫入速率計算，集群間的流量需求完全可以由常見的千兆網(wǎng)卡輕松滿足，無需額外升級網(wǎng)絡(luò)配置。

• 節(jié)點(diǎn)數(shù)量規(guī)劃

我們根據(jù)多個 vgroup 的資源需求，對總資源進(jìn)行了均衡分配，同時在生產(chǎn)環(huán)境中預(yù)留了充分的冗余。最終選用了 3 臺配置為 8 核 CPU / 8 GB 內(nèi)存 / 500 GB 存儲 的服務(wù)器，確保系統(tǒng)的高可用性和穩(wěn)定性。

自制小工具：TD-GUI

基于 TDengine 提供的 REST-API，我開發(fā)了一款便捷的查詢小工具，專為業(yè)務(wù)需求設(shè)計。同事們在實(shí)際工作中廣泛使用這一工具，大大提升了工作效率，并獲得了普遍好評。其實(shí)現(xiàn)原理非常簡單：通過拼接 SQL 請求，利用 REST-API 向 TDengine 發(fā)送查詢請求并解析響應(yīng)結(jié)果。雖然工具設(shè)計輕量，但在實(shí)際應(yīng)用中展現(xiàn)了強(qiáng)大的實(shí)用性。

遇到的挑戰(zhàn)&解決辦法

1. 老版本集群 2.x 存在庫、表信息異常的現(xiàn)象

在使用 TDengine 2.x 集群時，我們偶爾會遇到庫和表信息異常的現(xiàn)象。經(jīng)過反饋至開源社區(qū)，問題可能源于元數(shù)據(jù)管理的 Bug。短期解決方案是重啟 TDengine 恢復(fù)正常運(yùn)行，長期是通過升級到 3.x 版本徹底解決了問題，目前已不再復(fù)現(xiàn)。

2. 老版本集群 2.x 遷移至新版本 3.x

由于 2.x 和 3.x 版本之間存在不兼容情況，遷移需要將 2.x 數(shù)據(jù)導(dǎo)出后重新導(dǎo)入至 3.x 集群。然而，面對 2.x 的海量數(shù)據(jù)，導(dǎo)出速度和數(shù)量難以接受，同時還需保證生產(chǎn)系統(tǒng)正常運(yùn)行。我們采用了數(shù)據(jù)雙寫策略：新上報的數(shù)據(jù)同時寫入 2.x 和 3.x 兩套集群，并通過后臺程序逐步將 2.x 的歷史數(shù)據(jù)讀取并寫入到 3.x 集群，最終實(shí)現(xiàn)了數(shù)據(jù)的平滑遷移。

在雙寫過程中，我們開發(fā)了一個后臺程序，從 2.x 集群中逐步讀取歷史數(shù)據(jù)，并慢慢寫入到 3.x 集群，實(shí)現(xiàn)了對 2.x 的平滑替換。最終，順利完成了版本遷移。這種方法不僅保證了生產(chǎn)系統(tǒng)的正常運(yùn)行，還有效規(guī)避了 2.x 和 3.x 數(shù)據(jù)格式不兼容的問題。升級到 3.x 后，我們還遇到了一些小問題，簡單總結(jié)如下：

1. 老代碼與新版本兼容性問題遷移過程中，部分代碼需要調(diào)整。例如，由于 value 成為保留關(guān)鍵字，如果字段名為 value，則在 SQL 中需要使用反引號進(jìn)行引用。不過，這類問題對整體遷移影響不大。
2. 新版本配置項(xiàng)變動問題雖然 3.x 的大部分配置項(xiàng)與 2.x 基本相同或相似，但仍存在一些細(xì)微差異。經(jīng)過適當(dāng)調(diào)整后，對業(yè)務(wù)運(yùn)行未造成實(shí)質(zhì)性影響。

結(jié)語

通過實(shí)踐，我們成功將 TDengine 應(yīng)用于高頻時序數(shù)據(jù)的存儲與查詢，并在版本遷移和性能優(yōu)化中積累了豐富的經(jīng)驗(yàn)。這不僅幫助我們提升了業(yè)務(wù)系統(tǒng)的穩(wěn)定性和效率，也驗(yàn)證了 TDengine 在應(yīng)對復(fù)雜運(yùn)維場景時的強(qiáng)大能力。希望我們的經(jīng)驗(yàn)?zāi)転楦嗉夹g(shù)團(tuán)隊提供有價值的參考，共同探索時序數(shù)據(jù)處理的無限可能。

關(guān)于七云網(wǎng)絡(luò)

七云網(wǎng)絡(luò)（上海疊念信息科技有限公司）于 2017 年 1 月份成立于上海，是一家創(chuàng)新型 SDWAN 及網(wǎng)絡(luò)運(yùn)維解決方案服務(wù)商。企業(yè)核心成員源自阿里巴巴、思科、中國電信等技術(shù)型企業(yè)，擁有豐富的互聯(lián)網(wǎng)及企業(yè)信息化服務(wù)的經(jīng)驗(yàn)。

關(guān)于作者

王凱（kaamil Wang），七云網(wǎng)絡(luò) AIOps 產(chǎn)品部主管，熱愛開源，立志成為一名 IT 武林高手。