TSBS 是一個(gè)時(shí)序數(shù)據(jù)處理（數(shù)據(jù)庫(kù)）系統(tǒng)的性能基準(zhǔn)測(cè)試平臺(tái)，提供了 IoT、DevOps 兩個(gè)典型應(yīng)用場(chǎng)景，它由 Timescale 開(kāi)源并負(fù)責(zé)維護(hù)。作為一個(gè)性能基準(zhǔn)測(cè)試平臺(tái)，TSBS 具有便捷、易用、擴(kuò)展靈活等特點(diǎn)，涵蓋了時(shí)序數(shù)據(jù)的生成、寫(xiě)入（加載）、多種類別的典型查詢等功能，并能夠自動(dòng)匯總最終結(jié)果。由于其開(kāi)放開(kāi)源的特點(diǎn)，得到了眾多數(shù)據(jù)庫(kù)廠商的支持，作為專業(yè)的產(chǎn)品性能基準(zhǔn)測(cè)試平臺(tái)被若干數(shù)據(jù)庫(kù)廠商廣泛使用。

以下的性能基準(zhǔn)報(bào)告均使用了 TSBS 作為基礎(chǔ) Benchmark 平臺(tái)，我們從時(shí)間跨度和發(fā)布廠商的知名度同時(shí)來(lái)看，就能發(fā)現(xiàn)，基礎(chǔ)測(cè)試平臺(tái) TSBS 已經(jīng)具備了很高的認(rèn)可度：

2018 年 11 月
VictoriaMetrics 的創(chuàng)始人 Aliaksandr Valialkin 發(fā)布 《High-cardinality TSDB benchmarks: VictoriaMetrics vs TimescaleDB vs InfluxDB》，將 VictoriaMetrics 與 TimescaleDB、InfluxDB 進(jìn)行性能對(duì)比。

2018 年 11 月
文章《ClickHouse Crushing Time Series》中對(duì)比了 TimescaleDB, InfluxDB, ClickHouse 在時(shí)序數(shù)據(jù)場(chǎng)景下的性能。

2020 年 3 月
Cloudera 在網(wǎng)站博客中發(fā)布《Benchmarking Time Series workloads on Apache Kudu using TSBS》，在 DevOps場(chǎng)景 中對(duì)比了 Apache Kudu, InfluxDB, VictoriaMetrics, ClickHouse 等整體性能表現(xiàn)。

2020 年 3 月
Redis 發(fā)布了基于 TSBS 的性能報(bào)告《RedisTimeSeries Version 1.2 Benchmarks》。

2020 年 8 月
Timescale 在其官方博客發(fā)布了性能對(duì)比報(bào)告《TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data》。

2021 年 8 月
QuestDB 發(fā)布了 QuestDB 與 TimescaleDB 的性能對(duì)比報(bào)告——《QuestDB vs. TimescaleDB》。

DevOps 場(chǎng)景是一個(gè)典型的時(shí)序數(shù)據(jù)應(yīng)用場(chǎng)景，TSBS DevOps 場(chǎng)景提供了 CPU 狀態(tài)的模擬數(shù)據(jù)，針對(duì)每個(gè)設(shè)備（CPU）記錄其 10 個(gè)測(cè)量值（metric），1 個(gè)時(shí)間戳（納秒分辨率），10 個(gè)標(biāo)簽值（tag）。生成的數(shù)據(jù)每 10 秒間隔一條記錄，具體的內(nèi)容和示例數(shù)據(jù)如下：

TSBS 測(cè)試可以簡(jiǎn)單劃分為兩個(gè)主要部分——數(shù)據(jù)寫(xiě)入和數(shù)據(jù)查詢。在本次整個(gè)基準(zhǔn)性能評(píng)估中，共涉及以下五個(gè)場(chǎng)景，每個(gè)場(chǎng)景的具體數(shù)據(jù)規(guī)模和特點(diǎn)見(jiàn)下表：

通過(guò)上表可以看到，五個(gè)場(chǎng)景的區(qū)別主要在于數(shù)據(jù)集所包含的設(shè)備記錄數(shù)量、設(shè)備數(shù)的不同，數(shù)據(jù)時(shí)間間隔均維持在 10 sec。整體來(lái)看，五個(gè)場(chǎng)景的數(shù)據(jù)規(guī)模都不算大，數(shù)據(jù)規(guī)模最大的是場(chǎng)景五，數(shù)據(jù)達(dá)到了 1.8 億，數(shù)據(jù)規(guī)模最小的是場(chǎng)景一，只有 2678 萬(wàn)條記錄。在場(chǎng)景四和場(chǎng)景五中，由于設(shè)備數(shù)量相對(duì)較多，所以數(shù)據(jù)集僅覆蓋了 3 分鐘的時(shí)間跨度。

為了保證測(cè)試結(jié)果的公正可靠及可復(fù)制性，我們選用了公共 IaaS 平臺(tái)來(lái)搭建 Benchmark 基礎(chǔ)硬件環(huán)境，采用了大多數(shù)性能對(duì)比報(bào)告中使用的場(chǎng)景——亞馬遜 EC2 服務(wù)環(huán)境下 r4.8xlarge 類型的實(shí)例作為基礎(chǔ)運(yùn)行平臺(tái)，區(qū)域?yàn)楸泵赖貐^(qū)，包括 1 臺(tái)服務(wù)器、1 臺(tái)客戶端?？蛻舳伺c服務(wù)器硬件配置完全相同，兩者使用 10 Gbps 網(wǎng)絡(luò)連接。配置簡(jiǎn)表如下：

本次測(cè)試的對(duì)比軟件為 InfluxDB 1.8.10 及 Timescale 2.6.0，在這里要著重說(shuō)明一下，由于 InfluxDB 最新的 2.0 版本并沒(méi)有納入 TSBS 的主干分支，因此在這次測(cè)試中我們暫且使用了 TSBS 主干分支所支持的 InfluxDB 最新版本，即 1.8.10。

整個(gè) TSBS 測(cè)試流程相對(duì)比較簡(jiǎn)單，在進(jìn)行寫(xiě)入性能對(duì)比時(shí)，配置完成參數(shù)后直接運(yùn)行 TSBS 框架腳本，等待結(jié)果輸出即可。對(duì)于查詢處理，我們選擇了批量自動(dòng)化去運(yùn)行，對(duì)每個(gè)查詢語(yǔ)句運(yùn)行 5000 次，統(tǒng)計(jì)查詢延遲的算數(shù)平均作為最后的查詢延遲結(jié)果。此外我們還全程監(jiān)控并記錄了整個(gè)過(guò)程中服務(wù)器與客戶端節(jié)點(diǎn)的系統(tǒng)資源開(kāi)銷與負(fù)載情況。

下面可以簡(jiǎn)單為大家介紹下本次測(cè)試結(jié)果。如下表所示，在全部五個(gè)場(chǎng)景中，TDengine 寫(xiě)入性能均優(yōu)于 InfluxDB 和 TimescaleDB，寫(xiě)入過(guò)程中資源占用最低。對(duì)比 InfluxDB，TDengine 寫(xiě)入最優(yōu)的場(chǎng)景是在 1000 萬(wàn)設(shè)備下，達(dá)到了 InfluxDB 的?10.6 倍；對(duì)比 TimescaleDB ，TDengine 寫(xiě)入最優(yōu)的場(chǎng)景是在 4000 個(gè)設(shè)備下，達(dá)到了 TimeScaleDB 的?6.7 倍。

在查詢測(cè)試上，我們將其分為 5 大類、15 小類進(jìn)行查詢對(duì)比，從下圖結(jié)果匯總中可以看到，在全部 15 個(gè)查詢類型中，TDengine 的性能均優(yōu)于 InfluxDB 和 TimescaleDB，并且它的所有查詢延遲均比 InfluxDB 和 TimescaleDB 更低。亮點(diǎn)數(shù)據(jù)之一體現(xiàn)在 Double Rollups 查詢類型對(duì)比中，TDengine 最大達(dá)到 InfluxDB 的?34 倍，TimescaleDB 的?24 倍。

以上就是 TDengine 基于 TSBS 測(cè)試報(bào)告的測(cè)試背景介紹，如果你對(duì)測(cè)試結(jié)果感興趣，歡迎查閱整體報(bào)告。

1、介紹

基于 DataX，我們完成了 TDengine 的適配，對(duì)于 TDengine 3.0 版本，實(shí)現(xiàn)了 TDengine30Reader 和 TDengine30Writer 兩個(gè)插件。

TDengine30Reader 提供的功能：

1. 支持通過(guò) SQL 進(jìn)行數(shù)據(jù)篩選；
2. 根據(jù)時(shí)間間隔進(jìn)行任務(wù)切分；
3. 支持 TDengine 的全部數(shù)據(jù)類型；
4. 支持批量讀取，通過(guò) batchSize 參數(shù)控制批量拉取結(jié)果集的大小，提高讀取性能。

TDengine30Writer 支持的功能：

1. 支持 OpenTSDB 的 json 格式的行協(xié)議，使用 TDengine 的 schemaless 方式寫(xiě)入 TDengine。
2. 支持批量寫(xiě)入，通過(guò) batchSize 參數(shù)控制批量寫(xiě)入的數(shù)量，提高寫(xiě)入性能。

2、實(shí)現(xiàn)原理

TDengine30Reader：使用 JNI 方式從 TDengine 拉取數(shù)據(jù)。

TDengine30Writer：使用 JNI 方式寫(xiě)數(shù)據(jù)到 TDengine。對(duì) OpenTSDB 等使用 schemaless 寫(xiě)入，對(duì)于 MySQL 等關(guān)系型數(shù)據(jù)庫(kù)，使用批量 stmt 寫(xiě)入。

3、使用方法

3.1 環(huán)境準(zhǔn)備

（1）需要安裝 TDengine 客戶端

（2）需要安裝 JDK 1.8 環(huán)境（運(yùn)行 DataX）

（3）需要安裝 Python 環(huán)境（運(yùn)行 DataX）

（4）需要 maven 編譯環(huán)境（如果不編譯 DataX 則可以不安裝 maven）

3.2 安裝

下載源碼

git clone https://github.com/taosdata/DataX.git

編譯打包

cd DataX
mvn -U clean package assembly:assembly -Dmaven.test.skip=true

安裝

cp target/datax.tar.gz your_install_dir
cd your_install_dir
tar -zxvf dataX.tar.gz

3.3 數(shù)據(jù)遷移 Job 的配置

3.3.1 時(shí)序數(shù)據(jù)的遷移配置

以一個(gè)從 OpenTSDB 到 TDengine 3.0 版本的數(shù)據(jù)遷移任務(wù)為例，配置文件 opentsdb2tdengine.json 如下：

 {
   "job":{
     "content":[{
       "reader": {
         "name": "opentsdbreader",
         "parameter": {
           "endpoint": "http://192.168.1.180:4242",
           "column": ["weather_temperature"],
           "beginDateTime": "2021-01-01 00:00:00",
           "endDateTime": "2021-01-01 01:00:00"
         }
       },
     "writer": {
       "name": "tdengine30writer",
       "parameter": {
            "username": "root",
            "password": "taosdata",
            "connection": [
              {
                "table": [
                  "matric1"
                ],
                "jdbcUrl": "jdbc:TAOS://192.168.1.101:6030/test?timestampFormat=TIMESTAMP"
              }
            ],
            "batchSize": 1000,
            "ignoreTagsUnmatched": true
          }
       }
     }],
     "setting": {
       "speed": {
         "channel": 1
       }
     }
   }
 } 

配置說(shuō)明：

• 上面的配置表示，從 192.168.1.180 的 OpenTSDB，到 192.168.1.101 的 TDengine 的遷移。遷移 metric 為 weather_temperature，時(shí)間從 2021-01-01 00:00:00 開(kāi)始，到 2021-01-01 01:00:00 結(jié)束的數(shù)據(jù)。
• reader 使用 datax 的 opentsdbreader，parameter 的配置請(qǐng)參考：opentsdbreader.md#配置參數(shù)
• tdengine30writer 的 parameter 中，user，password 為必須項(xiàng)，沒(méi)有默認(rèn)值。batchSize 不是必須項(xiàng)，默認(rèn)值為 1。詳細(xì)參考：tdengine30writer.md#配置參數(shù)
• TDengine 中，如果 dbname 指定的 database 不存在，則需要在遷移前創(chuàng)建數(shù)據(jù)庫(kù)。

