在(zai) 8 月 13 日的 TDengine 開(kai)發(fa)者大(da)會上(shang)，TDengine 分布式系統架(jia)構(gou)師關勝亮帶來題(ti)為(wei)《支持 10 億(yi)時(shi)間線(xian)、100 個(ge)節點的 TDengine 分布式系統架(jia)構(gou)設計(ji)》的主題(ti)演(yan)(yan)講，詳細闡述了 TDengine 3.0 新(xin)的架(jia)構(gou)設計(ji)思路。本文根(gen)據此演(yan)(yan)講整理而成(cheng)。

點擊【這里】查看完整演講視頻

在物聯網大數(shu)據(ju)時(shi)代，隨(sui)著企業業務的(de)(de)不斷擴張，需要采(cai)集的(de)(de)設備(bei)數(shu)量急劇上升，通常要達到百萬(wan)甚(shen)至(zhi)千萬(wan)的(de)(de)級(ji)別，采(cai)集頻率(lv)也從以前(qian)的(de)(de) 15 分鐘一個(ge)點逐漸(jian)演變(bian)到現(xian)在的(de)(de) 1 分鐘、30 秒、15 秒，甚(shen)至(zhi) 1 秒的(de)(de)一個(ge)點，這么多數(shu)據(ju)還要源源不斷地發往云(yun)端(duan)，如何進行更好地寫入、存(cun)儲及查詢，成為企業亟待解決的(de)(de)難題。

在測點數(shu)暴漲、數(shu)據(ju)采(cai)集頻次不斷提高的大數(shu)據(ju)時代，傳統實時數(shu)據(ju)庫暴露出下列問(wen)題(ti)：

• 沒有水平擴展能力，如果數據量增加，只能依靠硬件 scale up
• 技術架構陳舊，使用磁盤陣列，大多運行在 Windows 環境下
• 數據分析能力偏弱，不支持現在流行的各種大數據分析接口
• 不支持云端部署，更無法支持 PaaS

在(zai)此背景(jing)下，依(yi)靠 Hadoop 架構(gou)形成的(de)一系列通用(yong)數據(ju)存(cun)儲解決方案，成為一眾(zhong)企業(ye)的(de)首選(xuan)，為了能夠(gou)適(shi)配更多的(de)業(ye)務場(chang)(chang)景(jing)，還(huan)要集(ji)成如 Kafka、Redis、Spark 等(deng)眾(zhong)多第三方開源軟(ruan)件，在(zai)一次次的(de)實(shi)踐中，也暴露出諸多問題，如開發效(xiao)率低、運行效(xiao)率差、運維復(fu)雜以及應用(yong)推向市場(chang)(chang)慢(man)等(deng)。

在此基礎上，時序數據庫（Time Series Database）應運而(er)生了。雖然新興的時序數據庫之間競爭激(ji)烈，但因為業務場(chang)景(jing)(jing)的復雜性(xing)和數據的多樣性(xing)，還(huan)沒有(you)哪一款產品(pin)真正成(cheng)為物聯網場(chang)景(jing)(jing)的領跑者，而(er)大部分產品(pin)還(huan)都存在以(yi)下三(san)點難(nan)以(yi)忽視的問(wen)題：

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

在調(diao)研(yan)了數百(bai)個業(ye)務(wu)場景的(de)基礎上(shang)，TDengine 完成了 3.0 版本的(de)迭代(dai)，集群支持 10 億條以(yi)上(shang)的(de)時(shi)間線(xian)、100 臺(tai)服(fu)務(wu)器節點，成為一款真正的(de)云原生時(shi)序(xu)數據庫，具有極強的(de)彈性(xing)伸縮能(neng)力，且無需再集成 Kafka、Redis、Spark、Flink 等(deng)軟(ruan)件，可(ke)以(yi)大幅降低(di)系統架(jia)構的(de)復雜度(du)。

TDengine 分布式系統架構設計

