小 T 導讀：格創東智(zhi)科(ke)技有(you)限公(gong)司成立于 2018 年(nian)，孵化(hua)于中國(guo) 500 強企業(ye) TCL，是我國(guo)知名(ming)的工(gong)(gong)(gong)(gong)業(ye)互(hu)聯網(wang)平臺服務商。公(gong)司依托 TCL 集(ji)團 40 年(nian)工(gong)(gong)(gong)(gong)業(ye)場(chang)景和制造(zao)基因沉淀，基于“面向(xiang)工(gong)(gong)(gong)(gong)業(ye)現場(chang)”的研發方向(xiang)和“連接、協同、共享”的發展(zhan)理念，深(shen)度融(rong)合(he)人工(gong)(gong)(gong)(gong)智(zhi)能、大數據、云(yun)計算、物(wu)聯網(wang)等前(qian)沿(yan)技術，打造(zao)了新一代具有(you)自主知識產(chan)權的工(gong)(gong)(gong)(gong)業(ye)互(hu)聯網(wang)平臺——”東智(zhi)工(gong)(gong)(gong)(gong)業(ye)應用智(zhi)能平臺”。

作為(wei)東(dong)智工(gong)(gong)業(ye)應用智能平臺(tai)產品(pin)家族的物聯(lian)網平臺(tai)，G-Things 為(wei)工(gong)(gong)業(ye)設(she)備(bei)提(ti)供了(le)安全可(ke)靠的連接(jie)通(tong)信能力(li)，其(qi)支持數據采集(ji)、規則引擎、數據轉(zhuan)發、指令下(xia)發、數據可(ke)視(shi)化(hua)，同(tong)時提(ti)供開放(fang)的 API 與(yu)第(di)三方(fang)系(xi)統快速(su)對接(jie)，為(wei)工(gong)(gong)業(ye)企業(ye)提(ti)供高(gao)效率、低成本、高(gao)可(ke)靠的工(gong)(gong)業(ye)物聯(lian)網解決方(fang)案。

從采集(ji)的數(shu)據(ju)類型上來看，平臺(tai)采集(ji)的設備(bei)數(shu)據(ju)以及系統(tong)業務主要有以下(xia)時(shi)序(xu)數(shu)據(ju)特(te)性:

• 設備所有采集的數據是時序性的、結構化的
• 設備采集點的數據源是唯一的
• 數據存在時效性
• 以寫操作為主，讀操作為輔
• 需要統計、聚合的實時計算操作
• 數據的查詢一般指定時間區間
• 支持高頻數據接入

為(wei)了讓用戶(hu)在最大(da)程(cheng)度上實現降本增效，G-Things 在接入不同的(de)(de)租戶(hu)時，會從用戶(hu)類型(輕量(liang)級(ji)、重量(liang)級(ji)等)、設備(bei)規模、設備(bei)采集的(de)(de)數據量(liang)等角度幫(bang)助用戶(hu)選擇(ze)適配合理的(de)(de)時序(xu)數據持久化落(luo)地方案。

一、時序數據庫選型調研

自 2019 年我們便開始關注一些國內的時序數據庫（Time-Series Database），通過調研發現 TDengine 很適(shi)合(he)我們的業務場景，它擁有讀寫性(xing)能強大、部(bu)署簡單、超(chao)強的數據壓縮比等特性(xing)，同時超(chao)級(ji)表、子表的標簽 tag 設(she)計也很好地契合(he)了平臺物模(mo)型中的設(she)備(bei)模(mo)型、設(she)備(bei)概念(nian)。

為了(le)驗證(zheng) TDengine 在讀(du)寫、存儲等方面(mian)的性(xing)能，我們將其與 Cassandra 、OpenTSDB 在同等條件之下進行了(le)相關的讀(du)寫性(xing)能對比測試，測試結果如下：

	TDengine	Cassandra	OpenTSDB
寫入吞吐量	1477208 記錄數/秒	61708記錄數/秒	57272記錄數/秒
100萬條記錄讀取時間	0.21秒	3.64秒	6.57秒
1億條記錄取平均值時間	0.06秒	264.49秒	66.99秒
1億條記錄按標簽分組取均值時間	0.123秒	308.39秒	126.41秒
1億條記錄按時間分組取均值時間	2.549秒	303.51秒	82.46秒