3.3.2 關(guān)系型數(shù)據(jù)的遷移配置

以一個(gè)從 MySQL 到 TDengine 3.0 版本的數(shù)據(jù)遷移任務(wù)為例，配置文件 mysql2tdengine.json 如下：

 {
   "job": {
     "content": [{
       "reader": {
         "name": "mysqlreader",
         "parameter": {
           "username": "root",
           "password": "root",
           "column": ["id","name"],
           "splitPk": "id",
           "connection": [{
             "table": ["test"],
             "jdbcUrl": ["jdbc:mysql://192.168.1.101:3306/db"]
           }]
         }
       },
       "writer": {
         "name": "tdengine30writer",
         "parameter": {
           "host": "192.168.1.105",
           "port": 6030,
           "dbname": "test",
           "user": "root",
           "password": "taosdata",
           "batchSize": 1000
         }
       }
     }],
     "setting": {
       "speed": {
         "channel": 1
       }
     }
   }
 } 

配置說(shuō)明：

• 上面的配置表示，從 192.168.1.101 的 MySQL，到 192.168.1.105 的 TDengine 的遷移。遷移 test 表中 id、name 兩列到 TDengine，使用 id 列作為任務(wù)劃分的列。
• reader 使用 datax 的 mysqlreader，parameter 的配置請(qǐng)參考：mysqlreader.md

3.3.3 TDengine 之間的遷移配置

以一個(gè)從 TDengine 到 TDengine 的數(shù)據(jù)遷移為例，配置文件 tdengine2tdengine.json 如下：

 {
   "job": {
     "content": [{
       "reader": {
         "name": "tdengine30reader",
         "parameter": {
           "host": "192.168.1.82",
           "port": 6030,
           "db": "test",
           "user": "root",
           "password": "taosdata",
           "sql": "select * from weather",
           "beginDateTime": "2021-01-01 00:00:00",
           "endDateTime": "2021-01-02 00:00:00",
           "splitInterval": "1h"
         }
       },
       "writer": {
         "name": "tdengine30writer",
         "parameter": {
           "host": "192.168.1.105",‘
           "port": 6030,
           "dbname": "test",
           "user": "root",
           "password": "taosdata",
           "batchSize": 1000
         }
       }
     }],
     "setting": {
       "speed": {
         "channel": 1
       }
     }
   }
 } 

配置說(shuō)明：

• 上面的配置表示，從 192.168.1.82 到 192.168.1.105 的 TDengine 之間的數(shù)據(jù)遷移。tdenginereader 根據(jù) sql、begieDateTime、endDateTime 過(guò)濾數(shù)據(jù)，使用 splitInteval 進(jìn)行任務(wù)劃分。
• reader 使用 tdengine30reader，parameter 的配置請(qǐng)參考：tdengine30reader.md#配置參數(shù)

3.4 執(zhí)行遷移任務(wù)

將上面寫(xiě)好的配置文件保存在 datax/job 目錄下，執(zhí)行下面的命令，啟動(dòng)數(shù)據(jù)遷移任務(wù)：

python bin/datax.py job/opentsdb2tdengine.json

4、限制條件

（1）目前，DataX 自帶的 opentsdbreader 僅支持 OpenTSDB-2.3.X 版本。詳細(xì)參考：opentsdbreader#約束限制

（2）數(shù)據(jù)遷移工具依賴 TDengine 客戶端中的 libtaos.so/taos.dll/libtaos.dylib，需要與服務(wù)端對(duì)應(yīng)版本的 TDengine-client。

5、FAQ

（1）如何估算一個(gè)數(shù)據(jù)遷移任務(wù)所需要的資源

DataX 的每個(gè) reader 按照自己的 task 切分策略進(jìn)行任務(wù)劃分，具體請(qǐng)參考 DataX 的任務(wù)調(diào)度規(guī)則。在估算資源是，需要按照數(shù)據(jù)遷移的數(shù)據(jù)量，任務(wù)切分規(guī)則和網(wǎng)絡(luò)帶寬限制等綜合考慮，最好以實(shí)際數(shù)據(jù)遷移測(cè)試結(jié)果為準(zhǔn)。

（2）TDengine30Writer 的 batchSize 設(shè)置多大效率最高？

batchSize 是控制批量寫(xiě)入的參數(shù)，在獲取 batchSize 行紀(jì)錄后，TDengineWriter 會(huì)向 TDengine 發(fā)送一次寫(xiě)入請(qǐng)求，這減少了與 TDengine 交互次數(shù)，從而提高了性能。從測(cè)試結(jié)果來(lái)看，batchSize 在 500-1000 范圍內(nèi)效率最高。

（3）job 的配置中 channel 數(shù)為多少合適？

job 中的 channel 數(shù)為流量控制的參數(shù)，每個(gè) channel 都需要開(kāi)辟一塊內(nèi)存，用來(lái)緩存數(shù)據(jù)。如果 channel 設(shè)置過(guò)大，會(huì)引起 OOM，所以 channel 數(shù)并不是越大越好。增加 channel 數(shù)后，需要提高 JVM 內(nèi)存大小。從測(cè)試結(jié)果來(lái)看，channel 在 1～6 的范圍內(nèi)都是合適，能夠保證 DataX 的流量最大化即可。

（4）java.sql.SQLException: TDengine ERROR (8000060b): Invalid client value

配置文件中 column 中沒(méi)有配置 tbname，此時(shí)會(huì)觸發(fā)行協(xié)議數(shù)據(jù)寫(xiě)入（行協(xié)議寫(xiě)入只會(huì)自動(dòng)創(chuàng)建子表名，但需要提前創(chuàng)建好超級(jí)表），行協(xié)議寫(xiě)入的情況下不支持 TAG 數(shù)據(jù)類型為非 NCHAR，所以此種情況有兩種解決方案：1.將 TAG 全部修改為 NCHAR 類型；2.在 Column 中配置好表名稱這樣不會(huì)觸發(fā)行協(xié)議寫(xiě)入。

（5）java.sql.SQLException: TDengine ERROR (8000060b): Timestamp data out of range

配置文件中 column 中沒(méi)有配置 tbname，此時(shí)會(huì)觸發(fā)行協(xié)議數(shù)據(jù)寫(xiě)入，且 TAG 全部為 NCHAR 類型，此時(shí)需要保證時(shí)間戳的一列名稱為 _ts，而不能是其他名稱（行協(xié)議寫(xiě)入下，默認(rèn)將最后的時(shí)間戳寫(xiě)入到 _ts 一列，且不能隨意命名）。若想避免請(qǐng)使用 tbname 指定表名以避免觸發(fā)行協(xié)議寫(xiě)入。

基于對(duì) TDengine 的定義和理解，筆者將會(huì)在本篇文章中從 TDengine 能解決什么問(wèn)題、它的優(yōu)勢(shì)與亮點(diǎn)、它與其它數(shù)據(jù)庫(kù)的區(qū)別等維度展開(kāi)詳述，希望能幫助到對(duì) TDengine 感興趣的小伙伴。

“區(qū)別于通用數(shù)據(jù)庫(kù)，TDengine 拋掉無(wú)用包袱”

數(shù)據(jù)庫(kù)想要完成出色的的讀寫(xiě)，最核心的能力就是索引，一般數(shù)據(jù)庫(kù)產(chǎn)品都具備正向索引能力。所謂正向索引就是通過(guò)文檔記錄里面的標(biāo)識(shí)符為關(guān)鍵字，通過(guò)關(guān)鍵標(biāo)識(shí)符不再需要進(jìn)行全盤(pán)掃描。雖然 B樹(shù)索引、哈希索引、位圖索引有區(qū)別，但是大方向都屬于正向索引。

除了正向索引，還有反向索引【也稱倒排索引】，反向索引主要用于全文檢索，例如 ElasticSearch，大多數(shù)據(jù)庫(kù)都是正向索引。TDengine 也是使用正向索引，它的特別之處是標(biāo)識(shí)符肯定包含時(shí)間戳，再加上一個(gè)維度指標(biāo)數(shù)據(jù)，構(gòu)成一個(gè)對(duì)數(shù)據(jù)值明確的描述——某個(gè)時(shí)間某個(gè)指標(biāo)對(duì)象的數(shù)據(jù)值是多少。

從數(shù)據(jù)組織的存儲(chǔ)引擎來(lái)看，數(shù)據(jù)庫(kù)底層可以分為 B樹(shù)機(jī)制、LSM 機(jī)制，兩種機(jī)制沒(méi)有最好，各有各的優(yōu)點(diǎn)和缺點(diǎn)：

B樹(shù)最大好處在于它對(duì)數(shù)據(jù)持續(xù)高漲讀性能的處理，即使數(shù)據(jù)量級(jí)增大，它的讀也沒(méi)有放大。奧秘在于對(duì)數(shù)據(jù)進(jìn)行終極持久存儲(chǔ)時(shí)，B樹(shù)是以有序有規(guī)律的數(shù)據(jù)結(jié)構(gòu)保存在硬盤(pán)上的。這樣隨著數(shù)據(jù)越來(lái)越大，它依然保持有序有規(guī)律的特性，面對(duì)成千上萬(wàn)的讀操作，都可以遵循條件運(yùn)行，減少或避免讀放大的行為。

與 B樹(shù)機(jī)制截然相反，LSM 機(jī)制則是減少避免了寫(xiě)放大。LSM 機(jī)制充分利用了內(nèi)存，在內(nèi)存里面開(kāi)辟了一個(gè)空間，寫(xiě)數(shù)據(jù)優(yōu)先往內(nèi)存里放，寫(xiě)進(jìn)去直接返回用戶成功，而不是像 B樹(shù)那樣寫(xiě)一個(gè)，我要找出誰(shuí)比我大誰(shuí)比我小，只要內(nèi)存有夠，就直接往內(nèi)存里面填就好，當(dāng)內(nèi)存達(dá)到一定的閾值，將內(nèi)存中的數(shù)據(jù)以批量、順序的方式一次寫(xiě)入硬盤(pán)上，內(nèi)存則重置清零再服務(wù)新的寫(xiě)要求。

傳統(tǒng)數(shù)據(jù)庫(kù) MySQL、Oracle 使用的是 B樹(shù)機(jī)制，而 TiDB、OceanBase 使用的是優(yōu)化后的 LSM 機(jī)制，而 TDengine 使用的是 B樹(shù) + LSM 機(jī)制的方式，其中 B樹(shù)存儲(chǔ)的是元數(shù)據(jù)【主要是時(shí)間戳+指標(biāo)數(shù)據(jù)】，LSM 機(jī)制存儲(chǔ)的是具體的數(shù)據(jù)，元數(shù)據(jù)以有序表結(jié)構(gòu)方式進(jìn)行存儲(chǔ)，而具體數(shù)據(jù)則是以追加的方式寫(xiě)入，這樣即避免了讀話大和寫(xiě)放大。

一般來(lái)說(shuō)，OLTP 產(chǎn)品為了提升并發(fā)控制的性能，必定會(huì)有寫(xiě)時(shí)復(fù)制或者 MVCC 的功能選項(xiàng)，寫(xiě)時(shí)復(fù)制與 MVCC 雖然保障了數(shù)據(jù)的一致性，但是帶來(lái)更多的 IO 負(fù)擔(dān)。TDengine 不需要對(duì)數(shù)據(jù)進(jìn)行修改，所以不需要考慮數(shù)據(jù)一致性的問(wèn)題，數(shù)據(jù)是以有序的規(guī)律并追加的形式寫(xiě)進(jìn)去的，因?yàn)橹挥凶x和寫(xiě)，所以也不需要鎖保護(hù)，拋掉一些無(wú)用的包袱，可以集中優(yōu)化其它地方，例如列式表。

業(yè)界通用數(shù)據(jù)庫(kù)針對(duì)各種業(yè)務(wù)都會(huì)有行式表、列式表甚至完全的內(nèi)存庫(kù)，對(duì)于具體的數(shù)據(jù)存儲(chǔ) TDengine 使用完全列式存儲(chǔ)在硬盤(pán)，而維度指標(biāo)則行式保存在內(nèi)存中。因?yàn)?TDengine 面對(duì)的是機(jī)器的數(shù)據(jù)，機(jī)器 24 小時(shí)工作精確到每個(gè)毫秒都在產(chǎn)生數(shù)據(jù)，為了存儲(chǔ)更多的數(shù)據(jù)，所以 TDengine 用上行列并存、用途分離的方式。

