本篇文章詳細講述了七云團(tuan)隊(dui)在運維平臺中(zhong)如何利用 TDengine 解決海量(liang)時序(xu)數(shu)據存儲與查(cha)詢的(de)(de)實際業務(wu)需求(qiu)。內容涵蓋了從數(shu)據庫選型(xing)、方案(an)落地到業務(wu)挑戰(zhan)及解決辦法的(de)(de)完整過程，特別(bie)是分享了升級 TDengine 3.x 時的(de)(de)實戰(zhan)經(jing)驗，給到有需要的(de)(de)小伙伴參考閱讀。

此前，我(wo)(wo)帶領(ling)的(de)(de)團隊負責過(guo)一個 AIOps 項目，核心任務(wu)是存儲和查(cha)詢(xun)大(da)量時(shi)序數據，包括(kuo)各種系(xi)統和性(xing)能指(zhi)(zhi)標。經過(guo)深(shen)入(ru)調(diao)研(yan)，我(wo)(wo)們最終選擇了 TDengine 作(zuo)為指(zhi)(zhi)標數據的(de)(de)存儲引擎。目前，相(xiang)關業務(wu)已(yi)穩定(ding)運(yun)行數年(nian)。本(ben)文將重點分享我(wo)(wo)們如(ru)何利用 TDengine 實現業務(wu)落地，以及過(guo)程(cheng)中遇到的(de)(de)挑戰與解決方(fang)案(an)。

項目介紹

在展開(kai)分享之前，我先簡單介紹一下(xia)指標采集業務和 TDengine，以便幫助大家(jia)更好地理解背景(jing)和技術選型。

1. 指標采集業務

在運維平臺中，核心的三大基礎功能包括：采集、監控和告警。采集(ji)是(shi)首要(yao)環節，需要(yao)通(tong)過多(duo)種(zhong)方式(shi)將(jiang)服務(wu)器、應用等關鍵(jian)指標數據匯集(ji)到平臺中，隨后(hou)實現監(jian)控圖表展示(shi)、告警策略觸發等一系列運維操作。

2. TDengine

TDengine 是一款開源、高性能、云原生的時序數據庫。它針對物聯網、車聯網、工業互聯網、金融和(he) IT 運(yun)維(wei)等(deng)場景進(jin)行了專門優化設(she)計(ji)(ji)，同時集成(cheng)了緩存(cun)、流式(shi)計(ji)(ji)算、數(shu)據訂閱等(deng)系(xi)統(tong)功能。這些特性不僅顯著(zhu)降低(di)了系(xi)統(tong)設(she)計(ji)(ji)的(de)復雜度，還有(you)效減(jian)少了研發和(he)運(yun)維(wei)成(cheng)本，是一個(ge)極簡(jian)高(gao)效的(de)時序數(shu)據處理平臺。

為什么選擇 TDengine

由于采集業務的點位眾多且頻率較高，數據存儲需要處理高并發的寫入（TPS）和監控、告警等場景下較高的查詢并發（QPS）。因此，選擇一個高性能、時序化、且易于橫向擴展的(de)數(shu)據(ju)存儲引(yin)擎是必然的(de)需求。

在調研了常見的時序數據(ju)庫解(jie)決方案（如(ru) InfluxDB、TimescaleDB、OpenTSDB 和(he) TDengine）后，我們最終(zhong)選擇了 TDengine，主要基于以下幾點考慮：

1. 設計理念契合

TDengine 的(de)設計高度貼合我(wo)們(men)的(de)數據(ju)采集需求：每個(ge)設備對(dui)應(ying)一(yi)張超級(ji)表(biao)，每個(ge)指標對(dui)應(ying)一(yi)張子表(biao)。這種設計極大簡化了(le)數據(ju)存儲和管理(li)的(de)復雜度，讓我(wo)們(men)能夠更高效地組織和處理(li)數據(ju)。

2. 卓越的性能表現

