小 T 導讀：獅橋集團的網(wang)貨平臺與金融 GPS 系統，對于(yu)車(che)輛軌(gui)跡(ji)(ji)收集與計(ji)算有著強需求。GPS 每日產生總(zong)量(liang)在 40 億左(zuo)右，需要(yao)為業務方提供(gong)實時末次位(wei)置查(cha)詢(xun)，近 180 日行駛軌(gui)跡(ji)(ji)查(cha)詢(xun)，類似車(che)輛軌(gui)跡(ji)(ji)對比查(cha)詢(xun)，以及一些風(feng)險(xian)逾期的智能(neng)分析等(deng)(deng)等(deng)(deng)。應用 TDengine Database 后，他們的整體數據存儲縮減超過 60% 以上，節省了大量(liang)硬件資源。

一、緣起

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

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

二、業務背景

獅(shi)橋集(ji)(ji)團(tuan)的(de)網貨(huo)平臺與金融 GPS 系統，對于車輛軌跡收集(ji)(ji)與計算(suan)有(you)著強(qiang)需(xu)求。獅(shi)橋大數據團(tuan)隊(dui)自(zi)研星熠(yi)平臺采(cai)用國標 JT808 協議(yi)前(qian)(qian)置接收數據，通過(guo) Flink 實時(shi)計算(suan)寫入(ru)到(dao)多個存儲模塊，最終(zhong)利用絡繹大數據 GPS 平臺進行(xing)業(ye)務呈現(xian)，支(zhi)撐(cheng)集(ji)(ji)團(tuan)多個業(ye)務系統的(de)風控、貸前(qian)(qian)、反欺詐等模塊。GPS 每日產(chan)生總量(liang)在 40 億(yi)左右，需(xu)要為業(ye)務方提供實時(shi)末次位(wei)置查(cha)詢(xun)，近 180 日行(xing)駛軌跡查(cha)詢(xun)，類(lei)似車輛軌跡對比查(cha)詢(xun)，以及一(yi)些風險逾期的(de)智能分(fen)析等等。

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

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

階段一

最初構建系統時，由于(yu)工(gong)期、團隊規模以及(ji)服務器資源的限制，實現上非常粗糙，僅能(neng)(neng)夠完成(cheng)最基本的功(gong)能(neng)(neng)。架構大(da)概如(ru)下：

在此模式下，我(wo)們通(tong)過 MQ 接入廠商的數(shu)據，利用非(fei)分(fen)布式的實時(shi)(shi)計算能(neng)力傳輸到系統(tong)當(dang)中，僅(jin)僅(jin)實現(xian)了實時(shi)(shi)的位置查詢以及一些非(fei)常基礎的功(gong)能(neng)。

階段二

之(zhi)后(hou)我(wo)(wo)們進(jin)行了(le)一(yi)次很大的(de)改版(ban)，構建起了(le)大數據(ju)(ju)集群，通過 Yarn 統(tong)一(yi)來進(jin)行資源調度(du)，采用(yong)分布式的(de)方式進(jin)行實時處(chu)理，實現了(le)彈性伸縮，同時也在做 Spark Streaming 到 Flink 的(de)過渡。業(ye)務上，從(cong)這個版(ban)本開始(shi)我(wo)(wo)們也接入了(le)不同的(de) GPS 數據(ju)(ju)源，并且(qie)針對(dui)不同數據(ju)(ju)源的(de)數據(ju)(ju)實現了(le)實時切換(huan)查詢，系統(tong)的(de)復(fu)雜度(du)提升(sheng)較高。

與此同(tong)時，GPS 的(de)(de)軌跡數據在(zai)業務中開始使用(yong)，這就要(yao)求我們必須有存(cun)儲的(de)(de)方案，需求是實時寫批量讀，即可以高效插入數據的(de)(de)同(tong)時還(huan)能夠快速掃描大(da)量數據。我們最終采(cai)用(yong)了 Kudu 進(jin)行存(cun)儲，同(tong)時利用(yong) Impala 在(zai)應用(yong)層進(jin)行 SQL 解析與加速，方便應用(yong)同(tong)學進(jin)行開發。此外，我們還(huan)需要(yao)留存(cun) GPS 的(de)(de)數據，會(hui)將(jiang)其進(jin)行壓(ya)縮并寫入到 HDFS 中。

階段三