一般來(lái)說(shuō)，數(shù)據(jù)庫(kù)里面每一行的文檔記錄都是非常重要的，即使這行記錄信息無(wú)關(guān)交易，只是一個(gè)用戶的基本信息，那它的價(jià)值密度也十分高。但時(shí)序數(shù)據(jù)庫(kù)（Time Series Database）不同，單行文檔記錄價(jià)值密度低，因?yàn)?1 秒可以產(chǎn)生 1 萬(wàn)條記錄，必須要把數(shù)據(jù)聚合匯總起來(lái)才能體現(xiàn)數(shù)據(jù)的價(jià)值。快速并有效聚合普通數(shù)據(jù)使之變成價(jià)值密度高的數(shù)據(jù)，這個(gè)也是時(shí)序數(shù)據(jù)庫(kù)區(qū)別于其它數(shù)據(jù)庫(kù)的一個(gè)重要的特征。

TDengine目前提供了三個(gè)版本的產(chǎn)品：社區(qū)版，企業(yè)版以及云版本， 以滿足市場(chǎng)的需求和個(gè)人開(kāi)發(fā)者的需求。

“拆解時(shí)序數(shù)據(jù)庫(kù)，幾大產(chǎn)品特點(diǎn)分析”

從技術(shù)上區(qū)分定位，TDengine 是專注時(shí)間序列領(lǐng)域的一個(gè)分布式的海量數(shù)據(jù)分析平臺(tái)。它的競(jìng)爭(zhēng)對(duì)手可以分為直接競(jìng)爭(zhēng)對(duì)手和間接競(jìng)爭(zhēng)對(duì)手，間接競(jìng)爭(zhēng)對(duì)手有國(guó)內(nèi)的 TiDB、OceanBase、GaussDB 以及國(guó)外的 Oracle、MySQL 等等，雖然它們?cè)诰C合技術(shù)維度上與 TDengine 沒(méi)有對(duì)標(biāo)，但是分析上只要是使用時(shí)間戳，與時(shí)間序列有關(guān)系，這里就有 TDengine 的用武之地。與 TDengine 構(gòu)成直接競(jìng)爭(zhēng)的對(duì)手有 Druid、OpenTSDB、InfluxDB集群版，他們都是時(shí)間序列分析的前輩。

Druid 是一個(gè)分布式系統(tǒng)，采用 Lambda 架構(gòu)，有利于充分利用內(nèi)存，也會(huì)把歷史數(shù)據(jù)保存到硬盤(pán)上，按一定的時(shí)間粒度對(duì)數(shù)據(jù)進(jìn)行聚合，實(shí)時(shí)處理和批處理數(shù)據(jù)解耦分開(kāi)。實(shí)時(shí)處理面向?qū)懚嘧x少的場(chǎng)景，主要是以流方式處理增量數(shù)據(jù)，批處理面向讀多寫(xiě)少的場(chǎng)景，主要是以此方式處理離線數(shù)據(jù)。Druid 依賴 Hadoop，集群中采用 share nothing 的架構(gòu)，各個(gè)節(jié)點(diǎn)都有自己的計(jì)算和存儲(chǔ)能力，整個(gè)系統(tǒng)通過(guò) Zookeeper 進(jìn)行協(xié)調(diào)。為了提高計(jì)算性能，其會(huì)采用近似計(jì)算方法包括 HyperLoglog、DataSketches 的一些基數(shù)計(jì)算。

OpenTSDB 是一個(gè)開(kāi)源的時(shí)序數(shù)據(jù)庫(kù)，支持存儲(chǔ)數(shù)千億的數(shù)據(jù)點(diǎn)，并提供精確的查詢，采用 Java 語(yǔ)言編寫(xiě)，通過(guò)基于 HBase 的存儲(chǔ)實(shí)現(xiàn)橫向擴(kuò)展，OpenTSDB 廣泛用于服務(wù)器的監(jiān)控和度量，包括網(wǎng)絡(luò)和服務(wù)器、傳感器、IoT、金融數(shù)據(jù)的實(shí)時(shí)監(jiān)控領(lǐng)域。OpenTSDB 在設(shè)計(jì)思路上是利用 HBase 的 key 去存儲(chǔ)一些 tag 信息，將同一個(gè)小時(shí)數(shù)據(jù)放在一行存儲(chǔ)，以此提高查詢速度。OpenTSDB 通過(guò)預(yù)先定義好維度 tag 等，采用精巧的數(shù)據(jù)組織形式放在 HBase 里面，通過(guò) HBase 的 keyRange 可以進(jìn)行快速查詢，但是在任意維度的組織查詢下，OpenTSDB的效率會(huì)降低。

InfluxDB 是一款非常流行的時(shí)序數(shù)據(jù)庫(kù)，采用 Go 語(yǔ)言開(kāi)發(fā)，社區(qū)非?；钴S，技術(shù)特點(diǎn)支持任意數(shù)量的列，去模式化，集成了數(shù)據(jù)采集、存儲(chǔ)和可視化存儲(chǔ)，使用高壓縮比的算法支持高效存儲(chǔ)，采用 TIME SERIES MERGE TREE 的內(nèi)部存儲(chǔ)引擎，支持與 SQL 類似的語(yǔ)言（2.0 版本不再支持）。

時(shí)間序列的業(yè)務(wù)背景，在 OLAP 場(chǎng)景中一般會(huì)進(jìn)行預(yù)聚合來(lái)減少數(shù)據(jù)量，影響預(yù)聚合主要因素可以匯總?cè)缦拢?/p>

• 維度指標(biāo)的個(gè)數(shù)
• 維度指標(biāo)的基數(shù)
• 維度指標(biāo)組合程度
• 時(shí)間維度指標(biāo)的粗粒度和細(xì)粒度

為了實(shí)現(xiàn)高效的預(yù)聚合，TDengine 的秘訣是超級(jí)表，Druid 會(huì)提前定義預(yù)計(jì)算，InfluxDB 也有自己的連續(xù)查詢方法，只有 HBase 使用時(shí)才進(jìn)行拼接，所以涉及不同的維度指標(biāo)查詢，HBase 會(huì)慢一些。

據(jù)了解，TDengine 基于 TSBS 的測(cè)試報(bào)告將于近日出爐，第一期報(bào)告針對(duì) InfluxDB 和 TimeScaleDB 進(jìn)行了詳細(xì)的性能層面的對(duì)比分析，感興趣的小伙伴最近可以多多關(guān)注下公眾號(hào)的內(nèi)容。

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

我對(duì) TDengine 的認(rèn)識(shí)和了解要從過(guò)去的項(xiàng)目經(jīng)驗(yàn)說(shuō)起，以 2018 年為背景，我給大家講述一個(gè)工業(yè)界壞件故障件預(yù)測(cè)的故事。

某知名集團(tuán)隨著公司業(yè)務(wù)的快速增長(zhǎng)、新工廠的不斷增加，各種有價(jià)值的數(shù)據(jù)不能很好的整合、分析與挖掘出它應(yīng)有的價(jià)值。此時(shí)公司發(fā)展已經(jīng)進(jìn)入下一輪“拼”的戰(zhàn)略，快速響應(yīng)與準(zhǔn)確預(yù)測(cè)是業(yè)務(wù)發(fā)展的關(guān)鍵，大數(shù)據(jù)在其中起到舉足輕重的作用，以科學(xué)的分析手法整合各系統(tǒng)數(shù)據(jù)、推動(dòng)工廠制造智能化發(fā)展，成為一件迫在眉睫的工作。

當(dāng)前工廠生產(chǎn)過(guò)程中出現(xiàn)了同一種特殊問(wèn)題的 glass id，glass 的品質(zhì)由于各種原因是參差不齊的，甚至?xí)衅焚|(zhì)異常的 glass。這些異常 glass 在檢測(cè)過(guò)程中，是無(wú)法檢測(cè)出異常原因的，如果無(wú)法快速定位出異常原因，就會(huì)造成更多的異常 glass，嚴(yán)重影響生產(chǎn)。應(yīng)對(duì)的具體手段包括：

1. 通過(guò)品質(zhì)異常的 glass，找到產(chǎn)生此異常的相關(guān)性因子。如：機(jī)臺(tái)、物料、載具、參數(shù)等。
2. 異常 glass 偵測(cè)預(yù)警，通過(guò)對(duì)產(chǎn)生品質(zhì)異常的因子進(jìn)行數(shù)學(xué)建模，預(yù)測(cè)出偏離正常范圍的異常玻璃，提前預(yù)警。
3. 分析 glass 的特征值與特征值之間的關(guān)聯(lián)關(guān)系，并建立預(yù)測(cè)模型，提前預(yù)測(cè)出 glass 的特征值。
4. 分析 glass 相關(guān)的電壓、電阻、電流、溫度、濕度影響。

很明顯這是數(shù)據(jù)挖掘的項(xiàng)目，要分析以上 glass 在生產(chǎn)過(guò)程中的環(huán)境信息、檢測(cè)機(jī)臺(tái)資料、量測(cè)機(jī)臺(tái)資料、制程參數(shù)信息，以及 FDC、OEE 系統(tǒng)的數(shù)據(jù)，才能找出產(chǎn)生這種問(wèn)題的原因。第一步是數(shù)據(jù)收集整合，第二步是數(shù)據(jù)探索，第三步是模型調(diào)?！页隹赡苄?、影響最大的因素的特征因素，第四步是投入生產(chǎn)驗(yàn)證，通過(guò) spark ml 提供預(yù)測(cè)動(dòng)力。

當(dāng)時(shí)的技術(shù)棧用的是 CDH，首先要通過(guò) Kafka 采集數(shù)據(jù)，Spark對(duì)接 Kafka 進(jìn)行初步計(jì)算去噪并匯總到 Hadoop 里面，以 parquet 的格式保存，如果需要進(jìn)一步的加工，就通過(guò) impala 進(jìn)行。這樣每天掛起 N 個(gè)任務(wù)，不停的調(diào)度計(jì)算。

CDH Hadoop 雖然無(wú)法做到實(shí)時(shí)數(shù)據(jù)分析，但是也還能做些事，聊勝于無(wú)，就繼續(xù)用著。當(dāng)時(shí)這個(gè)壞件故障件預(yù)測(cè)項(xiàng)目有以下痛點(diǎn)，主要是及時(shí)性、有效性、準(zhǔn)確性的問(wèn)題：

• 難以滿足用戶需求，某些機(jī)器數(shù)據(jù)的聚合計(jì)算需要第二天才能出結(jié)果，甚至更多的時(shí)間才能出來(lái)。
• 經(jīng)濟(jì)成本的費(fèi)用較高，CPU、磁盤(pán)、網(wǎng)絡(luò)都在一個(gè)高段的使用狀態(tài)，針對(duì)越來(lái)越多的數(shù)據(jù)需要投入新機(jī)器。
• 維護(hù)成本高，你需要維護(hù) Hadoop 所有的機(jī)器，各種 HBase、Spark、Zookeeper、HDFS 之類，不但對(duì)工程師要求高，而且工作量巨大。
• 低質(zhì)量數(shù)據(jù)，因?yàn)閿?shù)據(jù)流程或者錯(cuò)誤的邏輯整合，導(dǎo)致機(jī)器傳感器聚合后數(shù)據(jù)模型無(wú)法正常使用。
• 無(wú)法做到實(shí)時(shí)監(jiān)測(cè)，機(jī)器數(shù)據(jù)作為寶貴的自變量因素?zé)o法及時(shí)傳輸并進(jìn)行計(jì)算，自然會(huì)影響因變量。

筆者經(jīng)歷了這個(gè)項(xiàng)目，知道這個(gè)壞件故障預(yù)測(cè)與時(shí)間序列有緊密的關(guān)系。時(shí)至今日，時(shí)間序列分析也是重要的數(shù)據(jù)分析技術(shù)，尤其面對(duì)季節(jié)性、周期性變化數(shù)據(jù)時(shí)，傳統(tǒng)的回歸擬合技術(shù)難以奏效，這時(shí)就需要復(fù)雜的時(shí)間序列模型，以時(shí)間為特征作為抓手點(diǎn)。這樣即使你不太懂業(yè)務(wù)的前提下，也可以進(jìn)行數(shù)據(jù)挖掘的工作。

