時序數據庫進入雲原生時代,濤思數據創始人陶建輝詳解TDengine3.0

　　在 8 月 13 日的 TDengine 開發者大會上，濤思數據創始人陶建輝進行了題為《高性能、雲原生的極簡時序數據處理平台》的主題演講。在本次演講中，他不僅分享了時序數據庫現階段的技術痛點，還深入闡釋了打造 TDengine3.0 的原因以及實踐思路。本文根據演講内容整理而成。

　　在 2017 年剛開始做時序數據庫(Time-Series Database，TSDB)時，學物理的我想當然地認為做好數據庫沒有大家說的那麼難，但做了 5 年後才發現，這真的不是一件很容易的事。下面我具體說說難在哪裡：

　　水平擴展性（Scalability）問題。 在 TDengine 剛開發沒多久時，我用一台 128 核的機器對 TDengine 進行了測試，結果性能遠遠沒有達到預期，這件事情也讓我清楚地意識到，理想的水平擴展能力很難實現。

　　沒有真正的雲原生化。 我個人特别堅信雲是未來，數據庫也一定要走向雲原生(Cloud Native)，但在深度研究市面上的數據庫産品後，我發現大部分數據庫都不是雲原生，而僅僅是“雲就緒”(Cloud Ready)，即數據庫服務提供商在轉售雲平台。真正的雲原生數據庫應該具備存算分離、計算和存儲能力彈性擴張、能夠在雲上部署、自動化部署等特點。

　　複雜性（Complex）問題。 2016 年我看到很多人在處理一些簡單的時序數據時，要把整個 Hadoop 系統搬過來，要加 HBase 層，還要把 Flink、Spark 等等全部加上，這對于研發人員來講就是個災難。但時至今日，這個複雜性也并沒有随着時序數據庫的發展得到充分的解決，隻有打造一個集 Kafka、Flink、Spark、Redis 等第三方工具功能于一體的極簡時序數據處理平台，這一問題才有望充分解決。

　　數據分析能力跟不上。 諸如 InfluxDB、Prometheus 等較為流行的 Time-Series Database，由于不支持 SQL，導緻很多正常的數據服務、數據倉庫的分析方法都用不上。結合我過往不斷跨界的經驗，我發現了這個問題，所以 TDengine 早就支持了 SQL，不過仍然需要優化和加強。

　　發現并解決上述的問題，便是我們打造 TDengine 3.0 的初衷。從去年 6 月開始，在 40 多個研發一年多的努力下，TDengine 3.0 終于在今天正式和大家見面了。

　　下面我們就一起看看 TDengine 3.0 是什麼樣子的。

　　雲原生時序數據庫

　　水平擴展

　　TDengine 的新分布式架構

　　打造雲原生時序數據庫，第一個要素就是必須是分布式架構。其實 TDengine 以前也是分布式架構，但為了實現雲原生的種種特性，我們在此架構基礎上引入了一個新的節點——計算節點 Qnode。

　　那通過雲原生如何解決可擴展性問題?還是通過分片分區來解決，數據切分的方法我們沒有做太多改動，TDengine 一開始就是這麼做的，在時間軸上以天或周為單位對數據進行切分，同時将定量設備的數據分配給每個區(Vnode)進行處理。

　　跟 2.x 相比，3.0 的不同就是元數據的管理也變成了完全分布式的。 這也是我在此前版本中吸取了一個教訓而做出的改變，最開始我沒想到元數據的管理如此之難。

　　有一次我們和塗鴉聊合作，他們要測五千萬個設備的數據，TDengine 2.0 在測試中就出現了高基數問題。在 2.x 的設計中，我們的元數據統一存放在 mnode 中，這在此次測試中就成為了一個瓶頸——在進行聚合操作時，光是把五千萬個設備中的标簽數據拉出來就需要很長時間，聚合速度可想而知。也因此，高基數成為了我們在 3.0 版本中解決的首要問題。

　　現在的 TDengine 管理節點不再存儲每個設備或每張表的元數據了，而是把這些元數據還有時序數據完全存儲在 vnode 裡，之後會用 B+ 樹、一次性哈希來處理。這樣一來，我們在插入一個數據到任何一個片或者一個區時都不再需要經過任何中間節點，徹底解決了高基數的問題。

　　經過測試，TDengine 3.0 完全能夠支持 10 億個設備、100 台服務器節點 ，同時整個啟動時間也很快，不到一分鐘整個集群就能啟動。盡管此前的 2.6 也能支持五千萬的設備數，但啟動時間就大概要三四十分鐘，設備數量多的時候不太給力。

　　中國智能電表至少要有十億台，給十億台電表做聚合操作可以說相當不容易，解決高基數問題是很重要的，TDengine 發展到 3.0 版本才算是真正把這個問題解決了。

