小 T 導讀：獅橋集團的網貨平臺與金融 GPS 系統，對於車輛軌跡收集與計算有著強需求。GPS 每日產生總量在 40 億左右，需要為業務方提供實時末次位置查詢，近 180 日行駛軌跡查詢，類似車輛軌跡對比查詢，以及一些風險逾期的智慧分析等等。應用 TDengine 後，他們的整體資料儲存縮減超過 60% 以上，節省了大量硬體資源。

**一、緣起**

2021 年 10 月，我偶然讀到 Jeff（濤思資料創始人陶建輝）所作的一篇講述父親的文章，言辭之懇切，也讓我回想起了自己和父親的種種過往，於是在 TGO（鯤鵬會）微信群中加了 Jeff 的微信。彼時恰逢我們技術選型之時，在和他的寒暄之中，我瞭解到了時序資料庫 TDengine，我和 Jeff 一拍即合。帶著業務上的場景和問題，我們約見了一次，他的熱情及對 TDengine 的精妙設計深深吸引了我，對於我所提出的一些細節問題，他甚至拿出來最初寫的程式碼為我講解，吃驚之餘也讓我非常感動。

和 Jeff 的這次會面讓我更加了解了 TDengine，也讓我看到了國產開源產品的希望。經過審慎的思考，我們選擇將 TDengine 接入到系統之中，在一切塵埃落定後我整理出了這篇文章，對 TDengine 的技術架構特點、我們自身業務的實踐思路及應用效果進行了相關闡述，希望能幫到有需要的朋友。

**二、業務背景**

獅橋集團的網貨平臺與金融 GPS 系統，對於車輛軌跡收集與計算有著強需求。獅橋大資料團隊自研星熠平臺採用國標 JT808 協議前置接收資料，透過 Flink 實時計算寫入到多個儲存模組，最終利用絡繹大資料 GPS 平臺進行業務呈現，支撐集團多個業務系統的風控、貸前、反欺詐等模組。GPS 每日產生總量在 40 億左右，需要為業務方提供實時末次位置查詢，近 180 日行駛軌跡查詢，類似車輛軌跡對比查詢，以及一些風險逾期的智慧分析等等。

**三、從系統架構的迭代看業務需求**

縱觀獅橋集團的產品歷史，技術架構共進行過四個大版本的迭代。

