作者：大資料模型
本篇文章出自 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 會慢一些。
據了解，TDengine 基于 TSBS 的測試報告将于近日出爐，第一期報告針對 InfluxDB 和 TimeScaleDB 進行了詳細的性能層面的對比分析，感興趣的小夥伴最近可以多多關注下公衆号的内容。
“放到今天，TDengine 一定是首選”
我對 TDengine 的認識和了解要從過去的項目經驗說起，以 2018 年為背景，我給大家講述一個工業界壞件故障件預測的故事。
某知名集團随着公司業務的快速增長、新工廠的不斷增加，各種有價值的資料不能很好的整合、分析與挖掘出它應有的價值。此時公司發展已經進入下一輪“拼”的戰略，快速響應與準确預測是業務發展的關鍵，大資料在其中起到舉足輕重的作用，以科學的分析手法整合各系統資料、推動工廠制造智能化發展，成為一件迫在眉睫的工作。
目前工廠生産過程中出現了同一種特殊問題的 glass id，glass 的品質由于各種原因是參差不齊的，甚至會有品質異常的 glass。這些異常 glass 在檢測過程中，是無法檢測出異常原因的，如果無法快速定位出異常原因，就會造成更多的異常 glass，嚴重影響生産。應對的具體手段包括：
- 通過品質異常的 glass，找到産生此異常的相關性因子。如：機台、物料、載具、參數等。
- 異常 glass 偵測預警，通過對産生品質異常的因子進行數學模組化，預測出偏離正常範圍的異常玻璃，提前預警。
- 分析 glass 的特征值與特征值之間的關聯關系，并建立預測模型，提前預測出 glass 的特征值。
- 分析 glass 相關的電壓、電阻、電流、溫度、濕度影響。
很明顯這是資料挖掘的項目，要分析以上 glass 在生産過程中的環境資訊、檢測機台資料、量測機台資料、制程參數資訊，以及 FDC、OEE 系統的資料，才能找出産生這種問題的原因。第一步是資料收集整合，第二步是資料探索，第三步是模型調校——找出可能性、影響最大的因素的特征因素，第四步是投入生産驗證，通過 spark ml 提供預測動力。
當時的技術棧用的是 CDH，首先要通過 Kafka 采集資料，Spark對接 Kafka 進行初步計算去噪并彙總到 Hadoop 裡面，以 parquet 的格式儲存，如果需要進一步的加工，就通過 impala 進行。這樣每天挂起 N 個任務，不停的排程計算。
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的具體細節，歡迎大家在GitHub上檢視相關源代碼。