作為一家業(yè)務遍及多個國家及地區(qū)的物流公司，貨拉拉面臨的技術環(huán)境是非常復雜的，在云時代浪潮下基于混合云快速構建環(huán)境搭建系統(tǒng)成為其必然的選擇。但是在混合云上如何對基于各家云構建的系統(tǒng)進行有效的管理是個挑戰(zhàn)，尤其對處于系統(tǒng)最底層的數據庫層面臨的問題、業(yè)務訴求、各方痛點，是貨拉拉DBA團隊現下所需要重點解決的。

目前DBA團隊管理的數據存儲包括MySQL、Redis、Elasticsearch、Kafka、MQ、Canal等，為了保證監(jiān)控采樣的實時性，我們自研的監(jiān)控系統(tǒng)設置的采樣間隔為10秒，這樣每天都會產生龐大的監(jiān)控數據，監(jiān)控指標的數據量達到20億+。前期由于管理實例少，監(jiān)控數據量也少，所有數據都被存放到了MySQL中；之后隨著管理實例越來越多，使用MySQL來存儲規(guī)模日益龐大的監(jiān)控數據越發(fā)力不從心，急需進行升級改造。結合實際具體需求，通過對不同時序數據庫進行調研，最終我們選擇了TDengine，順利完成了數據存儲監(jiān)控的升級改造。

一、監(jiān)控系統(tǒng)開發(fā)中遇到的問題

從存儲路徑來看，每種數據存儲都分布在多個區(qū)域，每個區(qū)域將監(jiān)控采樣數據投遞上報到消息總線，然后由消費程序統(tǒng)?消費，消費程序會將必要的告警數據更新到告警表，同時將監(jiān)控原始數據存儲到MySQL。比如，針對Redis這款數據存儲，監(jiān)控采樣間隔設置10秒，那么每天實例采樣次數就會達到3000萬+，監(jiān)控指標累計6億+，數據量之龐大可見一斑。早期為了將數據存儲到MySQL中，同時也能很好地支持監(jiān)控繪圖的使用，每?次實例監(jiān)控采樣時都會計算出該實例全量監(jiān)控項采樣數據，然后將本次采樣的結果作為?條記錄存儲下來。

即使通過這樣的優(yōu)化處理，在做時間跨度大的監(jiān)控繪圖時，前端依然會出現延遲卡頓的問題，后端監(jiān)控數據存儲的MySQL也壓力山大，經常滿載，天天被吐槽。因此針對這種時間跨度大的查詢，我們專門開發(fā)了?系列的數據聚合調度任務——按照不同的時間跨度，提前將10秒采集間隔的監(jiān)控數據做好聚合，監(jiān)控繪圖程序再根據不同的時間跨度選取不同的聚合數據表繪圖，以此解決長時間跨度監(jiān)控繪圖展示延遲卡頓的問題。

但這仍然治標不治本。為了壓縮監(jiān)控數據存儲空間，原始10秒間隔的監(jiān)控數據表只能歸檔保留3天時間的監(jiān)控數據，但存儲大小也將近有200GB，加上與之相關的不同時間段的數據聚合表，存儲一下子突破300GB。這還只是Redis監(jiān)控數據的存儲大小，加上其它數據存儲的監(jiān)控數據，至少需要1TB+空間的MySQL存儲。

數據集合任務管理復雜、后期監(jiān)控原數據回溯缺失、MySQL存儲空間日益增長帶來的隱患，都是亟待解決的問題。

二、時序數據庫選型

為了解決MySQL監(jiān)控數據存儲的問題，我們把注意力轉移到了適合存儲監(jiān)控數據的時序數據庫上。市面上各種時序數據庫產品琳瑯滿目，有老牌的，也有后起之秀，經過?系列調研選型，我們選擇了時序數據庫TDengine，主要是因為其具備的如下幾大優(yōu)點：

·采用分布式架構，可支持線性擴展

·數據存儲壓縮率超高

·集群模式支持多副本，無單點故障

·單機模式性能強悍

·安裝部署維護簡單

·SQL?持

·時間維度聚合查詢

·客戶端支持RESTful API