在同(tong)等(deng)數據集和硬(ying)件(jian)環境下，對比發現：

TDengine Database 的(de)性(xing)(xing)(xing)能(neng)遠超 Cassandra 和 OpenTSDB，寫入性(xing)(xing)(xing)能(neng)分(fen)別是兩者的(de)近 20 倍(bei)(bei)(bei)(bei)、25 倍(bei)(bei)(bei)(bei)，讀取性(xing)(xing)(xing)能(neng)約(yue)為(wei) 17 倍(bei)(bei)(bei)(bei)、32 倍(bei)(bei)(bei)(bei)，聚合函數性(xing)(xing)(xing)能(neng)約(yue)為(wei) 4000 倍(bei)(bei)(bei)(bei)、1000 倍(bei)(bei)(bei)(bei)，按標簽分(fen)組查(cha)詢(xun)(xun)性(xing)(xing)(xing)能(neng)約(yue)為(wei)2500 倍(bei)(bei)(bei)(bei)、1000 倍(bei)(bei)(bei)(bei)，按時(shi)間分(fen)組查(cha)詢(xun)(xun)性(xing)(xing)(xing)能(neng)約(yue)為(wei) 119 倍(bei)(bei)(bei)(bei)、40 倍(bei)(bei)(bei)(bei)，壓縮比約(yue)為(wei) 26 倍(bei)(bei)(bei)(bei)、5 倍(bei)(bei)(bei)(bei)。

基于此，TDengine Database 在選(xuan)型中脫穎而出。

二、技術架構與具體實踐

具體到實際業務中，我們使用 TDengine 主要存儲(chu)以下三(san)種類(lei)型的數據：

• 租戶設備上拋的原始數據。經過實時計算處理后保存，租戶彼此之間數據隔離，一個租戶一個TDengine 庫
• 系統計算設備狀態變更的日志數據
• 系統中跟設備關聯的相關控制臺的操作日志數據

TDengine 在平臺中的總體架(jia)構圖如(ru)下所示(shi)：

相比于(yu)原架構，使用(yong) TDengine 之后出現了以(yi)下(xia)變化：

• 平臺接入的租戶相關庫、表通過監聽 Kafka 中的 binlog 日志自動初始化，每個設備點設置獨立一張表，數據分層清晰
• 將 Cassandra、KairosDB、OpenTSDB 均更換為 TDengine
• 可以使用 API 或 SDK 對 TDengine 進行讀寫
• 減少了數據流流動、處理以及服務之間的消息通訊步驟
• TDengine 提供的豐富函數減少了實時處理的數據計算
• TDengine 提升了讀寫速度，減少了數據流處理時間

2.1 TDengine 表結構設計

具體到表結構設計上，在我們的實際場景中，采用的是一個租戶一個 database 的方式進行創建，這樣的好處有三點：

• 可以為不同的租戶提供獨立的 database，用戶數據隔離級別很高，安全性很好
• 有助于簡化數據模型的擴展設計，滿足不同租戶的獨特需求
• 如果出現故障，恢復數據相對簡單

create database xxx keep 365 days 10 blocks 4 update 1；

參數名	釋義
keep	保存多少天
blocks	內存塊數
days	多久數據存一個文件
update	是否允許修改 1-允許，0-不允許

2.2 設備運行數據

設(she)備運行數據以(yi)設(she)備模型(xing)為超(chao)(chao)級(ji)表(biao)(biao)，該超(chao)(chao)級(ji)表(biao)(biao)命(ming)名規(gui)則為 pd_模型(xing)標志，例如(ru)：pd_devicemodel001，以(yi)設(she)備參數為子表(biao)(biao)名。具體的建表(biao)(biao)語(yu)句如(ru)下(xia)：

create table pd_devicemodel001(ts timestamp， smallint_value smallint， int_value int，bigint_value bigint，double_value double，boolean_value bool，string_value nchar(200) ) tags( device_model_mark nchar(25) ，device_mark nchar(25)， param_mark nchar(25)) ;

