小T導讀：跨越速運集團有限公司創(chuàng)建于2007年。擁有“國家AAAAA級物流企業(yè)”、“國家級高新技術企業(yè)”、“中國物流行業(yè)30強優(yōu)秀品牌”、“中國電商物流行業(yè)知名品牌”、“廣東省誠信物流企業(yè)”等榮譽稱號。在胡潤研究院發(fā)布的《2018 Q3胡潤大中華區(qū)獨角獸指數(shù)》《2019一季度胡潤大中華區(qū)獨角獸指數(shù)》榜單中，跨越速運兩次上榜，估值約200億元，與菜鳥網(wǎng)絡、京東物流、達達-京東到家等企業(yè)入選中國物流服務行業(yè)獨角獸企業(yè)。

作為一家物流企業(yè)，如何高效地記錄和處理車輛的軌跡信息，對于整體的交付效率至關重要。

一. 項目背景

數(shù)年前車輛軌跡定位存儲引擎項目成立，跨越速運集團購置的數(shù)萬臺車輛經(jīng)過車載定位設備上報信息到GPS-AGENT網(wǎng)關，服務解析報文下發(fā)到Apache Kafka消息中間件，再通過應用將歷史位置定位信息寫入Apache HBase，最新車輛位置信息寫入Redis，以此提供給業(yè)務服務進行對車輛的實時監(jiān)控與分析。

原來的業(yè)務架構如下圖所示：

在原有系統(tǒng)的實際運行過程中，我們也遇到了很多痛點。比如說，因為數(shù)據(jù)保存在HBase中，當我們需要查詢較大跨度的時間內(nèi)的數(shù)據(jù)時，系統(tǒng)的性能會顯著下降。

具體可以總結如下：

于是我們開始思考，該如何改進系統(tǒng)來解決這些痛點呢？

二. 項目演化

在開始新的技術選型之前，我們重新對業(yè)務場景進行了梳理，可以用下面這張圖來概括。

我們依次來看一下：

1. 數(shù)據(jù)不更新不刪除：軌跡信息是按照車輛實際信息的時間戳上報，不存在更新和刪除的需求。只需要按照某個時限來保存。
2. 無需傳統(tǒng)數(shù)據(jù)庫的事務處理：因為數(shù)據(jù)不需要更新，也就不需要像傳統(tǒng)數(shù)據(jù)庫那樣用事務來保證更新安全。
3. 流量平穩(wěn)，一段時間內(nèi)車輛的數(shù)量和上報的頻率都可以確定。
4. 數(shù)據(jù)的查詢分析基于時間段和空間區(qū)域，這跟業(yè)務需求有關。
5. 除存儲、查詢操作外，還需要根據(jù)業(yè)務的實際需求進行各種統(tǒng)計和實時計算等操作。
6. 數(shù)據(jù)量巨大，一天采集的數(shù)據(jù)超過5000萬條，并且會隨業(yè)務規(guī)模的不斷增長而增長。

技術選型

通過以上分析可以看到，車輛軌跡是典型的時間序列數(shù)據(jù)，所以用專門的時序數(shù)據(jù)庫（Time-Series Database）來處理會比較高效。在調(diào)研階段，我們對比了幾款比較有代表性的時序數(shù)據(jù)庫產(chǎn)品。

綜合對比后的結果如下：

• InfluxDB集群版本收費，硬件成本也相對較高；
• CTSDB騰訊云時序數(shù)據(jù)庫，內(nèi)存用量高，費用成本相對較高；
• OpenTSDB底層基座還是 HBase ，引入并不能使架構變得簡單；
• TDengine集群功能開源，具有典型的分布式數(shù)據(jù)庫特征，壓縮比例也非常高。

通過對比，我們認為TDengine Database的很多優(yōu)秀特性能夠滿足我們的業(yè)務場景。

于是我們基于TDengine進行了前期調(diào)研和演練。具體包括如下幾個方面：

我們從多個方面對TDengine的功能和性能進行了全方位的測試，功能完全能夠滿足我們的需求，性能、壓縮率給我們帶來了很大的驚喜。

在完成基本的功能和性能測試之后，我們又結合業(yè)務進行了場景測試和演練，主要包含如下幾方面的工作：

