小 T 導讀：吉科軟信息技(ji)術有(you)限公司是國(guo)(guo)家高(gao)新(xin)技(ji)術企業(ye)(ye)(ye)，公司以(yi)“讓天下(xia)沒(mei)有(you)不放心的食(shi)品(pin)”為(wei)(wei)使命，以(yi)“做數字化(hua)捍衛(wei)食(shi)品(pin)安(an)(an)全(quan)的領軍(jun)企業(ye)(ye)(ye)”為(wei)(wei)愿景(jing)，以(yi)打造食(shi)用農產品(pin)全(quan)流(liu)(liu)程(cheng)追溯(su)、全(quan)流(liu)(liu)程(cheng)監(jian)管、全(quan)流(liu)(liu)程(cheng)服務(wu)、全(quan)產業(ye)(ye)(ye)鏈(lian)(lian)升級為(wei)(wei)核心的產業(ye)(ye)(ye)互聯(lian)網生態鏈(lian)(lian)為(wei)(wei)主營業(ye)(ye)(ye)務(wu)，運(yun)用衛(wei)星遙感、5G通信、大數據、云計算、物聯(lian)網、區(qu)塊鏈(lian)(lian)和人(ren)工智(zhi)能等技(ji)術，推(tui)出一(yi)系列國(guo)(guo)內(nei)首(shou)創、行(xing)業(ye)(ye)(ye)領先和可落地的研發成果，為(wei)(wei)智(zhi)慧農業(ye)(ye)(ye)、智(zhi)慧食(shi)安(an)(an)、智(zhi)慧城市提供(gong)解決方案。

一、業務背景

車(che)(che)輛(liang)軌(gui)跡(ji)定(ding)位(wei)監控(kong)項(xiang)目旨在通(tong)過車(che)(che)輛(liang)的軌(gui)跡(ji)監管、異常預警、歷(li)史軌(gui)跡(ji)回(hui)放，達成對(dui)車(che)(che)輛(liang)的統一監管、軌(gui)跡(ji)追蹤、大(da)數(shu)據(ju)分析及(ji)可(ke)視化應(ying)用等(deng)目的。該項(xiang)目現已對(dui)數(shu)萬臺車(che)(che)輛(liang)經(jing)過車(che)(che)載定(ding)位(wei)設備上報定(ding)位(wei)數(shu)據(ju)至 GIS 網關服(fu)務(wu)，服(fu)務(wu)解析報文下(xia)發至消息隊列，應(ying)用再將定(ding)位(wei)數(shu)據(ju)寫入(ru) InfluxDB，最(zui)新車(che)(che)輛(liang)位(wei)置信(xin)息寫入(ru) Redis，為客戶(hu)提供(gong)車(che)(che)輛(liang)實時(shi)位(wei)置跟蹤和歷(li)史軌(gui)跡(ji)回(hui)放等(deng)查詢分析服(fu)務(wu)。

二、時序數據庫（Time-Series Database）選型

首先我們(men)梳理了當前車輛監管架構(gou)的主要特(te)性和新需求：

• 持續高并發寫入，帶有 tag，時間戳有時會亂序寫入(存在離線數據上傳的情況，離線數據的時間戳小于當前時間戳)；
• 業務數量級增長快，預估未來每天寫入約 8 億條數據；
• 對基于時間戳范圍的聚合查詢，屬于低頻查詢，通常是由用戶觸發，查詢最近幾天的軌跡，按執行任務的時間進行軌跡回放。
• 實時查詢需求，對每個車輛有最后一個定位點數據的查詢需求，獲取實時位置監控；
• 因為數據量非常大，所以需要支持數據壓縮，降本增效；
• 期望每個車輛單獨建表；
• 需支持批量數據寫入，且業務期望寫入延時較低；
• 車輛監管項目有產品國產化的需求，在中間件的選擇上需采用國產化產品。

