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

關(guān)于中移物聯(lián)網(wǎng)：

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

業(yè)務(wù)背景：

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

在調(diào)研中我們發(fā)現(xiàn)，智慧出行軌跡數(shù)據(jù)的特點天然適合 TDengine ：

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

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

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

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

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

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

3.0 使用體驗：

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

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

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

建模設(shè)計：

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

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

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

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.車輛事件：四急( 急加速  急減速 急剎車  急轉(zhuǎn)彎)

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. 汽車總線數(shù)據(jù)：

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));

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

未來展望：

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

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

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

最后，祝 TDengine 越來越好，最終成為時序數(shù)據(jù)庫的事實標(biāo)準(zhǔn)。

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