在性能方面(mian)，TDengine 明顯優于其他主流(liu)時序數據(ju)庫。我們參考了官(guan)方文(wen)檔中基于 TSBS 標準數據(ju)集的測試報告，數據(ju)顯示(shi) TDengine 在寫(xie)入和查詢性能上都具有顯著優勢。

報告鏈接：//yakult-sh.com.cn/performance-comparison-influxdb-and-timescaledb-vs-tdengine

3. 強大的分布式架構

TDengine 從設(she)計之(zhi)初(chu)便以分布式高可靠架構為核心(xin)，具備天然(ran)的橫向擴展能力(li)。正如官方文檔(dang)所述(shu)：

TDengine 的(de)(de)(de)設(she)(she)計(ji)(ji)(ji)是基于(yu)單個硬(ying)(ying)件(jian)、軟件(jian)系統不可(ke)靠(kao)，基于(yu)任(ren)何單臺(tai)計(ji)(ji)(ji)算機都無法(fa)提供足夠(gou)計(ji)(ji)(ji)算能力(li)和存(cun)儲能力(li)處理海(hai)量數(shu)據的(de)(de)(de)假設(she)(she)進(jin)行設(she)(she)計(ji)(ji)(ji)的(de)(de)(de)。因(yin)此(ci) TDengine 從研發的(de)(de)(de)第一天起，就(jiu)按照分布式高可(ke)靠(kao)架構進(jin)行設(she)(she)計(ji)(ji)(ji)，是支持水平擴展的(de)(de)(de)，這樣(yang)任(ren)何單臺(tai)或多臺(tai)服務器發生硬(ying)(ying)件(jian)故障或軟件(jian)錯誤都不影響系統的(de)(de)(de)可(ke)用(yong)(yong)性和可(ke)靠(kao)性。同時(shi)，通(tong)過節點虛擬化并(bing)輔以負載(zai)均衡技術，TDengine 能最高效率地利用(yong)(yong)異構集(ji)群(qun)中的(de)(de)(de)計(ji)(ji)(ji)算和存(cun)儲資源降低硬(ying)(ying)件(jian)投資。

業務落地方案

1. 庫設計

我們采(cai)用以用戶為單位進行庫的(de)拆分，每個(ge)(ge)用戶對(dui)應(ying)一(yi)個(ge)(ge)獨立的(de)數據庫。在創建庫時(shi)，建議對(dui)相關(guan)參數進行手動指(zhi)定，確(que)(que)保對(dui)每個(ge)(ge)配(pei)置項的(de)含義和(he)用途有明(ming)確(que)(que)的(de)了解。使(shi)(shi)用默(mo)認配(pei)置可能在未來使(shi)(shi)用中(zhong)因缺乏規劃而引發問題。

如果庫(ku)中的(de)(de)表數量非(fei)常多，建(jian)議適(shi)當增加 vgroup 參數的(de)(de)值（默認僅為 2）。合理(li)規劃 vgroup 的(de)(de)數量，可(ke)以有效提高系統(tong)性能并降(jiang)低(di)后續擴(kuo)展和維護的(de)(de)復雜性。

2. 表設計

我(wo)們(men)的(de)設計方(fang)案是一(yi)個設備創建一(yi)張(zhang)超級表，一(yi)個指標創建一(yi)張(zhang)子(zi)表。

3. 集群方案

根據(ju)不(bu)同(tong)業務體(ti)量我(wo)們(men)劃分了不(bu)同(tong)的(de)集群設施，我(wo)以(yi)其中一個集群的(de)要求舉例說明：

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

在(zai)容量(liang)規(gui)(gui)劃上，我(wo)們主要參考(kao)了官方提供的規(gui)(gui)劃方案——

做了下面的規劃內容：

• 內存規劃

