因為工作的關系，最近幾年我接觸到過各種國產實時數據庫，唯獨對 TDengine 時序數據庫(Time Series DataBase,TSDB)念念不忘。在眾多時序數據庫(ku)中，TiDB 一(yi)枝(zhi)獨秀，OceanBase 出(chu)身名門世家，openGauss 有(you)華為撐腰，只有(you) TDengine 給(gei)人有(you)一(yi)種(zhong)草莽出(chu)英(ying)雄的(de)感覺(jue)；在開(kai)發上，TiDB 借用了(le) rocksDB 的(de)性能(neng)，openGauss 是(shi)(shi)(shi)基于 postgreSQL9.2.4 開(kai)發的(de)，即使 OceanBase 也(ye)是(shi)(shi)(shi)基于內部應用需(xu)求開(kai)始打造(zao)的(de)，只有(you) TDengine 不(bu)依賴(lai)任何開(kai)源或第三方軟件自(zi)研而成。而且它(ta)(ta)不(bu)是(shi)(shi)(shi)一(yi)款通用型的(de)數據庫(ku)，劍走偏鋒，它(ta)(ta)有(you)自(zi)己獨特的(de)社會應用場景，主要為工業(ye)網服務。
基于對(dui) TDengine 的定義和理解，筆者將會(hui)在(zai)本篇文章中從 TDengine 能解決什么(me)問題、它的優勢與(yu)(yu)亮(liang)點、它與(yu)(yu)其它數據庫的區(qu)別(bie)等維度展(zhan)開(kai)詳述，希(xi)望(wang)能幫助(zhu)到對(dui) TDengine 感興(xing)趣的小伙伴。
“區別于通用數據庫，TDengine 拋掉無用包袱”
數據庫想要完成出(chu)色的(de)的(de)讀寫，最核(he)心的(de)能力(li)就是索(suo)引(yin)(yin)，一般(ban)數據庫產品都具(ju)備正(zheng)向索(suo)引(yin)(yin)能力(li)。所謂正(zheng)向索(suo)引(yin)(yin)就是通過文檔記錄里面的(de)標(biao)識符為關(guan)鍵(jian)字，通過關(guan)鍵(jian)標(biao)識符不(bu)再需要進行全盤掃描。雖然 B樹索(suo)引(yin)(yin)、哈(ha)希索(suo)引(yin)(yin)、位圖索(suo)引(yin)(yin)有區別，但是大方向都屬(shu)于正(zheng)向索(suo)引(yin)(yin)。
除了正向索引，還有反向索引【也稱倒排索引】，反向索引主要用于全文檢索，例如 ElasticSearch，大多數據庫都是正向索引。TDengine 也是使用正向索引，它的特別之處是標識符肯定包含時間戳，再加上一個維度指標數據，構成一個對數據值明確的描述——某個時間某個指標對象的數據值是多少。
從數(shu)據(ju)組織的存儲引擎來(lai)看，數(shu)據(ju)庫底層可以分為 B樹(shu)機制、LSM 機制，兩(liang)種機制沒有最好，各有各的優點(dian)和缺點(dian)：
B樹最大好處在于它對數據持續高漲讀性能的處理，即使數據量級增大，它的讀也沒有放大。奧秘在于對數據進行終極持久存儲時，B樹是以有序有規律的數據結構保存在硬盤上的。這樣(yang)隨著數(shu)據(ju)越來越大，它(ta)依(yi)然保持有序(xu)有規律的(de)特性，面對(dui)成千上萬的(de)讀(du)操(cao)作(zuo)，都可以遵循條(tiao)件運行(xing)，減(jian)少或避免讀(du)放大的(de)行(xing)為(wei)。
與 B樹機制截然相反，LSM 機制則是減少避免了寫放大。LSM 機制充分利用了內存，在內存里面開辟了一個空間，寫數據優先往內存里放，寫進去直接返回用戶成功，而不是像 B樹那樣寫一個，我要找出誰比我大誰比我小，只要內存有夠，就直接往內存里面填就好，當內存達到一定的閾值，將內存中的數據以批量、順序的方式一次寫入硬盤上，內存則重置清零再服務新的寫要求。
傳統數據庫 MySQL、Oracle 使用的是 B樹機制，而 TiDB、OceanBase 使用的是優化后的 LSM 機制，而 TDengine 使用的是 B樹 + LSM 機制的方式，其中 B樹存儲的是元數據【主要是時間戳+指標數據】，LSM 機制存儲的是具體的數據，元數據以有序表結構方式進行存儲，而具體數據則是以追加的方式寫入，這樣即避免了讀話大和寫放大。
一般來說，OLTP 產品為了提升并發控制的性能，必定會有寫時復制或者 MVCC 的功能選項，寫時復制與 MVCC 雖然保障了數據的一致性，但是帶來更多的 IO 負擔。TDengine 不(bu)(bu)需(xu)要對(dui)數(shu)(shu)據進(jin)行修改，所以(yi)(yi)不(bu)(bu)需(xu)要考慮數(shu)(shu)據一致性的(de)問(wen)題，數(shu)(shu)據是以(yi)(yi)有序的(de)規律并追(zhui)加的(de)形式寫進(jin)去的(de)，因(yin)為只有讀和(he)寫，所以(yi)(yi)也不(bu)(bu)需(xu)要鎖保(bao)護，拋掉一些(xie)無用(yong)的(de)包袱，可以(yi)(yi)集中優化其(qi)它地(di)方，例如(ru)列式表。
業界通用數據庫針對各種業務都會有行式表、列式表甚至完全的內存庫，對于具體的數據存儲 TDengine 使用完全列式存儲在硬盤，而維度指標則行式保存在內存中。因為 TDengine 面對的(de)(de)是機(ji)(ji)器(qi)(qi)的(de)(de)數據，機(ji)(ji)器(qi)(qi) 24 小時工作精確到每個毫(hao)秒(miao)都在產(chan)生(sheng)數據，為了存(cun)儲更多的(de)(de)數據，所以(yi) TDengine 用上行列并存(cun)、用途分(fen)離的(de)(de)方式。
一般來說，數據庫里面每一行的文檔記錄都是非常重要的，即使這行記錄信息無關交易，只是一個用戶的基本信息，那它的價值密度也十分高。但時序數據庫（Time Series Database）不同，單行文檔記錄價值密度低，因為 1 秒可以產生 1 萬條記錄，必須要把數據聚合匯總起來才能體現數據的價值。快速并有效聚合普通數據使之變成價值密度高的數據，這個也是時序數據庫區別于其它數據庫的一個重要的特征。
TDengine目前提供了三個版本的產品：社區版，企業版以及云版本， 以滿(man)足市場(chang)的需(xu)求(qiu)和個人開發者(zhe)的需(xu)求(qiu)。
“拆解時序數據庫，幾大產品特點分析”
從技術上區分定位，TDengine 是專注時間序列領域的一個分布式的海量數據分析平臺。它的競爭對手可以分為直接競爭對手和間接競爭對手，間接競爭對手有國內的 TiDB、OceanBase、GaussDB 以及國外的 Oracle、MySQL 等等，雖然它們在綜合技術維度上與 TDengine 沒有對標，但是分析上只要是使用時間戳，與時間序列有關系，這里就有 TDengine 的用武之地。與 TDengine 構成直接競爭的對手有 Druid、OpenTSDB、InfluxDB集群版(ban)，他們都(dou)是時間序列分(fen)析的前輩。
Druid 是一個分布式系統，采用 Lambda 架構，有利于充分利用內存，也會把歷史數據保存到硬盤上，按一定的時間粒度對數據進行聚合，實時處理和批處理數據解耦分開。實時處(chu)(chu)理面向寫多(duo)(duo)讀少(shao)的(de)場景，主(zhu)要是以(yi)流方(fang)式處(chu)(chu)理增量數據，批(pi)處(chu)(chu)理面向讀多(duo)(duo)寫少(shao)的(de)場景，主(zhu)要是以(yi)此方(fang)式處(chu)(chu)理離線數據。Druid 依賴 Hadoop，集群(qun)中采用(yong) share nothing 的(de)架構，各個節點都有(you)自己的(de)計(ji)(ji)算和存儲能力(li)，整個系(xi)統(tong)通(tong)過 Zookeeper 進行協調(diao)。為了提(ti)高計(ji)(ji)算性(xing)能，其會采用(yong)近(jin)似計(ji)(ji)算方(fang)法包括 HyperLoglog、DataSketches 的(de)一些基數計(ji)(ji)算。
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 場景中一般會進行預聚合來減少數據量，影(ying)響(xiang)預聚合主要因素可以匯(hui)總如下：
- 維度指標的個數
- 維度指標的基數
- 維度指標組合程度
- 時間維度指標的粗粒度和細粒度
為了實現高(gao)效的預(yu)聚合(he)，TDengine 的秘(mi)訣(jue)是超級表，Druid 會提(ti)前定義預(yu)計算，InfluxDB 也有(you)(you)自己的連(lian)續查(cha)詢方法(fa)，只有(you)(you) HBase 使用時才進(jin)行拼接，所(suo)以涉及不(bu)同的維度(du)指標查(cha)詢，HBase 會慢(man)一些。
據了解，TDengine 基于 TSBS 的測試報告將于近日出爐，第一期報告針對 InfluxDB 和 TimeScaleDB 進行了詳細的性能層面的對比分析，感(gan)興趣的(de)小伙(huo)伴最近可(ke)以(yi)多多關注下(xia)公眾號(hao)的(de)內容(rong)。
“放到今天，TDengine 一定是首選”
我對 TDengine 的認識和了解要從過去的項目經驗說起，以 2018 年(nian)為背(bei)景，我給大家講述一個工業界(jie)壞件故障件預(yu)測(ce)的故事(shi)。
某知名集團隨著(zhu)公司業務的(de)(de)快(kuai)速增(zeng)長、新工廠(chang)的(de)(de)不(bu)斷(duan)增(zeng)加，各(ge)種有(you)價值的(de)(de)數據不(bu)能(neng)很好的(de)(de)整(zheng)合、分(fen)析(xi)與(yu)(yu)挖掘(jue)出它應有(you)的(de)(de)價值。此(ci)時(shi)公司發(fa)展已經進(jin)入下一輪“拼”的(de)(de)戰(zhan)略，快(kuai)速響應與(yu)(yu)準確預測是業務發(fa)展的(de)(de)關鍵，大數據在(zai)其(qi)中起到(dao)舉(ju)足輕(qing)重的(de)(de)作用(yong)，以(yi)科學的(de)(de)分(fen)析(xi)手(shou)法(fa)整(zheng)合各(ge)系統數據、推動工廠(chang)制造智(zhi)能(neng)化發(fa)展，成(cheng)為一件迫(po)在(zai)眉睫的(de)(de)工作。
當(dang)前工(gong)廠生產過(guo)程中出(chu)現了(le)同一種特殊問(wen)題的(de)(de) glass id，glass 的(de)(de)品質由于各種原因是參(can)差(cha)不齊的(de)(de)，甚至(zhi)會(hui)有品質異常(chang)的(de)(de) glass。這(zhe)些異常(chang) glass 在檢測過(guo)程中，是無(wu)法檢測出(chu)異常(chang)原因的(de)(de)，如(ru)果無(wu)法快(kuai)速定位出(chu)異常(chang)原因，就會(hui)造成更多(duo)的(de)(de)異常(chang) glass，嚴重影響(xiang)生產。應對的(de)(de)具體手段包(bao)括：
- 通過品質異常的 glass，找到產生此異常的相關性因子。如：機臺、物料、載具、參數等。
- 異常 glass 偵測預警，通過對產生品質異常的因子進行數學建模，預測出偏離正常范圍的異常玻璃，提前預警。
- 分析 glass 的特征值與特征值之間的關聯關系，并建立預測模型，提前預測出 glass 的特征值。
- 分析 glass 相關的電壓、電阻、電流、溫度、濕度影響。
很明顯這是數據挖掘的項目，要分析以上 glass 在生產過程中的環境信息、檢測機臺資料、量測機臺資料、制程參數信息，以及 FDC、OEE 系統的數據，才能找出產生這種問題的原因。第一步是數據收集整合，第二步是數據探索，第三步是模型調校——找出可能性、影響最大的因素的特征因素，第四步是投入生產驗證，通過 spark ml 提供預測動力。
當時的(de)(de)技術(shu)棧用的(de)(de)是(shi) CDH，首先要通(tong)過 Kafka 采集數據，Spark對(dui)接 Kafka 進行(xing)(xing)初步計算去(qu)噪并匯總(zong)到(dao) Hadoop 里(li)面，以(yi) parquet 的(de)(de)格式保(bao)存，如果需要進一步的(de)(de)加工，就通(tong)過 impala 進行(xing)(xing)。這樣每(mei)天(tian)掛起 N 個任(ren)務，不停的(de)(de)調度計算。
CDH Hadoop 雖然(ran)無(wu)法(fa)做到實時數據分(fen)析(xi)，但是(shi)也還(huan)能做些事，聊勝于無(wu)，就繼續用著。當(dang)時這個(ge)壞件故障件預測項目(mu)有以下痛點，主(zhu)要是(shi)及時性(xing)、有效(xiao)性(xing)、準(zhun)確性(xing)的問題：
- 難以滿足用戶需求，某些機器數據的聚合計算需要第二天才能出結果，甚至更多的時間才能出來。
- 經濟成本的費用較高，CPU、磁盤、網絡都在一個高段的使用狀態，針對越來越多的數據需要投入新機器。
- 維護成本高，你需要維護 Hadoop 所有的機器，各種 HBase、Spark、Zookeeper、HDFS 之類，不但對工程師要求高，而且工作量巨大。
- 低質量數據，因為數據流程或者錯誤的邏輯整合，導致機器傳感器聚合后數據模型無法正常使用。
- 無法做到實時監測，機器數據作為寶貴的自變量因素無法及時傳輸并進行計算，自然會影響因變量。
筆者經歷了這個項目，知道這個壞件故障預測與時間序列有緊密的關系。時至今日，時間序列分析也是重要的數據分析技術，尤其面對季節性、周期性變化數據時，傳統的回歸擬合技術難以奏效，這時就需要復雜的時間序列模型，以時間為特征作為抓手點。這樣即使你不太懂業務(wu)的(de)前提下，也可以進行(xing)數據(ju)挖掘(jue)的(de)工作。
那這個項目與 TDengine 有什么關系呢？實際上，這個項目并沒有用上 TDengine，后來集團搭建了一個 Hadoop集群試點，這次居然用了 HDP，理由很簡單，因為 HDP 默認搭載了時序數據庫 Druid。
當時技術負責人認為壞件故障預測模型的數據庫基座應該是時序數據庫，而不是 Hadoop 不停的進行數據采集、數據轉換以及各種批計算，通過時序數據庫不但可以實時計算，而且輸出的數據質量高。至于選擇哪個時序數據庫，彼時考慮平穩過渡替換以及學習成本綜合因素后他們選擇了 Druid。
但當時是 2017 年，TDengine 也還沒有面世，如果放到今天，TDengine 必定是選型考慮的首選。
要知道(dao)，TDengine 的(de)(de)優勢相(xiang)對(dui)(dui) Druid 要多(duo)了去了，首先 Druid 不(bu)是一個經過(guo)開(kai)源版本 1.00 正(zheng)式(shi)發布的(de)(de)軟件(jian)，雖然發展多(duo)年，直至 HDP 與 CDH 兩家(jia)公司融合，HDP 搭配的(de)(de) Druid 也不(bu)是 1.00 版；其(qi)次 Druid 依(yi)賴 Hadoop，動輒就使(shi)用(yong)大量的(de)(de)資源以及各種復雜的(de)(de) Hadoop 組件(jian)，最后 Druid 只(zhi)提供 json 的(de)(de)方式(shi)，對(dui)(dui)傳統的(de)(de) DBA 使(shi)用(yong)十分不(bu)友好(hao)。
TDengine 有一個我認為很秀的功能，就是它的超級表的跨指標維度建模思想，目前它僅用于自由組合維度指標，拼接不同的時間粒度進行聚合。在(zai)我看(kan)來，將來應(ying)用(yong)于時(shi)(shi)間(jian)序(xu)列機(ji)(ji)器(qi)學習模(mo)(mo)型也會是(shi)(shi)它的一個亮點，在(zai)數(shu)據(ju)(ju)建模(mo)(mo)方面，針對工廠的設施、設備、機(ji)(ji)床、機(ji)(ji)房、車間(jian)、測臺等必須要做(zuo)高(gao)效準確(que)的定義。我們進行項(xiang)目規劃建設時(shi)(shi)，都會做(zuo)大(da)量的數(shu)據(ju)(ju)治理工作，但(dan)是(shi)(shi)在(zai)具(ju)體(ti)實施工作上，還是(shi)(shi)要使用(yong)這些(xie)傳統工具(ju)和技術。TDengine 可以有效匯集各種機(ji)(ji)器(qi)數(shu)據(ju)(ju)源，并且(qie)能(neng)夠高(gao)質量的提(ti)煉(lian)，這個是(shi)(shi)過去(qu)的時(shi)(shi)序(xu)數(shu)據(ju)(ju)產(chan)品(pin)所不具(ju)備的。
“是提速，更是賦能”
中國(guo)有(you)句話(hua)叫做(zuo)“長江(jiang)后浪(lang)推前浪(lang)，一(yi)(yi)代(dai)新(xin)人(ren)勝(sheng)舊人(ren)”，IT 世(shi)界千變萬化(hua)，如果你(ni)和我(wo)一(yi)(yi)樣，一(yi)(yi)直(zhi)在關注(zhu)著(zhu) TDengine，就會(hui)發(fa)現(xian)，它這(zhe)幾年崛起的(de)非常迅速。去年 TDengine 推出(chu) 3.0 版(ban)本，新(xin)版(ban)本升級(ji)成為了(le)一(yi)(yi)款真正(zheng)的(de)云(yun)原生時序數據庫(ku)，優化(hua)了(le)流計(ji)算功能，而且(qie)還重新(xin)設計(ji)了(le)計(ji)算引擎，優化(hua)工程師對 SQL 的(de)使用，另外增(zeng)加(jia)了(le) taosX，利用自己的(de)數據訂閱(yue)功能來解決增(zeng)量備份(fen)、異地容災，更(geng)加(jia)方便了(le)企業應(ying)用。
我對 TDengine 未來的期望是，希望它增加庫內機器學習函數，增加 ARIMA 模型、MA 模型等時間相關功能，TDengine 的未來(lai)(lai)是(shi)一個智能學習(xi)時間序列數據(ju)庫，對工業(ye) 4. 0 來(lai)(lai)說不(bu)僅是(shi)提速，更是(shi)賦能。
