小T導讀：
此前，智光電氣（股票代碼：002169）子公司智光研究院在工業(yè)項目中使用基于 Apache Hadoop 的 CDH 集群來做時序業(yè)務數(shù)據(jù)的處理，但由于數(shù)據(jù)量級太大，處理占用了大量資源，導致集群有發(fā)生崩潰的風險。在此背景下，智光研究院選擇應用 TDengine 進行技術升級，并產(chǎn)出本文分享應用經(jīng)驗。

作者：陳曉琪，智光研究院架構師，行業(yè)內多年開發(fā)與架構經(jīng)驗。

當前 TDengine 已成功應用于我司多個工業(yè)項目中，涵蓋數(shù)萬臺各類工業(yè)設備的數(shù)據(jù)存儲與查詢。作為數(shù)據(jù)中臺，TDengine 為上層應用提供了高效的歷史數(shù)據(jù)查詢，精確到秒級和分鐘級粒度，幫助我們大幅提升了應用效率，同時減少了硬件和人力資源的消耗。

選型背景

因此，我們急需一款時序數(shù)據(jù)庫（Time Series Database，TSDB）進行技術升級。經(jīng)過充分測試后，團隊最終決定把由 HBase 處理的、數(shù)據(jù)量最大的時序數(shù)據(jù)業(yè)務抽離出來，引入 TDengine 來降低 Hadoop 集群的壓力，成為獨立出來的數(shù)據(jù)中臺。

我們的設備數(shù)據(jù)首先通過邊緣網(wǎng)關進行采集，然后通過 MQTT 協(xié)議上報到工業(yè)互聯(lián)網(wǎng)平臺，報上來的數(shù)據(jù)經(jīng)過物模型解析后發(fā)送到 Kafka 集群，再把原始數(shù)據(jù)和經(jīng)過降采樣計算的分鐘級數(shù)據(jù)寫入到 TDengine 集群當中，以實現(xiàn)高效的數(shù)據(jù)存儲和查詢。

經(jīng)驗分享

從一個時序數(shù)據(jù)庫的初學者到使用者，我們最大的心得就是：

數(shù)據(jù)建?？梢哉f是最重要的一個環(huán)節(jié)，也是關乎是否能夠順利用好 TDengine 的根基。

考慮到對降采樣查詢的大量需求，我們經(jīng)過實際測試后發(fā)現(xiàn)，將這些計算量完全交給 TDengine 來做實時計算是不現(xiàn)實的。在此背景下我們選擇在應用層先做好一層降采樣計算，再寫入數(shù)據(jù)庫。為此我們將數(shù)據(jù)分為了原始數(shù)據(jù)和分鐘級數(shù)據(jù)兩類，對應到 TDengine 當中：iotdb 是原始數(shù)據(jù)，processeddb 是分鐘級庫。這種數(shù)據(jù)分類和存儲方式也更加符合我們的需求。

當全量數(shù)據(jù)導入之后（幾千億行），我們又發(fā)現(xiàn)了新的查詢性能問題，當時還以為 TDengine 的性能已經(jīng)封頂了。之后在 TDengine 官方團隊的協(xié)助定位下才找到核心問題——分鐘級庫與原始數(shù)據(jù)的寫入頻率差異過大，不能公用一套參數(shù)配置。

為了解決這一問題，后面官方根據(jù)我們實際的業(yè)務場景，分別對不同類型的數(shù)據(jù)進行建庫建表，做了針對性的建模優(yōu)化。然后我們又耐下心來，再次重新導入全量數(shù)據(jù)。

改造效果

經(jīng)過官方協(xié)助優(yōu)化后，數(shù)據(jù)塊變得更加緊密，壓縮率和查詢寫入性能均得到了大幅提升。

最終的成果如下：

寫入存儲方面，同樣是列式存儲，以半年的數(shù)據(jù)作為比較，三副本的 HBase 的總數(shù)據(jù)量占用是 10TB，TDengine 三副本的磁盤占用只有 2TB，存儲成本僅為 HBase 的 20 %。（由于和其他應用共用，內存、CPU 方面不好估算，但成本均大幅降低）

在查詢上，我們的業(yè)務主要就是針對 rundata_t1m（分鐘級數(shù)據(jù)）、rundata（原始數(shù)據(jù)）這兩張千億級別的大型超級表的篩選、過濾、降采樣。應用的查詢性能和 SQL 篩選的時間范圍相關較大，整體上的耗時大概在毫秒級至 2 秒內。

具體展示如下：

• 分鐘級數(shù)據(jù)的 5 分鐘級數(shù)據(jù)查詢（取 5 分鐘內最后的值）

select tbname, _wend - 1 as ts, LAST(val) AS val from rundata_t1m where tbname in ('b5Sk4IV6ld6-LErYYdQ1-ProcUsedPercent') and ts >= 1698768000000 and ts <= 1701100799000 partition by tbname interval(5m, 1a);

• 分鐘級數(shù)據(jù)的 15 分鐘級數(shù)據(jù)查詢（取 15 分鐘內最后的值）

select tbname, _wend - 1 as ts, LAST(val) AS val from rundata_t1m where tbname in ('b5Sk4IV6ld6-LErYYdQ1-ProcUsedPercent') and ts >= xxx and ts <= xxx partition by tbname interval(15m, 1a);

• 原始數(shù)據(jù)的秒級數(shù)據(jù)查詢

select tbname, _wend - 1 as ts, LAST(val) AS val from rundata where tbname in ('b5Sk4IV6ld6-LErYYdQ1-ProcUsedPercent') and ts >= xxx and ts <= xxx partition by tbname interval(1s, 1a);

寫在最后

TDengine 作為一款出色的國產(chǎn)時序數(shù)據(jù)庫，在實際應用中真正地為我們提供了巨大幫助。因此，我們決定整理成文，希望能夠吸引更多的企業(yè)和開發(fā)者加入我們的行列，共同探索 TDengine 的優(yōu)勢和潛力。讓我們一起共同推動國產(chǎn)數(shù)據(jù)庫技術的發(fā)展！

企業(yè)簡介：

智光研究院(廣州)有限公司【智光電氣（股票代碼：002169）下屬子公司】，是一家在能源動力技術領域具有深厚行業(yè)背景和創(chuàng)新研發(fā)能力的應用技術研究機構。憑借豐富的行業(yè)背景和創(chuàng)新研發(fā)能力，智光研究院在綜合能源工業(yè)互聯(lián)網(wǎng)平臺應用、大型工業(yè)設備狀態(tài)監(jiān)測和智能運維管理、能源系統(tǒng)數(shù)字化管理和能量優(yōu)化、新能源、儲能、電動化等方面取得了多項成果。目前已成功投入使用綜合能源服務工業(yè)互聯(lián)網(wǎng)平臺和多個垂直領域應用系統(tǒng)。

小 T 導讀：在 2021 樓宇科技 TRUE 大會上，美的暖通與樓宇事業(yè)部首次發(fā)布了數(shù)字化平臺 iBuilding，以“軟驅硬核”方式賦能建筑行業(yè)。作為一個全新的項目，iBuilding 在數(shù)據(jù)庫選型上比較謹慎，分別對比了多款 Database 產(chǎn)品之后，才做出了自己的選擇。本文分享了他們的數(shù)據(jù)庫選型思考和落地經(jīng)驗。

政策背景

根據(jù) 2021 年 12 月由美控智慧建筑聯(lián)合億歐智庫共同發(fā)布的《中國樓宇自控白皮書》，2021 年中國樓宇智能化市場產(chǎn)值約達 7238.2 億元，結合近幾年行業(yè)的發(fā)展趨勢，經(jīng)過初步估算，2016-2021 年中國樓宇智能化市場規(guī)模逐年上升，存量規(guī)模接近 5000 億元，新增規(guī)模超過 2200 億元。

因樓宇智能化在低碳、節(jié)能方面優(yōu)勢突出，同時能為人們的生活帶來更多舒適體驗，加之政府對樓宇智能化建設規(guī)范化、科學化的引導，未來樓宇智能化將有非常好的發(fā)展前景。從目標來看，樓宇智能化符合建筑行業(yè)對數(shù)字化和智能化的發(fā)展需求，未來將繼續(xù)助力中國建筑行業(yè)轉型升級，以順應國家對節(jié)能減排和數(shù)字經(jīng)濟的要求。

業(yè)務介紹

隨著 5G 時代的到來，美的一方面在繼續(xù)打造工業(yè)互聯(lián)網(wǎng)產(chǎn)品，另一方面也在不斷進行科技賦能，研發(fā)更加綠色環(huán)保的集成方案，為工業(yè)及制造業(yè)提供全新的思路。