如果需要創(chuang)建的是(shi)單個(ge)參數(shu)(shu)的數(shu)(shu)據表(biao)(biao)，那子表(biao)(biao)命名規則是(shi) pd_模型標志(zhi)(zhi)_參數(shu)(shu)標志(zhi)(zhi)，例如：pd_devicemodel001_param01。具體的建表(biao)(biao)語句如下(xia)：

create table pd_devicemodel001_param01 using pd_devicemodel001 tags ("device01"，"did01"，"di0001");

2.3 設備狀態變更日志

在設備狀態(tai)變更日志時超級表命名為 device_state_change_log，代碼如(ru)下所示：

create table if not exists device_state_change_log (ts timestamp， change_type nchar(10)， status_before nchar(10)，status_after nchar(10)) tags ( device_model_mark nchar(25) ，device_mark nchar(25));

如果(guo)是(shi)單(dan)個設備(bei)一(yi)張子表的模式(shi)，子表命(ming)名(ming)規則(ze)為 dsl_模型標志(zhi)_設備(bei)標志(zhi)，例如：al_model01_device01。

create table if not exists %s using device_state_change_log tags ( "devicemodleMark001"，"device01");

2.4 設備信息變更日志

在設備信息變更日志時(shi)超級表(biao)命名為 device_info_change_log，代碼如下(xia)所示：

create table if not exists device_info_change_log (ts timestamp， opera_user nchar(50)， change_type nchar(10)，change_info nchar(50)， info_before nchar(200)，info_after nchar(200)) tags ( device_model_mark nchar(25) ，device_mark nchar(25));

單個(ge)設(she)備(bei)一張子表情況下(xia)，子表命名(ming)規則(ze)為 dil_模(mo)型標志_設(she)備(bei)標志，例如：al_model01_device01。

create table if not exists %s using device_info_change_log tags ( "devicemodleMark001"，"device01" )

2.5 問題及解決

我們(men)剛開始使用(yong)的是 TDengine 2.0.13.0 的版本，在建表以(yi)及(ji)使用(yong)過程中遇到了一些問題，主要包括以(yi)下3點：

• TDengine 數據列需要提前創建
• TDengine 數據列長度不可修改
• 在新建設備操作日志表時，提示 DB error: invalid SQL: row length exceeds max length (0.000505s)

在(zai)我們(men)跟濤(tao)思數(shu)據的(de)(de)技術專家進(jin)行(xing)相關溝(gou)通后，他們(men)建(jian)議將(jiang) TDengine 升(sheng)級到 2.2.2.0 的(de)(de)最新(xin)穩定(ding)版本，該版本支持數(shu)據列的(de)(de)動態新(xin)增(zeng)、修改。在(zai)溝(gou)通中還發現(xian)，上面問題中“建(jian)表報錯”一(yi)項是因為單條記錄數(shu)據超(chao)長(chang)了，按理說總長(chang)度不能(neng)超(chao)過(guo) 16KB，后面我們(men)對字(zi)段長(chang)度進(jin)行(xing)了調整，問題隨即迎刃而解。

三、具體的效果展示

接下(xia)來為(wei)大家展示一下(xia) TDengine 在壓縮率（存儲）、寫(xie)入、查詢(xun)等性能(neng)上的各(ge)種數據。

3.1 單機寫入性能

1）模擬 10 個(ge)廠區的數據(ju)、每(mei)個(ge)廠區 10000 個(ge)監測點(dian)，每(mei)個(ge)監測點(dian)從(cong) 2020-01-01 00:00:00.000 開始寫入模擬數據(ju)，記(ji)錄時間戳間隔 5 秒，每(mei)個(ge)測點(dian)寫入 100 萬條(tiao)記(ji)錄

2）寫入(ru)的(de)數(shu)(shu)據應(ying)當保持一致，生成方式為：將 10000 條(tiao)真實采集的(de)數(shu)(shu)據復制 100 份(fen)，時間(jian)戳按照 5 秒間(jian)隔自(zi)動(dong)生成，分別作為不(bu)同測(ce)點的(de)數(shu)(shu)據寫入(ru)數(shu)(shu)據庫

