雙匯大資料方案選型：從棘手的InfluxDB+Redis到毫秒級查詢的TDengine
雙匯發展多個分廠的能源管控大資料系統主要採用兩種技術棧：InfluxDB/Redis和Kafka/Redis/HBase/Flink，對於中小型研發團隊來講，無論是系統搭建，還是實施運維都非常棘手。經過對InfluxDB/Redis和TDengine大資料平臺的功能和效能對比測試，最終將TDengine作為實施方案。
1. 專案背景
基於雙匯發展對能源管控的需求，利用雲平臺技術以及電氣自動化處理手段，對雙匯發展的一級、二級、三級能源儀表進行整體改造，實現儀表組網，進一步通過邊緣閘道器進行能源線上監測資料的採集，並上報至雲平臺，建立統一能源管理資訊化系統，實現能源的實時監控、報表統計、能源流向分析與預測，降低企業單位產品能源消耗，提高經濟效益，最終實現企業能源精細化管理。
2. 總體架構
能源管控平臺基於私有云構建，包括完整的IaaS層、PaaS層和SaaS層，而能源採集系統作為管控平臺中最為重要的一環，採用TDengine作為核心資料引擎，通過Restful介面進行儀表線上資料插入，並實現大規模時序資料的高效穩定儲存，同時，也為能源管控應用層提供實時資料查詢、歷史聚合統計、流計算和訂閱服務等功能，實現能源地圖監控、能耗預警、能源流向預測和能源互聯綜合決策，具體架構如下圖所示。
圖1 能源採集系統架構
3. TDengine關鍵應用
3.1 Connector選擇
本專案資料採集最關鍵的環節，就是將訂閱到的MQTT資料插入到TDengine中，於是也就涉及到了TDengine聯結器的選擇，我們平時專案中java使用居多，而且JDBC的效能也相對較強，理論上，應該選擇JDBC API，但最終選擇了RESTful Connector，主要考慮以下幾點：
1）簡潔性
毫無疑問，RESTful通用性最強，TDengine直接通過HTTP POST 請求BODY中包含的SQL語句來操作資料庫，而且TDengine本身作為時序資料庫並不提供儲存過程或者事務機制，基本上都是每次執行單條SQL語句，所以RESTful在使用上很簡便。
2）可移植性
本專案的Java應用都是部署在Kubernetes中，所以向TDengine插入資料的Java應用需要容器化部署，而之前瞭解到，JDBC需要依賴的本地函式庫libtaos.so檔案，所以容器化部署可能較為麻煩，而RESTful僅需採用OKHttp庫即可實現，移植性較強。
3）資料規模
本專案數採規模不大，大約每分鐘7000條資料，甚至後續數採功能擴充套件到其他分廠，RESTful也完全滿足效能要求。
但總體來講，JDBC是在插入與查詢效能上具有一定優勢的，而且支援從firstEp和secondEp選擇有效節點進行連線（類似於Nginx的keepalive高可用），目前TDengine版本釋出情況上看，JDBC的維護與提升也是重中之重，後續專案也可能會向JDBC遷移。
3.2 RESTful程式碼實現
1）ThreadPoolExecutor執行緒池
訂閱EMQX和RESTful插入TDengine的程式碼寫在了同一個java服務中，每接收到一條MQTT訂閱訊息，便開啟一個執行緒向TDengine插入資料，執行緒均來自於執行緒池，初始化如下：
ExecutorService pool =newThreadPoolExecutor(150,300,1000,TimeUnit.MILLISECONDS,newArrayBlockingQueue<Runnable>(100),Executors.defaultThreadFactory(),newThreadPoolExecutor.DiscardOldestPolicy());
執行緒池採用基於陣列的先進先出佇列，採用丟棄早期任務的拒絕策略，因為本次場景中單次RESTful插入資料量大約在100~200條，執行速度快，遲遲未執行完極可能是SQL語句異常或連線taosd服務異常等原因，應該丟棄任務。核心執行緒數設為150，相對較高，主要為了保證高峰抗壓能力。
2）OKHttp執行緒池
在每個ThreadPoolExecutor執行緒中，基於OKHttp庫進行RESTful插入操作，也是採用ConnectionPool管理 HTTP 和 HTTP/2 連線的重用，以減少網路延遲，OKHttp重點配置如下：
publicConnectionPool pool(){returnnewConnectionPool(20,5,TimeUnit.MINUTES);}
即最大空閒連線數為20，每個連線最大空閒時間為5分鐘，每個OKHttp插入操作採用非同步呼叫方式，主要程式碼如下：
publicvoid excuteTdengineWithSqlAsync(String sql,Callback callback){try{okhttp3.MediaType mediaType = okhttp3.MediaType.parse("application/octet-stream");RequestBody body =RequestBody.create(mediaType, sql);Request request =newRequest.Builder().url(tdengineHost).post(body).addHeader("Authorization","Basic cm9vdDp0YW9zZGF0YQ==").addHeader("cache-control","no-cache").build();mOkHttpClient.newCall(request).enqueue(callback);}catch(Exception e){logger.error("執行tdengine操作報錯:"+ e.getMessage());}}
3）Java打包映象
長期壓力測試顯示，每秒執行200次RESTful插入請求，單次請求包含100條資料，每條資料包含5組標籤，Java服務記憶體穩定在300M~600M。而且上述模擬規模僅針對單個Java應用而言，在Kubernetes可以跑多個這樣pod來消費不同的MQTT主題，所以併發能力完全夠用。打包映象時，堆記憶體最大值設為1024MB，主要語句為：
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-XX:MaxRAM=2000m","-Xms1024m","-jar","/app.jar"]
3.3 效能測試
1）RESTful插入效能
按照3.2小節中的RESTful程式碼進行資料插入，Java程式和TDengine叢集均執行在私有云中，虛擬機器之間配備萬兆光纖交換機，Java程式具體如3.2小節所示，TDengine叢集部署在3個虛擬機器中，配置均為1TB硬碟、12核、12GB（私有云中CPU比較充裕，但記憶體比較緊張），經過大約三週的生產環境執行，效能總結如下：
表1 生產環境下RESTful插入效能測試
生產環境下，單條插入效能極高，完全滿足需求，當然前期也進行過稍大規模的插入場景模擬，主要是基於2.0.4.0以後的版本，注意到2.0.4.0之前的TDengine版本RESTful的SQL語句上限為64KB。模擬環境下，RESTful插入效能非常優秀，具體如下表所示。
表2 模擬環境下RESTful插入效能測試
2）RESTful查詢效能
使用RESTful進行SQL查詢時，效能也是非常好，目前真實生產環境中，資料總量為800萬，相對單薄，所以查詢效能測試在模擬環境下進行，在8億資料量下，LAST_ROW函式可以達到10ms響應速度，count、interval、group by等相關函式執行速度均在百毫秒量級上。
3.4 實施方案
本專案針對雙匯發展下屬的6個分廠（後續會繼續擴充）進行能源資料採集，大約1200多塊儀表（後續會繼續擴充），每塊儀表包括3至5個採集標籤，採集頻率均為1分鐘，資料接入規模不大。六個廠各自有獨立的租戶空間，為了方便各自的時序資料庫管理，同時也方便各廠間的聚合查詢（目前六個分廠均從屬雙匯發展總部），所以各分廠分別建立超級表，每個超級表包括4個tag，分別為廠編號、儀表級別、所屬工序和儀表編號，具體超級表建表情況如下圖所示。
主要用到的叢集包括TDengine叢集、EMQX叢集和Redis叢集，其中Redis叢集在資料採集方面，僅僅用於快取儀表連線狀態，其重點在於快取業務系統資料；EMQX叢集用於支撐MQTT資料的釋出與訂閱，部署在Kubernetes中，可以實現資源靈活擴充套件；TDengine叢集部署在IaaS虛擬機器中，支援大規模時序資料的儲存與查詢。
表3 叢集配置資訊
按照TDengine官方的建議，“一個數據採集點一張表，同一型別資料採集點一張超級表”，我針對不同分廠的水錶、電錶、蒸汽表和燃氣表分別建立的超級表，每個儀表單獨建表，保證每張表的時間戳嚴格遞增。在實踐TDengine的過程中，重點體會如下：
1）叢集搭建門檻低
TDengine叢集安裝部署非常便捷，尤其相比於其他叢集，僅需要簡單的配置就可以實現生產環境級的搭建，官方文件也比較豐富，社群活躍，也大為降低了後續運維成本。
2）插入與查詢效率極高
TDengine的插入與查詢效能極高，這點在實際執行時也深有感觸，用last_row函式查詢儀表最新資料，基本上可以達到毫秒級，在幾十億級的資料上進行聚合查詢操作，也可達到百毫秒級，極大提供了系統的響應速度。
3）全棧式時序處理引擎
在未使用TDengine之前，我們主要採用InfluxDB/Redis和Kafka/Redis/HBase/Flink兩種技術棧，對於我們中小型研發團隊來講，無論是系統搭建，還是實施運維都非常棘手。但是使用TDengine後，一切都簡化了，TDengine將資料庫、訊息佇列、快取、流式計算等功能融合一起，以一種全棧的方式，為我們的大資料系統帶來了便捷。技術方案的對比如表4所示。
注：方案一為InfluxDB/Redis，方案二為Kafka/Redis/HBase/Flink，方案三為TDengine
表4 資料採集方案對比
從表4的對比方案中可以看出，TDengine（方案三）是有著很大的優勢，尤其在開源EMQX Broker的支援上也非常好（主要依賴於Restful介面），其他的例如Kafka和InfluxDB只能和企業版EMQX整合；在資料插入和查詢效率方面，上述三種方案關鍵在於TDengine、HBase和InfluxDB的對比，官網有非常詳細的測試報告，TDengine也是有絕對優勢，這裡就不過多敘述。所以選擇TDengine是勢在必行的。
3.5 技術期望
在時序資料庫效能方面，TDengine有著很大的優勢，並且也集成了訊息訂閱和流計算功能，可以說在中小型物聯場景下，是無需部署Kafka和Flink的。當然個人理解TDengine不是為了完全取代Kafka和Flink而生的，尤其是在大型雲服務專案中，更多是共存。
但是在邊緣端，TDengine憑藉著極低的資源佔用率和優秀的時序處理效能，將會產生更大的能量，期望能徹底整合邊緣流計算和MQTT broker等功能，擴充Modbus、OPC-UA等常見工業協議支援，向下連線工業裝置或者物聯設施，向上和邊緣Kubernetes生態（如KubeEdge、K3S等）協同，或者直接和雲中心協同。
3.6 系統執行介面
專案重點是能耗統計，而線上採集到TDengine裡的資料都是累計量，所以在計算能耗時，需要在不同的超級表執行按表分組、按時間週期取樣的查詢，類似下面語法：
selectlast(累計列)as max_val,first(累計列)as min_val from[超級表名]where[標籤欄相關過濾]and ts>=now-10h INTERVAL(1h)groupby[儀表編號];
得益於TDengine的極佳效能，基本能保證不超過百毫秒的訪問延時，下面是一些相關的PC端、移動端介面（我們移動端是用H5做的，為了直接能跑在Android和iOS上）。
寫在最後
其實從2019年開始就一直在關注TDengine，也看了很多陶總的演講，受益匪淺，尤其在今年8月份，TDengine進行了叢集版開源，也正好準備啟動能源資料採集專案，所以果斷採用TDengine作為核心時序引擎，目前也是收穫了非常的效果。本次專案實施過程中，尤其感謝濤思資料的蘇曉慰工程師，多次協助解決TDengine相關的實施問題。計劃在後續其他專案也也會繼續推廣TDengine，同時也願意為一些商業版功能付費，支援國產，支援濤思。
作者介紹
於淼，學歷碩士，副研究員，主要從事MES系統研發以及智慧製造相關理論和標準研究，主要研究方向：數字工廠使能技術、製造執行系統關鍵技術和智慧製造標準體系等，參與國家級專案及企業專案十餘項，包括國家重點研發計劃以及國家智慧製造專項等。
雙匯發展多個分廠的能源管控大資料系統主要採用兩種技術棧：InfluxDB/Redis和Kafka/Redis/HBase/Flink，對於中小型研發團隊來講，無論是系統搭建，還是實施運維都非常棘手。經過對InfluxDB/Redis和TDengine大資料平臺的功能和效能對比測試，最終將TDengine作為實施方案。
### 專案背景基於雙匯發展對能源管控的需求，利用雲平臺技術以及電氣自動化處理手段，對雙匯發展的一級、二級、三級能源儀表進行整體改造，實現儀表組網，進一步通過邊緣閘道器進行能源線上監測資料的採集，並上報至雲平臺，建立統一能源管理資訊化系統，實現能源的實時監控、報表統計、能源流向分析與預測，降低企業單位產品能源消耗，提高經濟效益，最終實現企業能源精細化管理。
### 總體架構能源管控平臺基於私有云構建，包括完整的IaaS層、PaaS層和SaaS層，而能源採集系統作為管控平臺中最為重要的一環，採用TDengine作為核心資料引擎，通過Restful介面進行儀表線上資料插入，並實現大規模時序資料的高效穩定儲存，同時，也為能源管控應用層提供實時資料查詢、歷史聚合統計、流計算和訂閱服務等功能，實現能源地圖監控、能耗預警、能源流向預測和能源互聯綜合決策，具體架構如下圖所示。### TDengine關鍵應用#### Connector選擇
本專案資料採集最關鍵的環節，就是將訂閱到的MQTT資料插入到TDengine中，於是也就涉及到了TDengine聯結器的選擇，我們平時專案中java使用居多，而且JDBC的效能也相對較強，理論上，應該選擇JDBC API，但最終選擇了RESTful Connector，主要考慮以下幾點：
**1）簡潔性**
毫無疑問，RESTful通用性最強，TDengine直接通過HTTP POST 請求BODY中包含的SQL語句來操作資料庫，而且TDengine本身作為時序資料庫並不提供儲存過程或者事務機制，基本上都是每次執行單條SQL語句，所以RESTful在使用上很簡便。
**2）可移植性**
本專案的Java應用都是部署在Kubernetes中，所以向TDengine插入資料的Java應用需要容器化部署，而之前瞭解到，JDBC需要依賴的本地函式庫libtaos.so檔案，所以容器化部署可能較為麻煩，而RESTful僅需採用OKHttp庫即可實現，移植性較強。
**3）資料規模**
本專案數採規模不大，大約每分鐘7000條資料，甚至後續數採功能擴充套件到其他分廠，RESTful也完全滿足效能要求。
但總體來講，JDBC是在插入與查詢效能上具有一定優勢的，而且支援從firstEp和secondEp選擇有效節點進行連線（類似於Nginx的keepalive高可用），目前TDengine版本釋出情況上看，JDBC的維護與提升也是重中之重，後續專案也可能會向JDBC遷移。
#### RESTful程式碼實現
**1）ThreadPoolExecutor執行緒池**
訂閱EMQX和RESTful插入TDengine的程式碼寫在了同一個java服務中，每接收到一條MQTT訂閱訊息，便開啟一個執行緒向TDengine插入資料，執行緒均來自於執行緒池，初始化如下：
```ExecutorService pool = new ThreadPoolExecutor(150, 300, 1000, TimeUnit.MILLISECONDS, new ArrayBlockingQueue<Runnable>(100), Executors.defaultThreadFactory(),new ThreadPoolExecutor.DiscardOldestPolicy());```
執行緒池採用基於陣列的先進先出佇列，採用丟棄早期任務的拒絕策略，因為本次場景中單次RESTful插入資料量大約在100~200條，執行速度快，遲遲未執行完極可能是SQL語句異常或連線taosd服務異常等原因，應該丟棄任務。核心執行緒數設為150，相對較高，主要為了保證高峰抗壓能力。
**2）OKHttp執行緒池**
在每個ThreadPoolExecutor執行緒中，基於OKHttp庫進行RESTful插入操作，也是採用ConnectionPool管理 HTTP 和 HTTP/2 連線的重用，以減少網路延遲，OKHttp重點配置如下：
```public ConnectionPool pool() { return new ConnectionPool(20, 5, TimeUnit.MINUTES);}```
即最大空閒連線數為20，每個連線最大空閒時間為5分鐘，每個OKHttp插入操作採用非同步呼叫方式，主要程式碼如下：
```public void excuteTdengineWithSqlAsync(String sql,Callback callback) { try{ okhttp3.MediaType mediaType = okhttp3.MediaType.parse("application/octet-stream"); RequestBody body = RequestBody.create(mediaType, sql); Request request = new Request.Builder() .url(tdengineHost) .post(body) .addHeader("Authorization", "Basic cm9vdDp0YW9zZGF0YQ==") .addHeader("cache-control", "no-cache") .build(); mOkHttpClient.newCall(request).enqueue(callback); } catch (Exception e) { logger.error("執行tdengine操作報錯:"+ e.getMessage()); }}```
**3）Java打包映象**
長期壓力測試顯示，每秒執行200次RESTful插入請求，單次請求包含100條資料，每條資料包含5組標籤，Java服務記憶體穩定在300M~600M。而且上述模擬規模僅針對單個Java應用而言，在Kubernetes可以跑多個這樣pod來消費不同的MQTT主題，所以併發能力完全夠用。打包映象時，堆記憶體最大值設為1024MB，主要語句為：
```ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-XX:MaxRAM=2000m","-Xms1024m","-jar","/app.jar"]```
#### 效能測試
**1）RESTful插入效能**
按照3.2小節中的RESTful程式碼進行資料插入，Java程式和TDengine叢集均執行在私有云中，虛擬機器之間配備萬兆光纖交換機，Java程式具體如3.2小節所示，TDengine叢集部署在3個虛擬機器中，配置均為1TB硬碟、12核、12GB（私有云中CPU比較充裕，但記憶體比較緊張），經過大約三週的生產環境執行，效能總結如下：
表1 生產環境下RESTful插入效能測試| Insert 行數| Insert 語句位元組數 | 耗時/ms||--|--|--||5 | 282 |3||33 | 2,136 |5||70 | 3,240 |8||156 | 9,205 |12|
生產環境下，單條插入效能極高，完全滿足需求，當然前期也進行過稍大規模的插入場景模擬，主要是基於2.0.4.0以後的版本，注意到2.0.4.0之前的TDengine版本RESTful的SQL語句上限為64KB。模擬環境下，RESTful插入效能非常優秀，具體如下表所示。
表2 模擬環境下RESTful插入效能測試|Java 併發客戶端數量| Insert 行數| Insert 語句位元組數 | 耗時/ms||--|--|--|--||5 | 1萬 |600,000|260||5 | 2萬 |1,200,000|480||8 | 6萬 |3,600,000|700|
**2）RESTful查詢效能**
使用RESTful進行SQL查詢時，效能也是非常好，目前真實生產環境中，資料總量為800萬，相對單薄，所以查詢效能測試在模擬環境下進行，在8億資料量下，LAST_ROW函式可以達到10ms響應速度，count、interval、group by等相關函式執行速度均在百毫秒量級上。
#### 實施方案
本專案針對雙匯發展下屬的6個分廠（後續會繼續擴充）進行能源資料採集，大約1200多塊儀表（後續會繼續擴充），每塊儀表包括3至5個採集標籤，採集頻率均為1分鐘，資料接入規模不大。六個廠各自有獨立的租戶空間，為了方便各自的時序資料庫管理，同時也方便各廠間的聚合查詢（目前六個分廠均從屬雙匯發展總部），所以各分廠分別建立超級表，每個超級表包括4個tag，分別為廠編號、儀表級別、所屬工序和儀表編號，具體超級表建表情況如下圖所示。
主要用到的叢集包括TDengine叢集、EMQX叢集和Redis叢集，其中Redis叢集在資料採集方面，僅僅用於快取儀表連線狀態，其重點在於快取業務系統資料；EMQX叢集用於支撐MQTT資料的釋出與訂閱，部署在Kubernetes中，可以實現資源靈活擴充套件；TDengine叢集部署在IaaS虛擬機器中，支援大規模時序資料的儲存與查詢。
表3 叢集配置資訊|叢集名稱|部署規模|虛擬機器數量| 虛擬機器配置|--|--|--|--||TDengine|三節點分散式|3|CPU-12核 記憶體-12GB 儲存-1TB|EMQX|三節點分散式|3|CPU-8核 記憶體-12GB 儲存-500GB|Redis|一主兩從三哨兵|3|CPU-4核 記憶體-12GB 儲存-500GB
按照TDengine官方的建議，“一個數據採集點一張表，同一型別資料採集點一張超級表”，我針對不同分廠的水錶、電錶、蒸汽表和燃氣表分別建立的超級表，每個儀表單獨建表，保證每張表的時間戳嚴格遞增。在實踐TDengine的過程中，重點體會如下：
**1）叢集搭建門檻低**
TDengine叢集安裝部署非常便捷，尤其相比於其他叢集，僅需要簡單的配置就可以實現生產環境級的搭建，官方文件也比較豐富，社群活躍，也大為降低了後續運維成本。
**2）插入與查詢效率極高**
TDengine的插入與查詢效能極高，這點在實際執行時也深有感觸，用last_row函式查詢儀表最新資料，基本上可以達到毫秒級，在幾十億級的資料上進行聚合查詢操作，也可達到百毫秒級，極大提供了系統的響應速度。
**3）全棧式時序處理引擎**
在未使用TDengine之前，我們主要採用InfluxDB/Redis和Kafka/Redis/HBase/Flink兩種技術棧，對於我們中小型研發團隊來講，無論是系統搭建，還是實施運維都非常棘手。但是使用TDengine後，一切都簡化了，TDengine將資料庫、訊息佇列、快取、流式計算等功能融合一起，以一種全棧的方式，為我們的大資料系統帶來了便捷。技術方案的對比如表4所示。
注：方案一為InfluxDB/Redis，方案二為Kafka/Redis/HBase/Flink，方案三為TDengine
表4 資料採集方案對比|技術方案|說明|優點|缺點|--|--|--|--||方案一|實時資料存入Redis 歷史資料存入InfluxDB|部署易上手，社群成熟|1）InfluxDB查詢與插入效率不高，叢集版收費 2）無法直接整合開源版EMQX Broker|方案二|將採集資料釋出到Kafka，利用Flink將實時資料存入/Redis，歷史資料存入HBase|1）訊息吞吐量大 2）流計算功能豐富，生態成熟 3）叢集版開源|1）技術體系龐大，部署運維成本高 2）HBase插入效能可能無法滿足Kafka的吞吐量 3）無法直接整合開源版EMQX Broker|方案三|直接將採集資料存入TDengine|1）部署便捷，運維簡單 2）叢集版開源 3）訂閱功能和流計算功能完善 4）插入與查詢效率極高 5）資源佔用少 6）可與開源版EMQX Broker直接整合|暫時不支援時序資料的更新與刪除（後續會支援）
從表4的對比方案中可以看出，TDengine（方案三）是有著很大的優勢，尤其在開源EMQX Broker的支援上也非常好（主要依賴於Restful介面），其他的例如Kafka和InfluxDB只能和企業版EMQX整合；在資料插入和查詢效率方面，上述三種方案關鍵在於TDengine、HBase和InfluxDB的對比，官網有非常詳細的測試報告，TDengine也是有絕對優勢，這裡就不過多敘述。所以選擇TDengine是勢在必行的。
#### 技術期望
在時序資料庫效能方面，TDengine有著很大的優勢，並且也集成了訊息訂閱和流計算功能，可以說在中小型物聯場景下，是無需部署Kafka和Flink的。當然個人理解TDengine不是為了完全取代Kafka和Flink而生的，尤其是在大型雲服務專案中，更多是共存。
但是在邊緣端，TDengine憑藉著極低的資源佔用率和優秀的時序處理效能，將會產生更大的能量，期望能徹底整合邊緣流計算和MQTT broker等功能，擴充Modbus、OPC-UA等常見工業協議支援，向下連線工業裝置或者物聯設施，向上和邊緣Kubernetes生態（如KubeEdge、K3S等）協同，或者直接和雲中心協同。
#### 系統執行介面
專案重點是能耗統計，而線上採集到TDengine裡的資料都是累計量，所以在計算能耗時，需要在不同的超級表執行按表分組、按時間週期取樣的查詢，類似下面語法：```select last(累計列) as max_val,first(累計列) as min_val from [超級表名] where [標籤欄相關過濾] and ts>=now-10h INTERVAL(1h) group by [儀表編號] ;```得益於TDengine的極佳效能，基本能保證不超過百毫秒的訪問延時，下面是一些相關的PC端、移動端介面（我們移動端是用H5做的，為了直接能跑在Android和iOS上）。### 寫在最後其實從2019年開始就一直在關注TDengine，也看了很多陶總的演講，受益匪淺，尤其在今年8月份，TDengine進行了叢集版開源，也正好準備啟動能源資料採集專案，所以果斷採用TDengine作為核心時序引擎，目前也是收穫了非常的效果。本次專案實施過程中，尤其感謝濤思資料的蘇曉慰工程師，多次協助解決TDengine相關的實施問題。計劃在後續其他專案也也會繼續推廣TDengine，同時也願意為一些商業版功能付費，支援國產，支援濤思。
### 作者介紹於淼，學歷碩士，副研究員，主要從事MES系統研發以及智慧製造相關理論和標準研究，主要研究方向：數字工廠使能技術、製造執行系統關鍵技術和智慧製造標準體系等，參與國家級專案及企業專案十餘項，包括國家重點研發計劃以及國家智慧製造專項等。