隨著功能的(de)逐漸增加，我們對(dui)散落的(de)技(ji)術(shu)點進(jin)行(xing)了(le)不斷的(de)整合——對(dui)所(suo)有的(de)實(shi)時計算(suan)進(jin)行(xing)了(le) Flink 的(de)統一(yi)(yi)，對(dui)所(suo)有離線的(de)計算(suan)進(jin)行(xing)了(le) Spark 的(de)統一(yi)(yi)。在這個過程中，也一(yi)(yi)直在對(dui) GPS 數(shu)據的(de)存儲進(jin)行(xing)嘗試和探索(suo)。

由于 Kudu+Impala 的(de)(de)模式是(shi)一(yi)個(ge)存儲和解(jie)釋(shi)引擎(qing)(qing)分離的(de)(de)架構(gou)體系(xi)(xi)，優雅(ya)與(yu)否(fou)放在一(yi)邊(bian)，更重(zhong)要的(de)(de)是(shi)， Impala 畢竟(jing)是(shi)運行在 OLAP 平臺上的(de)(de)解(jie)釋(shi)引擎(qing)(qing)，不適合在生產環(huan)境(jing)里做高并發的(de)(de)查詢(xun)引擎(qing)(qing)，這違背 Impala 的(de)(de)設計(ji)初衷。隨著(zhu)不斷深入的(de)(de)調研，我們嘗試使用 Hbase、Clickhouse 替換(huan) Kudu。此時系(xi)(xi)統(tong)架構(gou)演變為了計(ji)算引擎(qing)(qing)逐漸固化、存儲引擎(qing)(qing)不斷迭代的(de)(de)形態。

從存(cun)儲(chu)功(gong)能而言，我們(men)希望能夠(gou)讀寫兼(jian)顧、支持 SQL，同時(shi)還有合理的分區策略，這一點(dian) Hbase 肯(ken)定(ding)不能滿足，因此我們(men)寄希望于 Clickhouse。在這個階(jie)段(duan)中 Clickhouse 的表現確(que)實也不錯，但還是沒有完全滿足需求。

階段四

2021 年，我(wo)們在(zai) GPS 平臺(tai)基礎(chu)之上進(jin)行了協議層的開發，構建了 JT808 協議層平臺(tai)，并且和原  GPS 系統進(jin)行了打通。這樣一(yi)來，我(wo)們就可以在(zai)市場上按照協議來進(jin)行廠(chang)商的篩選(xuan)，提(ti)高競價和議價能力，提(ti)升(sheng)整(zheng)個平臺(tai)的效能。而在(zai)這個過程(cheng)中，存儲(chu)層的調(diao)研也帶來了一(yi)個好(hao)消息，我(wo)們發現了一(yi)款名為 TDengine 的時(shi)序數據庫。

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

本(ben)身 GPS 的數據(ju)就類似于設備產生的數據(ju)，即時序(xu)數據(ju)，因此(ci)我(wo)們(men)開始(shi)基(ji)于時序(xu)數據(ju)庫賽道進(jin)行了一輪篩選。因為(wei)同處 TGO“大(da)家庭”中，Jeff 所創立的 TDengine 自然而然地(di)走進(jin)了我(wo)的視線中，殊(shu)不知(zhi)，這(zhe)次遇見讓我(wo)們(men)跳過了千辛萬苦(ku)，直接觸碰到了時序(xu)數據(ju)庫賽道的“天花板”。

四、為什么我會選擇 TDengine？

TDengine 有著非(fei)常精妙的架(jia)構(gou)設計，它(ta)是基于物聯(lian)網典型業務場景和數據特性所(suo)設計和優化(hua)的優秀(xiu)時序數據庫產品。下面我(wo)把一些(xie)打動我(wo)的優雅設計策略為大家(jia)進行下分享。

Device = Table

可以說，這個概念直(zhi)接顛覆了我們對于普通數(shu)據(ju)庫的認知(zhi)。無論是(shi) ClickHouse 還(huan)是(shi)其(qi)他數(shu)據(ju)庫，大都(dou)是(shi)從(cong)業(ye)務維度來構建庫表(biao)，而在(zai) TDengine 中是(shi)以采集點為單位來構建表(biao)，一(yi)個 device 就(jiu)等(deng)于一(yi)個表(biao)。

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

同時(shi)(shi)，這個新型(xing)概念也讓(rang)時(shi)(shi)序(xu)數據的寫入(ru)速度有了非(fei)常大的提升，你可(ke)以用 Kafka 的順序(xu)寫入(ru)的思路去理解。

在表級別上做了“繼承”