作為美的集團旗下的五大業(yè)務板塊之一，美的暖通與樓宇事業(yè)部確立了“暖通及樓宇智慧生態(tài)集成解決方案引領者”的發(fā)展愿景，旨在用智慧集成的行業(yè)解決方案滿足復雜的建筑需求，目前主要涉足中央空調、電梯、樓宇控制等領域。在 2021 樓宇科技 TRUE 大會上，美的暖通與樓宇事業(yè)部首次發(fā)布了數(shù)字化平臺 iBuilding，以“軟驅硬核”方式賦能建筑行業(yè)。

作為一個全新的項目，我們分別對比了關系型數(shù)據(jù)庫（Relational Database）以及主流的時序數(shù)據(jù)庫（Time Series Database），包括 InfluxDB、TDengine、MySQL 等。對比關系型數(shù)據(jù)庫 MySQL 來說，在這個場景下，我們不需要復雜的查詢，卻需要高效的存儲和大范圍時間的數(shù)據(jù)拉取。和同為時序數(shù)據(jù)庫的 InfluxDB 對比，TDengine 的單機版性能遠好于 InfluxDB。因此，在綜合評估了適配、查詢、寫入和存儲等綜合能力后，我們最終選擇了 TDengine 這款產(chǎn)品。

iBuilding 項目屬于“智慧樓宇”的一部分，項目本身用于邊緣側對大型制冷設備（中央空調）的智能監(jiān)控與交互。具體應用場景是：項目所涉及的幾十個樓區(qū)，各自都有一些大型離心式冷水機組（10 臺左右），我們在每個樓區(qū)都部署了一個 TDengine 到 ARM64 系統(tǒng)上。通過 Python 程序，系統(tǒng)會先進行數(shù)據(jù)采集，然后把數(shù)據(jù)寫入 TDengine ，最后再把數(shù)據(jù)上傳到云端的 TDengine 進行處理。

具體實踐

以其中一個 Database 環(huán)境為例：

我們根據(jù) TDengine “一個設備一張表，一類設備一個超級表”的建模原則，創(chuàng)建了如下表，兩類設備的指標數(shù)分別為 97 和 199 ，數(shù)據(jù)列以 float 和 int 為主，設備每 5s 上報一批數(shù)據(jù)：

對于邊緣側的數(shù)據(jù)采集，由于資源有限，所以資源數(shù)據(jù)的使用就成為了十分重要的指標。這方面 TDengine 表現(xiàn)非常好，進一步幫我們降本增效了。

我們承載數(shù)據(jù)庫服務的邊緣盒子配置為 2GB 內存，4C CPU，ARM64 位的系統(tǒng)。由于子表數(shù)量不大，以及 TDengine 寫入內存比較固定的特點，當前內存占用還不到 200MB。數(shù)據(jù)庫日常 CPU 消耗比較低，大概在 3%-5% 左右，保守估計即便寫入量擴大 50-100 倍，也沒有問題。

應用效果

求某個設備 70 天前到 40 天前之間，每隔一段時間的設備用電量，無數(shù)據(jù)則用 prev 值填充。結果如下：

查詢一個月之前的某設備某幾項指標之和，按照時間戳降序排序。查詢大約 19 萬行數(shù)據(jù)，耗時 0.4s。結果如下：

經(jīng)驗匯總

在使用 TDengine 的過程中，我們也遇到過一些小問題，比如：我們環(huán)境眾多，但是客戶端和服務端又要保持版本精確一致，升級起來會比較復雜。再比如：監(jiān)控庫中 log 中的 dn 表的 disk_used 語義并不是實際的 TDengine 對磁盤的占用，而是數(shù)據(jù)文件所在文件系統(tǒng)的總占用，有些情況下會讓用戶誤以為是 TDengine 的空間占用，導致與預期不符，就像下圖一樣：

后面我們和 TDengine 社區(qū)工作人員一起討論了這個情況，大家認為可以新增一列，專門用來統(tǒng)計 TDengine 的數(shù)據(jù)文件的大小，然后把它與 disk_used、disk_total 一起規(guī)范化統(tǒng)一命名，就可以防止用戶誤解了。

目前 TDengine 官方已經(jīng)在積極地處理優(yōu)化。這也是開源社區(qū)的一大價值，大家都可以參與進去，讓產(chǎn)品不斷迭代，發(fā)展地更好。

寫在最后

當前，TDengine 主要被應用于中央空調制冷設備的監(jiān)控業(yè)務中，作為先行試點，這一場景已經(jīng)取得了不錯的效果。但由于機組價格昂貴、成本較高，因此通過平臺動態(tài)生成操作指令的這類智能化操作仍需謹慎，所以目前該功能還沒有正式開放。

在樓宇智能化方面，我們也有很多工作要做，從邊緣側的監(jiān)控、到指令控制、再到邊云協(xié)同的一體化服務，我們會在這些場景中繼續(xù)探索和挖掘 TDengine 的潛力。

小 T 導讀：SIMICAS? OEM 設備遠程運維套件是由 SIEMENS DE&DS DSM 團隊開發(fā)的一套面向設備制造商的數(shù)字化解決方案。在確定選擇 TDengine 作為系統(tǒng)的時序數(shù)據(jù)庫后，他們在 SIMICAS? OEM 2.0 版本中移除了 Flink、Kafka 以及 Redis，大大簡化了系統(tǒng)架構。

項目背景

IIoT（Industrial Internet of Things）是工業(yè)物聯(lián)網(wǎng)的簡稱，它將具有感知、監(jiān)控能力的各類采集、控制傳感器或控制器，以及移動通信、智能分析等技術不斷融入到工業(yè)生產(chǎn)過程的各個環(huán)節(jié)，從而大幅提高制造效率，改善產(chǎn)品質量，降低產(chǎn)品成本和資源消耗，最終實現(xiàn)將傳統(tǒng)工業(yè)提升到智能化的新階段。

通過新的互聯(lián)網(wǎng)連接設備獲取的數(shù)據(jù)可用于提高效率、實時決策、解決關鍵問題，并最終創(chuàng)造新的創(chuàng)新體驗。然而隨著相互連接的設備越來越多，公司所面臨的碎片化和新挑戰(zhàn)也越來越多。為了獲取和利用數(shù)據(jù)的力量，他們需要解決方案來提供可互操作的端到端協(xié)作，從而在互聯(lián)網(wǎng)和設備之間架起橋梁，同時駕馭即將到來的創(chuàng)新浪潮。

SIMICAS? OEM 設備遠程運維套件是由 SIEMENS DE&DS DSM 團隊開發(fā)的一套面向設備制造商的數(shù)字化解決方案，該方案借助物聯(lián)網(wǎng)實現(xiàn)設備的高效遠程運維，對售后服務數(shù)據(jù)進行智能分析，從而真正實現(xiàn)整體售后環(huán)節(jié)的降本增效。

在 IIoT 大背景的發(fā)展浪潮下，SIMICAS 為企業(yè)提供了一個踏入數(shù)字化世界的靈活選擇，幫助企業(yè)根據(jù)自身發(fā)展需求定制數(shù)字化發(fā)展路徑。SIMICAS 解決方案由四個部分組成：SIMICAS 智能網(wǎng)關、SIMICAS 組態(tài)工具，以及兩個在西門子基于云的開放式物聯(lián)網(wǎng)操作系統(tǒng) MindSphere 基礎上開發(fā)的 APP——SIMICAS 生產(chǎn)透鏡和 SIMICAS 產(chǎn)效分析。 

一、系統(tǒng)架構

在其 1.0 版中，我們使用了 Flink + Kafka + PostgreSQL + Redis 的架構。該系統(tǒng)的數(shù)據(jù)流如下：

設備數(shù)據(jù)通過部署至現(xiàn)場的網(wǎng)關上傳至物聯(lián)網(wǎng)接入組件，組件根據(jù)配置對數(shù)據(jù)進行解析處理后，將其寫入 Kafka 隊列，F(xiàn)link 從 Kafka 中消費數(shù)據(jù)并進行計算，原始值及計算后的指標數(shù)據(jù)都會被寫入 PostgreSQL 中，最新值還會存一份到 Redis 中，以便更快地響應前端實時的數(shù)據(jù)查詢，設備歷史數(shù)據(jù)則從 PostgreSQL 中查詢。

二、業(yè)務挑戰(zhàn)

1.0 系統(tǒng)落地之后，我們遇到了兩大挑戰(zhàn)，一個是部署繁瑣，一個是應用復雜。