**階段一**
最初構建系統時，由於工期、團隊規模以及伺服器資源的限制，實現上非常粗糙，僅能夠完成最基本的功能。架構大概如下：
![](http://img.blog.itpub.net/blog/2022/04/02/86f2388d6d9f1ddb.png?x-oss-process=style/bb)

在此模式下，我們透過 MQ 接入廠商的資料，利用非分散式的實時計算能力傳輸到系統當中，僅僅實現了實時的位置查詢以及一些非常基礎的功能。

**階段二**
之後我們進行了一次很大的改版，構建起了大資料叢集，透過 Yarn 統一來進行資源排程，採用分散式的方式進行實時處理，實現了彈性伸縮，同時也在做 Spark Streaming 到 Flink 的過渡。業務上，從這個版本開始我們也接入了不同的 GPS 資料來源，並且針對不同資料來源的資料實現了實時切換查詢，系統的複雜度提升較高。

與此同時，GPS 的軌跡資料在業務中開始使用，這就要求我們必須有儲存的方案，需求是實時寫批次讀，即可以高效插入資料的同時還能夠快速掃描大量資料。我們最終採用了 Kudu 進行儲存，同時利用 Impala 在應用層進行 SQL 解析與加速，方便應用同學進行開發。此外，我們還需要留存 GPS 的資料，會將其進行壓縮並寫入到 HDFS 中。
![](http://img.blog.itpub.net/blog/2022/04/02/c412823c31dd812c.png?x-oss-process=style/bb)

**階段三**
隨著功能的逐漸增加，我們對散落的技術點進行了不斷的整合——對所有的實時計算進行了 Flink 的統一，對所有離線的計算進行了 Spark 的統一。在這個過程中，也一直在對 GPS 資料的儲存進行嘗試和探索。

由於 Kudu+Impala 的模式是一個儲存和解釋引擎分離的架構體系，優雅與否放在一邊，更重要的是， Impala 畢竟是執行在 OLAP 平臺上的解釋引擎，不適合在生產環境裡做高併發的查詢引擎，這違背 Impala 的設計初衷。隨著不斷深入的調研，我們嘗試使用 Hbase、Clickhouse 替換 Kudu。此時系統架構演變為了計算引擎逐漸固化、儲存引擎不斷迭代的形態。

從儲存功能而言，我們希望能夠讀寫兼顧、支援 SQL，同時還有合理的分割槽策略，這一點 Hbase 肯定不能滿足，因此我們寄希望於 Clickhouse。在這個階段中 Clickhouse 的表現確實也不錯，但還是沒有完全滿足需求。
![](http://img.blog.itpub.net/blog/2022/04/02/0015178f122321f7.png?x-oss-process=style/bb)

**階段四**
2021 年，我們在 GPS 平臺基礎之上進行了協議層的開發，構建了 JT808 協議層平臺，並且和原  GPS 系統進行了打通。這樣一來，我們就可以在市場上按照協議來進行廠商的篩選，提高競價和議價能力，提升整個平臺的效能。而在這個過程中，儲存層的調研也帶來了一個好訊息，我們發現了一款名為 TDengine 的時序資料庫。

此前，我們對 ClickHouse 進行了一系列的測試，雖然效果還算不錯，但對於某些場景而言仍然存在問題，以軌跡查詢（一般是對單個車輛的軌跡進行查詢）為例，雖然列式儲存有著天然的優勢，但如果 HBase 的 rowkey 設計的更精巧一些，那使用 Hbase 進行時間週期的軌跡查詢將會更加直接高效，然而 HBase 天然又對 SQL 非常不友好。因此我們一直在思考一個問題，是否有一個儲存技術既可以兼併讀寫效能，又可以契合到我們的業務場景，且還是 SQL 原生的？

本身 GPS 的資料就類似於裝置產生的資料，即時序資料，因此我們開始基於時序資料庫賽道進行了一輪篩選。因為同處 TGO“大家庭”中，Jeff 所創立的 TDengine 自然而然地走進了我的視線中，殊不知，這次遇見讓我們跳過了千辛萬苦，直接觸碰到了時序資料庫賽道的“天花板”。

**四、為什麼我會選擇 TDengine？**

TDengine 有著非常精妙的架構設計，它是基於物聯網典型業務場景和資料特性所設計和最佳化的優秀時序資料庫產品。下面我把一些打動我的優雅設計策略為大家進行下分享。

**Device = Table**
可以說，這個概念直接顛覆了我們對於普通資料庫的認知。無論是 ClickHouse 還是其他資料庫，大都是從業務維度來構建庫表，而在 TDengine 中是以採集點為單位來構建表，一個 device 就等於一個表。

對於獅橋來講，如果我們有 50 萬輛車跑在路上，那麼就需要構建出 50 萬張表。乍一聽，好像有點不可思議，但是拋開固有思路，這樣做的第一個優點就是解決了我們在上述架構演變的第三階段中希望解決的問題，即我們希望一個裝置在一個時間範圍內的資料是連續儲存且可以整塊獲取的，這樣基本上殲滅了磁碟的隨機訪問，類似於 Kafka 的順序讀寫機制，可以獲得最高的效率，TDengine 在這一點上完全解決了我們的痛點。

同時，這個新型概念也讓時序資料的寫入速度有了非常大的提升，你可以用 Kafka 的順序寫入的思路去理解。

**在表級別上做了“繼承”**
這個小標題可能不太貼切，但是它帶來的效果有些類似。眾所周知，TDengine 有個超級表的概念，透過定義超級表的標籤可以歸類不同的超級表，每一個超級表是一類普通表的抽象集合統稱，在進行普通表的聚合操作時，透過其“繼承”（或者叫做實現）的超級表進行預聚合（類似於索引查詢），可以大幅提升效率，減少磁碟掃描。

**科學的邏輯單元劃分**
在 TDengine 中，所有的邏輯單元都叫做 node，在每個 node 之前加一個字母，不同的邏輯節點就誕生了：

物理節點(Pnode)，代表物理(機)節點，通俗來說即裸金屬節點
資料節點(Dnode)，代表執行例項，也是資料儲存的組合單元
虛擬節點(Vnode)，是真正負責資料儲存與使用的最小工作單元，Vnode 組合而成 Dnode
這種劃分的科學之處就在於，資料進行分片時將 Dnode 中的 Vnode 進行分散即可，而每一個 Vnode 中會有多個 device 的資料表，這個類似於 MongoDB 的 Sharding 的機制。根據 TDengine 的設計初衷，為了對 device 中的資料進行連續有序的儲存，它會針對一個 device 進行單 Vnode 的強對映，而不會拆成多個 Vnode，這樣就避免了因資料散落在不同位置（物理節點）還需要透過網路 merge 的問題，最大程度上提升了效率。

在 TDengine 中，利用的是 Vgroup 的機制保證資料的副本高可靠，這塊可以進入 TDengine 官網參看文件，寫的非常清楚。總而言之，這些職能劃分和邏輯設計使得 TDengine 既可以滿足高可靠，又能夠對 device 級別吞吐提供讀寫資料需求。當然，具體有多強，大家可以參看壓測對比，也可以自己嘗試一下。

**Mnode 的兩個精妙之處**
在上面的解釋中，我特意避開了 Mnode 的說明，下面我要單獨講解。

從邏輯意義上理解 Mnode 很簡單，就是 Meta Data 的管理者，在很多中介軟體中都有這個角色，比如 Hadoop 的 NameNode、Kafka 中透過 Zookeeper 儲存的 Metadata 資訊。但是 TDengine 的 Mnode 有兩個功能非常巧妙。

Mnode 是幽靈般的存在，究竟在哪一個 Dnode 上都是系統自動實現的，使用者無法選擇。當使用者需要訪問 TDengine 的叢集時，肯定要先知道 Mnode 在哪裡，繼而才能透過 Mnode 來獲取叢集資訊和資料，這個過程是透過 taosc（client 模組）進行訪問的。設計的精妙之處在於，這個過程中你直接訪問叢集中的任何一個 Dnode 都可以獲取到 Mnode 的資訊，從而免去了從一個 metadata center 中去獲取後設資料。這種設計策略在 ES 和新版的 Kafka 中都在使用，用一句話形容就是形式上去中心化的後設資料儲存與獲取機制，在這一點的架構設計上，TDengine 走在了時代的前列。

其次，Mnode 可以幫助監控 Dnode 的負載情況，一旦遇到 Dnode 負載壓力高、資料儲存熱點分佈不均衡的場景，Mnode 可以幫助轉移 Dnode 的資料，從而消除傾斜。值得一提的是，在這個過程中，對外服務是不會停止的。

**五、我們在 TDengine 上的實踐**

**軌跡資料儲存與查詢**
鑑於 TDengine 的特性，用它來儲存軌跡資料非常合適。我們在 JT808 協議平臺後掛上了 Kafka，透過 Flink 直接把資料寫入到了 TDengine 中。在和 TDengine 的小夥伴進行探討與最佳化的過程中，我們驚奇地發現，TDengine 寫入時的 driver 多采用堆外記憶體的讀寫策略，對資料快取和寫入做了極大的最佳化，寫入效率非常高。
![](http://img.blog.itpub.net/blog/2022/04/02/b43fb6557e8059c1.png?x-oss-process=style/bb)

**接入TDengine後流程**
在資料查詢上，由於 TDengine 天然支援 SQL，應用開發同學的學習成本呈現幾何級的下降，極大地提升了開發效率。對他們來說，資料不管是存在 MySQL 還是 Oracle 抑或是 TDengine 都是完全透明的。

**末次位置查詢**
此前，我們需要使用 Flink 把資料打入到 Redis 叢集中，進行末次位置的儲存與查詢。而 TDengine 中的“最新熱資料快取”的策略恰恰契合到了我們的需求，Redis 叢集就可以直接省略了。當我們研究到這個功能時，簡直熱淚盈眶——這不是針對某一個業務的幫助，而是在對一整個行業進行了透徹的洞察之後所設計出來的靈魂級的功能。

大家都知道 LRU，這種管理快取策略的初衷是，我們不知道資料以何種方式進入到系統中，只能用隨機與無序來定義資料，透過 LRU 的機制可以篩選出未來可能會被使用的資料來進行快取，用“猜想”的方式來提供查詢加速。

而 TDengine 本身就是為 IoT 而生，它洞察到了時序資料的特性，從而採用以時間順序來設計的 FIFO 來定義快取的策略，即新鮮的資料會落在快取中，方便企業查詢最新產生的熱資料。依靠著這個設計，我們只需要一個簡單的 SQL 即可從記憶體中以最快速度獲取想要的資料，此時 TDengine 搖身一變，就成為了一個支援 SQL 的記憶體資料庫。在部署了 TDengine 之後，我們下線了一整套的末次位置 Redis 叢集。

**自動化的分割槽與資料儲存策略**
上文中我們講到過 TDengine 的分片機制，那分割槽又是如何做到的？在我們使用時發現，TDengine 可以設定 days 的引數進行資料儲存，以時間範圍對資料進行分割槽。簡單來說，我們的場景是搜尋過去 180 天內的軌跡資料，但是更多的場景都是以月的緯度來搜尋，那我們我們可以把 days 設定成 30，這樣資料就是以每個月分塊，搜尋的時候也是整體撈出，效率非常高。

而超過 180 天的資料，我們不會去進行展示搜尋，因為資料在 HDFS 上還有壓縮的儲存，所以我們透過 TDengine 的 keep 引數來設定資料保留多久，即設定 keep=180，這樣超過 180 天的資料會被自動清除，對儲存極為友好。

**使用 TDengine 後的效果**
從時序資料量大的特點出發，TDengine 有著一系列非常高效的壓縮手段。大家可能都知道 ES 中的 FOR 或者 RBM 等壓縮演算法，我猜想 TDengine 中應該也使用了類似的壓縮方式，使得整體資料輕巧且有序。

應用 TDengine 後，我們整體資料儲存縮減超過 60% 以上，叢集更是指數級的下線——末次位置查詢的 Redis、軌跡查詢的 Hbase 叢集集體下掉、Clickhouse 也不再用作軌跡儲存，把裸金屬用在了更需要蠻力幹活的地方。目前 TDengine 在“降本”方面給予了我們巨大的幫助，相信未來在其助力下，我們也會在“增效”的道路上越走越遠。

**六、寫在最後**

從我的感受來講，TDengine 是一家年輕有活力的企業，工程師文化非常濃厚。我很喜歡和 Jeff 探討技術，每每看到他拿出筆記本開啟 IDE 看每一行的原始碼時，我就越發覺得我們應該重新認識程式設計師這個職業，偉大的不僅僅是那些商業領袖，更多的是用一行行程式碼來改變世界、懷揣著夢想卻又務實的人們。

希望 TDengine 未來能多舉辦一些 Meetup 來進行更多的交流，也可以做一些 Best Practice 的講解。在一些語言與中介軟體上，直接出一些簡單的 Showcase，便於大家上手實踐，一起來見證這個時代最好的時序資料庫的成長。

**作者簡介**

楊路，前獅橋集團大資料團隊負責人，深耕大資料平臺架構與三高應用平臺建設，標準技術控一枚。InfoQ 連載《大畫 Spark》作者。

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

想了解更多 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=20220401)

TDengine 應用實錄：儲存縮減超過 60%，HBase 等叢集指數級下線

相關文章