作者：大資料模型
本篇文章出自 2022 年“用 TDengine，寫 TDengine”徵文投稿活動。

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

因為工作的關係，最近幾年我接觸到過各種國產資料庫，唯獨對 TDengine 念念不忘。在眾多資料庫中，TiDB 一枝獨秀，OceanBase 出身名門世家，openGauss 有華為撐腰，只有 TDengine 給人有一種草莽出英雄的感覺；在開發上，TiDB 借用了 rocksDB 的效能，openGauss 是基於 postgreSQL9.2.4 開發的，即使 OceanBase 也是基於內部應用需求開始打造的，只有 TDengine 不依賴任何開源或第三方軟體自研而成。而且它不是一款通用型的資料庫，劍走偏鋒，它有自己獨特的社會應用場景，主要為工業網服務。

基於對 TDengine 的定義和理解，筆者將會在本篇文章中從 TDengine 能解決什麼問題、它的優勢與亮點、它與其它資料庫的區別等維度展開詳述，希望能幫助到對 TDengine 感興趣的小夥伴。

**“區別於通用資料庫，TDengine 拋掉無用包袱”**

資料庫想要完成出色的的讀寫，最核心的能力就是索引，一般資料庫產品都具備正向索引能力。所謂正向索引就是透過檔案記錄裡面的識別符號為關鍵字，透過關鍵識別符號不再需要進行全盤掃描。雖然 B樹索引、雜湊索引、點陣圖索引有區別，但是大方向都屬於正向索引。

除了正向索引，還有反向索引【也稱倒排索引】，反向索引主要用於全文檢索，例如 ElasticSearch，大多資料庫都是正向索引。**TDengine 也是使用正向索引，它的特別之處是識別符號肯定包含時間戳，再加上一個維度指標資料，構成一個對資料值明確的描述——某個時間某個指標物件的資料值是多少。**

從資料組織的儲存引擎來看，資料庫底層可以分為 B樹機制、LSM 機制，兩種機制沒有最好，各有各的優點和缺點：
B樹最大好處在於它對資料持續高漲讀效能的處理，即使資料量級增大，它的讀也沒有放大。 奧秘在於對資料進行終極持久儲存時，**B樹是以有序有規律的資料結構儲存在硬碟上的。**這樣隨著資料越來越大，它依然保持有序有規律的特性，面對成千上萬的讀操作，都可以遵循條件執行，減少或避免讀放大的行為。

與 B樹機制截然相反，LSM 機制則是減少避免了寫放大。LSM 機制充分利用了記憶體，在記憶體裡面開闢了一個空間，寫資料優先往記憶體裡放，寫進去直接返回使用者成功，而不是像 B樹那樣寫一個，我要找出誰比我大誰比我小，只要記憶體有夠，就直接往記憶體裡面填就好，當記憶體達到一定的閾值，**將記憶體中的資料以批次、順序的方式一次寫入硬碟上，記憶體則重置清零再服務新的寫要求。**

**傳統資料庫 MySQL、Oracle 使用的是 B樹機制，而 TiDB、OceanBae 使用的是最佳化後的 LSM 機制，而 TDengine 使用的是 B樹 + LSM 機制的方式，其中 B樹儲存的是後設資料【主要是時間戳+指標資料】，LSM 機制儲存的是具體的資料，後設資料以有序表結構方式進行儲存，而具體資料則是以追加的方式寫入，這樣即避免了讀話大和寫放大。**

一般來說，OLTP 產品為了提升併發控制的效能，必定會有寫時複製或者 MVCC 的功能選項，**寫時複製與 MVCC 雖然保障了資料的一致性，但是帶來更多的 IO 負擔。**TDengine 不需要對資料進行修改，所以不需要考慮資料一致性的問題，資料是以有序的規律並追加的形式寫進去的，因為只有讀和寫，所以也不需要鎖保護，拋掉一些無用的包袱，可以集中最佳化其它地方，例如列式表。

業界通用資料庫針對各種業務都會有行式表、列式表甚至完全的記憶體庫，對於具體的資料儲存 TDengine 使用完全列式儲存在硬碟，而維度指標則行式儲存在記憶體中。因為 TDengine 面對的是機器的資料，機器 24 小時工作精確到每個毫秒都在產生資料，為了儲存更多的資料，所以 TDengine 用上行列並存、用途分離的方式。

一般來說，資料庫裡面每一行的檔案記錄都是非常重要的，即使這行記錄資訊無關交易，只是一個使用者的基本資訊，那它的價值密度也十分高。但時序資料庫（Time Series Database）不同，單行檔案記錄價值密度低，因為 1 秒可以產生 1 萬條記錄，必須要把資料聚合彙總起來才能體現資料的價值。**快速並有效聚合普通資料使之變成價值密度高的資料，這個也是時序資料庫區別於其它資料庫的一個重要的特徵。**

TDengine目前提供了三個版本的產品：**社群版，企業版以及雲版本，** 以滿足市場的需求和個人開發者的需求。

