小T導讀(du)：在中(zhong)移(yi)物聯(lian)網的(de)(de)(de)智慧出行(xing)場(chang)景(jing)中(zhong)，需要存儲(chu)車聯(lian)網設備的(de)(de)(de)軌跡點，還要支持(chi)對車輛軌跡進(jin)行(xing)查詢。為了(le)更好(hao)地進(jin)行(xing)數據處(chu)理，他們在 2021 年上線了(le) TDengine 2.0 版(ban)(ban)本(ben)(ben)的(de)(de)(de) 5 節點 3 副本(ben)(ben)集群。 3.0 發布后，它的(de)(de)(de)眾多特性吸(xi)引著中(zhong)移(yi)物聯(lian)網進(jin)行(xing)了(le)大(da)版(ban)(ban)本(ben)(ben)升(sheng)級。本(ben)(ben)文(wen)詳細分(fen)享了(le)中(zhong)移(yi)物聯(lian)網在 3.0 項目的(de)(de)(de)業務實踐和全新體(ti)驗，以此給大(da)家(jia)作(zuo)參考。
關于中移物聯網：
中(zhong)移(yi)物(wu)聯(lian)(lian)(lian)網有(you)限公(gong)司是中(zhong)國(guo)移(yi)動通信集團有(you)限公(gong)司出(chu)資成立(li)的全資子公(gong)司。公(gong)司按照中(zhong)國(guo)移(yi)動整體(ti)戰(zhan)略布局，圍繞“物(wu)聯(lian)(lian)(lian)網業(ye)務服務的支撐者(zhe)、專(zhuan)用(yong)模組和(he)芯(xin)片的提供者(zhe)、物(wu)聯(lian)(lian)(lian)網專(zhuan)用(yong)產(chan)(chan)品的推動者(zhe)”的戰(zhan)略定(ding)位(wei)(wei)，專(zhuan)業(ye)化運(yun)營物(wu)聯(lian)(lian)(lian)網專(zhuan)用(yong)網絡，設計生(sheng)產(chan)(chan)物(wu)聯(lian)(lian)(lian)網專(zhuan)用(yong)模組和(he)芯(xin)片，打造(zao)智(zhi)慧出(chu)行(xing)、智(zhi)能家居、智(zhi)能穿(chuan)戴(dai)等特色(se)產(chan)(chan)品，開發運(yun)營物(wu)聯(lian)(lian)(lian)網連接管理(li)平(ping)臺(tai)(tai) OneLink 和(he)物(wu)聯(lian)(lian)(lian)網開放平(ping)臺(tai)(tai) OneNET，推廣物(wu)聯(lian)(lian)(lian)網解決(jue)方案(an)，形成了五(wu)大(da)方向業(ye)務布局和(he)物(wu)聯(lian)(lian)(lian)網“云-網-邊-端 ”全方位(wei)(wei)的體(ti)系架構。
業務背景：
智慧出行是中移物聯網的一個非常典型的場景，我們需要存儲車聯網設備的軌跡點，還要支持對軌跡進行查詢。最初我們使用的是 Oracle 小型機單表分區存儲數據，運維復雜不便管理。2017 年，響應集團去 IOE 的要求，該項目開始使用 MySQL 集群。2019 年，產品提出了更高的數據存儲需求，我們又開始調研國產數據庫 TiDB，但由于其存儲成本過高，不適合軌跡存儲這種低價值的數據，而且不能解決行業客戶軌跡數據存儲周期定制化的需要，因此我們開始繼續調研新的存儲方案——國產開源時序數據庫 （Time Series Database）TDengine 就是這個時候進入了(le)我們的視野(ye)。
在調(diao)研中我(wo)們發現，智慧出行軌跡數據(ju)的特點(dian)天然適合 TDengine ：
- 高頻寫入，每天寫入約兩億條軌跡數據；
- 低頻查詢，通常是由用戶觸發，查詢最近幾天的軌跡；
- 企業用戶有定制軌跡存儲周期的需求；
- 不針對 OLAP 需求，數據價值密度低。
因此，在經(jing)歷了嚴謹(jin)的選(xuan)型測試后(hou)，我們(men)最(zui)終確定(ding)選(xuan)擇 TDengine 作為新(xin)的數據存(cun)儲引擎(qing)。具體(ti)選(xuan)型過(guo)程和項目歷史(shi)背景(jing)可以參考 2.x 版本(ben)的案(an)例(li)。
改造后系統的(de)整體架構(gou)如下圖所示：
我(wo)們(men)在(zai) 2021 年上線(xian) TDengine 的(de) 2.4.0.18 的(de) 5 節點 3 副本集(ji)群穩(wen)定運(yun)行(xing)至今。今年 3.0 發(fa)布后，它的(de)眾(zhong)多特(te)性十(shi)分吸引我(wo)們(men)，其中最(zui)典型的(de)幾個包括(kuo)：
- Raft 協議的引入使 TDengine 擁有了更標準的一致性算法
- 存儲引擎的重構優化了 2.x 版本的設計
- 查詢靈活度大幅提升，可實現的需求變得多元化
- 支持更強大的流式計算
因此，盡管(guan) 2 – 3 版(ban)本底層(ceng)數據文件并不兼(jian)容，我們還是自己寫了(le)程(cheng)序(xu)把數據遷移(yi)到了(le) 3.0.2.5 版(ban)本，以至于后面官方正式發布了(le)企(qi)業(ye)版(ban)遷移(yi)工具 taosX 的時候，我們早(zao)就先走一步了(le)。
3.0 使用體驗：
TDengine 3.0 的(de)(de)安裝部署上保留了和 2.0 一樣的(de)(de)簡(jian)單易用(yong)模式，升(sheng)級(ji)操作只需要備份數(shu)據(ju)文(wen)件目錄，覆蓋安裝即可，而(er)且寫入速度極高，接近硬(ying)盤的(de)(de)連續寫入性能。TDengine 的(de)(de)高效壓(ya)縮(suo)算法，可以節(jie)省大量存(cun)儲空間(jian)(jian)，SQL 使(shi)用(yong)也非常簡(jian)單。在此前(qian)對 MySQL 方案的(de)(de)替換(huan)中(zhong)，我們的(de)(de)存(cun)儲空間(jian)(jian)降(jiang)為原(yuan)來的(de)(de) 1/7，可以看到，在節(jie)省存(cun)儲空間(jian)(jian)方面，TDengine 的(de)(de)優勢極為明顯(xian)。
目前我(wo)(wo)們共有 102 萬張子表，已經(jing)(jing)累(lei)積的(de)總數據(ju)量已經(jing)(jing)達到了 2000 億行(xing)，3 副本，磁盤占用 3.1TB。在遷(qian)移到 TDengine 3.0 之(zhi)后，各方面的(de)表現依然非常不錯：業務的(de)寫入峰值達到了 1.2-1.3w 行(xing)/s ，數據(ju)遷(qian)移的(de)過(guo)程中(zhong)可以達到 20w 行(xing)/s，這(zhe)些情況下 TDengine 都可以輕松處理；存儲(chu)大約只有 MySQL 的(de) 1/7；讀取(qu)數據(ju)性(xing)能(neng)也(ye)很突出，我(wo)(wo)們最常用的(de)單設備單日查詢，可以在 0.1s 內返(fan)回(hui)結(jie)果。
我們(men)當前(qian)(qian)使用的是 版(ban)本，但是由(you)于業(ye)務本身不(bu)允許停機，所(suo)以沒(mei)辦法做離線(xian)升級。因此，后續(xu)會由(you) TDengine 企(qi)業(ye)版(ban)團隊協(xie)助我們(men)在線(xian)升級至最(zui)新版(ban)本（當前(qian)(qian)最(zui)新版(ban)本為 ）。
建模設計：
在(zai)庫(ku)(ku)表設(she)計上，我們運用了(le)自(zi)動建(jian)表來寫入數(shu)據(ju)，每(mei)個終端設(she)備產生(sheng)的(de)(de)軌跡點(dian)位數(shu)據(ju)在(zai)第一次入庫(ku)(ku)的(de)(de)時候(hou)自(zi)動創建(jian)子(zi)表，這(zhe)樣(yang)只需要(yao)建(jian)一個 database 和業務需求的(de)(de)超級表就(jiu)可以了(le)，省(sheng)掉了(le)數(shu)據(ju)入庫(ku)(ku)時的(de)(de)校驗和建(jian)表操作。
值得一(yi)提的(de)(de)(de)是，在 2.x 時代(dai)，元(yuan)數(shu)據是在管(guan)理節點上(shang)集中存(cun)儲(chu)的(de)(de)(de)，因此在當時的(de)(de)(de)版本(ben)中，自(zi)(zi)動建(jian)表的(de)(de)(de)速度會(hui)受(shou)到(dao)單(dan)線程工作能力的(de)(de)(de)制約，當時大概最高每秒只能創建(jian) 6000 個子(zi)表左右，不過當時我們也(ye)沒有(you)這(zhe)么高的(de)(de)(de)建(jian)表頻率(lv)所以也(ye)沒有(you)受(shou)到(dao)太(tai)大影(ying)響。經(jing)過重構之(zhi)后，3.0 的(de)(de)(de)元(yuan)數(shu)據已經(jing)完(wan)全做(zuo)到(dao)了分(fen)布式存(cun)儲(chu)，所有(you) vnode 都會(hui)獨立存(cun)儲(chu)自(zi)(zi)己表的(de)(de)(de)元(yuan)數(shu)據并處理寫(xie)入操作，所以自(zi)(zi)動建(jian)表的(de)(de)(de)寫(xie)入效率(lv)已經(jing)大幅增加。
我們(men)的超級表建表語句如(ru)下，可以(yi)給大(da)家參考：
1.車輛歷(li)史狀(zhuang)態、位置：
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.車輛事件(jian)：四急(ji)(ji)( 急(ji)(ji)加速 急(ji)(ji)減速 急(ji)(ji)剎車 急(ji)(ji)轉(zhuan)彎)
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. 汽車總線數據(ju)：
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));在應(ying)用層，由于我們存儲(chu)的(de)數(shu)(shu)據是車(che)輛(liang)(liang)軌跡(ji)數(shu)(shu)據，因此會做很多關于車(che)輛(liang)(liang)軌跡(ji)數(shu)(shu)據的(de)分析，比如：熱(re)點路(lu)線、軌跡(ji)段(duan)數(shu)(shu)據、停(ting)留點、行(xing)駛事(shi)件（急(ji)轉彎(wan)、急(ji)加速、急(ji)減速、車(che)輛(liang)(liang)其它(ta)信息），但由于 TDengine 一直以來都是時序(xu)數(shu)(shu)據庫(ku)，并沒(mei)有地理信息相關的(de)計算(suan)函數(shu)(shu)，所以在這塊我們自己寫了很多函數(shu)(shu)，通過(guo) Spark 的(de) RDD 來進行(xing)了計算(suan)分析，最后再把(ba)分析后的(de)數(shu)(shu)據返(fan)回給客戶端。
未來展望：
目前 TDengine 能夠很好(hao)地解決我們的(de)需求，尤其(qi)是(shi)強大(da)的(de)存(cun)(cun)取能力(li)是(shi)我們最滿意的(de)地方。但近期(qi)我從官(guan)方人員處(chu)得(de)知，從即將(jiang)(jiang)于 7 月份發布的(de) 3.0.6.0 版(ban)本開始，TDengine 將(jiang)(jiang)提(ti)供全新的(de)數據類型 geometry 用(yong)于點線面等幾(ji)何(he)(he)(he)類型的(de)存(cun)(cun)儲，并(bing)且會(hui)逐步提(ti)供一套(tao)符(fu)合 OGC(Open Geospatial Consortium) 標準的(de) SQL 函(han)數，包括幾(ji)何(he)(he)(he)輸(shu)入輸(shu)出、空間(jian)關系、幾(ji)何(he)(he)(he)測量、集合操作和幾(ji)何(he)(he)(he)處(chu)理等等。
其實通過我(wo)們觀察(cha)，還是(shi)有很多車聯網用戶對于軌(gui)跡(ji)分析(xi)有使(shi)用需求，如果 TDengine 可(ke)以完整支持到(dao)空(kong)間數據的處理，這(zhe)樣我(wo)們的系統架構(gou)將會進一(yi)步簡(jian)化，連(lian) Spark 都可(ke)以不用了，這(zhe)就可(ke)以說是(shi)完全(quan)意義上地使(shi)用了 All in one 的時序數據處理引擎。
可惜的(de)(de)是，目前(qian)由于我(wo)們歷史數據(ju)的(de)(de)經緯(wei)度都是通過(guo)單獨列來存儲的(de)(de)，對于 Geometry 帶來的(de)(de)全新數據(ju)類(lei)型(xing)，我(wo)們龐大的(de)(de)歷史數據(ju)量(liang)和(he)應(ying)用層是很難快速(su)調(diao)整(zheng)的(de)(de)，所以只能在測試環境應(ying)用，先(xian)逐(zhu)漸試用起來。
最后，祝 TDengine 越來越好，最終成為時序數(shu)據庫(ku)的事(shi)實標準。
作者介紹： 薛(xue)超，中(zhong)移物(wu)聯(lian)網數(shu)據(ju)(ju)庫運(yun)維(wei)高級工程師，10 年(nian)數(shu)據(ju)(ju)庫運(yun)維(wei)經(jing)歷，2017 年(nian)加入(ru)中(zhong)移物(wu)聯(lian)網，負責智(zhi)能硬件產(chan)品部數(shu)據(ju)(ju)庫相關工作，專注于(yu)數(shu)據(ju)(ju)庫優化和推動(dong)架構演進；近年(nian)來主要研究國(guo)產(chan)新(xin)型(xing)(xing)數(shu)據(ju)(ju)庫，目前所在部門全部業務已經(jing)去“O”，在此過程中(zhong)，積累了大量新(xin)型(xing)(xing)數(shu)據(ju)(ju)庫的運(yun)維(wei)經(jing)驗。