具體來說，因為引入了 Flink 和 Kafka，導致系統(tǒng)部署時非常繁瑣，服務器開銷巨大；同時為了滿足大量數(shù)據(jù)的存儲問題，PostgreSQL 中不得不做分庫分表操作，應用程序較為復雜。

如何降低系統(tǒng)復雜度、減少硬件資源開銷，幫助客戶減少成本，成為研發(fā)團隊的核心任務。

三、技術選型

從產(chǎn)品的實際痛點出發(fā)，結合未來產(chǎn)品的發(fā)展規(guī)劃，我們團隊計劃對產(chǎn)品的數(shù)據(jù)處理部分進行重構，在技術選型時主要考慮了如下幾個方面：

• 高性能，可以支持百萬級別的并發(fā)寫入、萬級的并發(fā)讀取，大量聚合查詢時依然有高性能表現(xiàn)
• 高可用，可支持集群部署，可橫向擴展，不存在單點故障
• 低成本，數(shù)據(jù)庫對硬件資源要求低，數(shù)據(jù)壓縮率高
• 高度一體化，在具備以上三個特點的基礎上，是否具備一定的消息隊列、流式計算和緩存的功能

本著以上幾個需求，在對各種開源數(shù)據(jù)平臺、時序數(shù)據(jù)庫（Time Series Database）進行選型對比后，我們發(fā)現(xiàn) TDengine 正好符合產(chǎn)品重構所有的要求，尤其是低成本和高度一體化這兩個點，這是目前絕大部分數(shù)據(jù)平臺或時序數(shù)據(jù)庫都不具備的，所以團隊果斷選擇了 TDengine。

四、落地實踐

數(shù)據(jù)流程

在確定選擇 TDengine 作為系統(tǒng)的序數(shù)據(jù)庫后，我們在 SIMICAS? OEM 2.0 版本中移除了Flink、Kafka 以及 Redis，新系統(tǒng)的數(shù)據(jù)流如下：

數(shù)據(jù)建模

創(chuàng)建數(shù)據(jù)庫

數(shù)據(jù)默認保存 2 年，數(shù)據(jù)庫采用 3 節(jié)點集群，數(shù)據(jù)采用 3 副本存儲，保留 update 能力；

create database if not exists simicas_data keep 712 replica 3 update 2;

創(chuàng)建實時數(shù)據(jù)表格

為平臺中的每種設備類型創(chuàng)建一個獨立的超級表（super table），為每種設備類型下的每個具體設備創(chuàng)建獨立的設備子表。

create stable if not exists product_${productKey} (ts timestamp,linestate bool,${device_properties}) tags (device_code binary(64));
create table if not exists device_${device_code} using product_${productKey} tags (${device_code})

創(chuàng)建狀態(tài)表

為平臺中所有設備創(chuàng)建一個共同的超級表。

create stable if not exists device_state (ts timestamp,linestate bool,run_status int,error_code binary(64),run_total_time int,stop_total_time int,error_total_time int) tags (device_code binary(64),product_key binary(64));
create table if not exists device_state_${device_code} using device_state tags (${device_code},${productKey})

指標計算

我們基于 JEXL 表達式 + 實時查詢的方式實現(xiàn)了系統(tǒng)中的指標計算。我們使用 JEXL 表達式來定義指標的計算表達式，系統(tǒng)解析后將變量替換成 SQL 查詢任務，在查詢返回結果后再到系統(tǒng)中進行計算，返回至前端。

比如計算某項目下所有設備當前電壓的平均值，其表達式為 avg(voltage,run_status=1 && project=abc)，它會被分解為：1）查詢 run_status=1 && project=abc 的所有設備；2）查詢第一步結果中所有設備 voltage 字段的最新值；3）計算第二步所有設備最新結果的平均值。

得益于多線程和 TDengine 高效的查詢表現(xiàn)，單個 KPI 的查詢 P99 表現(xiàn)小于 100ms。

五、遇到的問題

在 TDengine 官方推薦的最佳實踐中，數(shù)據(jù)表建模建議使用多列模式，我們團隊在一開始選擇了這種方式，但是在實際使用中發(fā)現(xiàn)，部分客戶的設備測點非常多，甚至超過 2000 列，這樣可能會因為單行數(shù)據(jù)過大而導致插入數(shù)據(jù) SQL 過長的問題[1] ；另一個問題是現(xiàn)場設備是按照“OnChange（突發(fā)上送）”方式進行數(shù)據(jù)上傳，導致非常多的 NULL 值出現(xiàn)，在執(zhí)行 select last(*) from device_xxx 時效率較低[2]。

在與 TDengine 官方的技術人員溝通后，我們了解到，last 函數(shù)是對每列進行查找，直到最近一條非 NULL 值為止，在當時的版本下，cache 對 last 函數(shù)是無效的。

后來，團隊通過對項目中單個設備參數(shù)的最大數(shù)量進行限制，解決了問題[1]；又通過修改設備數(shù)據(jù)的上傳方式，解決了問題[2]。

但是在根本上，還是我們在最初建模時，沒有充分考慮到客戶的業(yè)務場景，從而導致了以上問題。因此，我們團隊后續(xù)在系統(tǒng)中實現(xiàn)了同時支持多列模式和單列模式，這樣客戶就可以根據(jù)現(xiàn)場的實際情況，自由切換建模方式。

六、寫在最后

與其他開源數(shù)據(jù)平臺或數(shù)據(jù)庫相比，目前 TDengine 的運維監(jiān)控能力還不算強大，不過前段時間發(fā)布的 TDinsight 已經(jīng)帶來了很多改進，我們團隊也規(guī)劃在下一階段試用一下。
特別感謝濤思數(shù)據(jù)的陳偉燦及其他同事在產(chǎn)品開發(fā)過程給予的支持，雖然在過程中遇到一些問題，但整體而言，TDengine 的各項優(yōu)異表現(xiàn)給了我們團隊很多驚喜。

最后期待 TDengine越來越好，幫助更多客戶、更多場景降本增效！

小 T 導讀：在拓斯達的智能工廠整體解決方案項目中，傳統(tǒng)的關系型數(shù)據(jù)庫已經(jīng)無法高效處理時序數(shù)據(jù)，在加載、存儲和查詢等多個方面都遇到了挑戰(zhàn)，最終他們選擇了 TDengine 來匹配工業(yè)傳感器數(shù)據(jù)的應用分析場景。本文將講述他們應用 TDengine 的具體實踐。

企業(yè)簡介

廣東拓斯達科技股份有限公司（簡稱：拓斯達，股票代碼：300607）是廣東省首家登陸創(chuàng)業(yè)板的機器人骨干企業(yè)。拓斯達堅持“讓工業(yè)制造更美好”的企業(yè)使命，通過以工業(yè)機器人、注塑機、CNC為核心的智能裝備，以及控制、伺服、視覺三大核心技術，打造以核心技術驅動的智能硬件平臺，為制造企業(yè)提供智能工廠整體解決方案。

項目介紹

在工業(yè)領域， 生產(chǎn)、測試、運行階段都可能會產(chǎn)生大量帶有時間戳的傳感器數(shù)據(jù)，這都屬于典型的時序數(shù)據(jù)。時序數(shù)據(jù)主要由各類型實時監(jiān)測、檢查與分析設備所采集或產(chǎn)生，涉及制造、電力、化工、工程作業(yè)等多個行業(yè)，具備寫多讀少、量非常大等典型特性。

在我們的業(yè)務中，傳統(tǒng)的關系型數(shù)據(jù)庫（Relational Database）已經(jīng)無法高效處理時序數(shù)據(jù)，在加載、存儲和查詢等多個方面都遇到了挑戰(zhàn)。主要問題可以匯總如下：

• 寫入吞吐低：單機寫入吞吐量低，很難滿足時序數(shù)據(jù)千萬級的寫入壓力；
• 存儲成本大：在對時序數(shù)據(jù)進行壓縮時性能不佳，需占用大量機器資源；
• 維護成本高：單機系統(tǒng)，需要在上層人工進行分庫分表，維護成本高；
• 查詢性能差：海量實時數(shù)據(jù)的聚合分析性能差。

為了更好地滿足時序數(shù)據(jù)的處理需求，我們決定進行數(shù)據(jù)庫選型調研，最終選擇了時序數(shù)據(jù)庫（Time-Series Database）TDengine。 事實證明，TDengine 針對時序數(shù)據(jù)的寫入、存儲、索引、查詢等方面都進行了特定的優(yōu)化，從而實現(xiàn)了更優(yōu)的數(shù)據(jù)加載、數(shù)據(jù)壓縮、查詢寫入性能，非常匹配工業(yè)傳感器數(shù)據(jù)的應用分析場景。

