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

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

一. 項(xiàng)目背景

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

原來的業(yè)務(wù)架構(gòu)如下圖所示：

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

具體可以總結(jié)如下：

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

二. 項(xiàng)目演化

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

我們依次來看一下：

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

技術(shù)選型

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

綜合對(duì)比后的結(jié)果如下：

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

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

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

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

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

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

三.深入理解TDengine

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

1. TDengine 架構(gòu)

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

2. 超級(jí)表

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

3. 高壓縮特點(diǎn)

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

四.引入TDengine之后的架構(gòu)

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

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

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

五. 優(yōu)化效果

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

1. 壓縮率

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

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

2. 日增量

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

3. 各項(xiàng)指標(biāo)的整體對(duì)比

下圖是我們實(shí)際落地前后各項(xiàng)指標(biāo)的對(duì)比。

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

從對(duì)比可以看出，TDengine確實(shí)極大降低了我們的各項(xiàng)成本。

六.問題和建議

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

比如下面這個(gè)就是我們?cè)谑褂?a href="http://www.fjzmyy.cn/docs/cn/v2.0/connector/java">JDBC過程中遇到的問題。我們也給官方提PR修復(fù)了。這就是開源的魅力吧，大家都可以參與進(jìn)來。

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

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

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