這(zhe)個(ge)(ge)小標題可(ke)能不(bu)太貼(tie)切，但(dan)是它帶來的(de)效(xiao)果有些類似。眾所周知，TDengine 有個(ge)(ge)超(chao)級表(biao)(biao)(biao)的(de)概念，通(tong)過(guo)定義超(chao)級表(biao)(biao)(biao)的(de)標簽可(ke)以歸類不(bu)同(tong)的(de)超(chao)級表(biao)(biao)(biao)，每一(yi)個(ge)(ge)超(chao)級表(biao)(biao)(biao)是一(yi)類普(pu)通(tong)表(biao)(biao)(biao)的(de)抽象集合(he)統稱，在進(jin)行普(pu)通(tong)表(biao)(biao)(biao)的(de)聚合(he)操作(zuo)時，通(tong)過(guo)其“繼承”（或者叫(jiao)做實現）的(de)超(chao)級表(biao)(biao)(biao)進(jin)行預(yu)聚合(he)（類似于索引查詢），可(ke)以大幅(fu)提升效(xiao)率，減少(shao)磁盤(pan)掃描。

科學的邏輯單元劃分

在(zai) TDengine 中，所有的(de)邏(luo)(luo)輯(ji)(ji)單元都(dou)叫做 node，在(zai)每個 node 之前加一(yi)個字母，不同的(de)邏(luo)(luo)輯(ji)(ji)節點就(jiu)誕生了：

• 物理節點(Pnode)，代表物理(機)節點，通俗來說即裸金屬節點
• 數據節點(Dnode)，代表運行實例，也是數據存儲的組合單元
• 虛擬節點(Vnode)，是真正負責數據存儲與使用的最小工作單元，Vnode 組合而成 Dnode

這種劃分的(de)科學之處就(jiu)在(zai)于，數據(ju)進(jin)行(xing)分片時(shi)將 Dnode 中的(de) Vnode 進(jin)行(xing)分散即可(ke)，而每一個 Vnode 中會(hui)有多個 device 的(de)數據(ju)表，這個類似(si)于 MongoDB 的(de) Sharding 的(de)機制。根據(ju) TDengine 的(de)設計初衷，為了(le)對(dui)(dui) device 中的(de)數據(ju)進(jin)行(xing)連(lian)續(xu)有序的(de)存儲，它會(hui)針(zhen)對(dui)(dui)一個 device 進(jin)行(xing)單 Vnode 的(de)強(qiang)映射，而不會(hui)拆(chai)成多個 Vnode，這樣就(jiu)避免(mian)了(le)因數據(ju)散落(luo)在(zai)不同(tong)位置(zhi)（物理節點）還需要通過網(wang)絡 merge 的(de)問題，最大程度(du)上提升了(le)效率。

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

Mnode 的兩個精妙之處

在上面的(de)解釋中，我特意避開了(le) Mnode 的(de)說明，下面我要單(dan)獨(du)講(jiang)解。

從邏輯意義上理解(jie) Mnode 很簡單，就是 Meta Data 的管理者，在很多中間(jian)件中都(dou)有這個角色，比如 Hadoop 的 NameNode、Kafka 中通(tong)過 Zookeeper 保存的 Metadata 信息。但是 TDengine 的 Mnode 有兩個功能非常巧妙。

Mnode 是幽靈般的存在，究竟在哪一個 Dnode 上都是系統自動實現的，用戶無法選擇。當用戶需要訪問 TDengine 的集群時，肯定要先知道 Mnode 在哪里，繼而才能通過 Mnode 來獲取集群信息和數據，這個過程是通過 taosc（client 模塊）進行訪問的。設計的精妙之處在于，這個過程中你直接訪問集群中的任何一個 Dnode 都可以獲取到 Mnode 的信息，從而免去了從一個 metadata center 中去獲取元數據。這種設(she)計策略在 ES 和新版的(de) Kafka 中(zhong)(zhong)都(dou)在使用，用一句話形容就是形式上去中(zhong)(zhong)心化的(de)元數據存儲與獲(huo)取機(ji)制，在這一點的(de)架(jia)構設(she)計上，TDengine 走在了時代的(de)前列。

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

五、我們在 TDengine 上的實踐

軌跡數據存儲與查詢

鑒于 TDengine 的特(te)性，用(yong)它來(lai)存(cun)儲(chu)軌跡數據(ju)(ju)非常合適(shi)。我(wo)們在 JT808 協議平臺后掛上了 Kafka，通過(guo)(guo) Flink 直(zhi)接把(ba)數據(ju)(ju)寫(xie)(xie)入(ru)到了 TDengine 中。在和 TDengine 的小伙伴(ban)進行探討與優(you)化(hua)的過(guo)(guo)程中，我(wo)們驚奇地發現(xian)，TDengine 寫(xie)(xie)入(ru)時的 driver 多采用(yong)堆外內存(cun)的讀寫(xie)(xie)策略，對數據(ju)(ju)緩存(cun)和寫(xie)(xie)入(ru)做(zuo)了極(ji)大的優(you)化(hua)，寫(xie)(xie)入(ru)效率非常高(gao)。

