吉科軟信息技術有限公司是國家高新技術企業(yè)，公司以“讓天下沒有不放心的食品”為使命，以“做數(shù)字化捍衛(wèi)食品安全的領軍企業(yè)”為愿景，以打造食用農產品全流程追溯、全流程監(jiān)管、全流程服務、全產業(yè)鏈升級為核心的產業(yè)互聯(lián)網(wǎng)生態(tài)鏈為主營業(yè)務，運用衛(wèi)星遙感、5G通信、大數(shù)據(jù)、云計算、物聯(lián)網(wǎng)、區(qū)塊鏈和人工智能等技術，推出一系列國內首創(chuàng)、行業(yè)領先和可落地的研發(fā)成果，為智慧農業(yè)、智慧食安、智慧城市提供解決方案。

項目背景介紹：

車輛軌跡定位監(jiān)控項目旨在通過車輛的軌跡監(jiān)管、異常預警、歷史軌跡回放，達成對車輛的統(tǒng)一監(jiān)管、軌跡追蹤、大數(shù)據(jù)分析及可視化應用等目的。該項目現(xiàn)已對數(shù)萬臺車輛經(jīng)過車載定位設備上報定位數(shù)據(jù)至GIS網(wǎng)關服務，服務解析報文下發(fā)至消息隊列，應用再將定位數(shù)據(jù)寫入InfluxDB，最新車輛位置信息寫入Redis，為客戶提供車輛實時位置跟蹤和歷史軌跡回放等查詢分析服務。

選型時的思考：

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

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

此前，我們的項目一期采用了InfluxDB時序數(shù)據(jù)庫作為存儲車輛軌跡數(shù)據(jù)，二期項目需要重新升級改版后進行全新架構設計，同時也要考慮業(yè)務規(guī)模的快速增長、國產化要求及InfluxDB的單節(jié)點問題。

因此我司需要需對時序數(shù)據(jù)庫進行重新選型。我們對業(yè)界主流的時序數(shù)據(jù)庫做了分析和測試：

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

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

落地：

初期我們選用了三臺服務器，搭建了3節(jié)點3副本的集群。目前已投入一批車輛運營監(jiān)控，后續(xù)我們將逐步遷移全部車輛的軌跡數(shù)據(jù)至TDengine。

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

?

?

? ? ? 以遷移的部分數(shù)據(jù)進行分析：總數(shù)據(jù)量為6.5億，分布在14742個子表中，占用磁盤空間4.7G，壓縮率達到4%。開啟了cachelast選項為1緩存子表最近一行數(shù)據(jù)，利用該緩存特性，查詢指定車輛的最新GIS定位數(shù)據(jù)進行實時監(jiān)控時，可直接從緩存中讀取，加快讀取速度。?

? ? ? ?在使用TDengine之前，對于所有車輛的最新位置實時監(jiān)控，我們采用的方案是在接收gis數(shù)據(jù)存儲至InfluxDB時，同時將車輛的最新位置數(shù)據(jù)存儲至Redis和Mysql，使用TDengine后方案中對實時位置的存儲直接使用TDengine的緩存子表最近一行數(shù)據(jù)的特性就可以實現(xiàn)，完全可以去掉Redis和Mysql的存儲。

性能表現(xiàn)：

項目對車輛軌跡數(shù)據(jù)的應用場景主要集中在車輛實時位置監(jiān)控、車輛時間范圍內的軌跡回放。

1.車輛實時位置監(jiān)控場景：

查詢單個或多個車輛的最新GIS位置數(shù)據(jù)。單個車輛最新位置查詢：select last_row(*) from d_track where car_id in ('dc8a9a0d7b634c9ba4446445c6c');

利用查詢超表的單個車輛最新位置數(shù)據(jù)時間在11毫秒。如果直接鎖定子表進行查詢的話， select last_row(*) from _018d16c826cb405ea4a94a14cd4f95a9 ;

?返回最后一條位置數(shù)據(jù)的響應時間在1毫秒。

?多個車輛的最新位置數(shù)據(jù)查詢，依舊使用超表結合標簽進行查詢， 查詢響應時間在12毫秒左右。

?繼續(xù)擴大查詢范圍，查詢500~1000個車輛的最新位置的查詢響應時間也能在1秒之內返回結果，完全達到業(yè)務響應的時間需求。

2.時間范圍內車輛的軌跡數(shù)據(jù)查詢

?指定車輛在指定時間范圍內的軌跡數(shù)據(jù)查詢，直接定位到具體的子表進行查詢，select * from _0128a4d193424dcfb217242f054716d4 where time >'2021-09-08 10:34:44.000' and time <'2021-09-23 21:38:18.000' ;

?測試數(shù)據(jù)的查詢響應時間為0.07秒左右。

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

寫在最后：

? ? ? ?非常感謝濤思的TDengine，切實解決了我們在國產化、性能、降本、平滑遷移的剛性需求。也非常感謝濤思的羅格老師在我們嘗試和應用TDengine過程中給予的悉心指導，加快了我們對TDengine的掌握，更快的應用落地。

? ? ? ? 當前TDengine的大規(guī)模應用車輛監(jiān)管項目中，支撐現(xiàn)有數(shù)萬輛車的行駛軌跡監(jiān)控，未來將繼續(xù)擴大規(guī)模支撐更多的車輛軌跡監(jiān)控。

作者：

孫運盛，吉科軟技術研究院架構師，致力于微服務、大數(shù)據(jù)、人工智能方向的研究與應用。

總結

以上是生活随笔為你收集整理的TDengine在吉科软车辆监管中的应用实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。