3）記錄以下(xia)內(nei)容，并觀察寫入過程中客戶端線程數、CPU、內(nei)存資源使用(yong)率：

• 確認 1000 億條記錄全部正確寫入數據庫
• 平均每秒寫入點數
• 所有寫入請求完成的總時延

最終顯示的結果為——條數/秒：2348220 總時延（秒）：42585.4531

3.2 時序數據庫壓縮比

1）確(que)認(ren) 1000 億條記錄原始數據文件(jian)大小，不計算標簽為(wei) 1117.59 GB，算上(shang)標簽為(wei) 67.666 TB；

2）落(luo)盤后數據文(wen)件大(da)小（自帶緩存的時(shi)序庫需(xu)重啟服務(wu)保證數據文(wen)件落(luo)盤）；

3）計算壓(ya)縮(suo)比=落盤后數據文(wen)件大(da)小(xiao)/原始數據文(wen)件大(da)小(xiao)；

落盤后所有文件大小為 113 GB，壓縮比為 10.11%

3.3 時序數據庫單測點原始歷史數據投影查詢性能

1）隨機選(xuan)擇任一個測點，查(cha)詢該測點在某個時(shi)間段內的歷史數(shu)(shu)據，比如從(cong) 2020-01-10 00:00:00.000 到(dao) 2020-01-11 00:00:00.000 一天內的共 17280條(tiao)數(shu)(shu)據記錄（數(shu)(shu)據輸出到(dao)文件）。 數(shu)(shu)據庫中對應查(cha)詢語句為(wei)：

select * from pt123 where ts >= '2020-01-10 00:00:00.000' and ts <= '2020-01-11 00:00:00.000' >> /dev/null

2）記錄以下內容：

• 確認查詢結果、記錄條數正確
• 查詢總耗時

3）重復(fu)執(zhi)行上述查詢(xun) 3 次，記錄平均耗時

具體結果為——3 次平均時延（秒）：0.13785

3.4 時序數據庫單測點原始歷史數據聚合查詢性能

1）隨機選擇任一個(ge)測(ce)點，查詢該測(ce)點在某個(ge)時間(jian)段(duan)測(ce)點采(cai)集值的(de)(de) count、max、min、avg，比如(ru)從 2020-01-01 00:00:00.000 到 2020-02-01 00:00:00.000 31 天內的(de)(de)共 535680 條數(shu)據記錄(lu)的(de)(de) count、max、min、avg。數(shu)據庫中對應(ying)查詢語句(ju)為：

select count(*), max(col1), min(col1), avg(col1) from pt1231 where ts >= '2020-01-10 00:00:00.000' and ts < '2020-01-11 00:00:00.000'

2）記(ji)錄以下內容(rong)：

• 確認查詢結果正確
• 查詢總耗時

3）重復執(zhi)行上述查詢3次，記錄平均耗時

具體結果為——3次平均時延（秒）：0.010504

目前(qian)我(wo)們已經(jing)將 TDengine 應用在數(shu)據(ju)采集(ji)、數(shu)據(ju)處理、數(shu)據(ju)邊緣計(ji)算、數(shu)據(ju)存(cun)儲(chu)等諸多方面，在實際業務中(zhong)也展(zhan)現出了(le)如上所示的超強性能，特別是在處理超高頻的數(shu)據(ju)采集(ji)、邊緣智能計(ji)算框架、數(shu)據(ju)流引擎和數(shu)據(ju)模型等方面效(xiao)果顯著，面對海量數(shu)據(ju)輕松(song)實現實時全生命周期管理。

四、寫在最后

在本次項目中，TDengine Database 展(zhan)現出(chu)了強(qiang)大的讀(du)寫(xie)性能和數據(ju)(ju)壓(ya)縮能力，聚合類查詢(xun)速度非(fei)常(chang)快，也幫助我們有效降(jiang)低了機器使用成本。超級表、子表、標簽等概念非(fei)常(chang)適配(pei)物(wu)聯網大數據(ju)(ju)應(ying)用場景，潛力無限。 未來希望TDengine發展(zhan)能夠越來越好，期待周邊生態(tai)工具更加完(wan)善。