> 在 8 月 13 日的[ TDengine]( https://www.taosdata.com/?zh" TDengine") 開發者大會上，TDengine 分散式系統架構師關勝亮帶來題為《支援 10 億時間線、100 個節點的 TDengine 分散式系統架構設計》的主題演講，詳細闡述了 TDengine 3.0 新的架構設計思路。本文根據此演講整理而成。

在物聯網大資料時代，隨著企業業務的不斷擴張，需要採集的裝置數量急劇上升，通常要達到百萬甚至千萬的級別，採集頻率也從以前的 15 分鐘一個點逐漸演變到現在的 1 分鐘、30 秒、15 秒，甚至 1 秒的一個點，這麼多資料還要源源不斷地發往雲端，如何進行更好地寫入、儲存及查詢，成為企業亟待解決的難題。

在測點數暴漲、資料採集頻次不斷提高的大資料時代，傳統實時資料庫暴露出下列問題：

- 沒有水平擴充套件能力，如果資料量增加，只能依靠硬體 scale up
- 技術架構陳舊，使用磁碟陣列，大多執行在 Windows 環境下
- 資料分析能力偏弱，不支援現在流行的各種大資料分析介面
- 不支援雲端部署，更無法支援 PaaS

在此背景下，依靠 Hadoop 架構形成的一系列通用資料儲存解決方案，成為一眾企業的首選，為了能夠適配更多的業務場景，還要整合如 Kafka、Redis、Spark 等眾多第三方開源軟體，在一次次的實踐中，也暴露出諸多問題，如開發效率低、執行效率差、運維複雜以及應用推向市場慢等。

在此基礎上，[時序資料庫（Time Series Database）]( https://www.taosdata.com/?zh"時序資料庫（Time Series Database）")應運而生了。雖然新興的時序資料庫之間競爭激烈，但因為業務場景的複雜性和資料的多樣性，還沒有哪一款產品真正成為物聯網場景的領跑者，而大部分產品還都存在以下三點難以忽視的問題：

- 功能單一，需要整合其他軟體，提升系統負重及運維難度
- 不是標準 SQL，學習成本高
- 沒有實現真正的雲原生化，水平擴充套件能力有限

在調研了數百個業務場景的基礎上，TDengine 完成了 3.0 版本的迭代，叢集支援 10 億條以上的時間線、100 臺伺服器節點，成為一款真正的雲原生時序資料庫，具有極強的彈性伸縮能力，且無需再整合 Kafka、Redis、Spark、Flink 等軟體，可以大幅降低系統架構的複雜度。

**TDengine 分散式系統架構設計**

![](http://img.blog.itpub.net/blog/2022/08/25/06beaeb9a1e3fdfb.png?x-oss-process=style/bb)

如上圖所示，在資料節點（Dnode）、虛擬節點（Vnode）、管理節點（Mnode）之上，**TDengine 3.0 叢集新增了彈性計算節點（Qnode）和流計算節點（Snode）。**其中 Qnode 主要在執行查詢計算任務中起作用，當一個查詢執行時，依賴執行計劃，排程器會安排一個或多個 Qnode；Snode 主要負責執行流計算任務，可以同時執行多個。

![](http://img.blog.itpub.net/blog/2022/08/25/4a3a7091f97708fd.png?x-oss-process=style/bb)

**針對資料庫級別的後設資料管理，3.0 版本透過兩階段提交來保證關鍵操作的一致性，**以上圖為例，假設我們要建立一張超級表，系統首先會把 SQL 語句先解析成請求發給 Mnode，之後 Mnode 會把這個請求發給各個不同的 Vnode（ Vnode1 和 Vnode2），最後我們會等這些請求都結束之後再做一個持久化，然後把它返回給客戶。

![](http://img.blog.itpub.net/blog/2022/08/25/d8a6f55046922ef6.png?x-oss-process=style/bb)

但在實際操作中，資料庫級別的後設資料，量是比較少的，更多的還是資料表級別的後設資料管理。在以前的版本中，後設資料都是集中管理，而 TDengine 3.0 會把後設資料都放到 Vnode 裡，在放棄中心節點之後，水平擴充套件能力顯著提升。這樣一來，當應用要將資料插入到一張表或對一張表做查詢操作時，我們就可以基於表名的特定 hash 值，將請求直接傳送到對應的 Vnode 裡，效能可以得到進一步提升。

資料表中大量標籤資料的處理也是一個重點，比如說一個裝置的標籤有 1K，那 100 萬個裝置合在一起的話可能就會產生 1GB 的後設資料，如果把它們都放在記憶體裡，啟動速度自然就會變得比較慢。

為了解決這個問題，**新的版本採用了 LRU 機制，只有使用比較頻繁的資料才會被放在記憶體中。**在全記憶體的情況下，對於千萬級別規模的標籤資料 TDengine 能做到毫秒級的返回，那在記憶體資源不足的情況下，我們仍然能夠支援數千萬張錶快速的查詢。同時 TDengine 還提供了 TTL 機制，方便對一些只需要儲存一個月或半年的資料，進行刪除過期資料表的操作。

**憑藉著 LRU 機制，TDengine 的每一個 Vnode 都能支援十萬乃至百萬以上資料表的管理。**不同於 Prometheus，TDengine 的每個資料表可以有很多個欄位，這樣的話假設說一個表有十個欄位，我們就可以認為每個 Vnode 可以支援百萬的時間線。

此外，資料表路由的資訊也是非常重要的。此前 TDengine 每一條資料表的路由資訊都需要在 Mnode 做登記，再把登記的資訊轉給 Vnode，我們想要做的事務頻率會越來越多，那可能就會導致每一個系統的 warmup 時間越來越長。而且在剛開始部署一套系統時，就需要先把這些表都建立好，壓力非常大。

![](http://img.blog.itpub.net/blog/2022/08/25/a4c10839e940529e.png?x-oss-process=style/bb)

為了解決這個問題，**TDengine 3.0 做了一個特殊的創新，即資料表的路由採用一致性 hash 演算法，**具體來說就是把資料表的名稱壓縮到 2 的 32 次方長度的一個環形空間，在建立 Database 時就建立指定數目的 Vnode，系統就會按照等分的方法，把它拆解到這一環形空間中，每一個 Vnode 就負責其中某一個 hash 範圍的資料表，並由 Mnode 來負責 hash 範圍的管理。

在系統縮容、擴容時還可以透過動態調整 hash 範圍來實現，比如上面這個環形，我們想把 Vnode 數量從 5 個變成 6 個，只需要調整其中某一個 Vnode 的 hash 範圍就可以做到了，這樣一來，TDengine 就能夠支援在 100 個資料節點上建立 Vnode 了。

大家可能會有一個疑問，如果用 hash 會不會產生比較嚴重的資料傾斜，如果你只有一百個裝置或者一千個裝置，這種傾斜可能是比較嚴重的，這時你可以建立數目較少的 vgroup，最少可以設定一個，一個 vgroup 包含 1-1000 個資料表時，效能差別不大。當你達到一萬個裝置時，這種傾斜我們基本都看不出來了，資料是非常均勻分佈的狀態。

**TDengine 支援特定查詢場景的效能調優**

所有的查詢效能也好，寫入效能也好，本質上都是為了降低對硬碟的讀寫次數，如果儲存量降下來了，那讀取速度自然就可以獲得更大的提升。一般來講，一個硬碟的寫入速度大概在 70MB/s 左右，讀取速度可能在 100MB/s，資料庫沒有辦法突破這樣一個物理上的瓶頸，那我們想要做到億級資料或者十億級資料這樣一個秒級的查詢計算，就必須想盡各種各樣的方法對資料進行降取樣，降低它的儲存量。

從這一思路出發，在 TDengine 3.0 中，我們也做了很多查詢效能上的最佳化，具體體現在如下的三個功能上：

**- 1.Block-Wise SMA（寫入過程中，儲存資料塊的預計算結果）**

![](http://img.blog.itpub.net/blog/2022/08/25/fa3454a00591ab19.png?x-oss-process=style/bb)

- 記憶體資料積累到一定大小觸發寫磁碟
- 由行儲存轉化為列儲存
- 在磁碟中以資料塊 Block 形式組織
- 把 Block 中各列資料的聚合結果，例如 max、min、sum、count 等儲存到 sma 檔案
- 根據查詢計劃選擇使用哪些聚合結果

**2.Rollup SMA（原始資料自動進行降取樣儲存）**

![](http://img.blog.itpub.net/blog/2022/08/25/7a59f03ab7b3380b.png?x-oss-process=style/bb)

- 支援三個不同的資料儲存層級，指定每層資料的聚合週期和儲存時長
- level 1 儲存原始資料，可以在 level 1 中儲存一條或者多條資料，level 2 和 3 儲存聚合資料
- Rollup 目前支援 avg, sum, min, max, last, first
- 適用於 DevOps 等關注資料趨勢的場景，本質是降低儲存開銷，加速查詢，同時拋棄原始資料

**3.Time-Range-Wise SMA（按照聚合結果降取樣儲存）**

![](http://img.blog.itpub.net/blog/2022/08/25/139f73c34cebea6c.png?x-oss-process=style/bb)

- 適用於高頻使用 interval 的查詢場景
- 採用與普通流計算一樣的邏輯，允許使用者透過設定 watermark 應對延時資料，相對應的實際的查詢結果也會有一定的延遲

**標籤索引**

我們在 3.0 裡也做了很多標籤索引的最佳化，新實現了一個 TDB 模組，特徵就是把標籤資料進行了 LRU 的儲存，這在前面也提到過。TDB 的查詢適用於標籤變化不頻繁或者說是有結構化標籤的裝置，例如文字型和數值型別。

**對於 JSON 型別的標籤，特點是標籤量很大但是資料內容很小，TDengine 採用的就是 FST 的索引方式。**索引的重建一直是 FST 裡面比較複雜的部分，TDengine 採用非同步方式重建索引資料，因而不會讓使用者在建立表或者修改表時等待太長的時間。

對於資料快取，雖然 TDengine 2.0 也可以快取最新的資料，但記憶體的消耗量會比較大，而在 3.0 中用基礎的 LRU 庫就可以把最近的資料放在記憶體裡面，讓使用者即便用很小的記憶體，也可以查到最近使用比較頻繁的資料。

**計算資源彈性擴充**

![](http://img.blog.itpub.net/blog/2022/08/25/7ffc52c23e4f7259.png?x-oss-process=style/bb)

如上圖所示，當客戶端要進行明細資料查詢時，需要先從磁碟裡或者記憶體裡源源不斷地把原始資料讀出來，這時我們肯定不希望這個資料要在不同節點裡進行大量的資料交換，增加網路或磁碟開銷，從這一點出發，TDengine 將明細資料查詢放在了 Vnode 中進行。

但在做一些聚合查詢（資料的計算、合併、插值等）時，比如說在車聯網場景下要觀察所有車輛每一天發動多長時間，這一類查詢都是在 Qnode 中進行，根據不同場景大家可以選擇配置不同數量的 Qnode。

**在時序場景下降低對 Kafka、Flink、Spark 的依賴**

![](http://img.blog.itpub.net/blog/2022/08/25/cfc68aa8e936c21f.png?x-oss-process=style/bb)

在時序場景下，TDengine 降低了對 Kafka 的依賴，我們的 Vnode 可以允許不同的消費者同時消費資料，所有的資料都是結構化的資料，使用者可以只訂閱自己關注的這部分資料，比如說我只想關注電流裡面超限的資料，使用 TDengine 進行訂閱時的資料傳輸總量非常小，但用 Kafka 進行資料訂閱時很可能需要從伺服器拉取全部的資料，然後在客戶端中進行資料篩選，這時兩者的效能就完全不在一個量級上了。

此外，如果是常用的一些計算，還可以把它們放到 Snode 裡，Snode 會將流計算的結果放到單獨 Vnode 裡面去做儲存，有了這樣一個流計算的引擎，就大大降低了對 Flink 和 Spark 的依賴。

**結語**

![](http://img.blog.itpub.net/blog/2022/08/25/4890173329dc173e.png?x-oss-process=style/bb)

TDengine 3.0 的架構改進，從關鍵特性上來看，除了水平擴充套件性之外，還增強了彈性和韌性，可作為一個極簡的時序資料處理平臺，能夠讓大家以更低的成本完成時序資料平臺的搭建。接下來我們還會陸續釋出 TDCloud 雲服務版本、TDLite 嵌入式版本，提供邊雲協同軟體包、資料預測軟體包，進一步提升系統高可用、高可靠、計算能力。

大家可以馬上[下載]( https://github.com/taosdata/TDengine"下載")體驗 TDengine 3.0，也歡迎大家多提寶貴意見。

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

想了解更多 TDengine Database的具體細節，歡迎大家在[GitHub]( https://github.com/taosdata/grafanaplugin"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 3.0 架構詳解

相關文章