• 數(shù)據(jù)在寫入時候?qū)簲U縮容
• cacheLast的應用是否有效
• 統(tǒng)計聚合分析interval，interp的一些業(yè)務場景應用
• update參數(shù)的覆蓋場景
• 常用業(yè)務的查詢語句，同等查詢范圍的數(shù)據(jù)對比

三.深入理解TDengine

在實際落地TDengine Database之前，我們也深入研究了這個系統(tǒng)的架構、設計等各方面特性。這里也簡單分享一下TDengine的核心概念。

1. TDengine 架構

如果是第一次接觸TDengine，可以看一下如下這張圖，其中的dnode就是實際存儲數(shù)據(jù)的物理節(jié)點，dnode框中的V2、V7等小框叫vnode，也就是虛擬節(jié)點，m0、m1就是元數(shù)據(jù)管理節(jié)點，存儲一些集群信息與表信息，熟悉分布式中間件的朋友肯定能直觀地感受到TDengine具有非常典型的分布式數(shù)據(jù)庫特征。

2. 超級表

TDengine有個超級表的概念，例如在跨越速運集團業(yè)務場景下，所有的車輛變成一張張子表，所有的子表會繼承一張叫超級表的父表，超級表定義子表的結構規(guī)范，不存儲實際物理數(shù)據(jù)，我們可以通過只查超級表做數(shù)據(jù)的統(tǒng)計分析查詢，而不用一個個子表去匯總。

3. 高壓縮特點

TDengine采用了二階段壓縮策略，一階段壓縮會使用delta-delta 編碼、simple 8B 方法、zig-zag 編碼、LZ4 等算法，二階段壓縮會采用LZ4算法。一階段壓縮會針對每個數(shù)據(jù)類型做特定的算法壓縮，二階段再做一次通用壓縮，前提是在建庫的時候?qū)?shù)comp設置為2 。

四.引入TDengine之后的架構

在進行了充分的測試和驗證之后，我們將TDengine引入到了我們的系統(tǒng)之中。新的系統(tǒng)架構如下圖所示：

從架構圖中可以看到，車載數(shù)據(jù)依然通過GPS-AGENT網(wǎng)關進行報文解析后發(fā)送到Apache Kafka中，再通過應用多開啟一個Kafka group同時消費消息，以此達到兩端數(shù)據(jù)的一致。

業(yè)務系統(tǒng)最新車輛位置信息不再通過Redis讀取，這樣就簡化了架構。查詢只讀取TDengine，HBase在一定的時間后會下線。

五. 優(yōu)化效果

引入TDengine之后，從各項指標來看，數(shù)據(jù)非常亮眼。

1. 壓縮率

如圖我們看到一個5萬行的表，每行在600字節(jié)以上，壓縮后的磁盤size是1665KB，壓縮率高達1%。接下來我們看個百萬行的子表。

它實際占用磁盤大小為7839KB。我們的壓縮效果比TDengine官方的各種測試還要好很多，這應該與我們業(yè)務數(shù)據(jù)重復度相對較高有一定關系。

2. 日增量

我們現(xiàn)在的業(yè)務日寫入量超過5000萬，對TDengine來說日增的磁盤大小基本維持在單臺1.4G左右。

3. 各項指標的整體對比

下圖是我們實際落地前后各項指標的對比。

下圖是數(shù)據(jù)增量的對比。

從對比可以看出，TDengine確實極大降低了我們的各項成本。

六.問題和建議

一個相對較新的系統(tǒng)，在使用過程中難免會遇到一些問題，我們也和TDengine Database的研發(fā)團隊一起去定位、解決。

比如下面這個就是我們在使用JDBC過程中遇到的問題。我們也給官方提PR修復了。這就是開源的魅力吧，大家都可以參與進來。

有兩個地方我們也希望TDengine能進一步優(yōu)化：

1. 2.3.0.x以下的監(jiān)控功能還比較簡單，我們期待后期的版本能提供更強更細致的監(jiān)控。我們注意到新發(fā)布的版本引入了一個叫TDinsight的監(jiān)控工具，我們也會盡快嘗試一下。
2. 目前的interval函數(shù)還不支持按業(yè)務列group by普通列，后續(xù)希望也能夠得到支持。

最后，在嘗試和落地TDengine的過程中，我們也得到了濤思數(shù)據(jù)多位同事的大力支持，在此一并表示感謝。