那這個(gè)項(xiàng)目與 TDengine 有什么關(guān)系呢？實(shí)際上，這個(gè)項(xiàng)目并沒(méi)有用上 TDengine，后來(lái)集團(tuán)搭建了一個(gè) Hadoop集群試點(diǎn)，這次居然用了 HDP，理由很簡(jiǎn)單，因?yàn)?HDP 默認(rèn)搭載了時(shí)序數(shù)據(jù)庫(kù) Druid。

當(dāng)時(shí)技術(shù)負(fù)責(zé)人認(rèn)為壞件故障預(yù)測(cè)模型的數(shù)據(jù)庫(kù)基座應(yīng)該是時(shí)序數(shù)據(jù)庫(kù)，而不是 Hadoop 不停的進(jìn)行數(shù)據(jù)采集、數(shù)據(jù)轉(zhuǎn)換以及各種批計(jì)算，通過(guò)時(shí)序數(shù)據(jù)庫(kù)不但可以實(shí)時(shí)計(jì)算，而且輸出的數(shù)據(jù)質(zhì)量高。至于選擇哪個(gè)時(shí)序數(shù)據(jù)庫(kù)，彼時(shí)考慮平穩(wěn)過(guò)渡替換以及學(xué)習(xí)成本綜合因素后他們選擇了 Druid。

但當(dāng)時(shí)是 2017 年，TDengine 也還沒(méi)有面世，如果放到今天，TDengine 必定是選型考慮的首選。

要知道，TDengine 的優(yōu)勢(shì)相對(duì) Druid 要多了去了，首先 Druid 不是一個(gè)經(jīng)過(guò)開(kāi)源版本 1.00 正式發(fā)布的軟件，雖然發(fā)展多年，直至 HDP 與 CDH 兩家公司融合，HDP 搭配的 Druid 也不是 1.00 版；其次 Druid 依賴 Hadoop，動(dòng)輒就使用大量的資源以及各種復(fù)雜的 Hadoop 組件，最后 Druid 只提供 json 的方式，對(duì)傳統(tǒng)的 DBA 使用十分不友好。

TDengine 有一個(gè)我認(rèn)為很秀的功能，就是它的超級(jí)表的跨指標(biāo)維度建模思想，目前它僅用于自由組合維度指標(biāo)，拼接不同的時(shí)間粒度進(jìn)行聚合。在我看來(lái)，將來(lái)應(yīng)用于時(shí)間序列機(jī)器學(xué)習(xí)模型也會(huì)是它的一個(gè)亮點(diǎn)，在數(shù)據(jù)建模方面，針對(duì)工廠的設(shè)施、設(shè)備、機(jī)床、機(jī)房、車間、測(cè)臺(tái)等必須要做高效準(zhǔn)確的定義。我們進(jìn)行項(xiàng)目規(guī)劃建設(shè)時(shí)，都會(huì)做大量的數(shù)據(jù)治理工作，但是在具體實(shí)施工作上，還是要使用這些傳統(tǒng)工具和技術(shù)。TDengine 可以有效匯集各種機(jī)器數(shù)據(jù)源，并且能夠高質(zhì)量的提煉，這個(gè)是過(guò)去的時(shí)序數(shù)據(jù)產(chǎn)品所不具備的。

“是提速，更是賦能”

中國(guó)有句話叫做“長(zhǎng)江后浪推前浪，一代新人勝舊人”，IT 世界千變?nèi)f化，如果你和我一樣，一直在關(guān)注著 TDengine，就會(huì)發(fā)現(xiàn)，它這幾年崛起的非常迅速。去年 TDengine 推出 3.0 版本，新版本升級(jí)成為了一款真正的云原生時(shí)序數(shù)據(jù)庫(kù)，優(yōu)化了流計(jì)算功能，而且還重新設(shè)計(jì)了計(jì)算引擎，優(yōu)化工程師對(duì) SQL 的使用，另外增加了 taosX，利用自己的數(shù)據(jù)訂閱功能來(lái)解決增量備份、異地容災(zāi)，更加方便了企業(yè)應(yīng)用。

我對(duì) TDengine 未來(lái)的期望是，希望它增加庫(kù)內(nèi)機(jī)器學(xué)習(xí)函數(shù)，增加 ARIMA 模型、MA 模型等時(shí)間相關(guān)功能，TDengine 的未來(lái)是一個(gè)智能學(xué)習(xí)時(shí)間序列數(shù)據(jù)庫(kù)，對(duì)工業(yè) 4. 0 來(lái)說(shuō)不僅是提速，更是賦能。

TDengine 通過(guò)對(duì)標(biāo)準(zhǔn) SQL 命令、常用實(shí)時(shí)數(shù)據(jù)庫(kù)連接器標(biāo)準(zhǔn)（例如 JDBC）、ORM 以及其他流行時(shí)序數(shù)據(jù)庫(kù)寫(xiě)入?yún)f(xié)議（例如 InfluxDB Line Protocol、OpenTSDB JSON、OpenTSDB Telnet 等）的支持可以使 TDengine 非常容易和第三方工具共同使用。

對(duì)于支持的第三方工具，無(wú)需任何代碼，你只需要做簡(jiǎn)單的配置，就可以將 TDengine 與第三方工具無(wú)縫集成起來(lái)。

GrafanaTDengine

Grafana 是一個(gè)開(kāi)源的數(shù)據(jù)可視化和監(jiān)控平臺(tái)，它可以與多種數(shù)據(jù)源無(wú)縫集成，提供強(qiáng)大的圖形展示、告警、注釋等功能。Grafana 是目前最流行的時(shí)序數(shù)據(jù)可視化工具之一，它可以幫助用戶快速構(gòu)建美觀且實(shí)用的儀表盤(pán)。

TDengine 能夠與開(kāi)源數(shù)據(jù)可視化系統(tǒng) Grafana 快速集成搭建數(shù)據(jù)監(jiān)測(cè)報(bào)警系統(tǒng)，整個(gè)過(guò)程無(wú)需任何代碼開(kāi)發(fā)，TDengine 中數(shù)據(jù)表的內(nèi)容可以在儀表盤(pán)(DashBoard)上進(jìn)行可視化展現(xiàn)。關(guān)于 TDengine 插件的使用您可以在 GitHub 中了解更多。

具體的安裝和使用步驟，請(qǐng)參考這里。

Google Data StudioTDengine

Google Data Studio 是一個(gè)免費(fèi)的在線數(shù)據(jù)可視化和報(bào)告平臺(tái)，它可以與多種 Google 產(chǎn)品和第三方服務(wù)無(wú)縫集成，提供強(qiáng)大的數(shù)據(jù)轉(zhuǎn)換、圖形展示、協(xié)作共享等功能。Google Data Studio 是一個(gè)適合于商業(yè)智能和分析場(chǎng)景的工具，它可以幫助用戶快速構(gòu)建專業(yè)且交互式的報(bào)表。

Data Studio 可以支持多種數(shù)據(jù)來(lái)源，除了諸如 Google Analytics、Google AdWords、Search Console、BigQuery 等 Google 自己的服務(wù)之外，用戶也可以直接將離線文件上傳至 Google Cloud Storage，或是通過(guò)連接器來(lái)接入其它數(shù)據(jù)源。

目前 TDengine 連接器已經(jīng)發(fā)布到 Google Data Studio 應(yīng)用商店，你可以在 “Connect to Data” 頁(yè)面下直接搜索 TDengine，將其選作數(shù)據(jù)源。

具體使用步驟，請(qǐng)參考這里。

Intel EllTDengine

Intel Ell是一個(gè)開(kāi)源的邊緣計(jì)算平臺(tái)，它可以讓用戶在邊緣設(shè)備上運(yùn)行高性能的機(jī)器學(xué)習(xí)模型，實(shí)現(xiàn)實(shí)時(shí)的數(shù)據(jù)分析和決策。Intel Ell可以與多種邊緣設(shè)備無(wú)縫集成，提供強(qiáng)大的數(shù)據(jù)采集、模型訓(xùn)練、模型部署等功能。Intel Ell是一個(gè)適合于邊緣計(jì)算和機(jī)器學(xué)習(xí)場(chǎng)景的工具，它可以幫助用戶提高邊緣設(shè)備的智能化水平。

時(shí)序數(shù)據(jù)處理是 EII 中的重要模塊。之前，EII 使用的時(shí)序數(shù)據(jù)庫(kù)為 InfluxDB。跟 InfluxDB 相比，TDengine 在性能和壓縮率方面都有非常明顯的優(yōu)勢(shì)。具體對(duì)比可以參考相關(guān)測(cè)試報(bào)告：《基于 TSBS 標(biāo)準(zhǔn)數(shù)據(jù)集的 TimescaleDB、InfluxDB 與 TDengine 的性能對(duì)比測(cè)試》。因此，濤思數(shù)據(jù)的工程師嘗試將 TDengine 引入了 EII，使時(shí)序數(shù)據(jù)能夠保存在這款更為高效的時(shí)序數(shù)據(jù)庫(kù)中，提升處理效率并降低成本。

感興趣的讀者可以參考 Intel 網(wǎng)站上的相關(guān)文檔來(lái)使用 EII + TDengine。讀者可以參照該文檔，構(gòu)建自己的 Docker 鏡像。運(yùn)行 EII 之后，可以使用 Telegraf 來(lái)采集時(shí)序數(shù)據(jù)，將其保存在 TDengine 之中，然后可以用 Grafana 以圖形化方式查看。

DataXTDengine

DataX 是一個(gè)開(kāi)源的數(shù)據(jù)同步平臺(tái)，它可以讓用戶在不同的數(shù)據(jù)源之間進(jìn)行高效的數(shù)據(jù)傳輸，實(shí)現(xiàn)數(shù)據(jù)的遷移和備份。DataX 可以與多種關(guān)系型數(shù)據(jù)庫(kù)、非關(guān)系型數(shù)據(jù)庫(kù)、文件系統(tǒng)等無(wú)縫集成，提供強(qiáng)大的數(shù)據(jù)讀取、寫(xiě)入、轉(zhuǎn)換等功能。DataX 是一個(gè)適合于數(shù)據(jù)同步和遷移場(chǎng)景的工具，它可以幫助用戶實(shí)現(xiàn)數(shù)據(jù)的一致性和可靠性。

基于 DataX 的設(shè)計(jì)思路，我們的研發(fā)團(tuán)隊(duì)完成了 TDengine 的適配，實(shí)現(xiàn)了 TDengineReader 和 TDengineWriter 兩個(gè)插件，并被 DataX 官方接受，合并到了其主干中。

現(xiàn)在，如果用戶要將歷史 Database（比如 MySQL、OpenTSDB 等）中的數(shù)據(jù)遷移到 TDengine，或者將 TDengine 中的數(shù)據(jù)導(dǎo)出，就可以利用 DataX 來(lái)實(shí)現(xiàn)了。

具體使用步驟參考這里。

總結(jié)

通過(guò)以上的介紹，您應(yīng)該對(duì) TDengine 與第三方工具的集成方案有了一個(gè)初步的了解。

如果您想了解更多關(guān)于TDengine可視化方案，請(qǐng)查看文檔。

本文匯總了包括西門子、美的、拓斯達(dá)、和利時(shí)在內(nèi)的四家比較具有代表性的工業(yè)企業(yè)的架構(gòu)改造案例，一起來(lái)看看他們都是如何做的，改造效果是否達(dá)成了預(yù)期。

西門子 x TDengine

“從高性能、高可用、低成本、高度一體化幾個(gè)目標(biāo)出發(fā)，我們發(fā)現(xiàn) TDengine 時(shí)序數(shù)據(jù)庫(kù)(Time Series DataBase)正好符合產(chǎn)品重構(gòu)所有的要求，尤其是低成本和高度一體化這兩個(gè)點(diǎn)，這是目前絕大部分?jǐn)?shù)據(jù)平臺(tái)或時(shí)序數(shù)據(jù)庫(kù)都不具備的。在確定選擇 TDengine 作為系統(tǒng)的實(shí)時(shí)數(shù)據(jù)庫(kù)后，我們?cè)?SIMICAS? OEM 2.0 版本中移除了Flink、Kafka 以及 Redis，系統(tǒng)架構(gòu)大大簡(jiǎn)化?！?/p>

