> 小 T 導讀：面對海量的車載軌跡資料，四維圖新資料儲存面對非常大的壓力——每分鐘的軌跡資料大概有 2000 萬條記錄，他們此前使用的 Elasticsearch 儲存方式不僅造成了嚴重的物理資源浪費，還存在查詢瓶頸，所以急需轉換資料儲存中介軟體。本文講述了四維圖新在資料庫選型測試、搭建與遷移等方面的相關實踐經驗。

**企業簡介**
四維圖新成立於 2002 年，是中國導航地圖產業的開拓者。經十餘年的創新發展，其已成為導航地圖、導航軟體、動態交通訊息、位置大資料以及乘用車和商用車定製化車聯網解決方案領域的領導者。如今，四維圖新以全面的技術發展戰略迎接汽車“新四化”時代的來臨，致力於以高精度地圖、高精度定位、雲服務平臺以及應用於 ADAS 和自動駕駛的車規級晶片等核心業務，打造“智慧汽車大腦”，賦能智慧出行，助力美好生活，成為中國市場乃至全球更值得客戶信賴的智慧出行科技公司。

**專案介紹**
在某車企專案中，面對車載軌跡資料 2000 萬/分鐘的寫入量，整體資料儲存的壓力非常之大。此前我們採用的是 Elasticsearch，共設定了 15 個節點（ 32 核 / 48GB 記憶體 / 2TB 磁碟空間），不到半個月磁碟佔用量就已經達到 80% 了，非常耗用物理資源。同時大量的 IO 操作不僅導致 PaaS 層不穩定，也波及到了其他的依賴資源，如雲主機、中介軟體等。在此背景下，轉換資料儲存中介軟體已經迫在眉睫。

從資料特點和處理需求出發，我們選擇了更加專業的時序資料庫。從資料插入、查詢、儲存效能提升，硬體或雲服務成本降低、設計架構簡化和叢集版本開源這四個維度進行選型考慮，最終我們初步選擇了 TDengine，隨即便著手進行模擬測試。