**“拆解時序資料庫，幾大產品特點分析”**

**從技術上區分定位，TDengine 是專注時間序列領域的一個分散式的海量資料分析平臺。**它的競爭對手可以分為直接競爭對手和間接競爭對手，間接競爭對手有國內的 TiDB、OceanBase、GaussDB 以及國外的 Oracle、MySQL 等等，雖然它們在綜合技術維度上與 TDengine 沒有對標，但是分析上只要是使用時間戳，與時間序列有關係，這裡就有 TDengine 的用武之地。與 TDengine 構成直接競爭的對手有 Druid、OpenTSDB、InfluxDB，他們都是時間序列分析的前輩。

**Druid 是一個分散式系統，採用 Lambda 架構，有利於充分利用記憶體，也會把歷史資料儲存到硬碟上，按一定的時間粒度對資料進行聚合，實時處理和批處理資料解耦分開。**實時處理面向寫多讀少的場景，主要是以流方式處理增量資料，批處理面向讀多寫少的場景，主要是以此方式處理離線資料。Druid 依賴 Hadoop，叢集中採用 share nothing 的架構，各個節點都有自己的計算和儲存能力，整個系統透過 Zookeeper 進行協調。為了提高計算效能，其會採用近似計算方法包括 HyperLoglog、DataSketches 的一些基數計算。

**OpenTSDB 是一個開源的時序資料庫，支援儲存數千億的資料點，並提供精確的查詢，**採用 Java 語言編寫，透過基於 HBase 的儲存實現橫向擴充套件，OpenTSDB 廣泛用於伺服器的監控和度量，包括網路和伺服器、感測器、IoT、金融資料的實時監控領域。**OpenTSDB 在設計思路上是利用 HBase 的 key 去儲存一些 tag 資訊，將同一個小時資料放在一行儲存，以此提高查詢速度。**OpenTSDB 透過預先定義好維度 tag 等，採用精巧的資料組織形式放在 HBase 裡面，透過 HBase 的 keyRange 可以進行快速查詢，**但是在任意維度的組織查詢下，OpenTSDB的效率會降低。 **

InfluxDB 是一款非常流行的時序資料庫，採用 Go 語言開發，社群非常活躍，技術特點支援任意數量的列，去模式化，整合了資料採集、儲存和視覺化儲存，使用高壓縮比的演演算法支援高效儲存，採用 TIME SERIES MERGE TREE 的內部儲存引擎，支援與 SQL 類似的語言**（2.0 版本不再支援）**。

時間序列的業務背景，**在 OLAP 場景中一般會進行預聚合來減少資料量，**影響預聚合主要因素可以彙總如下：
- 維度指標的個數
- 維度指標的基數
- 維度指標組合程度
- 時間維度指標的粗粒度和細粒度

為了實現高效的預聚合，TDengine 的秘訣是超級表，Druid 會提前定義預計算，InfluxDB 也有自己的連續查詢方法，只有 HBase 使用時才進行拼接，所以涉及不同的維度指標查詢，HBase 會慢一些。

