對于物流企業(yè)來說，如何高效地記錄和處理車輛的軌跡信息、應(yīng)對每天海量監(jiān)控數(shù)據(jù)的采集和處理工作，對于項目整體的交付效率至關(guān)重要。同時，伴隨著數(shù)字化、智能化的不斷加速，數(shù)據(jù)更是呈現(xiàn)出爆發(fā)式增長，老舊的數(shù)據(jù)架構(gòu)越來越難以應(yīng)對業(yè)務(wù)發(fā)展需求。在此背景下，諸多物流企業(yè)開始尋求數(shù)據(jù)架構(gòu)的變革，特別是選擇符合業(yè)務(wù)需求的時序數(shù)據(jù)庫（Time Series Database，TSDB）產(chǎn)品，本篇文章匯總了國內(nèi)四家大型物流公司的數(shù)據(jù)架構(gòu)改造實例，給到讀者參考。

順豐 x TDengine

“完成改造后，大數(shù)據(jù)監(jiān)控平臺擺脫了對大數(shù)據(jù)組件的依賴，有效縮短了數(shù)據(jù)處理鏈路，自上線以來，一直運行穩(wěn)定。在寫入方面，根據(jù)容量規(guī)劃完成相關(guān)參數(shù)調(diào)整后，理想情況下，集群寫入速度最高達 90W 條/s。查詢性能方面，在使用預(yù)計算函數(shù)情況下，查詢 p99 都在 0.7 秒以內(nèi)，能夠滿足我們?nèi)粘＝^大部分查詢需求。控制成本層面，服務(wù)端物理機由 21 臺降至 3 臺，每日所需存儲空間為 93GB（2 副本），同等副本下僅為 OpenTSDB+HBase 的約 1/10?！?/p>

業(yè)務(wù)背景

順豐科技大數(shù)據(jù)集群每天需要采集海量監(jiān)控數(shù)據(jù)，以確保集群穩(wěn)定運行。此前其采用了 OpenTSDB+HBase 作為大數(shù)據(jù)監(jiān)控平臺全量監(jiān)控數(shù)據(jù)的存儲方案，隨著接入數(shù)據(jù)量的不斷增長，這一方案衍生出了不少痛點，包括依賴多、使用成本高和性能不能滿足等問題，必須對全量監(jiān)控數(shù)據(jù)存儲方案進行改造。通過對 IoTDB、Druid、ClickHouse、TDengine 等時序數(shù)據(jù)存儲方案的調(diào)研， TDengine 時序數(shù)據(jù)成為他們的最終選擇。

架構(gòu)圖

為保證整個系統(tǒng)的高可用和可擴展性，整體架構(gòu)中，前端采用nginx集群進行負載均衡，保證高可用性；單獨分離出客戶端層，方便根據(jù)流量需求進行擴容縮容。點擊案例詳情查看三大實施難點及解決路徑。

?? 點擊案例查看更多技術(shù)細節(jié)

韻達 x TDengine

“我們目前使用 TDengine 2.2.2.0 版本，在三臺 16C 64G 的服務(wù)器上部署了集群，數(shù)據(jù)寫入速度大概為每秒 5000 行。值得一提的是，基于 TDengine，常用的查詢基本可以在 1 秒之內(nèi)完成，一些特定查詢甚至可以達到毫秒級。從存儲來說，同等數(shù)據(jù)體量下，TDengine 大約占用 300GB 不到的磁盤（單副本），而此前使用 MySQL 時，光硬盤使用就需要幾個 TB（主從）?！?/p>

業(yè)務(wù)背景

在業(yè)務(wù)尚未擴張之前，韻達采用的是 MySQL 分區(qū)+索引方式進行數(shù)據(jù)處理，但隨著企業(yè)的發(fā)展、業(yè)務(wù)量的增加，面對每日億級的數(shù)據(jù)量，MySQL 顯然已經(jīng)無法滿足當下的數(shù)據(jù)處理需求。隨后，韻達決定進行數(shù)據(jù)庫選型，考慮到目前業(yè)務(wù)主要是統(tǒng)計各個網(wǎng)點設(shè)備實時上傳的數(shù)據(jù)，無需再進行修改等操作，是典型的時序數(shù)據(jù)。經(jīng)過一番調(diào)研和測試，韻達發(fā)現(xiàn) TDengine 就很符合當下的業(yè)務(wù)要求。