此前(qian)，我們的(de)項(xiang)目一期采用了 InfluxDB 時序數據庫作(zuo)為存儲車輛軌(gui)跡數據，二期項(xiang)目需(xu)要(yao)重(zhong)新升級改版(ban)后(hou)進行全新架構設計，同時也要(yao)考慮業務規模(mo)的(de)快速增長、國(guo)產(chan)化要(yao)求及 InfluxDB 的(de)單(dan)節點(dian)問(wen)題。

因此我(wo)(wo)司(si)需要對時(shi)序(xu)數據庫進(jin)行重新選型。我(wo)(wo)們(men)對業界主(zhu)流的時(shi)序(xu)數據庫做了分析和測試：

• InfluxDB：由InfluxData開發的開源時序型數據。它由Go寫成，著力于高性能地查詢與存儲時序型數據。被廣泛應用于存儲系統的監控數據，IoT行業的實時數據等場景。缺點是開源版本只支持一個節點，開源版本沒有集群功能,存在前后版本兼容性問題，非國產化產品。
• OpenTSDB：基于HBase的分布式、可伸縮的時間序列數據庫。作為基于通用存儲開發的時序數據庫典型代表，起步比較早，在時序數據庫領域的認可度相對較高，但HBase成本高的問題無法免除。
• TDengine：國產開源時序數據庫，使用類SQL查詢語言來插入或查詢數據；通過連續查詢，支持基于滑動窗口的流式計算；引入超級表，讓設備之間的數據聚合通過標簽變得簡單靈活；內嵌緩存機制，每臺設備的最新狀態或記錄都可快速獲得；分布式架構，支持線性擴展，以保證任何規模的數據量都可以處理；支持多副本，無單點故障，保證系統的高可用與高可靠。這些功能和特性都非常符合我們的需求。

通過實際對比后、再加上遷移改(gai)動(dong)最小化以及(ji)國產化需求等因(yin)素(su)，我們最終選(xuan)定 TDengine Database 作為車輛軌跡數據的存儲(chu)方案(an)。

改造為使用 TDengine 后(hou)的方案(an)，如下：

三、TDengine 的落地應用

初期我們(men)(men)選用了(le)三臺服務器，搭(da)建了(le)3節點3副(fu)本的集群。目前已投入一(yi)批(pi)車輛(liang)運營監控，后續我們(men)(men)將逐步遷移全部車輛(liang)的軌跡數據(ju)至(zhi) TDengine。

歷史數據從 InfluxDB 遷移至 TDengine，采用的方案是基于 DataX 進行數據同步，我們擴展開發了 InfluxDB 的讀插件和 TDengine 的寫插件，單進程數據同步可達到 6 萬/秒的同步速度。（該速度受限于 InfluxDB 的讀取，在該過程中 InfluxDB 的內存上漲過快撐不住，所以最終測試的同步速度是6萬/秒。目前官方已發布“基于 DataX 的 TDengine 數據遷移工具和 taosAdapter 工具”）

以遷移(yi)的部分數(shu)據進(jin)行分析(xi)：總數(shu)據量(liang)為6.5億，分布在14742個子表(biao)中(zhong)，占用(yong)磁盤空間4.7G，壓縮率達到4%。開啟了(le)cachelast選項為1緩存(cun)子表(biao)最(zui)近一(yi)行數(shu)據，利用(yong)該(gai)緩存(cun)特性，查詢指定(ding)車輛的最(zui)新GIS定(ding)位數(shu)據進(jin)行實時(shi)監(jian)控(kong)時(shi)，可直接從緩存(cun)中(zhong)讀取，加快讀取速度。

在使(shi)(shi)用 TDengine 之(zhi)前，對于所有車輛的(de)(de)最新(xin)位置實(shi)時監控，我們采用的(de)(de)方案是在接(jie)收(shou) gis 數(shu)據(ju)存(cun)儲至 InfluxDB 時，同時將車輛的(de)(de)最新(xin)位置數(shu)據(ju)存(cun)儲至 Redis 和 MySQL，使(shi)(shi)用 TDengine 后方案中對實(shi)時位置的(de)(de)存(cun)儲直(zhi)接(jie)使(shi)(shi)用 TDengine 的(de)(de)緩存(cun)子表最近(jin)一(yi)行(xing)數(shu)據(ju)的(de)(de)特(te)性就可以實(shi)現，完(wan)全可以去掉 Redis 和 MySQL 的(de)(de)存(cun)儲。