　　彈性

　　雲原生裡面一個很重要的東西就是彈性，它跟水平擴展的彈性還略有不同，首先一定要把計算和存儲分離，我上面說 3.0 新增了一個計算節點 Qnode，它是專門用來做計算的，但簡單查詢 Vnode 就可以直接操作了，如果牽扯到 group by、 order by 等複雜查詢，就需要在 Qnode 上進行了。

　　Qnode 的優點就是操作者可以動态地啟動、停止 ，也就是說它的計算資源可以動态地進行操控，這樣就實現了存算分離。同時 Vnode 也可以進行拆分或合并，保證存儲也可以彈性伸縮。

　　如果系統不能做到真正的彈性伸縮，就一定不是雲原生的，很多企業打着雲原生的幌子，但實際上連雲原生是什麼都說不清楚。在我看來，雲原生就是要充分利用雲平台的優勢，即計算資源、存儲資源、網絡資源，且要完全彈性，你想要就馬上給你，不想要就馬上釋放，這樣才能真正實現成本的節約。

　　韌性

　　雲原生裡還有一個重要概念叫韌性，簡單來講就是高可靠、高可用。 TDengine 在設計之初就考慮到了這一點，其高可用就是用多個副本來實現，但後面發現以前的同步算法還是存在漏洞，因此 3.0 就完全采用了标準 RAFT 協議來實現數據複制，以此保證數據一緻性。

　　除了高可用，合格的韌性還要保證系統的高可靠，保證機器即使宕機了依然還能重啟，且還能繼續工作，數據也不會丢失。

　　部署、維護

　　我們以前都是建議用戶到 Kubernetes 上部署，但并沒有出詳細的自動化流程，3.0 版本給出了詳細的 Kubernetes 部署文檔，隻需修改兩個配置文件，馬上就能部署整個集群，極其簡單。

　　除了更加理解雲原生，3.0 給我帶來的另一個收獲就是對于可觀測性的理解，可觀測性其實遠遠不隻是監控，它包括了 logging、tracing、metrics，我們在 3.0 上實現了整個架構，讓用戶對 TDengine 所有集群的運行狀态都能真正監測到，讓系統維護變得更加簡單。在維護上，還有關鍵一點就是要做到自動化，一切都要腳本化，減少人工手動操作的成本。

　　極簡的時序數據處理平台

　　在 TDengine 創建之初，打造一款極簡的時序數據處理平台就是我的初衷。要知道，一個通用的架構往往是要先把采集數據送到 Kafka 或者各種消息隊列裡，消費之後一部分數據再送到 Spark 或者 Flink 裡做流計算處理，一部分數據送到數據庫做直接存儲，還有一部分則會傳輸到 Redis 做緩存，這樣一個數據處理平台，裡面要集成很多軟件，維護起來相當困難。

　　要打造一款極簡的時序數據處理平台，首先要解決的問題就是緩存，因為緩存對于物聯網、車聯網來講都是極其關鍵的，TDengine 早就具備了緩存功能，這個也是很多用戶特别喜歡的功能，非常方便。

　　TDengine 的數據訂閱實現機制

　　對于 TDengine 3.0 來說，還有一個很大的改進是重構并優化了數據訂閱功能。 TDengine 是用 WAL 來做的訂閱，技術人員應該都知道，WAL 本身就可以看作一個隊列，完全按照數據到達順序來追加寫入。在 TDengine 3.0 中，既可以訂閱一個數據庫，也可以訂閱一個自帶标簽的“超級表”，直接實現過濾，比如隻想訂閱功率超過多少的智能電表數據，直接就能實現。訂閱完成後無需再拿到應用端去過濾，極大提升了數據傳輸的效率。

　　我們做産品的目的就是要讓大家用起來簡單，因此在做消息隊列功能時，API 全部對标的都是 Kafka，現在不光是初始化和每條命令，連測試都完全一樣。以前經常有友商會對标 TDengine，提出性能要超出 TDengine 一百倍之類的觀點，但标準就是自己定義的，甚至都沒有公開。但我們隻采用國際通用的測試标準來測，包括消息隊列，直接用 Kafka 公開的 benchmark 進行測試，我們認為這樣才有說服力，才是客觀的。歡迎大家體驗。

　　TDengine 3.0 還有一個很大的改進就是繼續優化了流計算功能。 之前 TDengine 就已經支持一個連續查詢的流計算，這種周期性的查詢流計算還是很有用的，但是功能覆蓋卻還不夠。在 IoT 場景下做數據清洗、過濾時，要做一些實時的觸發，必須使用事件驅動的流計算，經過一年多的努力，TDengine 3.0 終于升級了這計算功能。