選擇 TDengine 的理由

與通用數(shù)據(jù)庫相比，TDengine 的壓縮率表現(xiàn)驚人，核心原因是其采用列式存儲，而且采用了二階段壓縮策略，還針對不同數(shù)據(jù)類型采取了不同的壓縮算法，這種壓縮機制使其壓縮率遠超其他數(shù)據(jù)庫。

此外 TDengine 還擁有極高的讀寫性能，并且讀寫速度受數(shù)據(jù)存儲規(guī)模的影響微乎其微，要知道通用數(shù)據(jù)庫的數(shù)據(jù)量一旦過百萬級，讀寫速度就會有明顯下降，之前我們做過一次 MySQL 批量插入數(shù)據(jù)的測試，性能差距明顯，這也是在大量級數(shù)據(jù)存儲下我們會選擇TDengine的重要原因之一。具體來說，TDengine 優(yōu)勢如下：

• 數(shù)據(jù)的讀寫速度快且自帶時間戳，使用 SQL 進行數(shù)據(jù)庫操作，簡單易學，支持復雜查詢
• 數(shù)據(jù)壓縮率高，大量級的數(shù)據(jù)也不會占據(jù)過多存儲空間，可導出數(shù)據(jù)進行備份
• 擁有交流社區(qū)和交流群，遇見問題可以和 TDengine 的其他使用者一起探討，而且官方的同學也能提供及時的幫助

當然，世上沒有完美的數(shù)據(jù)庫，我們在應用之后總結出了兩點待改進的地方：

• 無法使用可視化軟件如 Navicat 等進行數(shù)據(jù)庫操作（TDengine GUI）
• 目前還沒有 Windows 版的服務端，像我們上一個客戶，只在本地 Windows 上使用程序，在沒有安裝虛擬機和部署到服務器的情況下，就無法部署 TDengine

但每一款產(chǎn)品都是在發(fā)現(xiàn)問題和改進問題的步伐中逐漸進步的，而且對于我們的業(yè)務實現(xiàn)來說，TDengine 不存在明顯的短板。沒有最優(yōu)的數(shù)據(jù)庫，在場景匹配的情況下，我們最終采用了 TDengine。

落地實踐

• 平臺架構

我們是通過網(wǎng)關采集設備數(shù)據(jù)推送到 MQTT，Java 后端監(jiān)聽到后會寫入 TDengine，在后端按需求查詢處理后再把數(shù)據(jù)返回給前端。

具體來說，網(wǎng)關會先讀取后臺發(fā)布的上行規(guī)則，在采集到設備數(shù)據(jù)后，使用上行規(guī)則對數(shù)據(jù)進行處理計算后再將結果返回給下行規(guī)則模塊，后臺監(jiān)聽到后，會連接 TDengine 進行數(shù)據(jù)庫表的創(chuàng)建修改和數(shù)據(jù)寫入。之前在云平臺我們使用過 Kafka 進行數(shù)據(jù)的發(fā)布訂閱，現(xiàn)在所有環(huán)境都改為 MQTT 了。

• 超級表及建模思路

在應用 TDengine 時，我們建立了流水數(shù)據(jù)庫 “iot_platform” 用來存儲網(wǎng)關傳來的數(shù)據(jù)，便于日后查詢使用。我們遵循“一個采集點一張表，一類數(shù)據(jù)一個超級表”的思路來建表，在具體實踐上設計了兩張超級表，一張是用于存儲 log 指令內容的“l(fā)ogs”表，另一張是用于存儲其它指令內容的“datas”表，數(shù)據(jù)類型基本為電流電壓、設備狀態(tài)等。在進行數(shù)據(jù)存儲時首先會對數(shù)據(jù)加以判斷，再決定將數(shù)據(jù)存儲到哪張表里。

落地效果

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

• 流水數(shù)據(jù)查詢

查詢某一時間段內的流水數(shù)據(jù)，使用查詢語句：

SELECT datagettime as ts , ${dataName} as data FROM ${tableName}
 <where>
    uuid = ${uuid}
    <if test="startTime != null ">
        and datagettime > #{startTime}
    </if>
    <if test="endTime != null ">
        and #{endTime} > datagettime
    </if>
    and ${dataName} is not null
 </where>
 limit 0, ${countLimit}

• 聚合函數(shù)計算一天的數(shù)據(jù)

使用 TDengine 的函數(shù)計算每天的用電量，再通過每天的去計算月和年數(shù)據(jù)，查詢語句為：

select diff(${dataName}) as data
 from ${tableName}
 where ${dataName} > 0
  and datagettime > #{startTime}
   and #{endTime} >= datagettime

• 計算某一時間段內的數(shù)據(jù)

select ${method}(${dataName}) as data
 from ${tableName}
 where uuid = ${uuid}
  and datagettime > #{startTime}
  and #{endTime} > datagettime;

寫在最后

在工業(yè)互聯(lián)網(wǎng)快速發(fā)展的大背景下，工業(yè)生產(chǎn)現(xiàn)場投放了大量的設備傳感器和監(jiān)控系統(tǒng)，二者提供的實時數(shù)據(jù)能夠反映設備的狀態(tài)和生產(chǎn)的進度，其中的大多數(shù)據(jù)都是按照時間順序形成的實時數(shù)據(jù)，這些海量實時數(shù)據(jù)有著多樣化的分析需求和重要的參考價值。

未來希望 TDengine 可以提供更復雜的流式計算、查詢分析以及監(jiān)測預警等能力，可以為產(chǎn)品的可視化運維、預測性維護、遠程智能管理等方面提供數(shù)據(jù)依據(jù)，從而降低人員、時間等成本，加速工業(yè)化與信息化的深度融合，促進復雜重型裝備制造業(yè)的轉型升級，產(chǎn)生社會經(jīng)濟效益。

小 T 導讀：酷哞哞與 TDengine Database 結緣于 2019 年，在其工業(yè)互聯(lián)網(wǎng)設備上云解決方案中，選擇了 TDengine 作為數(shù)據(jù)平臺，以滿足海量工業(yè)數(shù)據(jù)存儲和分析的需求。本篇文章解讀了 TDengine 在此方案中的具體應用。

互聯(lián)網(wǎng)和傳統(tǒng)工業(yè)的融合將是新一輪制造業(yè)發(fā)展的制高點，企業(yè)數(shù)字化轉型與工業(yè)互聯(lián)網(wǎng)的發(fā)展是重要趨勢。我們憑借豐富的行業(yè)經(jīng)驗和深度研發(fā)，成功研制出一套工業(yè)互聯(lián)網(wǎng)設備上云的整體解決方案。在該方案中，通過主流的 PLC 協(xié)議，我們實現(xiàn)了眾多設備的互通互聯(lián)；除此之外，數(shù)據(jù)存儲服務可以解決大量數(shù)據(jù)存儲和分析的難題；應用開發(fā)服務則可以利用無代碼編程解決用戶開發(fā)成本高、技術棧復雜、鏈路長等一系列問題。總而言之，從數(shù)據(jù)采集，到存儲展示、運維監(jiān)控，再到應用發(fā)布等模塊，我們完成了工業(yè)設備全域一體化的管理方案。

整個方案的層次結構如下。

TDengine Database 作為數(shù)據(jù)存儲平臺，解決了我們海量工業(yè)數(shù)據(jù)存儲和分析的大難題。

作為一個 OT 數(shù)倉類的平臺，存儲時序數(shù)據(jù)的數(shù)據(jù)庫最好要滿足這幾個特點：高吞吐量、低消耗、強寫入，滿足工業(yè)場景的大數(shù)據(jù)量查詢。機緣巧合，在 2019 年，正是我們創(chuàng)業(yè)的初期，聽到了濤思數(shù)據(jù)創(chuàng)始人陶建輝老師關于 TDengine 的講座，一些理念與我們不謀而合。

于是我們沒有做過多的選型，直接選擇了 TDengine Database。

一、TDengine 的應用情況

三年過后的今天，我們發(fā)現(xiàn)自己的選擇十分正確，TDengine 為我們創(chuàng)造了很多價值；而且 TDengine 這個產(chǎn)品本身也是蒸蒸日上，已經(jīng)成為時序數(shù)據(jù)庫領域的佼佼者。

我們以單副本模式落地了數(shù)據(jù)庫服務，機器配置為 8C 處理器 + 16GB 內存 + 500GB 機械硬盤，備份用其他方式完成。由于我們暫時沒有分組聚合查詢的需求，所以沒有使用超級表。