![](http://img.blog.itpub.net/blog/2023/02/23/4366a4461925f78b.png?x-oss-process=style/bb)

據瞭解，TDengine 基於 TSBS 的測試報告將於近日出爐**，第一期報告針對 InfluxDB 和 TimeScaleDB 進行了詳細的效能層面的對比分析，**感興趣的小夥伴最近可以多多關注下公眾號的內容。

**“放到今天，TDengine 一定是首選”**

我對 TDengine 的認識和了解要從過去的專案經驗說起，以 2018 年為背景，我給大家講述一個工業界壞件故障件預測的故事。

某知名集團隨著公司業務的快速增長、新工廠的不斷增加，各種有價值的資料不能很好的整合、分析與挖掘出它應有的價值。此時公司發展已經進入下一輪“拼”的戰略，快速響應與準確預測是業務發展的關鍵，大資料在其中起到舉足輕重的作用，以科學的分析手法整合各系統資料、推動工廠製造智慧化發展，成為一件迫在眉睫的工作。

當前工廠生產過程中出現了同一種特殊問題的 glass id，glass 的品質由於各種原因是參差不齊的，甚至會有品質異常的 glass。這些異常 glass 在檢測過程中，是無法檢測出異常原因的，如果無法快速定位出異常原因，就會造成更多的異常 glass，嚴重影響生產。應對的具體手段包括：
1. 透過品質異常的 glass，找到產生此異常的相關性因子。如：機臺、物料、載具、引數等。
2. 異常 glass 偵測預警，透過對產生品質異常的因子進行數學建模，預測出偏離正常範圍的異常玻璃，提前預警。
3. 分析 glass 的特徵值與特徵值之間的關聯關係，並建立預測模型，提前預測出 glass 的特徵值。
4. 分析 glass 相關的電壓、電阻、電流、溫度、溼度影響。

很明顯這是資料探勘的專案，要分析以上 glass 在生產過程中的環境資訊、檢測機臺資料、量測機臺資料、製程引數資訊，以及 FDC、OEE 系統的資料，才能找出產生這種問題的原因。**第一步是資料收集整合，第二步是資料探索，第三步是模型調校——找出可能性、影響最大的因素的特徵因素，第四步是投入生產驗證，透過 spark ml 提供預測動力。**

當時的技術棧用的是 CDH，首先要透過 Kafka 採集資料，Spark對接 Kafka 進行初步計算去噪並彙總到 Hadoop 裡面，以 parquet 的格式儲存，如果需要進一步的加工，就透過 impala 進行。這樣每天掛起 N 個任務，不停的排程計算。

![](http://img.blog.itpub.net/blog/2023/02/23/0081629f7d9de31a.png?x-oss-process=style/bb)

CDH Hadoop 雖然無法做到實時資料分析，但是也還能做些事，聊勝於無，就繼續用著。當時這個壞件故障件預測專案有以下痛點，主要是及時性、有效性、準確性的問題：
- 難以滿足使用者需求，某些機器資料的聚合計算需要第二天才能出結果，甚至更多的時間才能出來。
- 經濟成本的費用較高，CPU、磁碟、網路都在一個高段的使用狀態，針對越來越多的資料需要投入新機器。
- 維護成本高，你需要維護 Hadoop 所有的機器，各種 HBase、Spark、Zookeeper、HDFS 之類，不但對工程師要求高，而且工作量巨大。
- 低質量資料，因為資料流程或者錯誤的邏輯整合，導致機器感測器聚合後資料模型無法正常使用。
- 無法做到實時監測，機器資料作為寶貴的自變數因素無法及時傳輸並進行計算，自然會影響因變數。

筆者經歷了這個專案，知道這個壞件故障預測與時間序列有緊密的關係。**時至今日，時間序列分析也是重要的資料分析技術，尤其面對季節性、週期性變化資料時，傳統的迴歸擬合技術難以奏效，這時就需要複雜的時間序列模型，以時間為特徵作為抓手點。**這樣即使你不太懂業務的前提下，也可以進行資料探勘的工作。

那這個專案與 TDengine 有什麼關係呢？ 實際上，這個專案並沒有用上 TDengine，後來集團搭建了一個 Hadoop叢集試點，這次居然用了 HDP，理由很簡單，因為 HDP 預設搭載了時序資料庫 Druid。

當時技術負責人認為壞件故障預測模型的資料庫基座應該是時序資料庫，而不是 Hadoop 不停的進行資料採集、資料轉換以及各種批計算，透過時序資料庫不但可以實時計算，而且輸出的資料質量高。至於選擇哪個時序資料庫，**彼時考慮平穩過渡替換以及學習成本綜合因素後他們選擇了 Druid。**

**但當時是 2017 年，TDengine 也還沒有面世，如果放到今天，TDengine 必定是選型考慮的首選。**

要知道，TDengine 的優勢相對 Druid 要多了去了，首先 Druid 不是一個經過開源版本 1.00 正式釋出的軟體，雖然發展多年，直至 HDP 與 CDH 兩家公司融合，HDP 搭配的 Druid 也不是 1.00 版；其次 Druid 依賴 Hadoop，動輒就使用大量的資源以及各種複雜的 Hadoop 元件，最後 Druid 只提供 json 的方式，對傳統的 DBA 使用十分不友好。

TDengine 有一個我認為很秀的功能，就是它的超級表的跨指標維度建模思想，目前它僅用於**自由組合維度指標，拼接不同的時間粒度進行聚合。**在我看來，將來應用於時間序列機器學習模型也會是它的一個亮點，在資料建模方面，針對工廠的設施、裝置、機床、機房、車間、測臺等必須要做高效準確的定義。我們進行專案規劃建設時，都會做大量的資料治理工作，但是在具體實施工作上，還是要使用這些傳統工具和技術。TDengine 可以有效彙集各種機器資料來源，並且能夠高質量的提煉，這個是過去的時序資料產品所不具備的。

**“是提速，更是賦能”**

中國有句話叫做“長江後浪推前浪，一代新人勝舊人”，IT 世界千變萬化，如果你和我一樣，一直在關注著 TDengine，就會發現，它這幾年崛起的非常迅速。去年 TDengine 推出 3.0 版本，新版本升級成為了一款真正的雲原生時序資料庫，最佳化了流計算功能，而且還重新設計了計算引擎，最佳化工程師對 SQL 的使用，另外增加了 taosX，利用自己的資料訂閱功能來解決增量備份、異地容災，更加方便了企業應用。**我對 TDengine 未來的期望是，希望它增加庫內機器學習函式，增加 ARIMA 模型、MA 模型等時間相關功能，**TDengine 的未來是一個智慧學習時間序列資料庫，對工業 4. 0 來說不僅是提速，更是賦能。

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

想了解更多 [TDengine Database]( https://www.taosdata.com/?zh"TDengine Database")的具體細節，歡迎大家在[GitHub]( https://github.com/taosdata/TDengine"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 以及它所在的時序資料庫“戰場”

相關文章