如上圖所示，在數據節點（Dnode）、虛擬節點（Vnode）、管理節點（Mnode）之上，TDengine 3.0 集群新增了彈性計算節點（Qnode）和流計算節點（Snode）。其中 Qnode 主(zhu)要(yao)在(zai)運(yun)行(xing)查詢計(ji)(ji)算(suan)任務(wu)(wu)中起(qi)作(zuo)用，當一(yi)個查詢執(zhi)行(xing)時，依(yi)賴執(zhi)行(xing)計(ji)(ji)劃(hua)，調(diao)度(du)器會安排一(yi)個或(huo)多(duo)個 Qnode；Snode 主(zhu)要(yao)負責運(yun)行(xing)流(liu)計(ji)(ji)算(suan)任務(wu)(wu)，可以同時執(zhi)行(xing)多(duo)個。

針對數據庫級別的元數據管理，3.0 版本通過兩階段提交來保證關鍵操作的一致性，以(yi)上(shang)圖為(wei)例，假設我們(men)要創建一(yi)張超級表，系統首先(xian)會把 SQL 語句先(xian)解析成請(qing)(qing)求(qiu)發給 Mnode，之(zhi)后(hou) Mnode 會把這個請(qing)(qing)求(qiu)發給各個不同的 Vnode（ Vnode1 和(he) Vnode2），最后(hou)我們(men)會等這些(xie)請(qing)(qing)求(qiu)都結束之(zhi)后(hou)再(zai)做一(yi)個持久化，然后(hou)把它返回給客戶。

但在實際操作中，數據(ju)(ju)庫級別的(de)元數據(ju)(ju)，量(liang)是(shi)比較少的(de)，更多的(de)還是(shi)數據(ju)(ju)表級別的(de)元數據(ju)(ju)管(guan)(guan)理。在以(yi)前的(de)版本(ben)中，元數據(ju)(ju)都是(shi)集中管(guan)(guan)理，而 TDengine 3.0 會把元數據(ju)(ju)都放到 Vnode 里，在放棄中心節點(dian)之后(hou)，水平(ping)擴展能(neng)力顯著提升。這樣一(yi)來，當應(ying)(ying)用要將數據(ju)(ju)插入到一(yi)張表或對一(yi)張表做查(cha)詢操作時，我們(men)就可以(yi)基于表名的(de)特定 hash 值，將請求直接發(fa)送(song)到對應(ying)(ying)的(de) Vnode 里，性能(neng)可以(yi)得(de)到進一(yi)步提升。

數(shu)據表中大量標(biao)簽數(shu)據的處理也(ye)是一(yi)個(ge)重點，比(bi)如(ru)說一(yi)個(ge)設(she)備(bei)的標(biao)簽有 1K，那(nei) 100 萬(wan)個(ge)設(she)備(bei)合在一(yi)起的話可能就會(hui)產生 1GB 的元數(shu)據，如(ru)果把它(ta)們都放在內存里，啟(qi)動(dong)速度(du)自然(ran)就會(hui)變得比(bi)較慢。

為了解決這個問題，新的版本采用了 LRU 機制，只有使用比較頻繁的數據才會被放在內存中。在全內存的(de)(de)(de)情況下，對于千萬級別(bie)規模的(de)(de)(de)標簽數據(ju)(ju) TDengine 能做到(dao)毫秒級的(de)(de)(de)返回，那在內存資(zi)源不足的(de)(de)(de)情況下，我們(men)仍然能夠(gou)支持數千萬張表快速(su)的(de)(de)(de)查詢。同時 TDengine 還(huan)提(ti)供了(le) TTL 機制，方便對一些只(zhi)需要存儲一個月(yue)或半(ban)年的(de)(de)(de)數據(ju)(ju)，進行刪(shan)除過期數據(ju)(ju)表的(de)(de)(de)操作。