當前環(huán)境下有 3797 張表，總數(shù)據(jù)量大概有 10 多億條。實際存儲量占用大概為 5G 左右

由于 PLC 通信協(xié)議種類繁多，即便有的設備會有部分協(xié)議開源，但是開放的只有通訊的方式和協(xié)議，所以驅動還是需要自己去實現(xiàn)的。而且一些通訊協(xié)議又有很多分支：比如 modbus 協(xié)議就包含了 modbusTCP、modbusRTU 以及 modbusASCII。此外，使用 modbus 通訊的不同設備之間，有的支持的功能碼和字節(jié)序還不同，所以數(shù)據(jù)采集這里還是比較復雜的。

在數(shù)據(jù)采集時，我們優(yōu)先使用 modbus 和其他我們已有的協(xié)議驅動接入，如果遇到不支持的協(xié)議，那么定制化開發(fā)驅動是難免的。在采集到數(shù)據(jù)后，數(shù)據(jù)的走向如下：

1. 由我們的底層邊緣網(wǎng)關系統(tǒng)將設備的數(shù)據(jù)采集起來后發(fā)送給后端 Java 服務。
2. Java 服務將收到的數(shù)據(jù)實時地存放在內存中。
3. 由 Java 服務最快 1 秒一次將數(shù)據(jù)消費，并通過 TDengine 的 insert 語句將數(shù)據(jù)存放到數(shù)據(jù)庫中。

二、落地效果

對于數(shù)據(jù)的實際使用，我們通過數(shù)據(jù)的變量 ID（即表名）查詢出變量數(shù)據(jù)通過 ECharts 圖形框架展示在前端頁面上，比較常用的查詢 SQL 就是降采樣查詢，全部都是毫秒級返回結果。

查詢展示效果如下：

后續(xù)，我們計劃對 TDengine 的使用進行改造，隨著設備量和用戶需求的多樣化，我們會使用 TDengine 的超級表和多副本等更加核心的功能來增強我們產(chǎn)品的能力。

三、寫在最后

中國制造業(yè)總體水平處于 2.0 向 3.0 過渡的階段，老舊設備多，數(shù)字化水平低。

工業(yè)互聯(lián)網(wǎng)的設備數(shù)字化率正走在逐年創(chuàng)新高的路上，工業(yè)互聯(lián)網(wǎng)的市場規(guī)模也正在井噴式發(fā)展，增長率喜人。因此，隨著國家的產(chǎn)業(yè)政策逐漸落地，我們有信心和 TDengine Database 一起，把握時代給予的機會，一起為中國工業(yè)的信息化、自動化和智能化做出我們的貢獻。

 關于作者

冷艷霞，酷哞哞科技創(chuàng)始人。四川酷哞哞科技有限公司是一家集工業(yè)大數(shù)據(jù)采集、云平臺于一體的新型科技公司。致力于為各大中小型制造企業(yè)服務，切實為企業(yè)解決痛點、難點，實現(xiàn)企業(yè)由自動化工廠向數(shù)字化工廠轉型，最終實現(xiàn)智能化。

小 T 導讀：和利時始創(chuàng)于 1993 年，業(yè)務集中在工業(yè)自動化、交通自動化和醫(yī)療大健康三大領域，結合自動化與信息化兩方面的技術優(yōu)勢，提出了“智能控制、智慧管理、自主可控、安全可信”的戰(zhàn)略指導方針。圍繞集團三大業(yè)務，公司對工業(yè)互聯(lián)網(wǎng)、大數(shù)據(jù)、5G、信息安全等新興技術開展更深入的研究和應用示范，打造面向各領域應用的工業(yè)互聯(lián)網(wǎng)平臺，進一步促進智能制造解決方案的落地應用。

在物聯(lián)網(wǎng)場景下，面對龐大的時序數(shù)據(jù)處理需求，Oracle、PostgreSQL 等傳統(tǒng)關系型數(shù)據(jù)庫越來越吃力?；诖?，目前國內外主流工業(yè)互聯(lián)網(wǎng)平臺幾乎都已經(jīng)采用時序數(shù)據(jù)庫（Time Series Database），來承接海量涌入的工業(yè)數(shù)據(jù)。

究其原因，可以從數(shù)據(jù)的三個核心需求來解釋。我們都知道，企業(yè)在選擇數(shù)據(jù)庫、文件系統(tǒng)等產(chǎn)品時，最終目的都是為了以最佳性價比來滿足數(shù)據(jù)的三個核心需求：數(shù)據(jù)寫入、數(shù)據(jù)讀取、數(shù)據(jù)存儲。時序數(shù)據(jù)庫完全是按照時序數(shù)據(jù)的三個需求特征進行設計和開發(fā)的，在數(shù)據(jù)處理上更加具有針對性：

• 在數(shù)據(jù)寫入上，如果將時間看作一個主坐標軸，時序數(shù)據(jù)通常是按照時間順序抵達，抵達的數(shù)據(jù)幾乎總是作為新條目被記錄，在數(shù)據(jù)處理操作上 95%-99% 都是寫入操作；
• 在數(shù)據(jù)讀取上，隨機位置的單個測量讀取、刪除操作幾乎沒有，讀取和刪除都是批量的，從某時間點開始的一段時間內讀取的數(shù)據(jù)可能非常巨大；
• 在數(shù)據(jù)存儲上，時序數(shù)據(jù)結構簡單，價值隨時間推移迅速降低，通常都是通過壓縮、移動、刪除等手段來降低存儲成本。

而關系型數(shù)據(jù)庫主要應對的數(shù)據(jù)特點卻大相徑庭：

• 數(shù)據(jù)寫入：大多數(shù)操作都是 DML 操作，插入、更新、刪除等
• 數(shù)據(jù)讀取：讀取邏輯一般都比較復雜
• 數(shù)據(jù)存儲：很少壓縮，一般也不設置數(shù)據(jù)生命周期管理

因此，從數(shù)據(jù)本質的角度而言，時序數(shù)據(jù)庫（不變性、唯一性以及可排序性）和關系型數(shù)據(jù)庫的服務需求完全不同。這也是我們一開始就鎖定時序數(shù)據(jù)庫來滿足工業(yè)互聯(lián)網(wǎng)場景的核心原因。

一、時序數(shù)據(jù)庫選型

我們對包括 InfluxDB、OpenTSDB、HolliTSDB（和利時自研時序數(shù)據(jù)庫）和 TDengine 在內的四款時序數(shù)據(jù)庫進行了選型調研及相關測試。測試數(shù)據(jù)的頻率為1秒鐘，數(shù)據(jù)集包含 10000 臺設備，每臺設備有 10000 條記錄，每條數(shù)據(jù)采集記錄包含 3 個標簽字段、2 個數(shù)據(jù)字段、1 個時間戳字段。測試對比項包括占用磁盤空間、百萬條數(shù)據(jù)遍歷查詢、聚合查詢（COUNT、AVG、SUM、MAX、MIN）。測試結果如下所示：

• 占用磁盤空間

• 百萬條數(shù)據(jù)遍歷查詢

• 聚合查詢COUNT

• 聚合查詢AVG

• 聚合查詢SUM

• 聚合查詢MAX

• 聚合查詢MIN

同等條件下，TDengine 的壓縮率最高，數(shù)據(jù)占用的存儲空間最??；在原始數(shù)據(jù)查詢上，OpenTSDB 最慢，TDengine 與 HolliTSDB 在伯仲之間；在聚合查詢操作上，TDengine 最快，HolliTSDB 的速度和 InfluxDB 相當，OpenTSDB 最慢。同時，InfluxDB 只能單機部署，集群版本并未開源，且查詢性能存在瓶頸，其 QPS 約為 30-50。

從性能測試結果來看，我們選擇 TDengine Database 的原因主要源于以下幾點：

• TDengine 在查詢性能維度上的表現(xiàn)非常優(yōu)異，滿足了我們的業(yè)務查詢需求
• 集群功能開源，方便橫向擴展，更彈性
• 在開源熱潮之下，支持如 TDengine 一般的國產(chǎn)開源數(shù)據(jù)庫、操作系統(tǒng)、中間件等也是企業(yè)的必修課

最終我們決定接入 TDengine，以享受更多元的本地化支持和響應。

二、技術架構與實現(xiàn)

目前 TDengine 作為邊緣版時序數(shù)據(jù)庫在搭建使用，具體的技術架構如下圖所示：

基于 TDengine 進行建庫建表思路如下：

CREATE STABLE IF NOT EXISTS ts_super 
(time TIMESTAMP, s BIGINT, vl BIGINT,vf DOUBLE,vb BOOL,vs BINARY(16349))
TAGS 
(innerId BIGINT, namespace BINARY(256), id BINARY(256), type BINARY(1), seq int);