　　全新優化的流計算功能

　　TDengine 3.0 所支持的流計算功能是非常典型的，如上面的架構圖所示，數據源要先進入 Input Queue，再進入流計算的 Task，再輸出到另外一個列。而且流計算可以嵌套，一層一層形成一個數據的 pipeline。從方便用戶使用的角度出發，TDengine 的流計算語法就是 SQL，裡面做了 windows 等擴展，可以在數據寫入時觸發，也可以在窗口結束觸發。

　　此外， TDengine 3.0 對 UDF 的支持也進行了優化。 3.0 對 UDF 進行了重新實現，加上時間驅動的流計算，我覺得至少在時序數據的場景下，TDengine 已經能夠完全代替 Spark 和 Flink。

　　極簡的時序數據處理平台

　　但在此我需要再重申一下，我們優化 TDengine 的緩存、消息隊列、流計算等功能，并不是想代替 Flink、Spark、Kafka 這類通用型的消息隊列軟件、流計算軟件，隻是想簡化這款基于時序數據場景做的數據庫軟件，更加便于大家使用，通過降低系統複雜度來真正降低運維和存儲成本，這也是我們搭建極簡時序數據處理平台的原因。

　　便捷的數據分析

　　重新構建查詢引擎

　　TDengine 3.0 還有一個較大的改變就是重新設計了計算引擎 ，現在像 Planner、優化器、執行器等都具備了。對于數據來說，查詢是非常重要的，數據存儲好之後，用戶最重要的就是要從中挖掘數據價值，TDengine 對 SQL 的支持已經做的很好了。

　　但是 SQL 這個概念也很複雜，我們不可能像 Oracle 一樣支持那麼多詳細的複雜查詢，3.0 的查詢對标的是 Hive，Hive 能做的所有的分析 TDengine 已經都能做了。此外，TDengine 也有很多針對時序數據的特有函數，比如說移動平均、時間加權平均等等。

　　重構查詢引擎的 TDengine 3.0 已經成為了一個很好的查詢工具，再輔以下面的這些手段，足以讓查詢變得更有效：

　　超級表适合做多維度分析

　　計算與存儲分離

　　數據分片、分區

　　流處理

　　曆史數據和實時數據統一分析

　　來自控制台的臨時查詢

　　Python Pandas，數據框支持

　　Grafana，用于可視化的谷歌數據工作室

　　TDengine 3.0 的最後一個更新功能叫作 taosX，它充分利用了 TDengine 的數據訂閱功能來解決增量備份、異地容災， 即把一個集群的數據複制到另外一個地方去，以實現邊雲協同。衆所周知，邊雲協同在物聯網裡面很重要，如果說工廠的數據想要同步到集團，就需要一個邊雲的盒子一層接一層做同步，而這個需求，在 TDengine 中就靠 taosX 解決了。

　　此外除了技術上的種種進步外，今天我還要給大家同步一個好消息。為了方便工業場景下大量的 Windows 客戶，TDengine 3.0 的 Windows 版本也正式發布了，包括客戶端和服務器。 同時，大概在 10 月 1 日，TDengine 的 Mac 版本也将正式對外發布，大家敬請期待。

　　目前 TDengine 3.0 的代碼已經在 GitHub 上公開，大家可以完全參照我們的 readme 文件來編譯，也可以到 TDengine 的官網去下載。如果你是一個開發者，覺得 TDengine 這個項目有意思，可以選擇加入我們的開發者社區，學習源代碼，甚至是貢獻代碼。如果你是一個物聯網或者工業互聯網應用的開發者，那歡迎你把 TDengine 應用起來，你可以加入我們的用戶群，我們很樂意回答你的問題。如果你是個 DBA ，那歡迎你馬上下載，去體驗我剛才講的各種功能。

　　中國的開源軟件特别需要大家的支持和使用，我經常跟銷售團隊起争論，比如在決定哪些功能必須放在企業版時，我就表示所有的核心功能都必須同步在開源版本上，而絕不能隻放在企業版裡。為什麼?因為想要做好開源就一定要給用戶帶來價值，我希望有越來越多的人能夠成為 TDengine 的布道者。

　　結語

　　我特别喜歡丘吉爾的這段名言，翻譯成中文就是“成功不是終點，失敗不是終結，唯有你繼續前行的勇氣最為關鍵”。從創建 TDengine 到現在，我們已經走過了 5 個年頭，開源也已經走過了 3 年，在這個過程中取得了一些小小的成功，但是我們前面的路還很漫長，我已經做好了再戰 5 年、10 年的準備。希望我在七八十歲的時候還能繼續寫代碼，和大家一起讨論問題，度過真正有價值的一生。