**一、選型測試**
針對時序資料庫 TDengine 的寫入效能優勢，我們選取了一些業務場景接入的軌跡資料進行寫入測試，測試環境如下圖所示：
![](http://img.blog.itpub.net/blog/2022/04/28/dd65b89c7c436dee.png?x-oss-process=style/bb)

我們以 40 萬記錄/天/輛車，共計 150 天、120 輛車的資料進行寫入測試，寫入的記錄總數為 72 億，匯流排程數為 40，最終的寫入和儲存效能對比如下圖：
![](http://img.blog.itpub.net/blog/2022/04/28/fa233696af1caa71.jpeg?x-oss-process=style/bb)

**總結：相比 Elasticsearch，TDengine 的儲存空間利用率提升8倍，寫入效能提升 2.5 倍。**

因為之前 blocks 只有預設的值，所以在後續測試中我們按照業務實際場景修改成了 100，將每 Vnode 寫入快取塊數做了適當的最佳化。
![](http://img.blog.itpub.net/blog/2022/04/28/87fc9be1ce0af95f.png?x-oss-process=style/bb)

之後我們從單日資料、單輛車資料、單日單車資料三個維度對 TDengine 進行查詢測試，測試結果如下圖所示：
![](http://img.blog.itpub.net/blog/2022/04/28/716756c47ab1efac.jpeg?x-oss-process=style/bb)

**總結：相比 Elasticsearch，TDengine 的“count（*）”查詢效能提升 4 倍，“select*”查詢效能提升 3-10 倍。**

此外，TDengine 支援查詢單個裝置一個時間段資料的需求，和我們的業務場景不謀而合；它的類 SQL 設計也非常便利，幾乎不需要學習成本，運維管理成本也幾乎為零。同時，它還是國產開源資料庫，相比其他開源軟體，能給中國的軟體工程師提供更好的本地服務。作為一款完全自主研發的時序資料庫，TDengine 的穩定性和安全性也已經被很多企業驗證過，相對已經比較成熟了。

經過多重測試和考量，最終我們選擇將 TDengine 接入到系統之中，以支撐當下的業務需求。

**二、實際執行**
在接入 TDengine 之後，業務上近實時的寫入大量軌跡資料的需求輕鬆實現，資料部門可以日更億級軌跡資料，在達成儲存要求的同時，查詢效能也能滿足下游的業務團隊使用。整體架構圖如下：
![](http://img.blog.itpub.net/blog/2022/04/28/97cc07e86e6d2a94.png?x-oss-process=style/bb)

在表結構的搭建上，我們是按照裝置和眾包車的編碼設定的 tag，建立了如下所示的索引關係。
![](http://img.blog.itpub.net/blog/2022/04/28/3cb41999e4546c69.png?x-oss-process=style/bb)

而具體到實際業務中，TDengine 仍然表現出上述測試所展現出的優秀效能。以儲存效能為例，之前我們使用 ES叢集時，15個節點只能支援3個月的資料儲存，在接入 TDengine 之後，7 個同樣配置的叢集，已經支撐了 5 個月的資料儲存。

**三、經驗分享**
實際上，在資料遷移工作中，我們的本地業務從 Elasticsearch 遷移到 TDengine 的過程並不複雜。一是由於 TDengine 支援的程式語言非常多，且是採用與 MySQL 相似的 SQL 語言，這種特性極大地簡化了遷移所需的資源成本和人力成本。此外，透過我們自研的傳輸工具，300T+ 資料的遷移工作在短時間內就完成了 。

在具體實現上，傳輸工具是採用多執行緒方式將資料讀取到 CSV，然後再批次寫入到新的叢集中，示例程式碼如下圖所示：
![](http://img.blog.itpub.net/blog/2022/04/28/47690ca3f7def5f2.png?x-oss-process=style/bb)

除此之外，在 TDengine 的應用上，我們也遇到了一些小問題，在濤思資料夥伴們的通力合作下，最終問題也都得到了解決。藉此機會將這些經驗分享出來，給大家一些參考。

我們有一個場景是“在頁面上畫一個矩形框”，剛開始我們是直接使用經緯度進行軌跡點資料的獲取，所需的時間非常長，基本沒法使用，程式碼如下所示：
![](http://img.blog.itpub.net/blog/2022/04/28/1d40742d2475062f.png?x-oss-process=style/bb)

在最佳化之後，我們使用 Spark 程式動態去請求，透過經緯度獲取某型別車的軌跡點個數，透過劃取時間點的方式，達到了最終的效果：
![](http://img.blog.itpub.net/blog/2022/04/28/bbb8e19ba9509378.png?x-oss-process=style/bb)

在後期使用 TDengine 進行多維度、大資料量查詢的時候，出現了查詢效能線性下降的問題，後面我們透過查詢官網資料，再對比本地的叢集配置引數以及資料建模方式，最終找到了效能問題的原因，而後結合本地應用場景以及未來業務規模進行了重新配置和資料建模，成功解決了查詢效能的問題。

所以，如果大家在應用 TDengine 的過程中出現了一些問題，建議可以先去官網查詢資料，官網文件非常全面，可以稱得上是 TDengine 使用的“百科全書”了，一些小問題都可以在這裡找到解決辦法。

**四、寫在最後**
基於 TDengine 在當下業務中所表現出的優異成績，我們在未來考慮向 TDengine 中接入更大規模的軌跡資料以及其他業務中的時序資料。也希望未來我們能借力 TDengine，實現大量的軌跡計算及挖掘，將公司內部的資料實現快速變現，加速充電樁業務的發展，依賴 LBS 幫助客戶挖掘更多的潛在客戶，實現多邊共贏。

**作者簡介**
曹志強，四維圖新位置服務部門資料平臺負責人，主要負責解決整個集團的資料接入、儲存、查詢和使用，支撐公司內部自動駕駛和智慧城市的資料治理工作。

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

想了解更多 TDengine 的具體細節，歡迎大家在[GitHub](https://github.com/taosdata/TDengine "GitHub")上檢視相關原始碼。
[![](http://img.blog.itpub.net/blog/2022/03/31/0fd6ee826ee55f96.jpeg?x-oss-process=style/bb)](https://www.taosdata.com/?utm_source=itpub&utm_medium=tdengine&utm_campaign=usecase&utm_term=20220428)

替代 Elasticsearch，TDengine 助力四維圖新將儲存空間利用率提升 8 倍

相關文章