在構建列時，包含元素為time（時間，主鍵）、s（數(shù)據(jù)質量）、vl（整形類型數(shù)據(jù)L）、vf（浮點型數(shù)據(jù)F）、vb（布爾型數(shù)據(jù)B）、vs（字符串數(shù)據(jù)S），其中time、s是必填的列，剩余列則要根據(jù)測點類型填寫，比如測點上報的是整形數(shù)據(jù)，就只需要設置time、s、vl這三列，vf、vb、vs這三列為null。

在構建tag時，要包括innerId（測點內部編碼）、id（測點id）、type（測點類型，L/F/B/S）、seq （序號，L/F/B類型數(shù)據(jù)設置為0，S類型測點的seq可能為0,1,2,3…）

同時，在建庫建表的操作中我們也碰到了一些小問題，放在這里給大家做下參考：

• 因為表名不支持特殊字符，所以需要再生成一個唯一編碼作為表名；
• 查詢語句會被填充，導致查詢過程性能變慢，網(wǎng)卡被打滿。這種情況下只需要將查詢請求手動壓縮，就能有效降低帶寬占用率；
• TDengine 字符串最長可以有16374字節(jié) ，超過的話需要從邏輯上處理。我們采用的方案是如果長度超過16374 ，截取該字符串，同一個測點再建新的表，通過tag關聯(lián)。

三、實際效果展示

數(shù)據(jù)庫配置

TDengine 集群5個節(jié)點，副本數(shù)設置為3。修改配置為：

• minTablesPerVnode 10
• tableIncStepPerVnode 10
• compressMsgSize 1024
• rpcForceTcp 1
• httpMaxThreads 16

各節(jié)點機器配置如下：

查詢客戶端配置

客戶端共有三臺主機，每臺主機上分別運行時序查詢及其對應的AB，各主機上的時序查詢獨立運行，分別啟動一/二/三個時序查詢及其對應的AB進行性能測試。

數(shù)據(jù)說明

共1000個測點，80000萬條數(shù)據(jù)，數(shù)據(jù)頻率為每秒鐘1條。存儲分布如下所示，存儲壓縮率不超過1/10。

查詢結果

在我們的業(yè)務查詢當中，增加QPS的主要方式是增加查詢的并發(fā)數(shù)。AB從1到2，QPS增加了45%，平均響應時間不超過1000ms，很好滿足了客戶需求

資源消耗(統(tǒng)計3個查詢服務的實例)

• TDengine node節(jié)點資源消耗

在查詢過程中，數(shù)據(jù)是相對均勻的分布，但是不同節(jié)點的CPU消耗仍然有較大的方差。這是由于TDengine 的 RESTful 的底層是在服務端通過單獨的代理線程作為客戶端查詢，所以會受到請求均勻度的影響。如果 TDengine 在后續(xù)可以做代理層面的負載均衡，相信能夠縮小這個偏差。

查詢服務資源消耗

在查詢段的節(jié)點資源消耗還是相當大的，因為需要對查詢請求和結果進行處理。在具體業(yè)務中，可以考慮使用RPC接口來降低查詢服務的CPU消耗。

四、寫在最后

TDengine Database 在本項目中展現(xiàn)出的性能效果非常顯著，推動本次項目快速且高質量落地，實現(xiàn)降本增效的目標。接下來，希望 TDengine 能夠在以下兩個方向上有更大的進步，也祝愿我們的合作能夠越來越緊密：

• 希望可以通過觸發(fā)器或協(xié)處理器等方式，在服務端做數(shù)據(jù)過濾再返回，解決網(wǎng)絡壓力過大的問題
• 希望能夠進一步改善長度限制的問題

小 T 導讀：格創(chuàng)東智科技有限公司成立于 2018 年，孵化于中國 500 強企業(yè) TCL，是我國知名的工業(yè)互聯(lián)網(wǎng)平臺服務商。公司依托 TCL 集團 40 年工業(yè)場景和制造基因沉淀，基于“面向工業(yè)現(xiàn)場”的研發(fā)方向和“連接、協(xié)同、共享”的發(fā)展理念，深度融合人工智能、大數(shù)據(jù)、云計算、物聯(lián)網(wǎng)等前沿技術，打造了新一代具有自主知識產(chǎn)權的工業(yè)互聯(lián)網(wǎng)平臺——”東智工業(yè)應用智能平臺”。

作為東智工業(yè)應用智能平臺產(chǎn)品家族的物聯(lián)網(wǎng)平臺，G-Things 為工業(yè)設備提供了安全可靠的連接通信能力，其支持數(shù)據(jù)采集、規(guī)則引擎、數(shù)據(jù)轉發(fā)、指令下發(fā)、數(shù)據(jù)可視化，同時提供開放的 API 與第三方系統(tǒng)快速對接，為工業(yè)企業(yè)提供高效率、低成本、高可靠的工業(yè)物聯(lián)網(wǎng)解決方案。

從采集的數(shù)據(jù)類型上來看，平臺采集的設備數(shù)據(jù)以及系統(tǒng)業(yè)務主要有以下時序數(shù)據(jù)特性:

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

為了讓用戶在最大程度上實現(xiàn)降本增效，G-Things 在接入不同的租戶時，會從用戶類型(輕量級、重量級等)、設備規(guī)模、設備采集的數(shù)據(jù)量等角度幫助用戶選擇適配合理的時序數(shù)據(jù)持久化落地方案。

一、時序數(shù)據(jù)庫選型調研

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

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

在同等數(shù)據(jù)集和硬件環(huán)境下，對比發(fā)現(xiàn)：

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

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

二、技術架構與具體實踐

具體到實際業(yè)務中，我們使用 TDengine 主要存儲以下三種類型的數(shù)據(jù)：

• 租戶設備上拋的原始數(shù)據(jù)。經(jīng)過實時計算處理后保存，租戶彼此之間數(shù)據(jù)隔離，一個租戶一個TDengine 庫
• 系統(tǒng)計算設備狀態(tài)變更的日志數(shù)據(jù)
• 系統(tǒng)中跟設備關聯(lián)的相關控制臺的操作日志數(shù)據(jù)

TDengine 在平臺中的總體架構圖如下所示：

相比于原架構，使用 TDengine 之后出現(xiàn)了以下變化：

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

2.1 TDengine 表結構設計

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

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

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

2.2 設備運行數(shù)據(jù)

設備運行數(shù)據(jù)以設備模型為超級表，該超級表命名規(guī)則為 pd_模型標志，例如：pd_devicemodel001，以設備參數(shù)為子表名。具體的建表語句如下：

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)) ;

如果需要創(chuàng)建的是單個參數(shù)的數(shù)據(jù)表，那子表命名規(guī)則是 pd_模型標志_參數(shù)標志，例如：pd_devicemodel001_param01。具體的建表語句如下：

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

2.3 設備狀態(tài)變更日志

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

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));

如果是單個設備一張子表的模式，子表命名規(guī)則為 dsl_模型標志_設備標志，例如：al_model01_device01。

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

2.4 設備信息變更日志

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

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));

單個設備一張子表情況下，子表命名規(guī)則為 dil_模型標志_設備標志，例如：al_model01_device01。

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

2.5 問題及解決

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

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

在我們跟濤思數(shù)據(jù)的技術專家進行相關溝通后，他們建議將 TDengine 升級到 2.2.2.0 的最新穩(wěn)定版本，該版本支持數(shù)據(jù)列的動態(tài)新增、修改。在溝通中還發(fā)現(xiàn)，上面問題中“建表報錯”一項是因為單條記錄數(shù)據(jù)超長了，按理說總長度不能超過 16KB，后面我們對字段長度進行了調整，問題隨即迎刃而解。

三、具體的效果展示

接下來為大家展示一下 TDengine 在壓縮率（存儲）、寫入、查詢等性能上的各種數(shù)據(jù)。

3.1 單機寫入性能

1）模擬 10 個廠區(qū)的數(shù)據(jù)、每個廠區(qū) 10000 個監(jiān)測點，每個監(jiān)測點從 2020-01-01 00:00:00.000 開始寫入模擬數(shù)據(jù)，記錄時間戳間隔 5 秒，每個測點寫入 100 萬條記錄

2）寫入的數(shù)據(jù)應當保持一致，生成方式為：將 10000 條真實采集的數(shù)據(jù)復制 100 份，時間戳按照 5 秒間隔自動生成，分別作為不同測點的數(shù)據(jù)寫入數(shù)據(jù)庫

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

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

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