SIMICAS? OEM 設(shè)備遠(yuǎn)程運(yùn)維套件是由 SIEMENS DE&DS DSM 團(tuán)隊(duì)開(kāi)發(fā)的一套面向設(shè)備制造商的數(shù)字化解決方案。在其 1.0 版中，團(tuán)隊(duì)使用了 Flink + Kafka + PostgreSQL + Redis 的架構(gòu)，因?yàn)橐肓?Flink 和 Kafka，導(dǎo)致系統(tǒng)部署時(shí)非常繁瑣，服務(wù)器開(kāi)銷巨大；同時(shí)為了滿足大量數(shù)據(jù)的存儲(chǔ)問(wèn)題，PostgreSQL 中不得不做分庫(kù)分表操作，應(yīng)用程序較為復(fù)雜。這種情況下，如何降低系統(tǒng)復(fù)雜度、減少硬件資源開(kāi)銷，幫助客戶減少成本，成為研發(fā)團(tuán)隊(duì)的核心任務(wù)。在調(diào)研過(guò)程中，TDengine 脫穎而出。

架構(gòu)圖

美的 x TDengine

“當(dāng)前，TDengine 時(shí)序數(shù)據(jù)庫(kù)(TSDB) 主要被應(yīng)用于中央空調(diào)制冷設(shè)備的監(jiān)控業(yè)務(wù)中，作為先行試點(diǎn)，這一場(chǎng)景已經(jīng)取得了不錯(cuò)的效果。在樓宇智能化方面，我們也有很多工作要做，從邊緣側(cè)的監(jiān)控、到指令控制、再到邊云協(xié)同的一體化服務(wù)，我們會(huì)在這些場(chǎng)景中繼續(xù)探索和挖掘 TDengine 的潛力?！?/p>

業(yè)務(wù)背景

在 2021 樓宇科技 TRUE 大會(huì)上，美的暖通與樓宇事業(yè)部首次發(fā)布了數(shù)字化平臺(tái) iBuilding，以“軟驅(qū)硬核”方式賦能建筑行業(yè)。作為一個(gè)全新的項(xiàng)目，iBuilding 在數(shù)據(jù)庫(kù)選型上比較謹(jǐn)慎，分別對(duì)比了關(guān)系型數(shù)據(jù)庫(kù)（Relational Database）以及主流的時(shí)序數(shù)據(jù)庫(kù)（Time Series Database），包括 InfluxDB、TDengine、MySQL 等，因?yàn)樵谛枨笊细蛴诟咝У拇鎯?chǔ)和大范圍時(shí)間的數(shù)據(jù)拉取，iBuilding 在綜合評(píng)估了適配、查詢、寫(xiě)入和存儲(chǔ)等綜合能力后，最終選擇了 TDengine。

架構(gòu)圖

拓斯達(dá) x TDengine

“運(yùn)行一段時(shí)間后，TDengine 的查詢、寫(xiě)入速度完全可以滿足我們目前的客戶需求，最慢的分鐘級(jí)，最快的能達(dá)到 1 秒一條；一個(gè)設(shè)備一天最多能寫(xiě)入近十萬(wàn)條數(shù)據(jù)，近千個(gè)設(shè)備同時(shí)寫(xiě)入也完全沒(méi)有問(wèn)題，相較于之前，寫(xiě)入速度提升了數(shù)十倍。查詢數(shù)據(jù)在以月為單位的時(shí)間范圍內(nèi)也沒(méi)有過(guò)于明顯的延遲，整體的數(shù)據(jù)壓縮比大概是 1/10，目前每天產(chǎn)生的數(shù)據(jù)量在數(shù) G 左右。”

業(yè)務(wù)背景

在拓斯達(dá)的業(yè)務(wù)中，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)已經(jīng)無(wú)法高效處理時(shí)序數(shù)據(jù)，在加載、存儲(chǔ)和查詢等多個(gè)方面都遇到了挑戰(zhàn)，主要問(wèn)題包括寫(xiě)入吞吐低、存儲(chǔ)成本大、維護(hù)成本高、查詢性能差。為了更好地滿足時(shí)序數(shù)據(jù)的處理需求，拓斯達(dá)開(kāi)始進(jìn)行數(shù)據(jù)庫(kù)選型調(diào)研，他們發(fā)現(xiàn)，TDengine 專為時(shí)序數(shù)據(jù)庫(kù)所打造和優(yōu)化的寫(xiě)入、存儲(chǔ)、查詢等功能，非常匹配工業(yè)傳感器數(shù)據(jù)的應(yīng)用分析場(chǎng)景，最終其使用 TDengine 搭建了新的數(shù)據(jù)處理架構(gòu)。

架構(gòu)實(shí)現(xiàn)思路

通過(guò)網(wǎng)關(guān)采集設(shè)備數(shù)據(jù)推送到 MQTT，Java 后端監(jiān)聽(tīng)到后會(huì)寫(xiě)入 TDengine，在后端按需求查詢處理后再把數(shù)據(jù)返回給前端。具體來(lái)說(shuō)，網(wǎng)關(guān)會(huì)先讀取后臺(tái)發(fā)布的上行規(guī)則，在采集到設(shè)備數(shù)據(jù)后，使用上行規(guī)則對(duì)數(shù)據(jù)進(jìn)行處理計(jì)算后再將結(jié)果返回給下行規(guī)則模塊，后臺(tái)監(jiān)聽(tīng)到后，會(huì)連接 TDengine 進(jìn)行數(shù)據(jù)庫(kù)表的創(chuàng)建修改和數(shù)據(jù)寫(xiě)入。之前在云平臺(tái)拓斯達(dá)使用過(guò) Kafka 進(jìn)行數(shù)據(jù)的發(fā)布訂閱，現(xiàn)在所有環(huán)境都改為 MQTT 了。

點(diǎn)擊【案例】查看更多技術(shù)細(xì)節(jié)

和利時(shí) x TDengine

“在測(cè)試階段，我們發(fā)現(xiàn)，同等條件下，TDengine 的壓縮率最高，數(shù)據(jù)占用的存儲(chǔ)空間最?。辉谠紨?shù)據(jù)查詢上，OpenTSDB 最慢，TDengine 與 HolliTSDB 在伯仲之間；在聚合查詢操作上，TDengine 最快，HolliTSDB 的速度和 InfluxDB 相當(dāng)，OpenTSDB 最慢。同時(shí)，InfluxDB 只能單機(jī)部署，集群版本并未開(kāi)源，且查詢性能存在瓶頸，其 QPS 約為 30-50?！?/p>

業(yè)務(wù)背景

在物聯(lián)網(wǎng)場(chǎng)景下，面對(duì)龐大的時(shí)序數(shù)據(jù)處理需求，Oracle、PostgreSQL 等傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)越來(lái)越吃力，因此和利時(shí)開(kāi)始進(jìn)行時(shí)序數(shù)據(jù)庫(kù)的選型，對(duì)包括 InfluxDB、OpenTSDB、HolliTSDB（和利時(shí)自研時(shí)序數(shù)據(jù)庫(kù)）和 TDengine 在內(nèi)的四款時(shí)序數(shù)據(jù)庫(kù)進(jìn)行了選型調(diào)研及相關(guān)測(cè)試。測(cè)試結(jié)果顯示，在同等條件下，TDengine 在查詢、存儲(chǔ)等方面均優(yōu)于其他幾款數(shù)據(jù)庫(kù)，最終和利時(shí)決定接入 TDengine，以享受更多元的本地化支持和響應(yīng)。

架構(gòu)圖

結(jié)語(yǔ)

從以上案例中不難看出，在工業(yè)互聯(lián)網(wǎng)場(chǎng)景下，面對(duì)龐大的時(shí)序數(shù)據(jù)處理需求，專業(yè)的時(shí)序數(shù)據(jù)庫(kù)顯然比傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)效果更加明顯，上述企業(yè)案例在架構(gòu)改造之后，確實(shí)達(dá)到了更高程度的降本增效。如果你有同樣的困擾，歡迎點(diǎn)擊下方卡片，加入 TDengine 用戶交流群，和專業(yè)的解決方案架構(gòu)師點(diǎn)對(duì)點(diǎn)溝通。

• 一是設(shè)備管理層面的挑戰(zhàn)，隨著自動(dòng)化程度越來(lái)越高，設(shè)備復(fù)雜度和管理難度也逐步增大，如何保障設(shè)備安全可靠的運(yùn)行，提升設(shè)備的利用率，促進(jìn)設(shè)備保值增值也成了挑戰(zhàn)之一；
• 二是安全生產(chǎn)的挑戰(zhàn)，安全是根本，如何通過(guò)數(shù)字化手段，將人和物的不安全因素統(tǒng)一管理好，提升整體煤礦企業(yè)安全生產(chǎn)水平至關(guān)重要。

從以上挑戰(zhàn)出發(fā)，一些煤礦企業(yè)已經(jīng)開(kāi)始進(jìn)行數(shù)據(jù)架構(gòu)轉(zhuǎn)型實(shí)踐，也取得了一些進(jìn)展，值得一提的是，時(shí)序數(shù)據(jù)庫(kù)（Time Series Database）在其中發(fā)揮了重要作用。本文將這些案例進(jìn)行了相關(guān)匯總，供讀者參考。

TDengine x 智慧礦山系統(tǒng)

“我們以智慧礦山業(yè)務(wù)中的 5000 設(shè)備、每天 1000 萬(wàn)采集點(diǎn)的數(shù)據(jù)量級(jí)下，在以車建模和以位置建模結(jié)合的數(shù)據(jù)模型下，TDengine 的性能遠(yuǎn)沒(méi)有達(dá)到極限，目前系統(tǒng)對(duì)于車和位置的查詢速度都在毫秒級(jí)?；谀壳皩?duì) TDengine 的理解和使用經(jīng)驗(yàn)，我們計(jì)劃在環(huán)保監(jiān)測(cè)和生產(chǎn)集控設(shè)備場(chǎng)景中進(jìn)一步使用它來(lái)完善系統(tǒng)?！?/p>

業(yè)務(wù)背景

元智信息的智慧礦山項(xiàng)目需要一款實(shí)時(shí)數(shù)據(jù)庫(kù)來(lái)支撐起生產(chǎn)交互管控系統(tǒng)的采運(yùn)排環(huán)節(jié)所有過(guò)程設(shè)備的采集、存儲(chǔ)、計(jì)算和監(jiān)控功能。這些數(shù)據(jù)涵蓋范圍廣，包括挖機(jī)、卡車的采集數(shù)據(jù)、調(diào)度管理數(shù)據(jù)、設(shè)備 GPS 信息、以及每一個(gè)固定位置工序的采集數(shù)據(jù)等。在 MySQL、InfluxDB集群版、TDengine 的時(shí)序數(shù)據(jù)庫(kù)選型調(diào)研中，TDengine 脫穎而出（點(diǎn)擊下方案例查看具體原因）。

架構(gòu)圖

TDengine x 陜煤礦山項(xiàng)目

“最終落地時(shí)項(xiàng)目采用了 3 個(gè)節(jié)點(diǎn)的集群環(huán)境，定位設(shè)備采用超級(jí)表進(jìn)行管理，將數(shù)據(jù)標(biāo)簽及數(shù)據(jù)類型作為 tag 區(qū)分各類定位設(shè)備。每個(gè)定位設(shè)備采用子表存儲(chǔ)，實(shí)際項(xiàng)目已包含 2 萬(wàn)多個(gè)定位設(shè)備。從寫(xiě)入性能到查詢性能均大幅滿足現(xiàn)場(chǎng)實(shí)際需求：總計(jì)定位數(shù)據(jù)量超過(guò) 11 億條，數(shù)據(jù)壓縮后 TDengine 數(shù)據(jù)目錄占用磁盤(pán)大約 12GB，整體壓縮率可以達(dá)到 3/100?！?/p>

業(yè)務(wù)背景