四、TDengine 的性能表現

項(xiang)目對(dui)車(che)輛軌跡數據的(de)應用(yong)場景(jing)主要集中(zhong)在車(che)輛實時位置監(jian)控、車(che)輛時間范(fan)圍內的(de)軌跡回放。

1.車輛實時位置監控場景

查詢(xun)單(dan)個(ge)(ge)或多個(ge)(ge)車輛(liang)(liang)的最新 GIS 位(wei)(wei)置數據。單(dan)個(ge)(ge)車輛(liang)(liang)最新位(wei)(wei)置查詢(xun)：

select last_row(*) from d_track where car_id in ('dc8a9a0d7b634c9ba4446445c6c');

利用查詢超表的單個車輛(liang)最新位置數據時間(jian)在11毫秒。如(ru)果直(zhi)接鎖定子表進行查詢的話，

select last_row(*) from _018d16c826cb405ea4a94a14cd4f95a9 ;

返回最后一條位(wei)置數(shu)據的響應時間在(zai)1毫(hao)秒。

多個車輛的最新位置(zhi)數據查(cha)詢(xun)，依(yi)舊使用超表結合(he)標簽(qian)進行查(cha)詢(xun)，

查詢(xun)響應時間在12毫(hao)秒左右。

繼續擴大查詢(xun)(xun)范圍，查詢(xun)(xun)500~1000個車輛(liang)的最新位置的查詢(xun)(xun)響應時間也能在1秒之(zhi)內返(fan)回(hui)結(jie)果，完全達到業務響應的時間需(xu)求。

2.時間范圍內車輛的軌跡數據查詢

指定(ding)車輛在指定(ding)時間范圍(wei)內的(de)軌(gui)跡數據查(cha)詢，直接定(ding)位(wei)到具(ju)體(ti)的(de)子(zi)表進(jin)行查(cha)詢，

select * from _0128a4d193424dcfb217242f054716d4 where time >'2021-09-08 10:34:44.000' and time <'2021-09-23 21:38:18.000' ;

測試數(shu)據的查詢響應時(shi)間為(wei)0.07秒左(zuo)右。

在以上兩種數據查詢場景中，TDengine 的性能不僅完全可滿足需求(qiu)，更是比原 InfluxDB+Redis+MySQL 方案大幅度(du)的提升，解(jie)決了原方案中車輛(liang)查詢較大時間跨度(du)的軌跡數據(ju)響應超級慢的問題。

整體應用效果：

五、寫在最后

非常(chang)(chang)感謝濤思數據的(de)(de) TDengine Database，切實(shi)解決(jue)了我(wo)們(men)在國產化、性(xing)能、降本(ben)、平滑遷移的(de)(de)剛性(xing)需求(qiu)。也非常(chang)(chang)感謝濤思的(de)(de)陳玉(yu)老師在我(wo)們(men)嘗試和應用(yong) TDengine 過程中給予的(de)(de)悉心指導，加快了我(wo)們(men)對 TDengine 的(de)(de)掌握(wo)，更快的(de)(de)應用(yong)落地。

當前 TDengine 的大規模應用(yong)車(che)輛監(jian)管項目中(zhong)，支(zhi)撐現有數萬輛車(che)的行(xing)駛軌(gui)跡監(jian)控，未來將(jiang)繼續擴大規模支(zhi)撐更多的車(che)輛軌(gui)跡監(jian)控。

作者簡介

孫運盛，吉(ji)科軟技(ji)術研究院。一(yi)個從事信(xin)息傳輸(shu)、軟件和信(xin)息技(ji)術服(fu)務業的(de)新生代“農民工”。