3.2 時序數(shù)據(jù)庫壓縮比

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

2）落盤后數(shù)據(jù)文件大小（自帶緩存的時序庫需重啟服務保證數(shù)據(jù)文件落盤）；

3）計算壓縮比=落盤后數(shù)據(jù)文件大小/原始數(shù)據(jù)文件大??；

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

3.3 時序數(shù)據(jù)庫單測點原始歷史數(shù)據(jù)投影查詢性能

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

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

2）記錄以下內容：

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

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

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

3.4 時序數(shù)據(jù)庫單測點原始歷史數(shù)據(jù)聚合查詢性能

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

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）記錄以下內容：

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

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

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

目前我們已經(jīng)將 TDengine 應用在數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)邊緣計算、數(shù)據(jù)存儲等諸多方面，在實際業(yè)務中也展現(xiàn)出了如上所示的超強性能，特別是在處理超高頻的數(shù)據(jù)采集、邊緣智能計算框架、數(shù)據(jù)流引擎和數(shù)據(jù)模型等方面效果顯著，面對海量數(shù)據(jù)輕松實現(xiàn)實時全生命周期管理。

四、寫在最后

在本次項目中，TDengine Database 展現(xiàn)出了強大的讀寫性能和數(shù)據(jù)壓縮能力，聚合類查詢速度非?？?，也幫助我們有效降低了機器使用成本。超級表、子表、標簽等概念非常適配物聯(lián)網(wǎng)大數(shù)據(jù)應用場景，潛力無限。 未來希望TDengine發(fā)展能夠越來越好，期待周邊生態(tài)工具更加完善。

小T導讀：作為全球性的電氣產(chǎn)品和服務經(jīng)銷商，藍格賽于2000年進駐中國市場，一直致力于幫助中國更有效地使用能源。經(jīng)過20年的不斷壯大，如今藍格賽在中國國內電氣產(chǎn)品和服務經(jīng)銷商中已經(jīng)成為重要的市場參與者之一，通過6家業(yè)務實體、全國53個銷售網(wǎng)點服務工業(yè)、商業(yè)及樓宇客戶，為它們提供多樣化的工業(yè)自動化產(chǎn)品及解決方案。

本次項目為某市政供水水廠的數(shù)字化項目，數(shù)據(jù)來源于包括水泵、閥門、電表、液位計、流量計等多種設備近6000測點。該平臺需要實現(xiàn)以下功能：數(shù)據(jù)秒級采集，歷史數(shù)據(jù)留存3年，為上層應用提供數(shù)據(jù)支撐，包括所有測點的瞬時數(shù)據(jù)、聚合分析、數(shù)據(jù)報表等。值得注意的是，在本項目中聚合查詢的使用場景非常的多，頁面上圖表不論大小有上百張之多，因此聚合查詢的實現(xiàn)也是本項目的關鍵之處。

根據(jù)本項目特點，從整體架構的具體實現(xiàn)效果出發(fā)，我們對存儲技術提出了很高的要求，甚至可以說，存儲技術的選擇會直接影響項目后續(xù)的推進乃至成敗，這是一個決定平臺“脊梁”硬不硬的組件。考慮到這一問題，團隊在技術選型上著實花費了一些功夫，本次選型也相對更加慎重。

在選型過程中我們共調研了20多個開源存儲技術，從開源組織、授權協(xié)議、數(shù)據(jù)模型、社區(qū)成熟度、開發(fā)語言、組件依賴、性能、穩(wěn)定性、聚合友好、操作系統(tǒng)、集群支撐、副本策略等多個角度進行了對比，最終選擇了TDengine Database作為海量數(shù)據(jù)存儲引擎。

從7個優(yōu)點看選擇TDengine Database的原因

事實上，我們最初選擇的是單純以InfluxDB作為本次項目的核心存儲組件，不過這一設想在進行技術驗證時卻發(fā)現(xiàn)難以繼續(xù)推進。 主要原因是在技術驗證的過程中，我們發(fā)現(xiàn)了InfluxDB存在的幾個問題，其中最重要的兩個是：

• 首先，社區(qū)版本僅支持單節(jié)點。這個可以說是InfluxDB非常不友好的一個點了，多數(shù)項目采用的都是集群設計方案，如果數(shù)據(jù)只能在其中一個節(jié)點上存儲，浪費其他節(jié)點存儲空間不說，一旦所在節(jié)點出現(xiàn)故障，對整個項目的影響是災難級的。
• 其次，隨著數(shù)據(jù)量及存儲時長的提升，InfluxDB的聚合性能出現(xiàn)了巨大的瓶頸，我們在實際測試的時候，模擬了百萬測點近1年的數(shù)據(jù)，當聚合請求比較多的時候，基本上就很慢了，這點也對本項目影響很大。

由于以上兩個問題的存在，從架構實現(xiàn)的角度來講，我們必須對存儲技術進行重新選擇。恰好此時TDengine也開放了集群版本，偶然的契機下又聽到了陶老師對于時序數(shù)據(jù)的特點總結，感覺研究的非常深入，總結的也很全面。 后經(jīng)與團隊溝通，在技術選型調研時就一并把TDengine包含在了調研范圍之內。簡單嘗試之后，我們發(fā)現(xiàn)TDengine的數(shù)據(jù)模型真的非常適合工業(yè)場景，總結來說有以下幾個優(yōu)點。

優(yōu)點：

1. 社區(qū)版本支持集群：可以比較好的利用集群的存儲空間，數(shù)據(jù)也可以分散開來。
2. 聚合性能優(yōu)越：由于TDengine的數(shù)據(jù)模型特定及對集群的支撐，在模擬測試過程中，基本上沒有遇到聚合瓶頸。隨著數(shù)據(jù)量的增加及存儲時長的延長，聚合性能也非常穩(wěn)定。
3. 簡單易用：在工業(yè)場景中，組件低耦合是很必要的，TDengine開箱即用的特性很“香”，學習成本低，上手快速。
4. 數(shù)據(jù)模型優(yōu)秀：在工業(yè)場景中，設備及測點的增減非常的普遍，TDengine的超級表及子表的概念很好地解決了這個問題，單列模式的場景對本項目來說非常友好。
5. 查詢語義具有普適性：TDengine的查詢語句與InfluxDB非常接近，這點也非常好。
6. 版本升級簡單：卸載原有版本，安裝新版本即可，無需數(shù)據(jù)遷移。
7. 社區(qū)支持：普通的問題基本上都可以在issue上得到答復，遇到緊急問題的時候，濤思數(shù)據(jù)的同事甚至可以親自遠程解決，為他們點贊，在使用的時候放心不少。

10個看板頁面，近百個聚合請求

選型確定之后，我們就正式開始了搭建。搭載TDengine之后的架構圖如下所示：

采用該方案的很大一部分原因是InfluxDB和TDengine在查詢語義上的天然一致性。我們?yōu)門Dengine外層包裝了一層SDK，對應用層開放SDK，使應用層對存儲技術無感，在SDK內部通過查詢的時間跨度、組件健康程度等多個因素自動選擇查詢引擎，這樣可以保障其中一個技術在出現(xiàn)問題的時候，另一個技術隨時頂上來，大大降低了由于技術穩(wěn)定性所帶來的風險。

在數(shù)據(jù)處理的具體分工上，當前我們主要使用TDengine支持數(shù)據(jù)聚合的場景。在本次項目中，數(shù)據(jù)看板是功能的核心，同時也是用戶最看中的地方，而這部分的數(shù)據(jù)聚合基本上都依賴于TDengine——目前其共支持應用端約10個看板頁面，合計近百個聚合請求，是本項項目落地的關鍵。

TDengine Database在本項目中運行穩(wěn)定，為項目的具體功能實現(xiàn)提供了關鍵助力。未來，隨著TDengine技術的不斷成熟穩(wěn)定，團隊準備將其作為工業(yè)數(shù)據(jù)庫的存儲引擎運用在其他項目中。在接下來的產(chǎn)品線規(guī)劃上，TDengine也將作為首選的重要技術組件。

安徽三禾一信息科技有限公司（以下簡稱三禾一科技），專業(yè)從事大數(shù)據(jù)行業(yè)應用及工業(yè)互聯(lián)網(wǎng)解決方案，致力于攜手各行業(yè)客戶共同發(fā)現(xiàn)產(chǎn)業(yè)新價值。目前，三禾一科技自研的3H1高端裝備運維服務平臺已經(jīng)成功應用在高端裝備制造、汽車制造、環(huán)保設備、色選機械、水泥行業(yè)等領域。

