小T導讀：跨越速(su)運(yun)集團有限公司創建于2007年。擁有“國(guo)(guo)家AAAAA級(ji)(ji)物(wu)(wu)流(liu)(liu)企(qi)業”、“國(guo)(guo)家級(ji)(ji)高(gao)新技(ji)術企(qi)業”、“中(zhong)國(guo)(guo)物(wu)(wu)流(liu)(liu)行業30強(qiang)優秀品牌(pai)(pai)”、“中(zhong)國(guo)(guo)電商(shang)物(wu)(wu)流(liu)(liu)行業知(zhi)名(ming)品牌(pai)(pai)”、“廣東省誠信物(wu)(wu)流(liu)(liu)企(qi)業”等榮譽稱號。在胡潤(run)(run)研(yan)究院發(fa)布的《2018 Q3胡潤(run)(run)大(da)中(zhong)華區(qu)獨(du)(du)角(jiao)獸(shou)指(zhi)數》《2019一(yi)季度胡潤(run)(run)大(da)中(zhong)華區(qu)獨(du)(du)角(jiao)獸(shou)指(zhi)數》榜單中(zhong)，跨越速(su)運(yun)兩次上榜，估值約200億(yi)元，與菜鳥網絡、京東物(wu)(wu)流(liu)(liu)、達達-京東到家等企(qi)業入選中(zhong)國(guo)(guo)物(wu)(wu)流(liu)(liu)服(fu)務行業獨(du)(du)角(jiao)獸(shou)企(qi)業。
作為一家物流企業，如何高(gao)效(xiao)地記錄和(he)處理車輛的軌跡信息(xi)，對(dui)于整體的交付效(xiao)率至關重要。
一. 項目背景
數年前車(che)輛軌跡定(ding)(ding)(ding)位存儲引擎項(xiang)目成立，跨越速(su)運集團(tuan)購(gou)置的(de)數萬臺車(che)輛經過(guo)車(che)載定(ding)(ding)(ding)位設備上(shang)報信息(xi)到(dao)GPS-AGENT網關(guan)，服務(wu)解(jie)析(xi)報文下發到(dao)Apache Kafka消息(xi)中間(jian)件(jian)，再(zai)通過(guo)應用將歷史位置定(ding)(ding)(ding)位信息(xi)寫入(ru)Apache HBase，最新車(che)輛位置信息(xi)寫入(ru)Redis，以此(ci)提(ti)供(gong)給業務(wu)服務(wu)進行對車(che)輛的(de)實時監控與分析(xi)。
原(yuan)來(lai)的業務架構如下圖所(suo)示：
在原有系統的實際運行過程(cheng)中，我們(men)也(ye)遇(yu)到了很多痛點。比如說，因(yin)為數據保存在HBase中，當我們(men)需要查詢(xun)較(jiao)大(da)跨度的時間內的數據時，系統的性能會顯著下降(jiang)。
具體可以總結如下：
于是(shi)我們開始思考，該如何(he)改進系統來解決這些痛點(dian)呢(ni)？
二. 項目演化
在開始新的技術選型之(zhi)前，我們重(zhong)新對業務場景進行了梳理，可以用下面這張圖(tu)來概(gai)括(kuo)。
我們依次(ci)來看(kan)一下：
- 數據不更新不刪除：軌跡信息是按照車輛實際信息的時間戳上報，不存在更新和刪除的需求。只需要按照某個時限來保存。
- 無需傳統數據庫的事務處理：因為數據不需要更新，也就不需要像傳統數據庫那樣用事務來保證更新安全。
- 流量平穩，一段時間內車輛的數量和上報的頻率都可以確定。
- 數據的查詢分析基于時間段和空間區域，這跟業務需求有關。
- 除存儲、查詢操作外，還需要根據業務的實際需求進行各種統計和實時計算等操作。
- 數據量巨大，一天采集的數據超過5000萬條，并且會隨業務規模的不斷增長而增長。
技術選型
通過以上分析可以看到，車輛軌跡是典型的時間序列數據，所以用專門的時序數據庫（Time-Series Database）來處理會比較高效。在調研(yan)階段，我們對比了(le)幾款比較有代表性(xing)的時(shi)序數據庫產品。
綜(zong)合(he)對比(bi)后的結果(guo)如(ru)下：
- InfluxDB集群版本收費，硬件成本也相對較高；
- CTSDB騰訊云時序數據庫，內存用量高，費用成本相對較高；
- OpenTSDB底層基座還是 HBase ，引入并不能使架構變得簡單；
- TDengine集群功能開源，具有典型的分布式數據庫特征，壓縮比例也非常高。
通過對比，我們認為TDengine Database的很多優秀特性能夠滿足(zu)我(wo)們的業(ye)務場景。
于是我們基于TDengine進行了(le)前期調研(yan)和演(yan)練(lian)。具體包括如(ru)下幾個方面：
我(wo)們(men)(men)從多個(ge)方面對TDengine的功能(neng)(neng)(neng)和(he)性能(neng)(neng)(neng)進行了全方位的測試(shi)，功能(neng)(neng)(neng)完(wan)全能(neng)(neng)(neng)夠滿(man)足我(wo)們(men)(men)的需求，性能(neng)(neng)(neng)、壓縮率給(gei)我(wo)們(men)(men)帶來了很大(da)的驚喜。
在完成基本(ben)的功(gong)能(neng)和性能(neng)測試之后，我們又結合業(ye)務(wu)進行了場景測試和演練，主要包含如(ru)下幾方面的工作：
- 數據在寫入時候對集群擴縮容
- cacheLast的應用是否有效
- 統計聚合分析interval，interp的一些業務場景應用
- update參數的覆蓋場景
- 常用業務的查詢語句，同等查詢范圍的數據對比
三.深入理解TDengine
在實際落地TDengine Database之(zhi)前，我(wo)們(men)也深(shen)入研究了這(zhe)個系統的架構、設計等各方面特性。這(zhe)里也簡單分享一下TDengine的核心概念。
1. TDengine 架構
如果(guo)是(shi)(shi)第一次(ci)接觸TDengine，可(ke)以看(kan)一下(xia)如下(xia)這張圖，其中的(de)dnode就是(shi)(shi)實際存儲(chu)數(shu)據(ju)的(de)物(wu)理(li)節(jie)點(dian)(dian)，dnode框中的(de)V2、V7等小框叫vnode，也就是(shi)(shi)虛擬節(jie)點(dian)(dian)，m0、m1就是(shi)(shi)元(yuan)數(shu)據(ju)管理(li)節(jie)點(dian)(dian)，存儲(chu)一些(xie)集群信息與表信息，熟悉分布式(shi)中間件的(de)朋友肯定能直觀地感受(shou)到TDengine具有非常典型(xing)的(de)分布式(shi)數(shu)據(ju)庫(ku)特征(zheng)。
2. 超級表
TDengine有個超級表的(de)(de)(de)概念，例如在跨越速運集團業務場景下，所(suo)有的(de)(de)(de)車輛變(bian)成一張張子表，所(suo)有的(de)(de)(de)子表會(hui)繼承一張叫超級表的(de)(de)(de)父表，超級表定義子表的(de)(de)(de)結構規范，不存儲實際(ji)物(wu)理數據，我們可以通(tong)過只查超級表做數據的(de)(de)(de)統計分析查詢，而不用一個個子表去(qu)匯總。
3. 高壓縮特點
TDengine采用了二(er)(er)(er)階(jie)段(duan)(duan)壓縮(suo)(suo)(suo)策(ce)略，一(yi)階(jie)段(duan)(duan)壓縮(suo)(suo)(suo)會(hui)使用delta-delta 編碼(ma)、simple 8B 方法(fa)、zig-zag 編碼(ma)、LZ4 等算(suan)(suan)(suan)法(fa)，二(er)(er)(er)階(jie)段(duan)(duan)壓縮(suo)(suo)(suo)會(hui)采用LZ4算(suan)(suan)(suan)法(fa)。一(yi)階(jie)段(duan)(duan)壓縮(suo)(suo)(suo)會(hui)針對每個數(shu)據類型做特(te)定的算(suan)(suan)(suan)法(fa)壓縮(suo)(suo)(suo)，二(er)(er)(er)階(jie)段(duan)(duan)再(zai)做一(yi)次通用壓縮(suo)(suo)(suo)，前提是在建庫(ku)的時(shi)候將參數(shu)comp設置為2 。
四.引入TDengine之后的架構
在進行了充分(fen)的測(ce)試(shi)和驗證(zheng)之后，我(wo)(wo)們將(jiang)TDengine引(yin)入(ru)到了我(wo)(wo)們的系統之中(zhong)。新的系統架構如下圖所示：
從架構(gou)圖中(zhong)可(ke)以看到，車(che)載數據依然(ran)通過GPS-AGENT網關進行報文解析后發送到Apache Kafka中(zhong)，再通過應(ying)用多(duo)開啟一個Kafka group同時消(xiao)費消(xiao)息，以此達到兩端數據的一致。
業務系統(tong)最(zui)新車輛位置信息不再通過Redis讀取(qu)，這(zhe)樣就簡化了架構(gou)。查詢(xun)只讀取(qu)TDengine，HBase在一定的時間后會下(xia)線。
五. 優化效果
引入TDengine之后(hou)，從各項指標來看，數據非常亮眼。
1. 壓縮率
如圖我們看(kan)(kan)到(dao)一個5萬(wan)行(xing)的表，每行(xing)在600字節以上，壓縮后的磁(ci)盤size是1665KB，壓縮率高達1%。接下來我們看(kan)(kan)個百萬(wan)行(xing)的子(zi)表。
它(ta)實際(ji)占用(yong)磁盤大小(xiao)為(wei)7839KB。我們(men)的(de)壓縮效(xiao)果比(bi)TDengine官方的(de)各(ge)種測試(shi)還要好很多，這應(ying)該與我們(men)業(ye)務數據重復(fu)度相對較高(gao)有一定關(guan)系。
2. 日增量
我們(men)現在(zai)(zai)的業務(wu)日(ri)寫(xie)入量超過5000萬，對TDengine來說日(ri)增的磁盤大(da)小基本維持在(zai)(zai)單臺1.4G左右。
3. 各項指標的整體對比
下圖是我(wo)們實際落地前后各項指標的對比。
下圖是數據增量的對比。
從對比可(ke)以看出，TDengine確(que)實(shi)極(ji)大降低了(le)我們的各項成本(ben)。
六.問題和建議
一個相對較(jiao)新(xin)的(de)系統，在使用過程中難免會遇到一些問題，我們也和TDengine Database的(de)研發團隊一起去定位、解決。
比如下面這個就是我們在使用JDBC過程中遇到的(de)問題。我們也給官方提PR修復了。這(zhe)就是開源的(de)魅力(li)吧，大家都(dou)可以參與(yu)進來。
有兩個(ge)地(di)方我(wo)們也希望TDengine能進一步優化：
- 2.3.0.x以下的監控功能還比較簡單，我們期待后期的版本能提供更強更細致的監控。我們注意到新發布的版本引入了一個叫TDinsight的監控工具，我們也會盡快嘗試一下。
- 目前的interval函數還不支持按業務列group by普通列，后續希望也能夠得到支持。
最后，在(zai)(zai)嘗試(shi)和落(luo)地TDengine的過程中，我們也得(de)到了濤思數據(ju)多位同事的大力支持(chi)，在(zai)(zai)此一并(bing)表示(shi)感謝。