在數據查詢上，由于 TDengine 天然支(zhi)持 SQL，應用開發同學的(de)學習成本呈現(xian)幾(ji)何級的(de)下降，極(ji)大地提升(sheng)了開發效(xiao)率(lv)。對他(ta)們來說(shuo)，數據不(bu)管(guan)是(shi)(shi)(shi)(shi)存(cun)在 MySQL 還是(shi)(shi)(shi)(shi) Oracle 抑或是(shi)(shi)(shi)(shi) TDengine 都(dou)是(shi)(shi)(shi)(shi)完全透明的(de)。

末次位置查詢

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

大家都知道 LRU，這種管理緩(huan)存策略的(de)(de)初衷(zhong)是(shi)，我(wo)們不知道數(shu)據以何種方(fang)式(shi)進(jin)入到系統中，只(zhi)能用隨(sui)機(ji)與無序(xu)來(lai)(lai)定義數(shu)據，通(tong)過(guo) LRU 的(de)(de)機(ji)制(zhi)可以篩選出未(wei)來(lai)(lai)可能會(hui)被使用的(de)(de)數(shu)據來(lai)(lai)進(jin)行(xing)緩(huan)存，用“猜想”的(de)(de)方(fang)式(shi)來(lai)(lai)提供查詢(xun)加速。

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

自動化的分區與數據保存策略

上文中我們講到過 TDengine 的分片機制，那分區又是如何做到的？在我們使用時發現，TDengine 可以設置 days 的參數進行數據存儲，以時間范圍對數據進行分區。簡單來說(shuo)，我們(men)的(de)(de)場(chang)景是(shi)搜索(suo)過去 180 天(tian)內的(de)(de)軌(gui)跡數(shu)據(ju)，但(dan)是(shi)更多的(de)(de)場(chang)景都(dou)是(shi)以月(yue)的(de)(de)緯度來搜索(suo)，那我們(men)我們(men)可以把 days 設(she)置(zhi)成 30，這樣數(shu)據(ju)就(jiu)是(shi)以每個月(yue)分塊，搜索(suo)的(de)(de)時候也是(shi)整體撈出，效(xiao)率非常高。

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

使用 TDengine 后的效果

從時序(xu)數據(ju)(ju)量大的特點出發，TDengine 有(you)著一系列非常高效的壓縮(suo)手段。大家可能都知(zhi)道 ES 中(zhong)的 FOR 或(huo)者 RBM 等壓縮(suo)算(suan)法，我猜想 TDengine 中(zhong)應該也使用了類似的壓縮(suo)方式，使得(de)整(zheng)體數據(ju)(ju)輕巧且有(you)序(xu)。

應用 TDengine 后，我們整體數據存儲縮減超過 60% 以上，集群更是指數級的下線——末次(ci)位置(zhi)查詢的(de) Redis、軌跡(ji)查詢的(de) Hbase 集(ji)群集(ji)體下掉、Clickhouse 也(ye)不(bu)再(zai)用作(zuo)軌跡(ji)存儲，把裸金屬用在了(le)(le)更需要(yao)蠻力干活的(de)地方(fang)。目前 TDengine 在“降本”方(fang)面給予了(le)(le)我們巨大的(de)幫(bang)助，相信未來在其助力下，我們也(ye)會在“增(zeng)效(xiao)”的(de)道路上越走越遠。

六、寫在最后

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

希望(wang) TDengine Database 未(wei)來能(neng)多(duo)舉辦一(yi)些(xie)(xie) Meetup 來進行更(geng)多(duo)的交流(liu)，也可以做一(yi)些(xie)(xie) Best Practice 的講解。在(zai)一(yi)些(xie)(xie)語言與中間件上(shang)，直接出一(yi)些(xie)(xie)簡單的 Showcase，便于大家上(shang)手實踐，一(yi)起來見證這個時代最好的時序數據(ju)庫的成長。

作者簡介

楊路(lu)，前獅橋(qiao)集團(tuan)大數據團(tuan)隊(dui)負(fu)責人，深耕大數據平(ping)臺(tai)架構(gou)與(yu)三高應用平(ping)臺(tai)建設，標準技術控一枚(mei)。InfoQ 連載(zai)《大畫 Spark》作者。