高端成形裝備是國家的戰(zhàn)略性支柱產(chǎn)業(yè)，應用于汽車、石化、航空、航天、軍工、工程機械、家用電器等國民經(jīng)濟發(fā)展中的重要領域，是許多重大工程的基礎。當前，新一代信息技術的快速發(fā)展，使得高端成形裝備制造業(yè)正處于由數(shù)字化、網(wǎng)絡化向智能化發(fā)展的重要階段。

作為一個高端裝備運維服務平臺，3H1的底層物聯(lián)網(wǎng)數(shù)據(jù)庫要支持數(shù)百家企業(yè)、數(shù)十萬設備的接入，此前一直采用開源的InfluxDB，原因是在其單機版本基礎上可以擴展多實例分庫架構，但在使用過程中一些缺點也逐漸暴露，如硬件成本較高、維護難度較大，不便于橫向擴展。所幸后來遇到10倍高性能數(shù)據(jù)庫TDengine，經(jīng)多次試驗其各項指標均滿足業(yè)務需求，便一直使用至今。

為什么選擇TDengine？

在裝備行業(yè)物聯(lián)網(wǎng)場景下實時數(shù)據(jù)量巨大，包括溫度、壓力、振動、位移等眾多參數(shù)，針對這些參數(shù)如何進行分析和預警都是難點。這些需求概況如下：

• 高并發(fā)數(shù)據(jù)寫入，每條記錄都需要帶時間戳；
• 不同傳感器設備需要記錄的數(shù)據(jù)字段不同，希望能夠針對不同設備單獨建表；
• 原始數(shù)據(jù)存儲要求在5年以上，需要支持數(shù)據(jù)壓縮，以降低數(shù)據(jù)存儲成本；
• 支持國產(chǎn)化，支持數(shù)據(jù)庫廠商服務快速響應。

選用TDengine Database社區(qū)版2.2.1.1進行分布式模擬試驗，用到了3臺配置如下的服務器：

測試一：驗證時序數(shù)據(jù)庫產(chǎn)品3臺數(shù)據(jù)庫節(jié)點時序數(shù)據(jù)寫入性能

模擬2個廠區(qū)共10個車間的數(shù)據(jù)、每個車間1000個監(jiān)測點，每個監(jiān)測點從2017-07-14 10:40:00.000開始寫入模擬數(shù)據(jù)，記錄時間戳間隔0.001秒，每個測點寫入500000條記錄。

8線程寫入，在寫入超過50億條記錄后停止了寫入程序。本次測試對50億條數(shù)據(jù)記錄的寫入，平均寫入速度達到191萬條/秒。

測試二：驗證時序數(shù)據(jù)庫產(chǎn)品3臺數(shù)據(jù)庫節(jié)點時序數(shù)據(jù)壓縮能力

在測試一的基礎上，查看3臺數(shù)據(jù)庫節(jié)點實際文件大小，如下：

落盤后所有文件大小為36GB，

原始數(shù)據(jù)大小為5000000000*20/1024/1024/1024=93.13GB，

壓縮比為36 / 93.13 = 38.65%。

測試三：時序數(shù)據(jù)庫產(chǎn)品3臺數(shù)據(jù)庫節(jié)點對歷史時序數(shù)據(jù)按時間回溯查詢的性能

隨機選擇任一個測點，查詢該測點在某個時間段內的歷史數(shù)據(jù)，比如從2017-07-14 10:40:00.000 到 2017-07-14 10:40:10.000 10s內的共10001條數(shù)據(jù)記錄（數(shù)據(jù)輸出到文件）。

數(shù)據(jù)庫中對應查詢語句為：

  select * from d0 where ts >= ‘2017-07-14 10:40:00.000’ and ts <= ’2017-07-14 10:40:10.000’ >> /dev/null;   

通過試驗證，TDengine的寫入性能高、并發(fā)高、查詢時延極短；整體集群采用分布式架構，可靠性、穩(wěn)定性、數(shù)據(jù)完整性滿足項目需求。

在選型結果確定之后，我們便立刻對原有業(yè)務系統(tǒng)進行了升級改造，正式引入 TDengine。

TDengine在3H1上的落地實踐

3H1高端裝備運維服務平臺重點解決高端成形裝備企業(yè)由制造化向服務化轉型的關鍵問題，為企業(yè)提供工業(yè)互聯(lián)網(wǎng)與智能運維的整體解決方案。

平臺總體架構如圖1所示，其中，TDengine與高端成形裝備的智能數(shù)據(jù)采集終端模塊相連，助力采集終端完成對設備運行數(shù)據(jù)的采集，為系統(tǒng)提供設備數(shù)據(jù)基礎；工業(yè)云計算服務平臺提供系統(tǒng)數(shù)據(jù)的存儲、轉換、分析等，為系統(tǒng)提供業(yè)務數(shù)據(jù)支持；智能運維服務系統(tǒng)由裝備智能運維服務平臺和智能運維服務APP組成，分別為企業(yè)人員提供系統(tǒng)和移動端的服務支持。

針對企業(yè)多種應用場景，系統(tǒng)應用服務共分為六大功能模塊。

（1）企業(yè)駕駛艙：主要是服務于設備制造企業(yè)的管理者，方便了解平臺數(shù)據(jù)情況與關鍵業(yè)務流程的指標，從整體界面上可以很方便的了解到設備的售賣情況，企業(yè)接入的信息，平臺數(shù)據(jù)的采集情況。同時還可以對一些關鍵的業(yè)務流程，包括企業(yè)設備的監(jiān)控、報警信息的展示、維修效率的管理、設備的故障情況和三包任務的信息進行追蹤與管理，如圖2所示。

（2）設備資源管理：主要的目的是為了給每一個高端成形裝備建立電子檔案，以便了解設備歷史、當前情況，優(yōu)化設備運行，預測設備未來狀況，查看具體的設備信息時主要展示設備的四個維度——當前工況、健康分析、維修情況和歷史工況。

圖3所示的當前工況方便用戶了解設備的基本信息、關鍵指標和報警情況，還能夠提供設備當前情況的總覽。圖4所示為健康分析，其目的則是讓設備用戶更加深入地了解設備的當前狀況、設備的健康狀況隨著時間的變化情況，如果設備當前面臨故障風險，也能快速查找到引起風險的故障原因以及故障模塊。維修情況則是給了用戶設備維修信息的總覽和當前維修任務的流程跟蹤，如圖5所示。歷史工況則是為了進行故障模塊預排查，如圖6所示。

（3）維修服務管理：主要提供給維修服務部門人員所維修任務當前和歷史的效率分析。維修任務展示當前待處理的任務數(shù)量，比如待接單、待派單和待回訪，同時還可以對每個維修任務進行查看和操作，查看的內容具體到維修流程的每一個環(huán)節(jié)，如圖7所示。

維修效率分析則是對維修中的關鍵效率指標進行統(tǒng)計分析、近一年來的訂單量的變化情況、維修響應時間變化情況、故障類型分布、維修人員任務統(tǒng)計，方便維修管理人員對維修服務和效率進行管理，如圖8所示。

（4）設備健康分析：通過分析設備的歷史和當前設備信息來預測設備未來可能發(fā)生的故障，并且給出故障的可能性和類型，方便維修部門為用戶指定維保策略，主動聯(lián)系用戶，如圖9所示。

（5）三包服務管理：服務于三包部門，提供當前維?；顒犹嵝选⒃O備維?；顒佑涗?、設備維保到期預警等功能。

（6）備品備件管理：備品備件管理通過將與維修保養(yǎng)相關的備品備件也都建檔立案。用戶和各相關部門人員可以在移動端和系統(tǒng)端進行備品備件查詢申請審批等操作，較少不必要的工作流程，提高維修保養(yǎng)效率。同時通過數(shù)據(jù)分析來預測備品備件需求量，保證需求的同時減少企業(yè)的庫存成本。

在應用TDengine Database后，這六大功能模塊在使用效果上也獲得了顯著提升，不光體現(xiàn)在數(shù)據(jù)的寫入、查詢性能上，同時也體現(xiàn)在高效的壓縮效率上，真正實現(xiàn)了性能和成本平衡的最優(yōu)化。

未來規(guī)劃

目前，在搭載TDengine Database后，3H1原有業(yè)務系統(tǒng)在升級改造后獲得了極大的提升，不僅降低了研發(fā)和維護的成本，同時實現(xiàn)了橫向擴展。TDengine優(yōu)異的查詢性能給我們帶來了很大的驚喜，極高的壓縮效率，也給我們節(jié)省了大量的存儲資源。未來，我們也會嘗試在更多場景應用TDengine，加強與TDengine的深度合作。