官方推(tui)薦(jian)的(de)計算公式(shi)：vgroups × replica × (buffer + pages × pagesize + cachesize) 參(can)數對號入座，10 * 1 * (32MB + 256MB * 4KB + 1MB) = 340MB 還需要再加上 OS 自身的(de)一(yi)些內存消(xiao)耗(hao)，并(bing)且冗余一(yi)定的(de) buffer 空(kong)間。我們最終每臺節點分配了(le) 8GB 內存。

• CPU 規劃

我們(men)(men)來大概計算(suan)一下數(shu)(shu)據(ju)(ju)分片 & 數(shu)(shu)據(ju)(ju)寫(xie)入(ru)(ru)所需(xu)要(yao)的 CPU 資(zi)源：3w/s ÷ 單核(he)(he)1w/s = 3，即只考(kao)慮寫(xie)入(ru)(ru)請(qing)求次數(shu)(shu)（每次寫(xie)入(ru)(ru)只寫(xie)1條數(shu)(shu)據(ju)(ju)，無批量寫(xie)入(ru)(ru)）只需(xu)要(yao) 3 個 CPU 核(he)(he)心(xin)即可(ke)。再給幾個用來滿足(zu)查詢需(xu)求的計算(suan)資(zi)源冗余，并(bing)且保(bao)持(chi) CPU 使用率不超過 50%，我們(men)(men)最(zui)終(zhong)每臺節點分配了 8 個 CPU 核(he)(he)心(xin)。

• 磁盤規劃

在不(bu)考慮 TDengine 對(dui)落盤(pan)數據進行壓(ya)縮的(de)情(qing)況下(xia)，那么每秒的(de)寫入(ru)速(su)率是 30000/s * 0.5KB = 15000KB/s，約(yue)等(deng)于 14.65MB/s，這(zhe)個(ge)數量級(ji)的(de)磁盤(pan) IO，哪怕是機械硬盤(pan)也很容(rong)易滿足性能要(yao)求，所以只需要(yao)保證磁盤(pan)總量足夠即可。我(wo)們最(zui)終每臺(tai)節點先給(gei)了 500GB 的(de)數據盤(pan)，隨著數據的(de)增長還在擴容(rong)。

• 網絡帶寬規劃

由(you)于業(ye)務與服務器均部署在同一內網環境中，數據(ju)傳輸可以直接使用(yong)內網帶寬。根(gen)據(ju)上述寫入速率計算，集群間(jian)的流量需(xu)求完全(quan)可以由(you)常見的千兆(zhao)網卡輕(qing)松滿足，無需(xu)額(e)外升級網絡配(pei)置。

• 節點數量規劃

我們根據多(duo)個 vgroup 的(de)資(zi)源需求(qiu)，對總資(zi)源進行(xing)了(le)均衡分(fen)(fen)配(pei)，同(tong)時(shi)在生產環境中預留了(le)充分(fen)(fen)的(de)冗余。最(zui)終選用(yong)了(le) 3 臺配(pei)置(zhi)為(wei) 8 核 CPU / 8 GB 內存(cun) / 500 GB 存(cun)儲 的(de)服務器(qi)，確保系統(tong)的(de)高(gao)可(ke)用(yong)性和穩定性。

自制小工具：TD-GUI

基于 TDengine 提供的 REST-API，我(wo)開發了(le)一(yi)款便(bian)捷的查詢小工(gong)具(ju)(ju)，專為業務(wu)需(xu)求(qiu)設計(ji)。同事們在(zai)實際工(gong)作中廣(guang)泛(fan)使用這一(yi)工(gong)具(ju)(ju)，大(da)大(da)提升了(le)工(gong)作效(xiao)率，并(bing)獲(huo)得了(le)普(pu)遍好評。其(qi)實現原理非常簡單(dan)：通過拼接 SQL 請求(qiu)，利用 REST-API 向 TDengine 發送(song)查詢請求(qiu)并(bing)解(jie)析響應結果(guo)。雖然(ran)工(gong)具(ju)(ju)設計(ji)輕量，但(dan)在(zai)實際應用中展現了(le)強大(da)的實用性(xing)。