憑借著 LRU 機制，TDengine 的每一個 Vnode 都能支持十萬乃至百萬以上數據表的管理。不(bu)同于 Prometheus，TDengine 的每個(ge)數據表(biao)可以有很(hen)多個(ge)字(zi)段，這(zhe)樣(yang)的話假設(she)說(shuo)一個(ge)表(biao)有十個(ge)字(zi)段，我們就可以認為每個(ge) Vnode 可以支持百萬的時間線(xian)。

此外，數據(ju)表(biao)路(lu)(lu)由的信息(xi)也是非(fei)常重(zhong)要(yao)的。此前 TDengine 每一(yi)條(tiao)數據(ju)表(biao)的路(lu)(lu)由信息(xi)都需要(yao)在 Mnode 做登記(ji)，再把(ba)(ba)登記(ji)的信息(xi)轉給 Vnode，我(wo)們想要(yao)做的事務頻(pin)率會越(yue)來(lai)越(yue)多，那可能(neng)就(jiu)會導(dao)致(zhi)每一(yi)個系(xi)(xi)統(tong)的 warmup 時(shi)間越(yue)來(lai)越(yue)長。而(er)且在剛開始(shi)部署(shu)一(yi)套系(xi)(xi)統(tong)時(shi)，就(jiu)需要(yao)先把(ba)(ba)這些(xie)表(biao)都創建好，壓力非(fei)常大。

為了解決這個問題，TDengine 3.0 做了一個特殊的創新，即數據表的路由采用一致性 hash 算法，具體來(lai)說就是把數據(ju)表(biao)的(de)(de)名稱(cheng)壓縮到 2 的(de)(de) 32 次方(fang)長度的(de)(de)一個(ge)環(huan)形空間(jian)，在創(chuang)建 Database 時就創(chuang)建指(zhi)定(ding)數目的(de)(de) Vnode，系統就會按照等分的(de)(de)方(fang)法(fa)，把它(ta)拆解到這(zhe)一環(huan)形空間(jian)中，每(mei)一個(ge) Vnode 就負責(ze)其中某一個(ge) hash 范圍的(de)(de)數據(ju)表(biao)，并由(you) Mnode 來(lai)負責(ze) hash 范圍的(de)(de)管理。

在系統縮容、擴容時還可以通過(guo)動態(tai)調整 hash 范(fan)圍來(lai)實(shi)現，比如上面這個環形，我(wo)們(men)想把 Vnode 數量從 5 個變成 6 個，只需要調整其中某一(yi)(yi)個 Vnode 的 hash 范(fan)圍就(jiu)(jiu)可以做到了，這樣一(yi)(yi)來(lai)，TDengine 就(jiu)(jiu)能(neng)夠支(zhi)持在 100 個數據節(jie)點(dian)上創建 Vnode 了。

大家可(ke)(ke)能會(hui)有一(yi)(yi)個(ge)疑問，如果(guo)用(yong) hash 會(hui)不(bu)會(hui)產生比較嚴重的(de)(de)數(shu)據(ju)傾斜(xie)，如果(guo)你只有一(yi)(yi)百個(ge)設(she)(she)備(bei)或(huo)者一(yi)(yi)千個(ge)設(she)(she)備(bei)，這種(zhong)傾斜(xie)可(ke)(ke)能是比較嚴重的(de)(de)，這時(shi)你可(ke)(ke)以創建(jian)數(shu)目較少(shao)的(de)(de) vgroup，最少(shao)可(ke)(ke)以設(she)(she)置一(yi)(yi)個(ge)，一(yi)(yi)個(ge) vgroup 包含(han) 1-1000 個(ge)數(shu)據(ju)表(biao)時(shi)，性(xing)能差別不(bu)大。當你達到一(yi)(yi)萬(wan)個(ge)設(she)(she)備(bei)時(shi)，這種(zhong)傾斜(xie)我們基本都看不(bu)出來了，數(shu)據(ju)是非常均勻分布的(de)(de)狀態。

TDengine 支持特定查詢場景的性能調優

