> 對於物流企業來說，如何高效地記錄和處理車輛的軌跡資訊、應對每天海量監控資料的採集和處理工作，對於專案整體的交付效率至關重要。同時，伴隨著數字化、智慧化的不斷加速，資料更是呈現出爆發式增長，老舊的資料架構越來越難以應對業務發展需求。在此背景下，諸多物流企業開始尋求資料架構的變革，特別是選擇符合業務需求的[時序資料庫]( https://www.taosdata.com/"時序資料庫")（Time Series Database，TSDB）產品，本篇文章彙總了國內四家大型物流公司的資料架構改造例項，給到讀者參考。

**[順豐 x TDengine]( https://www.taosdata.com/user-cases/2314.html"順豐 x TDengine")**

> “完成改造後，大資料監控平臺擺脫了對大資料元件的依賴，有效縮短了資料處理鏈路，自上線以來，一直執行穩定。在寫入方面，根據容量規劃完成相關引數調整後，理想情況下，叢集寫入速度最高達 90W 條/s。查詢效能方面，在使用預計算函式情況下，查詢 p99 都在 0.7 秒以內，能夠滿足我們日常絕大部分查詢需求。控制成本層面，服務端物理機由 21 臺降至 3 臺，每日所需儲存空間為 93GB（2 副本），同等副本下僅為 OpenTSDB+HBase 的約 1/10。”

**業務背景**

順豐科技大資料叢集每天需要採集海量監控資料，以確保叢集穩定執行。此前其採用了 OpenTSDB+HBase 作為大資料監控平臺全量監控資料的儲存方案，隨著接入資料量的不斷增長，這一方案衍生出了不少痛點，包括依賴多、使用成本高和效能不能滿足等問題，必須對全量監控資料儲存方案進行改造。透過對 IoTDB、Druid、ClickHouse、TDengine 等時序資料儲存方案的調研， TDengine 成為他們的最終選擇。

**架構圖**

![](http://img.blog.itpub.net/blog/2022/11/09/5953c31dc637c3a3.png?x-oss-process=style/bb)

為保證整個系統的高可用和可擴充套件性，整體架構中，前端採用nginx叢集進行負載均衡，保證高可用性；單獨分離出客戶端層，方便根據流量需求進行擴容縮容。點選案例詳情檢視三大實施難點及解決路徑。

點選[案例]( https://www.taosdata.com/user-cases/2314.html"案例")檢視更多技術細節

**[韻達 x TDengine]( https://www.taosdata.com/user-cases/7815.html"韻達 x TDengine")**

> “我們目前使用 TDengine 2.2.2.0 版本，在三臺 16C 64G 的伺服器上部署了叢集，資料寫入速度大概為每秒 5000 行。值得一提的是，基於 TDengine，常用的查詢基本可以在 1 秒之內完成，一些特定查詢甚至可以達到毫秒級。從儲存來說，同等資料體量下，TDengine 大約佔用 300GB 不到的磁碟（單副本），而此前使用 MySQL 時，光硬碟使用就需要幾個 TB（主從）。”

**業務背景**

在業務尚未擴張之前，韻達採用的是 MySQL 分割槽+索引方式進行資料處理，但隨著企業的發展、業務量的增加，面對每日億級的資料量，MySQL 顯然已經無法滿足當下的資料處理需求。隨後，韻達決定進行資料庫選型，考慮到目前業務主要是統計各個網點裝置實時上傳的資料，無需再進行修改等操作，是典型的時序資料。經過一番調研和測試，韻達發現 TDengine 就很符合當下的業務要求。

**架構圖**

當前韻達的架構是 Spring Boot + MyBatis + MySQL + TDengine，TDengine 負責處理時序資料，MySQL 則負責非時序資料的儲存及應用，整體架構如下：

![](http://img.blog.itpub.net/blog/2022/11/09/423e0ef8da0f3bf8.png?x-oss-process=style/bb)

點選[案例]( https://www.taosdata.com/user-cases/7815.html"案例")檢視更多技術細節

**[貨拉拉 x TDengine]( https://www.taosdata.com/user-cases/3626.html"貨拉拉 x TDengine")**

> “值得一提的是，TDengine 的 SQL 原生語法支援時間維度聚合查詢，同時資料儲存壓縮率⾼儲存空間小， 這兩點直接切中了我們的痛點。落地後實測相同資料的儲存空間只有 MySQL 儲存空間的 1/10 甚至更少。還有⼀個驚喜是，在現有監控資料儲存(MySQL)頂不住的情況下，⼀臺 8C16GB 的單機版 TDengine 輕鬆就抗下目前所有監控流量和儲存壓力，且執行穩定，基本沒有故障。”

**業務背景**

目前貨拉拉 DBA 團隊管理的資料儲存包括 MySQL、Redis、Elasticsearch、Kafka、MQ、Canal 等，為了保證監控取樣的實時性，其自研的監控系統設定的取樣間隔為 10 秒，每天都會產生龐大的監控資料，監控指標的資料量達到 20 億+。隨著管理例項越來越多，使用 MySQL 來儲存規模日益龐大的監控資料越發力不從心，急需進行升級改造。結合實際具體需求，透過對不同時序資料庫進行調研，最終貨拉拉選擇了 TDengine，順利完成了資料儲存監控的升級改造。

**架構圖**

![](http://img.blog.itpub.net/blog/2022/11/09/c895cd8bec66a4a1.jpeg?x-oss-process=style/bb)

點選[案例]( https://www.taosdata.com/user-cases/3626.html"案例")檢視更多技術細節

**[中通 x TDengine]( https://www.taosdata.com/user-cases/14207.html"中通 x TDengine")**

> “透過專案初期的表現，可以知道 TDengine 能夠輕鬆滿足我們的業務需求，輕鬆支撐起業務中使用比較頻繁的幾種查詢。未來我們還有其他的使用規劃，後續接入的車輛將會達到幾萬輛，對於部標機產生的相關時序資料的使用也會越來越多，期待 TDengine 可以繼續為車聯網場景下的查詢提供更為多樣性的支援。”

**業務背景**

車聯網業務是中通科技配送全鏈路業務中非常重要的一環，透過人、車、貨、場全鏈條覆蓋的車聯網裝置應用，實現物流運輸全鏈路感知。在中智車聯服務平臺的實際專案需求中，需要實時查詢車輛最新位置狀態，達到車輛運營視覺化管理。在進行資料庫選型時，其對比了 Prometheus 和 TDengine 這兩款很有代表性的時序資料庫，最終被 TDengine “一個裝置採集點一張表”的底層設計，及自帶的降取樣和視窗函式等優秀效能所吸引。

**架構圖**

![](http://img.blog.itpub.net/blog/2022/11/09/c79c4996b737a5cd.png?x-oss-process=style/bb)

點選[案例]( https://www.taosdata.com/user-cases/14207.html"案例")檢視更多技術細節

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

> 歡迎新增小T（VX：TDengine），加入物聯網技術討論群，第一時間瞭解TDengine 官方資訊，與關注前沿技術的同學們共同探討新技術、新玩法。

------------

想了解更多 [TDengine Database]( https://www.taosdata.com/?zh"TDengine Database")的具體細節，歡迎大家在[GitHub]( https://github.com/taosdata/TDengine"GitHub")上檢視相關原始碼。
[![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)](https://www.taosdata.com/?zh "![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)")

TDengine：國內4家大型物流公司的資料架構改造例項彙總

相關文章