小T導讀：在中移物聯網的智慧出行場景中，需要存儲車聯網設備的軌跡點，還要支持對車輛軌跡進行查詢。為了更好地進行數據處理，他們在 2021 年上線了 TDengine 2.0 版本的 5 節(jié)點 3 副本集群。 3.0 發(fā)布后，它的眾多特性吸引著中移物聯網進行了大版本升級。本文詳細分享了中移物聯網在 3.0 項目的業(yè)務實踐和全新體驗，以此給大家作參考。

關于中移物聯網：

中移物聯網有限公司是中國移動通信集團有限公司出資成立的全資子公司。公司按照中國移動整體戰(zhàn)略布局，圍繞“物聯網業(yè)務服務的支撐者、專用模組和芯片的提供者、物聯網專用產品的推動者”的戰(zhàn)略定位，專業(yè)化運營物聯網專用網絡，設計生產物聯網專用模組和芯片，打造智慧出行、智能家居、智能穿戴等特色產品，開發(fā)運營物聯網連接管理平臺 OneLink 和物聯網開放平臺 OneNET，推廣物聯網解決方案，形成了五大方向業(yè)務布局和物聯網“云-網-邊-端 ”全方位的體系架構。

業(yè)務背景：

智慧出行是中移物聯網的一個非常典型的場景，我們需要存儲車聯網設備的軌跡點，還要支持對軌跡進行查詢。最初我們使用的是 Oracle 小型機單表分區(qū)存儲數據，運維復雜不便管理。2017 年，響應集團去 IOE 的要求，該項目開始使用 MySQL 集群。2019 年，產品提出了更高的數據存儲需求，我們又開始調研國產數據庫 TiDB，但由于其存儲成本過高，不適合軌跡存儲這種低價值的數據，而且不能解決行業(yè)客戶軌跡數據存儲周期定制化的需要，因此我們開始繼續(xù)調研新的存儲方案——國產開源時序數據庫 （Time Series Database）TDengine 就是這個時候進入了我們的視野。

在調研中我們發(fā)現，智慧出行軌跡數據的特點天然適合 TDengine ：

• 高頻寫入，每天寫入約兩億條軌跡數據；
• 低頻查詢，通常是由用戶觸發(fā)，查詢最近幾天的軌跡；
• 企業(yè)用戶有定制軌跡存儲周期的需求；
• 不針對 OLAP 需求，數據價值密度低。

因此，在經歷了嚴謹的選型測試后，我們最終確定選擇 TDengine 作為新的數據存儲引擎。具體選型過程和項目歷史背景可以參考 2.x 版本的案例《存儲空間降為原來的1/7，TDengine在中移物聯網軌跡數據存儲中的應用》。

改造后系統(tǒng)的整體架構如下圖所示：

我們在 2021 年上線 TDengine 的 2.4.0.18 的 5 節(jié)點 3 副本集群穩(wěn)定運行至今。今年 3.0 發(fā)布后，它的眾多特性十分吸引我們，其中最典型的幾個包括：

1. Raft 協議的引入使 TDengine 擁有了更標準的一致性算法
2. 存儲引擎的重構優(yōu)化了 2.x 版本的設計
3. 查詢靈活度大幅提升，可實現的需求變得多元化
4. 支持更強大的流式計算

因此，盡管 2 – 3 版本底層數據文件并不兼容，我們還是自己寫了程序把數據遷移到了 3.0.2.5 版本，以至于后面官方正式發(fā)布了企業(yè)版遷移工具 taosX 的時候，我們早就先走一步了。

3.0 使用體驗：

TDengine 3.0 的安裝部署上保留了和 2.0 一樣的簡單易用模式，升級操作只需要備份數據文件目錄，覆蓋安裝即可，而且寫入速度極高，接近硬盤的連續(xù)寫入性能。TDengine 的高效壓縮算法，可以節(jié)省大量存儲空間，SQL 使用也非常簡單。在此前對 MySQL 方案的替換中，我們的存儲空間降為原來的 1/7，可以看到，在節(jié)省存儲空間方面，TDengine 的優(yōu)勢極為明顯。

目前我們共有 102 萬張子表，已經累積的總數據量已經達到了 2000 億行，3 副本，磁盤占用 3.1TB。在遷移到 TDengine 3.0 之后，各方面的表現依然非常不錯：業(yè)務的寫入峰值達到了 1.2-1.3w 行/s ，數據遷移的過程中可以達到 20w 行/s，這些情況下 TDengine 都可以輕松處理；存儲大約只有 MySQL 的 1/7；讀取數據性能也很突出，我們最常用的單設備單日查詢，可以在 0.1s 內返回結果。

我們當前使用的是 3.0.2.5 版本，但是由于業(yè)務本身不允許停機，所以沒辦法做離線升級。因此，后續(xù)會由 TDengine 企業(yè)版團隊協助我們在線升級至最新版本（當前最新版本為 3.0.5.1）。

建模設計：

在庫表設計上，我們運用了自動建表來寫入數據，每個終端設備產生的軌跡點位數據在第一次入庫的時候自動創(chuàng)建子表，這樣只需要建一個 database 和業(yè)務需求的超級表就可以了，省掉了數據入庫時的校驗和建表操作。

值得一提的是，在 2.x 時代，元數據是在管理節(jié)點上集中存儲的，因此在當時的版本中，自動建表的速度會受到單線程工作能力的制約，當時大概最高每秒只能創(chuàng)建 6000 個子表左右，不過當時我們也沒有這么高的建表頻率所以也沒有受到太大影響。經過重構之后，3.0 的元數據已經完全做到了分布式存儲，所有 vnode 都會獨立存儲自己表的元數據并處理寫入操作，所以自動建表的寫入效率已經大幅增加。