所有的(de)(de)查(cha)詢性(xing)能(neng)也好，寫入(ru)(ru)性(xing)能(neng)也好，本質上都是為了降低對(dui)硬(ying)盤的(de)(de)讀寫次(ci)數(shu)(shu)，如果存(cun)儲量降下來(lai)了，那讀取(qu)速度(du)(du)自然就(jiu)(jiu)可以獲得(de)更大的(de)(de)提升。一般(ban)來(lai)講(jiang)，一個(ge)硬(ying)盤的(de)(de)寫入(ru)(ru)速度(du)(du)大概在 70MB/s 左右，讀取(qu)速度(du)(du)可能(neng)在 100MB/s，數(shu)(shu)據庫沒有辦法(fa)突破這樣一個(ge)物理(li)上的(de)(de)瓶頸(jing)，那我們想要(yao)做到(dao)億級數(shu)(shu)據或者(zhe)十億級數(shu)(shu)據這樣一個(ge)秒級的(de)(de)查(cha)詢計算，就(jiu)(jiu)必須想盡各(ge)種各(ge)樣的(de)(de)方法(fa)對(dui)數(shu)(shu)據進行降采樣，降低它的(de)(de)存(cun)儲量。

從(cong)這(zhe)一思路出發(fa)，在 TDengine 3.0 中，我們也(ye)做(zuo)了很(hen)多查詢性(xing)能(neng)上的優化，具體(ti)體(ti)現(xian)在如下的三(san)個功(gong)能(neng)上：

1. Block-Wise SMA（寫入過程中，保存數據塊的預計算結果）

• 內存數據積累到一定大小觸發寫磁盤
• 由行存儲轉化為列存儲
• 在磁盤中以數據塊 Block 形式組織
• 把 Block 中各列數據的聚合結果，例如 max、min、sum、count 等存儲到 sma 文件
• 根據查詢計劃選擇使用哪些聚合結果

2. Rollup SMA（原始數據自動進行降采樣存儲）

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

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

• 適用于高頻使用 interval 的查詢場景
• 采用與普通流計算一樣的邏輯，允許用戶通過設定 watermark 應對延時數據，相對應的實際的查詢結果也會有一定的延遲

標簽索引

我們在(zai) 3.0 里也(ye)做(zuo)了很(hen)多標簽(qian)(qian)索(suo)引的優化，新實(shi)現(xian)了一個 TDB 模塊(kuai)，特征(zheng)就是(shi)(shi)把標簽(qian)(qian)數(shu)據(ju)進行了 LRU 的存(cun)儲，這在(zai)前面也(ye)提到過。TDB 的查詢適(shi)用于(yu)標簽(qian)(qian)變化不頻繁(fan)或者說(shuo)是(shi)(shi)有結構(gou)化標簽(qian)(qian)的設備，例如文本(ben)型和數(shu)值類型。

對于 JSON 類型的標簽，特點是標簽量很大但是數據內容很小，TDengine 采用的就是 FST 的索引方式。索(suo)(suo)引的重(zhong)建一直是 FST 里面比較復雜的部分，TDengine 采用異步(bu)方式重(zhong)建索(suo)(suo)引數據，因而(er)不會讓用戶在創建表或(huo)者(zhe)修改表時等待(dai)太長的時間。

對于數據(ju)緩(huan)存，雖(sui)然 TDengine 2.0 也可以(yi)緩(huan)存最新(xin)的數據(ju)，但(dan)內存的消耗量會比(bi)較大，而在 3.0 中用(yong)基礎的 LRU 庫就可以(yi)把最近的數據(ju)放在內存里面，讓用(yong)戶即便用(yong)很小的內存，也可以(yi)查到(dao)最近使用(yong)比(bi)較頻繁的數據(ju)。

計算資源彈性擴充