值得一提的是，TDengine的SQL原生語法支持時間維度聚合查詢，同時數據存儲壓縮率?存儲空間小，這兩點直接切中了我們的痛點。落地后實測相同數據的存儲空間只有MySQL存儲空間的十分之?甚至更少。還有?個驚喜是，在現有監(jiān)控數據存儲(MySQL)頂不住的情況下，?臺8C16GB的單機版TDengine輕松就抗下目前所有監(jiān)控流量和存儲壓力，且運行穩(wěn)定，基本沒有故障。

三、改造過程

TDengine用于存儲監(jiān)控數據的超級表設計原則就是簡單高效，字段?般都比較少，每?種監(jiān)控項類型(INT、FLOAT、NCHAR等)的數據存儲都需要單獨建立?個超級表，超級表?般都有關鍵的ts、type、value字段，具體監(jiān)控項由type字段標識，加上必要的tag及少量其它字段構成。

之前監(jiān)控數據存儲在MySQL的時候，每條數據記錄包含了該實例?次監(jiān)控采樣的所有監(jiān)控項(25+)數據。如果采用通用的監(jiān)控超級表設計原則，就需要改造采樣的數據結構，改造方式有兩種：

·改造監(jiān)控數據投遞的數據結構

·改造消費程序消費邏輯重組數據結構

但消費端有時效性要求，改造難度大，生產端涉及范圍大阻力也不小。經過綜合考量，最后我們決定采用類似MySQL數據存儲的表結構來設計超級表，這樣的改造對原來系統(tǒng)入侵最少，改造難度系數最低，改造大致過程如下：

·TDengine，每種數據存儲的監(jiān)控數據單獨建庫存放

1.taos>create database redis;

2.taos>create database es;

3..........

·TDengine，建超級表，以Redis為例

1.taos>useredis;

2.taos>create table redis_node_meters(created_at TIMESTAMP,qps INT,...)TAGS(region NCHAR(10),cluster_name NCHAR(50),ip NCHAR(20),port INT,role NCHAR(15));

·監(jiān)控數據消費，由于新增的實例節(jié)點是不確定的，比如Redis的節(jié)點資源是由Agent自動發(fā)現注冊后自動進行監(jiān)控指標采集，這時寫入數據并不確定某個子表是否存在，就需要TDengine的自動建表語法來創(chuàng)建不存在的子表，若該子表已存在則不會建立新表只會寫入數據。

1.taos>INTO tablename USING redis_node_meters TAGS('China','t est','127.0.0.3',9200,'master')VALUES('2021-12-02 14:21:14',6490,...)

·繪圖展示，繪圖程序沒有安裝客戶端驅動，直接使用了TDengine提供的RESTful API，采用HTTP的方式進行數據查詢。在SQL查詢上大量使用了TDengine提供的時間維度聚合函數INTERVAL，長時間跨度的數據查詢，只需要合理選擇聚合間隔，基本都是毫秒級響應，保障了前端繪圖的流暢穩(wěn)定。

四、改造后的落地效果

將監(jiān)控的數據存儲由MySQL改造為TDengine后，不僅頂住了監(jiān)控數據增長所帶來的壓力，還節(jié)約了存儲空間，成本壓縮到了原來的十分之?甚至更低。歷史原生監(jiān)控數據可回溯時間也變得更長，之前存儲3天原生數據及聚合數據的空間，現在可供原始數據存儲45天。

此外，改造之后不再需要維護復雜的數據聚合調度任務，大幅降低了監(jiān)控系統(tǒng)、監(jiān)控數據管理復雜度，同時前端繪圖數據查詢也變得更加簡潔高效。

五、寫在最后

隨著對TDengine越發(fā)深入的了解及經驗累積，后續(xù)我們也會逐步考慮將貨拉拉大監(jiān)控系統(tǒng)、業(yè)務數據（行車軌跡）等時序數據均遷移至TDengine。為了方便有需要的朋友更好地使用TDengine，在此也分享一下我們的一些使用經驗：

·由于TDengine不支持太復雜的SQL查詢語法，在設計超級表tag的時候需要充分考慮清楚，目前只有tag的字段支持函數運算結果的分組(GROUP BY)查詢，普通字段是不支持的。

·子表tag的值是可以改變的，但是同?個子表tag的值是唯?的，建議用子表tag的組合值來生成子表名。

在本次項目中，TDengine很好地幫助我們實現了降本增效，是一款值得嘗試的時序數據庫產品，未來也希望其能夠發(fā)揮出越來越豐富的功能和特性，也期待我們之后能有更緊密深入的合作。