遇到的挑戰&解決辦法

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

在(zai)使用 TDengine 2.x 集群時，我們偶爾會遇到庫(ku)和表信息異(yi)常的(de)現(xian)象。經過反饋至開源社區，問(wen)題可(ke)能(neng)源于元數據管理的(de) Bug。短期解(jie)決(jue)(jue)方案(an)是重啟 TDengine 恢復正常運行，長期是通過升級到 3.x 版本(ben)徹底解(jie)決(jue)(jue)了問(wen)題，目前已(yi)不再(zai)復現(xian)。

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

由于 2.x 和(he) 3.x 版本之(zhi)間存(cun)在不兼(jian)容情況，遷移需要將 2.x 數據(ju)導出后重新導入至 3.x 集(ji)群(qun)。然(ran)而，面(mian)對 2.x 的海量數據(ju)，導出速度和(he)數量難以接(jie)受，同(tong)時還需保證(zheng)生產系統正(zheng)常運(yun)行。我們采(cai)用了數據(ju)雙寫策略：新上報(bao)的數據(ju)同(tong)時寫入 2.x 和(he) 3.x 兩套集(ji)群(qun)，并(bing)通過后臺(tai)程序(xu)逐步(bu)將 2.x 的歷史數據(ju)讀取并(bing)寫入到 3.x 集(ji)群(qun)，最終實現了數據(ju)的平滑遷移。

在雙寫過(guo)程中，我(wo)們開發了(le)一(yi)個(ge)后臺程序，從 2.x 集群(qun)中逐步(bu)讀取歷(li)史數(shu)據，并慢(man)慢(man)寫入到 3.x 集群(qun)，實(shi)現(xian)了(le)對 2.x 的平滑替換。最終，順利完成了(le)版(ban)本(ben)遷移。這種方法不僅保(bao)證了(le)生(sheng)產系(xi)統的正常運行，還有效規避了(le) 2.x 和 3.x 數(shu)據格(ge)式不兼容(rong)的問題。升級到 3.x 后，我(wo)們還遇到了(le)一(yi)些小(xiao)問題，簡(jian)單總結如(ru)下：

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

結語

通過實(shi)踐，我們(men)(men)成功將 TDengine 應用(yong)于高頻時(shi)(shi)序(xu)數據(ju)(ju)的(de)存儲(chu)與查詢，并在(zai)版(ban)本遷(qian)移和性(xing)能優化中積(ji)累了豐富的(de)經(jing)驗(yan)。這不(bu)僅幫助我們(men)(men)提升了業務(wu)系(xi)統的(de)穩定性(xing)和效率，也(ye)驗(yan)證了 TDengine 在(zai)應對(dui)復雜(za)運(yun)維場景時(shi)(shi)的(de)強大能力。希望我們(men)(men)的(de)經(jing)驗(yan)能為更多技術團隊提供有(you)價值的(de)參(can)考，共同探索時(shi)(shi)序(xu)數據(ju)(ju)處理的(de)無限可能。

關于七云網絡

七云網(wang)絡（上(shang)海疊念信(xin)(xin)息科(ke)技有限公司(si)）于 2017 年 1 月份成立于上(shang)海，是一家創新型 SDWAN 及(ji)(ji)網(wang)絡運維解決方案服務商。企(qi)業(ye)核心(xin)成員(yuan)源自(zi)阿(a)里巴巴、思科(ke)、中國電信(xin)(xin)等技術型企(qi)業(ye)，擁有豐富的互聯網(wang)及(ji)(ji)企(qi)業(ye)信(xin)(xin)息化服務的經驗。

關于作者

王凱(kai)（kaamil Wang），七(qi)云網(wang)絡 AIOps 產品部主管，熱愛(ai)開(kai)源，立志成為一名 IT 武林高手。