為打通煤礦生產(chǎn)環(huán)境中各類單一子系統(tǒng)之間的數(shù)據(jù)壁壘，實(shí)現(xiàn)各類子系統(tǒng)數(shù)據(jù)之間的互聯(lián)互通，陜煤開(kāi)發(fā)團(tuán)隊(duì)打造了全礦井?dāng)?shù)字化平臺(tái)。以位置數(shù)據(jù)為例，由于初期系統(tǒng)容量較小且硬件設(shè)備上傳周期較大，所以采用了傳統(tǒng)的 SQL Server 數(shù)據(jù)庫(kù)來(lái)進(jìn)行軌跡數(shù)據(jù)存儲(chǔ)。隨著后續(xù)項(xiàng)目迭代，硬件設(shè)備定位精度提高且上報(bào)周期縮短，也導(dǎo)致數(shù)據(jù)庫(kù)存儲(chǔ)壓力增大。考慮到數(shù)據(jù)類型及特點(diǎn)，其決定使用時(shí)序數(shù)據(jù)庫(kù)，在 OpenTSDB、TDengine、InfluxDB 三款數(shù)據(jù)庫(kù)中做選型調(diào)研。

架構(gòu)圖

TDengine x 華夏天信露天煤礦

“對(duì)于每個(gè)電機(jī)，客戶要求系統(tǒng)能夠快速讀取相關(guān)設(shè)備屬性趨勢(shì)圖，這是我們發(fā)現(xiàn) TDengine 最強(qiáng)大的地方：針對(duì)一天 2 萬(wàn)條數(shù)據(jù)展示速度在 200ms 內(nèi)。之所以 TDengine 對(duì)這類查詢速度飛快，主要是設(shè)計(jì)時(shí)按照設(shè)備分表后，數(shù)據(jù)按塊存儲(chǔ)并按塊查出來(lái)，相對(duì) Key-Value 型數(shù)據(jù)庫(kù)節(jié)省很多尋址時(shí)間?！?/p>

業(yè)務(wù)背景

華夏天信 RED-MOS 露天煤礦智慧礦山操作系統(tǒng)，在對(duì)接某地面生產(chǎn)集控系統(tǒng)數(shù)據(jù)時(shí)，接入的監(jiān)控點(diǎn)數(shù)量將近 1 萬(wàn) 5 千點(diǎn)，其中接近 2300 點(diǎn)需要綁定組態(tài)顯示，即時(shí)頁(yè)面更新，整體數(shù)據(jù)采集到顯示到前端要求秒級(jí)展示及大數(shù)據(jù)量展示（歷史數(shù)據(jù)回溯），可展示 30 天的全量數(shù)據(jù)，點(diǎn)數(shù)量超過(guò) 50 萬(wàn)條，讀取時(shí)間要求在 5~10 s，這對(duì)底層的數(shù)據(jù)庫(kù)提出了一個(gè)相當(dāng)大的挑戰(zhàn)。

這種場(chǎng)景中，最大難點(diǎn)是要處理的數(shù)據(jù)量太大，而不是關(guān)聯(lián)關(guān)系復(fù)雜，因此 MySQL 這類關(guān)系庫(kù)的關(guān)聯(lián)查詢優(yōu)勢(shì)其實(shí)無(wú)法發(fā)揮，而 HBase 這種大數(shù)據(jù)存儲(chǔ)方案對(duì)于礦山系統(tǒng)而言又太過(guò)龐大，且硬件資源要求很多，出于成本考慮也排除了。最終其選擇了 TDengine，解決了最為頭疼的歷史數(shù)據(jù)回溯性能問(wèn)題。

效果展示

TDengine 能夠滿足大數(shù)據(jù)量展示的需求——可展示 30 天的全量數(shù)據(jù)，點(diǎn)數(shù)量超過(guò) 50 萬(wàn)條，讀取時(shí)間要求 5 秒級(jí)。

結(jié)語(yǔ)

對(duì)于礦山生產(chǎn)系統(tǒng)而言，安全是第一位的，基于此，各個(gè)生產(chǎn)環(huán)節(jié)和場(chǎng)地都要進(jìn)行全面、有效的數(shù)字化監(jiān)控，這些監(jiān)控?cái)?shù)據(jù)的特點(diǎn)就是時(shí)序、結(jié)構(gòu)化、簡(jiǎn)單但量大。作為時(shí)序數(shù)據(jù)庫(kù)賽道中的重量級(jí)選手，再?gòu)拿旱V企業(yè)的實(shí)踐效果出發(fā)，TDengine時(shí)序數(shù)據(jù)庫(kù)(TSDB)就是為助力煤礦行業(yè)智能化發(fā)展而量身定做的數(shù)據(jù)庫(kù)。

北京科技大學(xué)設(shè)計(jì)研究院有限公司作為北京科技大學(xué)全資產(chǎn)業(yè)化技術(shù)推廣機(jī)構(gòu)，從 2013 年開(kāi)始在冶金、鋼鐵行業(yè)進(jìn)行業(yè)務(wù)系統(tǒng)開(kāi)發(fā)和實(shí)施，圍繞先進(jìn)材料、綠色低碳和智能制造不斷深耕細(xì)作，持續(xù)創(chuàng)新。其擁有高效軋制與智能制造國(guó)家工程研究中心、國(guó)家板帶生產(chǎn)先進(jìn)裝備工程技術(shù)研究中心和北京市交通與能源用特殊鋼工程技術(shù)研究中心三個(gè)主要研究機(jī)構(gòu)，多年來(lái)一直專注于金屬材料加工領(lǐng)域的自動(dòng)化、信息化、智能化全產(chǎn)業(yè)鏈解決方案，已經(jīng)建立起完備的控制管理體系、售后服務(wù)體系和維保服務(wù)體系，并已通過(guò)質(zhì)量、環(huán)境、職業(yè)健康、信息安全、信息技術(shù)服務(wù)等多項(xiàng)管理體系認(rèn)證，獲得北京市優(yōu)秀技術(shù)轉(zhuǎn)移機(jī)構(gòu)及首屆鋼鐵工業(yè)智能制造優(yōu)秀品牌稱號(hào)、入選北京市專精特新中小企業(yè)，“金屬材料軋制過(guò)程智能檢測(cè)與精準(zhǔn)控制關(guān)鍵技術(shù)應(yīng)用”榮獲中國(guó)技術(shù)市場(chǎng)協(xié)會(huì)金橋獎(jiǎng)項(xiàng)目一等獎(jiǎng)。

在企業(yè)數(shù)字化的早期階段，很多企業(yè)在處理工業(yè)生產(chǎn)中大量的典型時(shí)序數(shù)據(jù)時(shí)，因海外軟件(OpenTSDB、influxdb集群版)有先發(fā)優(yōu)勢(shì)，大都選擇了 Wonderware InTouch + InSQL/Historian 的解決方案。但是隨著業(yè)務(wù)的發(fā)展，生產(chǎn)中需要監(jiān)測(cè)的指標(biāo)從幾萬(wàn)個(gè)增加到幾十萬(wàn)甚至百萬(wàn)個(gè)以上，原有方案在擴(kuò)展能力上遇到瓶頸，出現(xiàn)了以下挑戰(zhàn)：

• 非國(guó)產(chǎn)化：在復(fù)雜的國(guó)際形勢(shì)下，存在一些不確定性
• 封閉性：很多軟件是閉源的，而且處于自己的封閉體系之下，擴(kuò)展性差
• 高度復(fù)雜度：需要采購(gòu)一系列產(chǎn)品組合
• 高成本：采購(gòu)價(jià)格昂貴、功能擴(kuò)展需要額外付費(fèi)，依賴 Windows、SQL Server 等其他軟件，會(huì)產(chǎn)生額外的采購(gòu)成本
• 服務(wù)響應(yīng)慢：國(guó)外產(chǎn)品普遍服務(wù)響應(yīng)不及時(shí)，反饋經(jīng)常以天為單位，服務(wù)保障性差

面對(duì)上述挑戰(zhàn)，國(guó)產(chǎn)開(kāi)源時(shí)序數(shù)據(jù)庫(kù)(Time Series Database)TDengine 在提升數(shù)據(jù)存取效率、打破傳統(tǒng)數(shù)據(jù)孤島、提升數(shù)據(jù)有效利用率方面為北京科技大學(xué)設(shè)計(jì)研究院的冶金數(shù)字化提供了實(shí)質(zhì)性的幫助，協(xié)助打造了智能化統(tǒng)一平臺(tái)，方便部署、簡(jiǎn)化整體架構(gòu)的同時(shí)，憑借高性能、高壓縮率，TDengine 時(shí)序數(shù)據(jù)庫(kù)(TSDB)還實(shí)現(xiàn)了總體擁有成本的大幅降低、滿足國(guó)產(chǎn)化等要求。

未來(lái)，TDengine 將與北京科技大學(xué)設(shè)計(jì)研究院一起，充分利用雙方技術(shù)優(yōu)勢(shì)，賦能冶金行業(yè)發(fā)展，讓冶金行業(yè)的數(shù)據(jù)處理能力得到實(shí)質(zhì)性提升。

新奧集團(tuán)于 1989 年創(chuàng)立于河北廊坊，以城市燃?xì)鉃槠瘘c(diǎn)，逐步覆蓋了分銷、貿(mào)易、輸儲(chǔ)、生產(chǎn)、工程智造等天然氣產(chǎn)業(yè)全場(chǎng)景，貫通清潔能源產(chǎn)業(yè)鏈，提供智能化低碳綜合能源服務(wù)。目前，新奧在全國(guó)21個(gè)省，已服務(wù)超過(guò) 2681 萬(wàn)個(gè)家庭用戶、21 萬(wàn)家企業(yè)。

新奧集團(tuán)旗下企業(yè)新奧新智科技有限公司（簡(jiǎn)稱“新奧新智”）是一家智能生態(tài)運(yùn)營(yíng)商，致力于以物聯(lián)促進(jìn)智能、用智能升級(jí)產(chǎn)業(yè)。其依托智能物聯(lián)、新智云、聯(lián)合學(xué)習(xí)、平臺(tái)引擎等技術(shù)，重點(diǎn)建設(shè)了組織中臺(tái)、行業(yè)中臺(tái)和數(shù)智中臺(tái)，為產(chǎn)業(yè)客戶的數(shù)字化發(fā)展提供賦能產(chǎn)品及解決方案。作為新奧的數(shù)字化創(chuàng)值型能力平臺(tái)，新奧新智一直秉持著“源自客戶、成就彼此、共創(chuàng)生態(tài)”的新奧之道，以長(zhǎng)期實(shí)踐經(jīng)驗(yàn)和強(qiáng)大的產(chǎn)品能力不斷推動(dòng)著多產(chǎn)業(yè)智能化發(fā)展。

新奧集團(tuán)作為國(guó)內(nèi)較大的清潔能源分銷商，旗下的新奧新智通過(guò)信息化手段對(duì)能源站、燃?xì)夤芫W(wǎng)、燃?xì)獗淼冗M(jìn)行設(shè)備網(wǎng)聯(lián)，實(shí)現(xiàn)高效管理和監(jiān)測(cè)。然而隨著應(yīng)用場(chǎng)景的增多、聯(lián)網(wǎng)設(shè)備的指數(shù)級(jí)增長(zhǎng)，使得數(shù)據(jù)存儲(chǔ)成本大幅度提升，數(shù)據(jù)寫(xiě)入和查詢緩慢。新奧集團(tuán)在進(jìn)行整體物聯(lián)網(wǎng)數(shù)據(jù)處理平臺(tái)搭建和升級(jí)的過(guò)程中，逐漸發(fā)現(xiàn)了老式時(shí)序數(shù)據(jù)庫(kù) OpenTSDB 寫(xiě)入性能和并發(fā)查詢能力的不足，重度依賴 HBase，整體平臺(tái)運(yùn)維非常沉重。同時(shí)數(shù)據(jù)從邊緣側(cè)采集到應(yīng)用層展示有顯著延時(shí)；報(bào)表計(jì)算也無(wú)法在限定時(shí)間內(nèi)完成，嚴(yán)重影響了業(yè)務(wù)的時(shí)效性。

為了解決巨大數(shù)據(jù)量帶來(lái)的數(shù)據(jù)存儲(chǔ)挑戰(zhàn)以及原方案性能不足的問(wèn)題，經(jīng)過(guò)多輪深入的技術(shù)探討和選型評(píng)測(cè)，新奧新智選擇應(yīng)用時(shí)序數(shù)據(jù)庫(kù) TDengine Database (Time Series DataBase) 來(lái)改造原有數(shù)據(jù)架構(gòu)，改造完成后，不僅系統(tǒng)架構(gòu)得到了極大簡(jiǎn)化，數(shù)據(jù)讀寫(xiě)能力也得到了極大提升，企業(yè)的總擁有成本顯著降低，同時(shí)對(duì)于未來(lái)整體物聯(lián)網(wǎng)平臺(tái)的升級(jí)和擴(kuò)展打下了良好的基礎(chǔ)。