我們的超級表建表語句如下，可以給大家參考：

1.車輛歷史狀態(tài)、位置：

create stable device_statushis (pos_time TIMESTAMP,sample_time TIMESTAMP,record_time TIMESTAMP,online_status SMALLIN
T,alarm_status SMALLINT,pos_method SMALLINT,pos_precision SMALLINT,pos_longitude DOUBLE,pos_latitude DOUBLE,pos_altitude D
OUBLE,pos_speed FLOAT,pos_direction FLOAT,acc_forward FLOAT,acc_side FLOAT,acc_verticle FLOAT,rollover_level SMALLINT,powe
r_voltage FLOAT,acc_status SMALLINT,satellite_num SMALLINT) tags(device_id BINARY(32)) ;

2.車輛事件：四急( 急加速  急減速 急剎車  急轉彎)

CREATE STABLE `emg_info` (`pos_time` TIMESTAMP, `sample_time` TIMESTAMP, `record_time` TIMESTAMP, `duration` SMALLINT, `mid_interval` SMALLINT, `mid_number` SMALLINT, `pre_number` SMALLINT, `pre_interval` SMALLINT, `start_time` TIMESTAMP, `end_time` TIMESTAMP, `start_lat` DOUBLE, `end_lat` DOUBLE, `start_lng` DOUBLE, `end_lng` DOUBLE, `event_type` SMALLINT, `sample_info` NCHAR(2048), `parameter_type` NCHAR(10)) TAGS (`device_id` VARCHAR(32), `app_code` NCHAR(32));

3.GPS 信息：

CREATE STABLE `gps_info` (`pos_time` TIMESTAMP, `sample_time` TIMESTAMP, `record_time` TIMESTAMP, `online_status` SMALLINT, `alarm_status` SMALLINT, `pos_method` SMALLINT, `pos_precision` SMALLINT, `pos_longitude` DOUBLE, `pos_latitude` DOUBLE, `pos_altitude` DOUBLE, `pos_speed` FLOAT, `pos_direction` FLOAT, `acc_forward` FLOAT, `acc_side` FLOAT, `acc_verticle` FLOAT, `rollover_level` SMALLINT, `power_voltage` FLOAT, `acc_status` SMALLINT, `satellite_num` SMALLINT) TAGS (`device_id` VARCHAR(32), `app_code` NCHAR(32), `device_hash` INT);

4. 汽車總線數據：

CREATE STABLE `can_info` (`pos_time` TIMESTAMP, `sample_time` TIMESTAMP, `record_time` TIMESTAMP, `gas_pedal_position` FLOAT, `spark_angle` FLOAT, `total_fuel_consumption` INT, `storage_battery_voltage` FLOAT, `latest_engine_runtime` INT, `fuel_pressure` INT, `distance_after_mil` INT, `long_term_fuel_trim` FLOAT, `engine_rpm` INT, `intake_manifold_pressure` SMALLINT, `distance_total` INT, `engine_inlet_port_temp` SMALLINT, `calcu_load` TINYINT, `vehicle_speed` SMALLINT, `fuel_type` NCHAR(30), `area_code` INT) TAGS (`device_id` VARCHAR(32), `app_code` NCHAR(32));

在應用層，由于我們存儲的數據是車輛軌跡數據，因此會做很多關于車輛軌跡數據的分析，比如：熱點路線、軌跡段數據、停留點、行駛事件（急轉彎、急加速、急減速、車輛其它信息），但由于 TDengine 一直以來都是時序數據庫，并沒有地理信息相關的計算函數，所以在這塊我們自己寫了很多函數，通過 Spark 的 RDD 來進行了計算分析，最后再把分析后的數據返回給客戶端。

未來展望：

目前 TDengine 能夠很好地解決我們的需求，尤其是強大的存取能力是我們最滿意的地方。但近期我從官方人員處得知，從即將于 7 月份發(fā)布的 3.0.6.0 版本開始，TDengine 將提供全新的數據類型 geometry 用于點線面等幾何類型的存儲，并且會逐步提供一套符合 OGC(Open Geospatial Consortium) 標準的 SQL 函數，包括幾何輸入輸出、空間關系、幾何測量、集合操作和幾何處理等等。

其實通過我們觀察，還是有很多車聯網用戶對于軌跡分析有使用需求，如果 TDengine 可以完整支持到空間數據的處理，這樣我們的系統(tǒng)架構將會進一步簡化，連 Spark 都可以不用了，這就可以說是完全意義上地使用了 All in one 的時序數據處理引擎。

可惜的是，目前由于我們歷史數據的經緯度都是通過單獨列來存儲的，對于 Geometry 帶來的全新數據類型，我們龐大的歷史數據量和應用層是很難快速調整的，所以只能在測試環(huán)境應用，先逐漸試用起來。

最后，祝 TDengine 越來越好，最終成為時序數據庫的事實標準。

作者介紹： 薛超，中移物聯網數據庫運維高級工程師，10 年數據庫運維經歷，2017 年加入中移物聯網，負責智能硬件產品部數據庫相關工作，專注于數據庫優(yōu)化和推動架構演進；近年來主要研究國產新型數據庫，目前所在部門全部業(yè)務已經去“O”，在此過程中，積累了大量新型數據庫的運維經驗。