如(ru)上圖所示，當客戶端要(yao)進行明(ming)細(xi)(xi)數據查詢(xun)時，需要(yao)先從磁盤里或者(zhe)內存里源源不(bu)斷(duan)地(di)把原始數據讀出來，這時我們(men)肯定不(bu)希望這個數據要(yao)在(zai)不(bu)同節點里進行大量的數據交(jiao)換，增加網絡或磁盤開銷(xiao)，從這一點出發，TDengine 將明(ming)細(xi)(xi)數據查詢(xun)放在(zai)了 Vnode 中(zhong)進行。

但在做一(yi)些聚合查詢（數據的計算、合并、插值(zhi)等(deng)）時(shi)，比如說(shuo)在車聯網場(chang)景(jing)下要觀察所有車輛(liang)每一(yi)天發動多長時(shi)間，這一(yi)類(lei)查詢都(dou)是在 Qnode 中(zhong)進行，根據不(bu)同場(chang)景(jing)大家(jia)可(ke)以選擇(ze)配置不(bu)同數量的 Qnode。 

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

在時(shi)序場(chang)景下，TDengine 降低了(le)對 Kafka 的依賴，我們的 Vnode 可(ke)以允許不(bu)同(tong)的消費者(zhe)(zhe)同(tong)時(shi)消費數(shu)(shu)(shu)據(ju)(ju)(ju)，所(suo)有的數(shu)(shu)(shu)據(ju)(ju)(ju)都是結構化的數(shu)(shu)(shu)據(ju)(ju)(ju)，用(yong)戶可(ke)以只訂(ding)閱(yue)自己關注的這(zhe)部(bu)分(fen)數(shu)(shu)(shu)據(ju)(ju)(ju)，比如(ru)說我只想關注電(dian)流里面超(chao)限(xian)的數(shu)(shu)(shu)據(ju)(ju)(ju)，使(shi)用(yong) TDengine 進(jin)行(xing)訂(ding)閱(yue)時(shi)的數(shu)(shu)(shu)據(ju)(ju)(ju)傳(chuan)輸總量非常(chang)小，但用(yong) Kafka 進(jin)行(xing)數(shu)(shu)(shu)據(ju)(ju)(ju)訂(ding)閱(yue)時(shi)很可(ke)能需(xu)要從服務(wu)器(qi)拉取(qu)全(quan)(quan)部(bu)的數(shu)(shu)(shu)據(ju)(ju)(ju)，然后(hou)在客(ke)戶端中進(jin)行(xing)數(shu)(shu)(shu)據(ju)(ju)(ju)篩選，這(zhe)時(shi)兩者(zhe)(zhe)的性能就完全(quan)(quan)不(bu)在一(yi)個量級上了(le)。

此外，如(ru)果是常用(yong)的(de)一些計算，還可以(yi)把(ba)它們放(fang)到 Snode 里(li)，Snode 會(hui)將流計算的(de)結果放(fang)到單獨(du) Vnode 里(li)面(mian)去做(zuo)存儲(chu)，有了這樣一個流計算的(de)引擎(qing)，就大大降低了對 Flink 和 Spark 的(de)依賴。

結語

TDengine 3.0 的(de)架構改(gai)進，從關鍵特性(xing)(xing)(xing)上來看，除了(le)水(shui)平擴(kuo)展性(xing)(xing)(xing)之外，還增強了(le)彈(dan)性(xing)(xing)(xing)和韌性(xing)(xing)(xing)，可(ke)(ke)作(zuo)為一個極簡的(de)時(shi)(shi)序數(shu)據(ju)處理平臺(tai)(tai)，能夠讓大家以更(geng)低的(de)成本完(wan)成時(shi)(shi)序數(shu)據(ju)平臺(tai)(tai)的(de)搭建。接下來我們還會陸(lu)續發布 TDCloud 云(yun)服務版(ban)本、TDLite 嵌入式版(ban)本，提供邊云(yun)協同軟(ruan)件包、數(shu)據(ju)預測軟(ruan)件包，進一步提升系(xi)統高可(ke)(ke)用、高可(ke)(ke)靠、計算(suan)能力。

大家可以馬上體驗(yan) TDengine 3.0，也歡迎大家多(duo)提寶貴意見。