順豐 x TDengine

“完成改造后，大數(shù)據(jù)監(jiān)控平臺(tái)擺脫了對(duì)大數(shù)據(jù)組件的依賴，有效縮短了數(shù)據(jù)處理鏈路，自上線以來(lái)，一直運(yùn)行穩(wěn)定。在寫(xiě)入方面，根據(jù)容量規(guī)劃完成相關(guān)參數(shù)調(diào)整后，理想情況下，集群寫(xiě)入速度最高達(dá) 90W 條/s。查詢性能方面，在使用預(yù)計(jì)算函數(shù)情況下，查詢 p99 都在 0.7 秒以內(nèi)，能夠滿足我們?nèi)粘＝^大部分查詢需求。控制成本層面，服務(wù)端物理機(jī)由 21 臺(tái)降至 3 臺(tái)，每日所需存儲(chǔ)空間為 93GB（2 副本），同等副本下僅為 OpenTSDB+HBase 的約 1/10。”

業(yè)務(wù)背景

順豐科技大數(shù)據(jù)集群每天需要采集海量監(jiān)控?cái)?shù)據(jù)，以確保集群穩(wěn)定運(yùn)行。此前其采用了 OpenTSDB+HBase 作為大數(shù)據(jù)監(jiān)控平臺(tái)全量監(jiān)控?cái)?shù)據(jù)的存儲(chǔ)方案，隨著接入數(shù)據(jù)量的不斷增長(zhǎng)，這一方案衍生出了不少痛點(diǎn)，包括依賴多、使用成本高和性能不能滿足等問(wèn)題，必須對(duì)全量監(jiān)控?cái)?shù)據(jù)存儲(chǔ)方案進(jìn)行改造。通過(guò)對(duì) IoTDB、Druid、ClickHouse、TDengine 等時(shí)序數(shù)據(jù)存儲(chǔ)方案的調(diào)研， TDengine 時(shí)序數(shù)據(jù)成為他們的最終選擇。

架構(gòu)圖

為保證整個(gè)系統(tǒng)的高可用和可擴(kuò)展性，整體架構(gòu)中，前端采用nginx集群進(jìn)行負(fù)載均衡，保證高可用性；單獨(dú)分離出客戶端層，方便根據(jù)流量需求進(jìn)行擴(kuò)容縮容。點(diǎn)擊案例詳情查看三大實(shí)施難點(diǎn)及解決路徑。

點(diǎn)擊案例查看更多技術(shù)細(xì)節(jié)

韻達(dá) x TDengine

“我們目前使用 TDengine 2.2.2.0 版本，在三臺(tái) 16C 64G 的服務(wù)器上部署了集群，數(shù)據(jù)寫(xiě)入速度大概為每秒 5000 行。值得一提的是，基于 TDengine，常用的查詢基本可以在 1 秒之內(nèi)完成，一些特定查詢甚至可以達(dá)到毫秒級(jí)。從存儲(chǔ)來(lái)說(shuō)，同等數(shù)據(jù)體量下，TDengine 大約占用 300GB 不到的磁盤(pán)（單副本），而此前使用 MySQL 時(shí)，光硬盤(pán)使用就需要幾個(gè) TB（主從）?！?/p>

業(yè)務(wù)背景

在業(yè)務(wù)尚未擴(kuò)張之前，韻達(dá)采用的是 MySQL 分區(qū)+索引方式進(jìn)行數(shù)據(jù)處理，但隨著企業(yè)的發(fā)展、業(yè)務(wù)量的增加，面對(duì)每日億級(jí)的數(shù)據(jù)量，MySQL 顯然已經(jīng)無(wú)法滿足當(dāng)下的數(shù)據(jù)處理需求。隨后，韻達(dá)決定進(jìn)行數(shù)據(jù)庫(kù)選型，考慮到目前業(yè)務(wù)主要是統(tǒng)計(jì)各個(gè)網(wǎng)點(diǎn)設(shè)備實(shí)時(shí)上傳的數(shù)據(jù)，無(wú)需再進(jìn)行修改等操作，是典型的時(shí)序數(shù)據(jù)。經(jīng)過(guò)一番調(diào)研和測(cè)試，韻達(dá)發(fā)現(xiàn) TDengine 就很符合當(dāng)下的業(yè)務(wù)要求。

架構(gòu)圖

當(dāng)前韻達(dá)的架構(gòu)是 Spring Boot + MyBatis + MySQL + TDengine，TDengine 負(fù)責(zé)處理時(shí)序數(shù)據(jù)，MySQL 則負(fù)責(zé)非時(shí)序數(shù)據(jù)的存儲(chǔ)及應(yīng)用，整體架構(gòu)如下：

點(diǎn)擊案例查看更多技術(shù)細(xì)節(jié)

貨拉拉 x TDengine

“值得一提的是，TDengine 的 SQL 原生語(yǔ)法支持時(shí)間維度聚合查詢，同時(shí)數(shù)據(jù)存儲(chǔ)壓縮率?存儲(chǔ)空間小， 這兩點(diǎn)直接切中了我們的痛點(diǎn)。落地后實(shí)測(cè)相同數(shù)據(jù)的存儲(chǔ)空間只有 MySQL 存儲(chǔ)空間的 1/10 甚至更少。還有?個(gè)驚喜是，在現(xiàn)有監(jiān)控?cái)?shù)據(jù)存儲(chǔ)(MySQL)頂不住的情況下，?臺(tái) 8C16GB 的單機(jī)版 TDengine 時(shí)序數(shù)據(jù)庫(kù)輕松就抗下目前所有監(jiān)控流量和存儲(chǔ)壓力，且運(yùn)行穩(wěn)定，基本沒(méi)有故障。”

業(yè)務(wù)背景

目前貨拉拉 DBA 團(tuán)隊(duì)管理的數(shù)據(jù)存儲(chǔ)包括 MySQL、Redis、Elasticsearch、Kafka、MQ、Canal 等，為了保證監(jiān)控采樣的實(shí)時(shí)性，其自研的監(jiān)控系統(tǒng)設(shè)置的采樣間隔為 10 秒，每天都會(huì)產(chǎn)生龐大的監(jiān)控?cái)?shù)據(jù)，監(jiān)控指標(biāo)的數(shù)據(jù)量達(dá)到 20 億+。隨著管理實(shí)例越來(lái)越多，使用 MySQL 來(lái)存儲(chǔ)規(guī)模日益龐大的監(jiān)控?cái)?shù)據(jù)越發(fā)力不從心，急需進(jìn)行升級(jí)改造。結(jié)合實(shí)際具體需求，通過(guò)對(duì)不同時(shí)序數(shù)據(jù)庫(kù)進(jìn)行調(diào)研，最終貨拉拉選擇了 TDengine，順利完成了數(shù)據(jù)存儲(chǔ)監(jiān)控的升級(jí)改造。

架構(gòu)圖

點(diǎn)擊案例查看更多技術(shù)細(xì)節(jié)

中通 x TDengine

“通過(guò)項(xiàng)目初期的表現(xiàn)，可以知道 TDengine 能夠輕松滿足我們的業(yè)務(wù)需求，輕松支撐起業(yè)務(wù)中使用比較頻繁的幾種查詢。未來(lái)我們還有其他的使用規(guī)劃，后續(xù)接入的車輛將會(huì)達(dá)到幾萬(wàn)輛，對(duì)于部標(biāo)機(jī)產(chǎn)生的相關(guān)時(shí)序數(shù)據(jù)的使用也會(huì)越來(lái)越多，期待 TDengine 可以繼續(xù)為車聯(lián)網(wǎng)場(chǎng)景下的查詢提供更為多樣性的支持?！?/p>

業(yè)務(wù)背景

車聯(lián)網(wǎng)業(yè)務(wù)是中通科技配送全鏈路業(yè)務(wù)中非常重要的一環(huán)，通過(guò)人、車、貨、場(chǎng)全鏈條覆蓋的車聯(lián)網(wǎng)設(shè)備應(yīng)用，實(shí)現(xiàn)物流運(yùn)輸全鏈路感知。在中智車聯(lián)服務(wù)平臺(tái)的實(shí)際項(xiàng)目需求中，需要實(shí)時(shí)查詢車輛最新位置狀態(tài)，達(dá)到車輛運(yùn)營(yíng)可視化管理。在進(jìn)行數(shù)據(jù)庫(kù)選型時(shí)，其對(duì)比了 Prometheus 和 TDengine 這兩款很有代表性的時(shí)序數(shù)據(jù)庫(kù)，最終被 TDengine “一個(gè)設(shè)備采集點(diǎn)一張表”的底層設(shè)計(jì)，及自帶的降采樣和窗口函數(shù)等優(yōu)秀性能所吸引。

架構(gòu)圖

點(diǎn)擊案例查看更多技術(shù)細(xì)節(jié)

寫(xiě)在最后

據(jù)國(guó)家郵政局?jǐn)?shù)據(jù)顯示，我國(guó)快遞業(yè)發(fā)展迅猛，已經(jīng)連續(xù)幾年保持 50% 左右的爆發(fā)式增長(zhǎng)，為經(jīng)濟(jì)增長(zhǎng)注入了強(qiáng)大的活力，然而高速發(fā)展的同時(shí)也面臨著越來(lái)越多的數(shù)據(jù)處理難題，好在大數(shù)據(jù)處理方案也在與時(shí)俱進(jìn)。以上企業(yè)用實(shí)際案例證明，對(duì)于物流企業(yè)，時(shí)序數(shù)據(jù)庫(kù)在降本增效上確實(shí)更加顯著，值得更多有此類需求的企業(yè)嘗試。

小 T 導(dǎo)讀：為了在數(shù)據(jù)采集項(xiàng)頻繁變動(dòng)的情況下保證用戶仍然能夠順利地完成數(shù)據(jù)記錄工作，TDengine 提供了三種無(wú)模式寫(xiě)入?yún)f(xié)議，分別是 InfluxDB Line 協(xié)議、OpenTSDB Telnet 協(xié)議和 OpenTSDB JSON 格式協(xié)議。本文將對(duì)無(wú)模式寫(xiě)入方式的主要處理邏輯、映射規(guī)則與變更處理等進(jìn)行分析，便于用戶理解與使用。

通常來(lái)說(shuō)，物聯(lián)網(wǎng)應(yīng)用常會(huì)采集比較多的數(shù)據(jù)項(xiàng)，用于實(shí)現(xiàn)智能控制、業(yè)務(wù)分析、設(shè)備監(jiān)控等功能。但在此過(guò)程中，由于應(yīng)用邏輯的版本升級(jí)，或者設(shè)備自身的硬件調(diào)整等原因，數(shù)據(jù)采集項(xiàng)可能較為頻繁地出現(xiàn)變動(dòng)。這也是時(shí)序數(shù)據(jù)庫(kù)（Time Series Database，TSDB）需要應(yīng)對(duì)的一個(gè)挑戰(zhàn)。

為了在這種情況下順利完成數(shù)據(jù)記錄工作，TDengine 時(shí)序數(shù)據(jù)庫(kù) 提供了 Schemaless 寫(xiě)入方式，讓用戶可以省略掉預(yù)先創(chuàng)建超級(jí)表/子表的步驟，憑借數(shù)據(jù)寫(xiě)入接口能夠自動(dòng)創(chuàng)建與數(shù)據(jù)對(duì)應(yīng)的存儲(chǔ)結(jié)構(gòu)。在必要時(shí)，Schemaless 將自動(dòng)增加必要的數(shù)據(jù)列，保證用戶寫(xiě)入的數(shù)據(jù)能夠被正確存儲(chǔ)。

值得一提的是，通過(guò)無(wú)模式寫(xiě)入方式建立的超級(jí)表及其對(duì)應(yīng)的子表，與通過(guò) SQL 直接建立的超級(jí)表和子表完全沒(méi)有區(qū)別，你也可以通過(guò) SQL 語(yǔ)句直接向其中寫(xiě)入數(shù)據(jù)。但需要注意，通過(guò)無(wú)模式寫(xiě)入方式建立的表，其表名是基于標(biāo)簽值按照固定的映射規(guī)則生成的，所以無(wú)法明確地進(jìn)行表意，缺乏可讀性。