架構(gòu)圖

當前韻達的架構(gòu)是 Spring Boot + MyBatis + MySQL + TDengine，TDengine 負責處理時序數(shù)據(jù)，MySQL 則負責非時序數(shù)據(jù)的存儲及應(yīng)用，整體架構(gòu)如下：

?? 點擊案例查看更多技術(shù)細節(jié)

貨拉拉 x TDengine

“值得一提的是，TDengine 的 SQL 原生語法支持時間維度聚合查詢，同時數(shù)據(jù)存儲壓縮率?存儲空間小， 這兩點直接切中了我們的痛點。落地后實測相同數(shù)據(jù)的存儲空間只有 MySQL 存儲空間的 1/10 甚至更少。還有?個驚喜是，在現(xiàn)有監(jiān)控數(shù)據(jù)存儲(MySQL)頂不住的情況下，?臺 8C16GB 的單機版 TDengine 時序數(shù)據(jù)庫輕松就抗下目前所有監(jiān)控流量和存儲壓力，且運行穩(wěn)定，基本沒有故障?！?/p>

業(yè)務(wù)背景

目前貨拉拉 DBA 團隊管理的數(shù)據(jù)存儲包括 MySQL、Redis、Elasticsearch、Kafka、MQ、Canal 等，為了保證監(jiān)控采樣的實時性，其自研的監(jiān)控系統(tǒng)設(shè)置的采樣間隔為 10 秒，每天都會產(chǎn)生龐大的監(jiān)控數(shù)據(jù)，監(jiān)控指標的數(shù)據(jù)量達到 20 億+。隨著管理實例越來越多，使用 MySQL 來存儲規(guī)模日益龐大的監(jiān)控數(shù)據(jù)越發(fā)力不從心，急需進行升級改造。結(jié)合實際具體需求，通過對不同時序數(shù)據(jù)庫進行調(diào)研，最終貨拉拉選擇了 TDengine，順利完成了數(shù)據(jù)存儲監(jiān)控的升級改造。

架構(gòu)圖

?? 點擊案例查看更多技術(shù)細節(jié)

中通 x TDengine

“通過項目初期的表現(xiàn)，可以知道 TDengine 能夠輕松滿足我們的業(yè)務(wù)需求，輕松支撐起業(yè)務(wù)中使用比較頻繁的幾種查詢。未來我們還有其他的使用規(guī)劃，后續(xù)接入的車輛將會達到幾萬輛，對于部標機產(chǎn)生的相關(guān)時序數(shù)據(jù)的使用也會越來越多，期待 TDengine 可以繼續(xù)為車聯(lián)網(wǎng)場景下的查詢提供更為多樣性的支持?！?/p>

業(yè)務(wù)背景

車聯(lián)網(wǎng)業(yè)務(wù)是中通科技配送全鏈路業(yè)務(wù)中非常重要的一環(huán)，通過人、車、貨、場全鏈條覆蓋的車聯(lián)網(wǎng)設(shè)備應(yīng)用，實現(xiàn)物流運輸全鏈路感知。在中智車聯(lián)服務(wù)平臺的實際項目需求中，需要實時查詢車輛最新位置狀態(tài)，達到車輛運營可視化管理。在進行數(shù)據(jù)庫選型時，其對比了 Prometheus 和 TDengine 這兩款很有代表性的時序數(shù)據(jù)庫，最終被 TDengine “一個設(shè)備采集點一張表”的底層設(shè)計，及自帶的降采樣和窗口函數(shù)等優(yōu)秀性能所吸引。

架構(gòu)圖

?? 點擊案例查看更多技術(shù)細節(jié)

寫在最后

據(jù)國家郵政局數(shù)據(jù)顯示，我國快遞業(yè)發(fā)展迅猛，已經(jīng)連續(xù)幾年保持 50% 左右的爆發(fā)式增長，為經(jīng)濟增長注入了強大的活力，然而高速發(fā)展的同時也面臨著越來越多的數(shù)據(jù)處理難題，好在大數(shù)據(jù)處理方案也在與時俱進。以上企業(yè)用實際案例證明，對于物流企業(yè)，時序數(shù)據(jù)庫在降本增效上確實更加顯著，值得更多有此類需求的企業(yè)嘗試。