無(wú)模式寫(xiě)入行協(xié)議

TDengine 的無(wú)模式寫(xiě)入行協(xié)議兼容 InfluxDB 的行協(xié)議（Line Protocol）、OpenTSDB 的 telnet 行協(xié)議、OpenTSDB 的 JSON 格式協(xié)議。但是使用這三種協(xié)議的時(shí)候，需要在 API 中指定輸入內(nèi)容使用解析協(xié)議的標(biāo)準(zhǔn)。

對(duì)于 InfluxDB、OpenTSDB 的標(biāo)準(zhǔn)寫(xiě)入?yún)f(xié)議請(qǐng)參考《在 TDengine 中如何高效寫(xiě)入？四種寫(xiě)入方式提效大全》。下面首先以 InfluxDB 的行協(xié)議為基礎(chǔ)，介紹 TDengine 擴(kuò)展的協(xié)議內(nèi)容，允許用戶采用更加精細(xì)的方式控制（超級(jí)表）模式。

Schemaless 采用一個(gè)字符串來(lái)表達(dá)一個(gè)數(shù)據(jù)行（可以向?qū)懭?API 中一次傳入多行字符串來(lái)實(shí)現(xiàn)多個(gè)數(shù)據(jù)行的批量寫(xiě)入），其格式約定如下：

measurement,tag_set field_set timestamp

其中：

• measurement 將作為數(shù)據(jù)表名。它與 tag_set 之間使用一個(gè)英文逗號(hào)來(lái)分隔。
• tag_set 將作為標(biāo)簽數(shù)據(jù)，其格式形如 <tag_key>=<tag_value>,<tag_key>=<tag_value>，也即可以使用英文逗號(hào)來(lái)分隔多個(gè)標(biāo)簽數(shù)據(jù)。它與 field_set 之間使用一個(gè)半角空格來(lái)分隔。
• field_set 將作為普通列數(shù)據(jù)，其格式形如 <field_key>=<field_value>,<field_key>=<field_value>，同樣是使用英文逗號(hào)來(lái)分隔多個(gè)普通列的數(shù)據(jù)。它與 timestamp 之間使用一個(gè)半角空格來(lái)分隔。
• timestamp 即本行數(shù)據(jù)對(duì)應(yīng)的主鍵時(shí)間戳。

tag_set 中所有的數(shù)據(jù)自動(dòng)轉(zhuǎn)化為 nchar 數(shù)據(jù)類型，并不需要使用雙引號(hào)（”)。在無(wú)模式寫(xiě)入數(shù)據(jù)行協(xié)議中，field_set 中的每個(gè)數(shù)據(jù)項(xiàng)都需要對(duì)自身的數(shù)據(jù)類型進(jìn)行描述。具體來(lái)說(shuō)：

• 如果兩邊有英文雙引號(hào)，表示 BINARY(32) 類型。例如 "abc"。
• 如果兩邊有英文雙引號(hào)而且?guī)в?L 前綴，表示 NCHAR(32) 類型。例如 L"報(bào)錯(cuò)信息"。
• 對(duì)空格、等號(hào)（=）、逗號(hào)（,）、雙引號(hào)（”），前面需要使用反斜杠（\）進(jìn)行轉(zhuǎn)義（都指的是英文半角符號(hào)）。
• 數(shù)值類型將通過(guò)后綴來(lái)區(qū)分?jǐn)?shù)據(jù)類型，如后綴為無(wú)或 f64，映射的數(shù)據(jù)類型為 double；后綴為 f32，映射為 float，可移步 https://docs.taosdata.com/reference/schemaless/ 了解更多的后綴及映射類型。
• t, T, true, True, TRUE, f, F, false, False 將直接作為 BOOL 型來(lái)處理。

例如如下數(shù)據(jù)行表示：向名為 st 的超級(jí)表下的 t1 標(biāo)簽為 “3”（NCHAR）、t2 標(biāo)簽為 “4”（NCHAR）、t3 標(biāo)簽為 “t3″（NCHAR）的數(shù)據(jù)子表，寫(xiě)入 c1 列為 3（BIGINT）、c2 列為 false（BOOL）、c3 列為 “passit”（BINARY）、c4 列為 4（DOUBLE）、主鍵時(shí)間戳為 1626006833639000000 的一行數(shù)據(jù)。

st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4f64 1626006833639000000

需要注意的是，如果描述數(shù)據(jù)類型后綴時(shí)使用了錯(cuò)誤的大小寫(xiě)，或者為數(shù)據(jù)指定的數(shù)據(jù)類型有誤，均可能引發(fā)報(bào)錯(cuò)提示而導(dǎo)致數(shù)據(jù)寫(xiě)入失敗。

無(wú)模式寫(xiě)入的主要處理邏輯

無(wú)模式寫(xiě)入使用如下規(guī)則來(lái)生成子表名：首先將 measurement 的名稱和標(biāo)簽的 key 和 value 組合成為如下的字符串——

"measurement,tag_key1=tag_value1,tag_key2=tag_value2"

需要注意的是，這里的 tagkey1，tag_key2 并不是用戶輸入的標(biāo)簽的原始順序，而是使用了標(biāo)簽名稱按照字符串升序排列后的結(jié)果，所以，tag_key1 并不是在行協(xié)議中輸入的第一個(gè)標(biāo)簽。 排列完成以后計(jì)算該字符串的 MD5 散列值為 “md5_val”，我們將計(jì)算的結(jié)果與字符串組合生成表名：“t_md5_val”，其中的 “t” 是固定的前綴，每個(gè)通過(guò)該映射關(guān)系自動(dòng)生成的表都具有該前綴。

用戶可以通過(guò)在 taos.cfg 里配置 smlChildTableName 參數(shù)來(lái)指定生成的表名。 舉例如下：配置 smlChildTableName=tname 插入數(shù)據(jù)為 st,tname=cpu1,t1=4 c1=3 1626006833639000000，則創(chuàng)建的表名為 cpu1，注意如果多行數(shù)據(jù) tname 相同，但是后面的 tag_set 不同，則使用第一行自動(dòng)建表時(shí)指定的 tag_set，其他的行會(huì)忽略。

此外，在處理行數(shù)據(jù)時(shí)，其他原則如下所示：

1. 如果解析行協(xié)議獲得的超級(jí)表不存在，則會(huì)自動(dòng)創(chuàng)建這個(gè)超級(jí)表（不建議手動(dòng)創(chuàng)建超級(jí)表，不然插入數(shù)據(jù)可能異常）。
2. 如果解析行協(xié)議獲得子表不存在，則 Schemaless 會(huì)按照步驟 1 或 2 確定的子表名來(lái)創(chuàng)建子表。
3. 如果數(shù)據(jù)行中指定的標(biāo)簽列或普通列不存在，則在超級(jí)表中增加對(duì)應(yīng)的標(biāo)簽列或普通列（只增不減）。
4. 如果超級(jí)表中存在一些標(biāo)簽列或普通列未在一個(gè)數(shù)據(jù)行中被指定取值，那么這些列的值在這一行中會(huì)被置為 NULL。
5. 對(duì) BINARY 或 NCHAR 列，如果數(shù)據(jù)行中所提供值的長(zhǎng)度超出了列類型的限制，自動(dòng)增加該列允許存儲(chǔ)的字符長(zhǎng)度上限（只增不減），以保證數(shù)據(jù)的完整保存。
6. 整個(gè)處理過(guò)程中遇到的錯(cuò)誤會(huì)中斷寫(xiě)入過(guò)程，并返回錯(cuò)誤代碼。
7. 為了提高寫(xiě)入的效率，默認(rèn)假設(shè)同一個(gè)超級(jí)表中 field_set 的順序是一樣的（第一條數(shù)據(jù)包含所有的 field，后面的數(shù)據(jù)按照這個(gè)順序），如果順序不一樣，需要配置參數(shù) smlDataFormat 為 false，否則，數(shù)據(jù)寫(xiě)入按照相同順序?qū)懭耄瑤?kù)中數(shù)據(jù)會(huì)異常。

注意，無(wú)模式所有的處理邏輯仍會(huì)遵循 TDengine 對(duì)數(shù)據(jù)結(jié)構(gòu)的底層限制，例如每行數(shù)據(jù)的總長(zhǎng)度不能超過(guò) 16KB。這方面的具體限制約束請(qǐng)參見(jiàn) TDengine SQL 邊界限制（https://docs.taosdata.com/taos-sql/limit/）。

數(shù)據(jù)模式映射規(guī)則與變更處理

以 InfluxDB 行協(xié)議為例，其數(shù)據(jù)如何映射成為具有模式的數(shù)據(jù)？從上文中我們了解到，每個(gè)行協(xié)議中數(shù)據(jù) measurement 映射為超級(jí)表名稱，tag_set 中的標(biāo)簽名稱為數(shù)據(jù)模式中的標(biāo)簽名，field_set 中的名稱為列名稱。以如下數(shù)據(jù)為例，說(shuō)明映射規(guī)則：

st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4f64 1626006833639000000

該行數(shù)據(jù)映射生成一個(gè)超級(jí)表：st， 其包含了 3 個(gè)類型為 nchar 的標(biāo)簽，分別是：t1, t2, t3；五個(gè)數(shù)據(jù)列，分別是 ts（timestamp），c1 (bigint），c3(binary)，c2 (bool), c4 (bigint）。映射成為如下 SQL 語(yǔ)句：

create stable st (_ts timestamp, c1 bigint, c2 bool, c3 binary(6), c4 bigint) tags(t1 nchar(1), t2 nchar(1), t3 nchar(2))

在數(shù)據(jù)模式變更處理中，不同行數(shù)據(jù)寫(xiě)入情況下，對(duì)于數(shù)據(jù)模式的影響也不同。在使用行協(xié)議寫(xiě)入一個(gè)明確標(biāo)識(shí)的字段類型時(shí)，后續(xù)再更改該字段的類型定義，會(huì)出現(xiàn)明確的數(shù)據(jù)模式錯(cuò)誤，即會(huì)觸發(fā)寫(xiě)入 API 報(bào)告錯(cuò)誤。如下所示：

st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4    1626006833639000000
st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4i   1626006833640000000

第一行的數(shù)據(jù)類型映射將 c4 列定義為 Double， 但是第二行的數(shù)據(jù)又通過(guò)數(shù)值后綴方式聲明該列為 BigInt， 由此會(huì)觸發(fā)無(wú)模式寫(xiě)入的解析錯(cuò)誤。如果列前面的行協(xié)議將數(shù)據(jù)列聲明為了 binary， 后續(xù)的要求長(zhǎng)度更長(zhǎng)的 binary 長(zhǎng)度，此時(shí)會(huì)觸發(fā)超級(jí)表模式的變更。

st,t1=3,t2=4,t3=t3 c1=3i64,c5="pass"     1626006833639000000
st,t1=3,t2=4,t3=t3 c1=3i64,c5="passit"   1626006833640000000

第一行中行協(xié)議解析會(huì)聲明 c5 列是一個(gè) binary(4)的字段，第二次行數(shù)據(jù)寫(xiě)入會(huì)提取列 c5 仍然是 binary 列，但是其寬度為 6，此時(shí)需要將 binary 的寬度增加到能夠容納新字符串的寬度。

st,t1=3,t2=4,t3=t3 c1=3i64               1626006833639000000
st,t1=3,t2=4,t3=t3 c1=3i64,c6="passit"   1626006833640000000

第二行數(shù)據(jù)相對(duì)于第一行來(lái)說(shuō)增加了一個(gè)列 c6，類型為 binary(6)。那么此時(shí)會(huì)自動(dòng)增加一個(gè)列 c6， 類型為 binary(6)。

寫(xiě)在最后

受篇幅所限，關(guān)于無(wú)模式寫(xiě)入的時(shí)間分辨率識(shí)別、寫(xiě)入完整性、錯(cuò)誤碼等內(nèi)容請(qǐng)參考 https://docs.taosdata.com/reference/schemaless/ 。如有更多問(wèn)題，歡迎加入 TDengine 用戶交流群，屆時(shí)將會(huì)有專業(yè)的技術(shù)人員為你解惑。